Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
Date: Thu, 13 Oct 2005 10:30:30 +0200

> 
> Stefano,
> 
> Good points. I suppose I need to be convinced that a CS-type 
> protocol abstracted away from the details of the particular 
> radio resource management for a particular radio link type or 
> collection of radio link types has value. Using your SIP 
> example, SDP deals with the actual details of how to set up a 
> session, including codecs, bit rates, etc. Without SDP, SIP 
> wouldn't be worth much. I would think that kind of 
> information for radio resource management would need to be 
> included into any cross-techology CS-type protocol. Let me 
> hasten to add, that I don't think the task of defining this 
> is impossible, its just that I think it is a research issue, 
> because there are no existence proofs that it can be done, 
> and I typically am not in favor of starting IETF action 
> unless a problem is well-understood.
> 
> Maybe we should think about moving the ES/CS work to IRTF, 
> for example, in MOBOPTS? Once there has been some work on 
> defining some prototypes and there's a better idea of how it 
> might work, we could think about moving it back to MIPSHOP. 

Prototypes have been defined for a long time now an the problem well
enough understood even if as said, there might be some more tuning on
getting more precise on the sets of information that need to be
transported. What is needed on this issue is standardization not
MOBOPTS. Again couple 3GPP systems providers would like to extend their
coverage to broadband wireless systems and keep their management
facilities within the network. And a step to that is to have the
facilities to report some informations back to the network, which is not
native for some systems as 802 systems. I do not see any reason to
putting things to IRTF when there is evidence that it is required of the
industry. 

So far i can only see one voice asking not to include this item. 

> Perhaps this won't satisfy 802.21, since they seem to be 
> really interested in a standard, but I think it is really 
> premature to work on this in IETF before all the issues are 
> well understood.
> 
>             jak
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 12, 2005 10:38 AM
> Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> James,
> the aspects you list below need indeed to be considered. 
> However, those 
> aspects are part of the "logic" for controlling the handoff, not the 
> mechanism to enable a network element to control the handoff. 
> Neither IETF 
> nor IEEE should focus on the logic, since it is dependent on 
> a long list of 
> factors, like specific deployment scenarios and operator 
> policies. However, 
> IETF can work on the mechanisms to enable such scenarios.
> 
> Let me use an analogy. In commercials solutions using SIP and 
> mechanism to 
> control VoIP call setup, the decision of whether to allow a 
> certain call 
> setup by a certain user is based on user profile, policies, 
> network status, 
> etc. All aspects that IETF cannot and should not define 
> because they depend 
> heavily on deployment and operators choices (unless such 
> information need a 
> standardized transport in which case IETF can define the 
> transport, but not 
> the way such information is used to make decisions). However, 
> this did not 
> stop (and should have not stopped) IETF from developing SIP, i.e. the 
> mechanism to setup the calls. Similarly, even if IETF and 
> IEEE don't mingle 
> with e.g. the policies used to make such decision, that does 
> not exclude 
> that IETF can define the mechanisms to enable such scenarios.
> 
> Stefano
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of ext James Kempf
> > Sent: Wednesday, October 12, 2005 12:14
> > To: NJEDJOU Eric RD-RESA-REN
> > Cc: [email-masked]
> > Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter
> >
> >
> > A particular radio link protocol send commands for handoff
> > within that
> > system. Do you know of a way for the network to tell a
> > station to move to
> > WLAN using 3GPP RRC procedures? There is none.
> >
> > jak>> No, but any solution for how to do this must take into
> > consideration
> > things like the load on each system, the signal quality
> > between the mobile
> > and base stations that the mobile can see in both
> > technologies, avaliable
> > radio resources such as spreading codes, and possibly 
> operator policy
> > considerations, among other very radio protocol specific
> > issues. I cannot
> > see IEEE or IETF getting into these issues, since they
> > involve interactions
> > with the RAN control protocol, and that is not controlled by
> > IETF nor in
> > some cases IEEE.*
> >
> >         jak
> >
> > * IETF is currently working on a RAN protocol for 802.11
> > (CAPWAP) but that
> > is for just one radio protocol, though one of the goals of
> > the design is
> > that it could be extended to others. So it might be possible
> > to have CS work
> > with CAPWAP, but I can't see 3GPP adopting CAPWAP as their
> > nextgen RAN
> > protocol. The cellular SDOs typically want to keep close
> > control of the RAN
> > protocol, because it is pretty intimately tied into how
> > efficiently the
> > radio access network functions.
> >
> >
> >
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> >
> 
> 
> 

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Oct 2005 11:26:45 -0700

transported. 

jak>> Perhaps you can provide a reference to a publication?

        jak