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

From: [email-masked]
Date: Wed, 12 Oct 2005 12:38:27 -0500

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: Wed, 12 Oct 2005 13:48:58 -0700

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. 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