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

From: [email-masked]
Date: Tue, 11 Oct 2005 09:48:12 -0500

Eric,
just to make sure I understand you correctly, your point is that the charter should also include 802.21 MIES and MICS, correct?
Stefano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext NJEDJOU Eric RD-RESA-REN
> Sent: Tuesday, October 11, 2005 07:09
> To: [email-masked]; [email-masked]
> Subject: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> Hi folks,
> 
> Agree with couple previous mails that we are discussion solutions
> (CARD...)  without even having set the requirements for those.
> 
> Stephano has brought up a point here which is about having ES and CS
> within the charter of MIPSHOP. For that he gave a quite clear example
> scenario where those would be needed. I will stress that point here:
> 
> WISPs want to put inter-system mobility functions in their network
> deployment roadmaps. Some milestones in these roadmaps demand that the
> access systems have to be used as they are for the first generation of
> mobility management architectures. Therefore, as many WISPs would like
> the mobility management to be network initiated and controlled (to
> control the resources usage), they need to have Management entities in
> their networks. As acces systems are to be kept unchanged for first
> deployments, the most straitghtforward option is to exchange the
> Mobility Management signaling (event and command) on top of layer 3.
> Effectively, this is the only way forward because for example 
> Management
> facilities within 802.11 will be standardized long after first WISP
> deployments milestones.
> Example: the terminal experiences bad radio conditions on an .11 link,
> report that directly on top of IP to a management entity somewhere in
> the network. The entity takes into account other information 
> as operator
> policies, load conditions (not seen by terminal) to decide of the
> handoff to another link. OF COURSE, POLICIES ARE TO BE KEPT OUT OF
> SCOPE. Once the entity has run the selection algorithm, it needs to
> instrut the terminal of its target link. Today, an AP can not 
> relay that
> management decision (received by the entity in the network) to a
> station. This because .11 is not adapated for that, at least 
> as the 1999
> specification stands. Therefore, the management entity in the network
> has to find a way to relay the selection decision. And again the most
> straightforward way seems to use IP. 
> Hope that with these usage scenarios people will understand 
> and support
> the need to bring back ES and CS in the charter 
> 
> I will suggest that we have separate threads for each new item we want
> in the charter. Otherwise people are discussing every thing and
> confusing every other. 
> 
> Eric
> 
> _______________________________________________
> 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: "Hepworth, Eleanor" <[email-masked]>
Date: Wed, 12 Oct 2005 10:25:47 +0100

Hi,

A couple of thoughts on this:

My understanding is that IEEE 802.21 are working on defining information elements (be that information about the network characteristics, commands to handover, delivery of remote triggers) and require some way to transport this information from the source to the target.  It is this requirement for transport that IEEE 802.21 is requesting support for from the IETF.  

Therefore, I would quite like to see ES/CS use cases in MIPSHOP (in addition to IS) to allow us to identify whether there is any commonality between the transport requirements for the different MIH services.

It is important that we undertake this work in the IETF so we can ensure compatibility with current solutions, and (hopefully) develop solutions that have a wider applicability than just supporting 802.21 requirements.

Perhaps it may be a good idea to tweak the MIPSHOP charter so that it is less tightly bound to the problem structure that IEEE 802.21 has defined, and confine itself to analysing the requirements and solutions for the part of the signalling problem which is important to the IETF to develop solutions for?

Cheers,

Ele

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of NJEDJOU Eric 
> RD-RESA-REN
> Sent: 12 October 2005 09:18
> To: James Kempf
> Cc: [email-masked]
> Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> 
> James,
> 
> 
> > -----Message d'origine-----
> > De : James Kempf [mailto:[email-masked]]
> > Envoyé : mardi 11 octobre 2005 20:52
> > À : NJEDJOU Eric RD-RESA-REN; [email-masked]; 
> > [email-masked]
> > Objet : Re: [Mipshop] ES and CS within the MIPSHOP charter
> > 
> > Eric,
> > 
> > I would oppose putting ES and CS into the charter.
> 
> That's one view. I am not sure it represents the thinking of 
> the majority.
> 
> > 
> > ES has been discussed twice within IETF already, and both
> > times the approach of having a network-based signaling 
> > protocol for link events (which is what ES is) has been rejected:
> > 
> > - The DNA working group discussed ES and decided to confine
> > their work to link hints derived through APIs on the device.
> > 
> > - The Trigtran BOF met twice and was not able to overcome
> > some strong objections to using network-based link hints.
> > 
> The approaches you are refering to were not necessarily 
> linked to any real problem statement on network controlled 
> handovers. Today there is a problem to be solved for 
> deployments needs of Wireless Access Providers, that have 
> built strong and successfull network-based signalling models 
> on 3GPP that they want to extend to 802.11 and 802.16. 
> 
> Furthermore,
> DNA has nothing to do with the ES/CS transport problem that 
> is being raised. 
> 802.21 is bringing to maturity some considerations about 
> events and commands. The problem was not necessarily well 
> understood at he time of the TRIGTRAN Bof.  
> 
> > Bernard Abboba's draft on link hints:
> > 
> > 
> http://www.iab.org/documents/drafts/draft-iab-link-indications-03.txt
> > 
> > summarizes the IETF objections to network-based link indications.
> > 
> > Regarding CS, I have a difficult time seeing exactly how
> > these would be done independently from the particular radio 
> > link protocol.
> 
> 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.
> 
> > 
> > Finally, I think we are having enough trouble converging on a
> > shared consensus about what the WG should be doing for IS, 
> > that trying to also tackle ES and CS might be too big a job. 
> > I think we should get consensus on what we want to put into 
> > the charter for IS and actually complete the work first. 
> > Then, if people think they have some new ideas about 
> > overcoming the objections for ES, we can consider tackling that.
> 
> If some feel IS is important to be in the charter for their 
> applications, other thing EC/CS is for theirs and that just 
> represents the variety of interests of involved actors. As 
> far as i understand IETF operation, one does not decide what 
> is important or not for everyone SO again i call upon all 
> interested parties to voice their opinion on having ES/CS in 
> the charter 
> 
> > 
> >             jak
> > 
> > ----- Original Message -----
> > From: "NJEDJOU Eric RD-RESA-REN" <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>
> > Sent: Tuesday, October 11, 2005 5:08 AM
> > Management facilities within 802.11 will be standardized long after 
> > first WISP deployments milestones.
> > [email-masked] https://www1.ietf.org/mailman/listinfo/mipshop
> > 
> > 
> > 
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Oct 2005 10:13:34 -0700

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.

---

From: [email-masked]
Date: Wed, 12 Oct 2005 15:56:48 -0500

James,
I see your point. I tend to disagree with this being a research area and the problem not yet understood enough. The 802.21 community has been working on this for a while. Perhaps we should first discuss a bit more about ES and CS to see what scenarios we are actually talking about. As I mentioned in previous e-mails, I do agree that there is still a lot of discussion needed on ES and CS aspects before any decisions can be made wrt MIPSHOP charter.
Stefano

> From: ext James Kempf [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2005 15:49
> To: Faccin Stefano (Nokia-NRC/Dallas); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 
> 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
> 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 12, 2005 10:38 AM
> 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
> 
> > 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
> >
> >
> > within that

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Wed, 12 Oct 2005 21:20:59 -0400

Hi Charlie, 

Please find my inline replies. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Charles E. Perkins
Sent: Wednesday, October 12, 2005 12:35 PM
To: Petrescu Alexandru-AAP021
Cc: [email-masked]
Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter

Hello Alexandru,

I am hopelessly far behind on this discussion, but
I have to at least respond to this one passage:

Alexandru Petrescu wrote:

>                                I think it resumes
>the earlier ideas that are now in FMIP: triggered handover,
>network-controlled handover, inter-AR communication.  I think the
FMIPv6
>draft should be edited to acknowledge ideas and contributors of similar
>work, including CARD.
>  
>
No, those ideas did _not_ come from CARD. I was there.
I think a lot of people had the intention to make sure that there
was no _necessary_ relationship between FMIPv6 and CARD.

Ajoy-> The idea of information service protocol was introduced by CARD.
CARD does not setup any inter-AR tunnel, it just provides query/
response message to query handover related information. If I remember
correctly, in fact the idea of network controlled handoff, inter-AR
tunnel etc originally came from low latency handoff. Low latency handoff
was designed much before FMIPv6 protocol. 

I do think we may find in the future that other techniques for
identifying target routers may be of use with FMIPv6.

Ajoy-> I think the idea of getting capability information about
neighboring L2 and L3 point of attachment is key to seamless
heterogeneous handoff. 
I guess this one of the motivator of 802.21 IS protocol. 

Regards,
Charlie P.

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Wed, 12 Oct 2005 21:36:10 -0400

> ProxyRouterAdv was used for movement detection purpose only. 

This is so strong statement limiting the role of ProxyRouterAdv message.
The notable role of ProxyRouterAdv message is to configure NCoA by using
the
new network prefix.

Ajoy-> My intent was not to limit the role of ProxyRouterAdv. Rather I
meant to say that information service aspect of ProxyRouterAdv was not
there till CARD protocol was deigned.  

> The idea of ProxyRouter Adv and inter-AR tunnel came from low 
> latency handoff. 

Basically, tunnel in FMIPv6 does exist between the PAR and MN ,not
between
PAR and NAR by binding the PCoA and NCoA at PAR using FBU, 
even though optionally might configure inter-AR tunnel using HI/HAck.
I don't think default tunnel in FMIPv6 can be expressed as inter-AR
tunnel.

Ajoy-> Sure, again I did not talk about tunnel between PAR and MN. Sure
this is something FMIPv6 has introduced.

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Wed, 12 Oct 2005 23:40:02 -0400

Alex, 

Regards,
Ajoy 

That was probably not the intention.  I think the MIHEP BoF did not
actually even happen.  I imagine one of the intentions of the BoF was to
show not only that CARD is not enough for 802.21 but all other IETF
protocols are not enough for 802.21 so new protocols are needed.  Most
BoFs do just that, that's the main goal.

Ajoy-> Ok. 

> To me this is not a productive way to get thing done in any standard 
> forum.  We should always leverage from previous work so that we can 
> make meaningful progress. If we don't then we end up defining new 
> things that goes no where.

Ajoy, CARD is a good protocol.  It has EXPERIMENTAL status.  I think
many of its concepts have been discussed in SeaMoby.  I think it resumes
the earlier ideas that are now in FMIP: triggered handover,
network-controlled handover, inter-AR communication.  I think the FMIPv6
draft should be edited to acknowledge ideas and contributors of similar
work, including CARD.

Ajoy-> I think we should modularize the Fast Handoff protocols so that
it can be implemented efficiently along with other protocols. We should
also eliminate redundancy across various protocols. For that matter I do
see lots of value in dividing the entire fast handoff protocols scheme
into following three protocols: 

a. FMIPv6: Solely responsible for routing aspect of fast handoff. That
is to proactively and reactively set up routing for data forwarding. 
b. NED-CARD+: Protocol for information service for network selection.
This protocol will be used by mobile node to retrieve mobility related
information. 
c. CTP : Protocol for transferring context from one AR to other. This
means we will have to advance CTP to proposed standard. 

The idea of de-coupling various mobility related function would enable
re-use across different scenario. For example, context transfer and
Information service protocol can be re-used along with mobility
management protocol such as SIP, HIP, and NETLMM also.  

Would you say the same about e.g. NED?  Would you identify the positive
aspects of NED?

Ajoy-> Sure. NED is a good idea. The explicit de-coupling of message
encoding from transport is a good aspect of NED. Not only that I think
the NED contributor were also involved in CARD protocol design as WG
member and chair. James has contributed the security consideration
section of CARD. Lots of folks including have formally reviewed CARD and
provided feedback.  You can see the acknowledgement of CARD for that
matter.

---

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

James,

> jak>> No, but any solution for how to do this must take into 
> jak>> 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.*

No one for sure wants IETF to get into these issues. What is required of
IETF is to provide mechanisms at layer 3 and because there are
technologies as 802.11 that can not carry anything to the
infrastructure. In UMTS the RNC receives at RRC layers measurements from
the stations. These measurements can be used by an inter-system control
entity to decide of handoff to another system. But for that, the control
entity needs also local environment for other systems as .11. therefore
measurements and other events from other technologies also have to be
reported to the network. What is required of IETF is a transport for
those. 
It is not required of IETF to specify the mobility management procedures
here. 
> 
>         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. 
> 
> 
>

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 09:21:55 -0400

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. 

Ajoy-> I also see some problem in transporting events over existing
cellular radio link layer. This is based upon my observation of round
trip delay of 3G radio. Currently the round trip delay of existing 3G
cellular link is in order of several hundred milliseconds. So, it may
not be useful to send real time event over the cellular radio using L3
transport. Same can be said about ES as well. You do not want to send
network controlled handoff command that would take several hundred
milliseconds to execute. This beats the purpose of handoff command
specially for fast moving mobile devices. However, this may change as we
develop radio system with better round trip delay. So, 
IMHO, it makes to sense work on MOBOTS for sometime before standardizing
it in IETF. Please note that hard part of ES and CS is not necessarily
the transport or message encoding. This may be achieved with minor
modification to IS protocol. 

> Perhaps this won't satisfy 802.21, since they seem to be 
> premature to work on this in IETF before all the issues are 
> well understood.
> 
>             jak
> 
> > consideration
> > between the mobile
> > (CAPWAP) but that
> > control of the RAN

---

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

Ajoy,
The problem is not really for cellular radio link layer. For those, there are already functions within existing layers of the cellular radio interfaces to report measurements and events to the network. The design of these layers is adapted to report quickly varying events. Therefore I many not want to use IP for that side of my architecture but directly collect the information on control plane in the radio access network.

Eric

> De : Singh Ajoy-ASINGH1 [mailto:[email-masked]] 
> Envoyé : jeudi 13 octobre 2005 15:22
> À : NJEDJOU Eric RD-RESA-REN; James Kempf; [email-masked]
> Cc : [email-masked]
> Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter
> 
> 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. 
> 
> cellular radio link layer. This is based upon my observation 
> of round trip delay of 3G radio. Currently the round trip 
> delay of existing 3G cellular link is in order of several 
> hundred milliseconds. So, it may not be useful to send real 
> time event over the cellular radio using L3 transport. Same 
> can be said about ES as well. You do not want to send network 
> controlled handoff command that would take several hundred 
> milliseconds to execute. This beats the purpose of handoff 
> command specially for fast moving mobile devices. However, 
> this may change as we develop radio system with better round 
> trip delay. So, IMHO, it makes to sense work on MOBOTS for 
> sometime before standardizing it in IETF. Please note that 
> hard part of ES and CS is not necessarily the transport or 
> message encoding. This may be achieved with minor

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 09:35:26 -0400

Eric, 

Do you see need for a protocol between RNC and some other network entity then? It will help us if you explicitly suggest which protocol you want. I think you also agree over the air IP based ES and CS is a bad idea for 3G cellular. 

Regards,
Ajoy 

-----Original Message-----
From: NJEDJOU Eric RD-RESA-REN [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 8:34 AM
To: Singh Ajoy-ASINGH1; James Kempf; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Eric

---

From: [email-masked]
Date: Thu, 13 Oct 2005 09:48:44 -0500

Ajoy,
The new (IS, ES and CS) services we are dicussing here involves multiple link technologies. We are not using ES and CS over IP for handovers within 3G networks, for that 3G SDO have already done work, which is what Eric is stating. 

Regards,
Srini

>[mailto:[email-masked]] On Behalf Of ext Singh Ajoy-ASINGH1
>Sent: Thursday, October 13, 2005 8:35 AM
>To: NJEDJOU Eric RD-RESA-REN; James Kempf; Faccin Stefano 
>(Nokia-NRC/Dallas)
>Cc: [email-masked]
>Do you see need for a protocol between RNC and some other 
>network entity then? It will help us if you explicitly suggest 
>which protocol you want. I think you also agree over the air 
>IP based ES and CS is a bad idea for 3G cellular. 
>
>Regards,
>Ajoy 
>
>The problem is not really for cellular radio link layer. For 
>those, there are already functions within existing layers of 
>the cellular radio interfaces to report measurements and 
>events to the network. The design of these layers is adapted 
>to report quickly varying events. Therefore I many not want to 
>use IP for that side of my architecture but directly collect 
>the information on control plane in the radio access network.
>
>Eric
>
>> De : Singh Ajoy-ASINGH1 [mailto:[email-masked]] Envoyé : jeudi 
>> 13 octobre 2005 15:22 À : NJEDJOU Eric RD-RESA-REN; James Kempf; 
>> [email-masked] Cc : [email-masked] Objet : RE: [Mipshop] 
>> ES and CS within the MIPSHOP charter
>> 
>> MOBOPTS. Again couple 3GPP systems providers would like to extend 
>> their coverage to broadband wireless systems and keep their 
>management 
>> 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.
>> 
>of round 
>> specially for fast moving mobile devices. However, this may 
>change as 
>> we develop radio system with better round trip delay. So, IMHO, it 
>> makes to sense work on MOBOTS for sometime before 
>standardizing it in 
>> IETF. Please note that hard part of ES and CS is not necessarily the 
>> transport or message encoding. This may be achieved with minor 
>> > 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 
>> > 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.
>> > 
>> > 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
>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
>> > 
>[mailto:[email-masked]]On
>> > > 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.
>> > >
>> > > 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
>> > >
>> > > 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.
>> > >
>> > >
>> > >

---

From: [email-masked]
Date: Thu, 13 Oct 2005 09:53:39 -0500

>You do not want to send network 
>command specially for fast moving mobile devices.

Ajoy,

Can you state where you have seen this requirement? Even if there was
one, do have prototypes or hard data to show that it does not work?  I
will be very interested to see it.

Regards,
Srini

>Sent: Thursday, October 13, 2005 8:22 AM
>problem well enough understood even if as said, there might be 
>some more tuning on getting more precise on the sets of 
>message encoding. This may be achieved with minor modification 
>to IS protocol. 
>
>
>> > issues. I cannot

---

From: "Gupta, Vivek G" <[email-masked]>
Date: Thu, 13 Oct 2005 08:13:13 -0700

If it is not 3G networks, then what are the primary candidate networks
for using ES and CS services over IP?

BR,
-Vivek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, October 13, 2005 7:49 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,
The new (IS, ES and CS) services we are dicussing here involves multiple
link technologies. We are not using ES and CS over IP for handovers
within 3G networks, for that 3G SDO have already done work, which is
what Eric is stating. 

Regards,
Srini

---

From: [email-masked]
Date: Thu, 13 Oct 2005 10:27:30 -0500

Vivek,
We are not using IS/ES/CS to aid intra-technology 3G handovers because
all the signaling and associated parameters are clearly defined in the
3G protocols. When the multi-access terminal needs to send or receive
information about other link technologies in its vicinity, that's when
we use these services. BTW, the same mechansims can also be used for
handovers from 802.16, 802.11 etc.

Let's separate the discussion of L2 vs L3 here. We need both at the
standards track and deployment can use just one or perhaps both.

Regards,
Srini

>From: ext Gupta, Vivek G [mailto:[email-masked]] 
>Sent: Thursday, October 13, 2005 10:13 AM
>To: Sreemanthula Srinivas (Nokia-NRC/Dallas); 
>[email-masked]; [email-masked]; 
>[email-masked]; Faccin Stefano (Nokia-NRC/Dallas)
>Cc: [email-masked]
>If it is not 3G networks, then what are the primary candidate 
>networks for using ES and CS services over IP?
>
>BR,
>-Vivek
>
>
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>The new (IS, ES and CS) services we are dicussing here 
>involves multiple link technologies. We are not using ES and 
>CS over IP for handovers within 3G networks, for that 3G SDO 
>have already done work, which is what Eric is stating. 
>
>Regards,
>Srini
>

---

From: "Gupta, Vivek G" <[email-masked]>
Date: Thu, 13 Oct 2005 08:45:09 -0700

Srini,

802.21 mostly means inter-technology handovers to me and so in no way am
I referring to intra-technology handovers. Many of us already believe in
and are working towards a L2 transport specifically for 802.11 and
802.16 networks.
If the primary networks for ES and CS services over IP are 802 networks
(.11 and .16), then it would at least be worthwhile to do a pros and
cons between L2 and L3 choices and come up with some clear articulation
as to when/why one is preferable over the another.

One of the earlier argument for L3 support in this case was that L2 PoAs
(such as APs and BSs) may take a while to be updated with new changes
and that L3 may speed up initial deployment. Even if that is true
(somehow...) would still be worthwhile to answer the above question.

BR,
-Vivek

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 8:28 AM
To: Gupta, Vivek G; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Vivek,

Regards,
Srini

---

From: [email-masked]
Date: Thu, 13 Oct 2005 10:56:08 -0500

Vivek,
This is exactly what I wanted to avoid on the IETF mailing list. IMHO,
we need L3. That's why we are here. As I said earlier, having L3 does
not preclude L2 facilities and may well be useful for IEEE based
wireless systems.

Regards,
Srini

>Sent: Thursday, October 13, 2005 10:45 AM
>802.21 mostly means inter-technology handovers to me and so in 
>no way am I referring to intra-technology handovers. Many of 
>us already believe in and are working towards a L2 transport 
>specifically for 802.11 and
>802.16 networks.
>(.11 and .16), then it would at least be worthwhile to do a 
>pros and cons between L2 and L3 choices and come up with some 
>clear articulation as to when/why one is preferable over the another.
>
>One of the earlier argument for L3 support in this case was 
>that L2 PoAs (such as APs and BSs) may take a while to be 
>updated with new changes and that L3 may speed up initial 
>deployment. Even if that is true
>We are not using IS/ES/CS to aid intra-technology 3G handovers 
>because all the signaling and associated parameters are 
>clearly defined in the 3G protocols. When the multi-access 
>terminal needs to send or receive information about other link 
>technologies in its vicinity, that's when we use these 
>services. BTW, the same mechansims can also be used for 
>Let's separate the discussion of L2 vs L3 here. We need both 
>at the standards track and deployment can use just one or perhaps both.
>
>Regards,
>Srini
>
>>To: Sreemanthula Srinivas (Nokia-NRC/Dallas); [email-masked]; 
>>[email-masked]; [email-masked]; Faccin 
>>Stefano (Nokia-NRC/Dallas)
>>Cc: [email-masked]
>>The new (IS, ES and CS) services we are dicussing here involves 
>>multiple link technologies. We are not using ES and CS over IP for 
>>handovers within 3G networks, for that 3G SDO have already done work, 
>>which is what Eric is stating.
>>
>>Regards,
>>Srini
>>
>

---

From: [email-masked]
Date: Thu, 13 Oct 2005 11:15:22 -0500

Hi,
one additional aspect to consider is that the handoff controlled by the
entwork may not need to be extremely fast. there are two reasons to
handoff: (1) degradation of link, (2) "opportunistic" handoff (i.e. due
to a set of events and based on specific policies, it is preferrable to
move the communication to another link). I agree that if we try to
support inter-technology network-controlled handoffs for case (1) above,
delay in performing handoff is an issues. However, if we target (2)
above, the delay of performing handoff is less significant, since the
mobile node is not having any degradation over the current link, the
handoff will be performed because the network has policies indicating
that it is preferrable to move to the new link. An example is load
sharing.
Stefano

> From: Sreemanthula Srinivas (Nokia-NRC/Dallas) 
> Sent: Thursday, October 13, 2005 09:54
> To: ext Singh Ajoy-ASINGH1; NJEDJOU Eric RD-RESA-REN; James Kempf;
> Faccin Stefano (Nokia-NRC/Dallas)
> Cc: [email-masked]
> Can you state where you have seen this requirement? Even if 
> there was one, do have prototypes or hard data to show that 
> it does not work?  I will be very interested to see it.
> 
> Regards,
> Srini
> 
>

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 12:16:29 -0400

Srini, 

I agree that 802.21 is not proposing ES, CS for intra-technology handoff. 
But even in inter-technology handover sending event/command over IP layer over 3G radio will have face problem. However, if you are discussing some protocol between RNC and MIH handoff controller then that is a different point. 

Regards,
Ajoy  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 9:49 AM
To: Singh Ajoy-ASINGH1; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Regards,
Srini

---

From: "zze-Seamless PERESSE M ext RD-RESA-REN" <[email-masked]>
Date: Thu, 13 Oct 2005 18:16:48 +0200

Hi all,

Here is a start:

ES & CS @ L2:

Pro: 
- ES and CS will be embedded in L2 standards, such as the required software could be included in a chip, which will result in less overhead on the UE's OS.
- Broadcast capability inherent to the access technology could help (for discovery,...)...

Cons: 
- the transport of ES and CS messages can only take place within an access network (i.e. ES & CS messages do not pass through routers)
- non 802.21 compliant devices will not be able to have MIH support.

ES & CS L3: 

Pro: 
- This is an easy way to quicly provide a generic way of transporting ES & CS, without waiting for L2 standards modifications.
- The ES & CS messages can pass through routers, which is required if we have a controlling entity (that will be interested in ES and CS messages!) in a core network.

Cons: 
- This will introduce more processing for the UE OS and the PoA OS.
- IP Connectivity must be in place to be able to transmit and receive ES and CS messages...

I guess the two solution are complementary, ideally,  L2 could be used to exchange ES and CS messages between the UE and the PoA, and L3 could be used to
Exchange messages between the PoA and a Mobility Management Entity in the network.
But during a (possibly long?) transition phase (L2 ES and CS not available in every equipment/technologies), L3 could be used in the access network as well...

Regards,

Mat

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Gupta, Vivek G
Envoyé : jeudi 13 octobre 2005 17:45
À : [email-masked]; [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Srini,

802.21 mostly means inter-technology handovers to me and so in no way am I referring to intra-technology handovers. Many of us already believe in and are working towards a L2 transport specifically for 802.11 and
802.16 networks.
If the primary networks for ES and CS services over IP are 802 networks
(.11 and .16), then it would at least be worthwhile to do a pros and cons between L2 and L3 choices and come up with some clear articulation as to when/why one is preferable over the another.

One of the earlier argument for L3 support in this case was that L2 PoAs (such as APs and BSs) may take a while to be updated with new changes and that L3 may speed up initial deployment. Even if that is true
(somehow...) would still be worthwhile to answer the above question.

BR,
-Vivek

-----Original Message-----
To: Gupta, Vivek G; [email-masked]; [email-masked]; [email-masked]; [email-masked]

Vivek,
We are not using IS/ES/CS to aid intra-technology 3G handovers because all the signaling and associated parameters are clearly defined in the 3G protocols. When the multi-access terminal needs to send or receive information about other link technologies in its vicinity, that's when we use these services. BTW, the same mechansims can also be used for handovers from 802.16, 802.11 etc.

Let's separate the discussion of L2 vs L3 here. We need both at the standards track and deployment can use just one or perhaps both.

Regards,
Srini

---

From: "Gupta, Vivek G" <[email-masked]>
Date: Thu, 13 Oct 2005 09:19:37 -0700

Steano,

Thanx for this clarification. I am fine with this.
In fact as we have discussed this many times before, L3 may be the only
way of affecting such handovers in a pragmatic manner.
-Vivek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 9:00 AM
To: Gupta, Vivek G; [email-masked];
[email-masked]

Vivek,
perhaps there is a bit of confusion here. What we're saying is that if
you want to deploy 802.21 in a network that has both 3G access and e.g.
802.11, you need the L3 solution because it is not realistic to expect
that 3GPP will modify their L2 to implement 802.21 concepts. 3GPP has
clear requirements for the inter-access handoff stating that no changes
to 3G access interface shall be made. Therefore, when you put together
3G and 802.xx you need the L3 solution.
Stefano

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 12:33:28 -0400

Hi Mat, 

I also agree that layer 3 solution is independent of specific link layer technology. There is no doubt about that. But my question was regarding feasibility of sending ES and CS over IP layer connection from network to mobile node over 3G cellular network. I have not heard any convincing arguments about its feasibility. I will repeat that I do see some value in defining a transport protocol between RNC and some other network entity in cellular for network controlled handoff. 

Regards,
Ajoy 

-----Original Message-----
From: zze-Seamless PERESSE M ext RD-RESA-REN [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 11:17 AM
To: Gupta, Vivek G; [email-masked]; Singh Ajoy-ASINGH1; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Hi all,

Here is a start:

ES & CS @ L2:

Pro: 

Cons: 

ES & CS L3: 

Pro: 

Cons: 

Regards,

Mat

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Gupta, Vivek G
Envoyé : jeudi 13 octobre 2005 17:45
À : [email-masked]; [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Srini,

BR,
-Vivek

-----Original Message-----

Vivek,

Regards,
Srini

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 12:44:35 -0400

Good point! But I am under impression that cellular system already
provides some mechanism to send load related information to mobile node.
Please correct me as I am not too sure. I will have to double check 3GPP
RRC spec. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 11:15 AM
To: [email-masked]; Singh Ajoy-ASINGH1;
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Hi,

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 12:57:48 -0400

by past history i'm referring to the endless exchanges between CARD,
FMIP's provision 
for info exchange, NED, 802.21, etc (any others?).Judging from past
history of those exchanges, I do not at all expect any convergence to
occur. 

Ajoy-> OK 

I do not wish for more endless exchanges in MIPSHOP, so I'd rather
try something more structured.

Ajoy->OK 

-gabriel

--- Singh Ajoy-ASINGH1 <[email-masked]> wrote:

> Hi Gabriel, 
> 
> I am not sure if selection of winner and looser is a good idea here. I
> do not know which past history you are referring to you. Are your
> referring to 
> SeaMoby WG. If yes, then I would like to cite example of IP Paging. IP
> paging work was killed even though it went through proper evaluation.
> IMHO, I think it is always better idea to converge. 
> 
> Regards,
> Ajoy 
> 
> Behalf Of gabriel montenegro
> Sent: Wednesday, October 12, 2005 2:27 AM
> To: Petrescu Alexandru-AAP021; James Kempf
> Cc: [email-masked]
> It seems to me like in this particular case, and given the past
history,
> we'd be better off *not* trying to converge and just doing an
> evaluation,
> declare one winner, and be done with it. I note that in addition to
the
> other examples, MIDCOM also did this. I've actually been thinking that
> this is perhaps another item to add, but I'd rather do a quick
recharter
> just for the evaluation draft when (and if) it does appear to be 
> necessary. 
> 
> Also, Alex you mention that having at least two interoperable
> implementations
> is a pre-requisite before sending anything to the IESG. Someone on
this
> list is
> bound to have the facts at hand, but I was under the impression that
> whereas that's
> true of the routing area, it is not necessarily true in the INT area.
Of
> course,
> it's good to have. Now, to progress to Draft standard, it is a
> requirement (rfc1264).
> 
> -gabriel
> 
> --- Alexandru Petrescu <[email-masked]> wrote:
> 
> > James Kempf wrote:
> > > Alex,
> > > 
> > > CAPWAP did, in fact, pick winners and losers. Sometimes, this is 
> > > unavoidable, especially when the various proposals involve very 
> > > different architectural approaches. This was partially the case in

> > > CAPWAP.
> > 
> > James, thanks for pointing to that, and for the description - good
to
> > know.  So I went on and skimmed through
draft-ietf-capwap-eval-00.txt.
> > It's interesting to see the four Member Statements in the Evaluation
> > Team similar declarations of intent of the IEEE/ACM Candidates I
> receive
> > for voting.  Where's 'rough consensus'?
> > 
> > Then I checked the IESG Queue for CAPWAP.  Only two INFORMATIONAL
> RFCs.
> >  And a set of personal I-Ds submitted with no intended status and
not
> > assigned to any shepherding AD.  It's true that things may change in
> the
> > near future, since the 'winner/looser' decision is relatively
recent.
> > 
> > But I am wondering whether 'Evaluation Team' seemingly used by
CAPWAP
> is
> > a recommended practice.  RFC 2418 'IETF Working Group Guidelines and
> > Procedures' recommends 'Design Teams' not 'Evaluation Teams'.
> > 
> > Further browsing RFCs I found that 'Evaluation Teams' were used
> > for selecting other protocols too, e.g. RFC3127 on AAA and 3955 on
> > IPFIX.  RFC3127 recommended Diameter for AAA (against SNMP, Radius++
> and
> > COPS).  Diameter is a PS RFC.  All three others are PS RFCs too, and
> > being updated for other than AAA purposes.
> > 
> > RFC3955 on IPFIX recommended NetFlow against Diameter (and others).
> > There's no IPFIX RFC PS yet.  The IESG Queue indicates two IPFIX
> > INFORMATIONAL RFCs and a protocol draft version 19, presumably based
> on
> > NetFlow, but not assigned yet.  There's however a Cisco
INFORMATIONAL
> > RFC on NetFlow.
> > 
> > > Personally, I am very much in favor of design teams and
> collaborative
> > >  work when there are competing proposals, since this seems to me
to
> > > be more in the spirit of IETF, and I've had most success with that
> in
> > > the past.
> > 
> > >From the standpoint of IETF I think DTs are probably more
successful
> at
> > converging that ETs are.
> > Alex

---

From: [email-masked]
Date: Thu, 13 Oct 2005 12:05:39 -0500

Ajoy,

> Hi Mat, 
> 
> I also agree that layer 3 solution is independent of specific 
> link layer technology. There is no doubt about that. But my 
> question was regarding feasibility of sending ES and CS over 
> IP layer connection from network to mobile node over 3G 
> cellular network. I have not heard any convincing arguments 
> about its feasibility. 
Given my comment in the other e-mail about "opportunistic handoff", let me make an analogy. Why would there be a difference between exchanging an ES/CS message over L3 between the mobile node and a network node, and exchanging SIP signalling between the mobile node and a SIP server over IP?
Stefano

---

From: [email-masked]
Date: Thu, 13 Oct 2005 12:02:40 -0500

The current mechanisms would not allow the network to command the mobile node to move to another link layer technology, nor will allow to provide the type of information that may be needed for the handoff. The current mechanisms would mainly allow the mobile node to make its own decision on the handoff, but not to allow the network to force any handoff.
Stefano

> From: ext Singh Ajoy-ASINGH1 [mailto:[email-masked]]
> Sent: Thursday, October 13, 2005 11:45
> To: Faccin Stefano (Nokia-NRC/Dallas); Sreemanthula Srinivas
> (Nokia-NRC/Dallas); [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 13:25:01 -0400

Hi Stefano, 

I think both of us are talking two different things here. I was
referring to possibility of receiving load using existing RRC protocol
whereas you are suggesting that current cellular does not provide
network controlled inter-technology handoff. Is it right? I have few
points, but I will till I hear from you. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 12:03 PM
To: Singh Ajoy-ASINGH1; [email-masked];

The current mechanisms would not allow the network to command the mobile
node to move to another link layer technology, nor will allow to provide
the type of information that may be needed for the handoff. The current
mechanisms would mainly allow the mobile node to make its own decision
on the handoff, but not to allow the network to force any handoff.
Stefano

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 13 Oct 2005 13:41:31 -0400

Hi Rajeev, 

Sorry for confusion. Please few inline replies. 

Regards,
Ajoy 

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 12:20 PM
To: Singh Ajoy-ASINGH1
Cc: Petrescu Alexandru-AAP021; [email-masked]; James Kempf
Subject: Re: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Singh Ajoy-ASINGH1 wrote:
> 
> hmm.. This is wrong both historically and in terms of roles. FMIPv6 
> started late 2000/early 2001 and the proxy messages, HI/HAck, 
> network-controlled handovers have been around since then.
> 
> There was no CARD then.
> 
> Ajoy-> CARD introduced the idea of information service. Information
> exchange was not part of FMIPv6 from the beginning and still I do not
> believe FMIPv6 supports any information service like CARD.  Also,
> inter-AR information query was introduced by CARD. 

which part of my response talked about "Information Service"?

Ajoy-> There were few email exchange suggesting that information service
is also supported by FMIPv6. I am NOT suggesting that you created such
perception. Somehow such perception was created. Just see recent email
from Gabriel. He also has similar perception from earlier email
discussion. 
Good that you clarified this, btw. Thanks for your clarification btw. 

> 
> ProxyRouterAdv was used for movement detection purpose only. The idea
of
> ProxyRouter Adv and inter-AR tunnel came from low latency handoff. Low
> latency handoff was designed around 98 much before FMIPv6. 

Thank you for (yet another) monday morning quarter-backing.

Ajoy-> Please ignore this. This is not important for current discussion.

-Rajeev

---

From: [email-masked]
Date: Thu, 13 Oct 2005 15:00:36 -0500

I will get back to you with a reference ASAP.
Stefano

> From: ext Takashi Aramaki [mailto:[email-masked]]
> Sent: Thursday, October 13, 2005 11:26
> To: Faccin Stefano (Nokia-NRC/Dallas)
> Cc: [email-masked]; Sreemanthula Srinivas (Nokia-NRC/Dallas);
> [email-masked]; [email-masked]
> Would you happen to have reference to the 3GPP requirements which
> states no changes are required for inter-access handoff?  I think that
> will be beneficial for the WG to understand necessity of L3 solution.
> 
> Cheers,
> Takashi
> 
> 
> On Thu, 13 Oct 2005 11:00:17 -0500,
>    [email-masked] wrote:
> > Vivek,
> > perhaps there is a bit of confusion here. What we're saying 
> is that if you want to deploy 802.21 in a network that has 
> both 3G access and e.g. 802.11, you need the L3 solution 
> because it is not realistic to expect that 3GPP will modify 
> their L2 to implement 802.21 concepts. 3GPP has clear 
> requirements for the inter-access handoff stating that no 
> changes to 3G access interface shall be made. Therefore, when 
> you put together 3G and 802.xx you need the L3 solution.
> > Stefano
> > 
> > > Sent: Thursday, October 13, 2005 10:45
> [email-masked];
> > > that L2 PoAs

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 14 Oct 2005 11:26:14 -0400

Hi Srini, 

Sorry for late response. Please find my inline response. 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, October 13, 2005 9:54 AM
To: Singh Ajoy-ASINGH1; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Can you state where you have seen this requirement? 
Even if there was one, do have prototypes or hard data to show that it
does not work?  I will be very interested to see it.

Ajoy-> This requirement is coming from current experience of cellular
hard handoff. Handoff command of cellular hard handoff does not take
several hundred milliseconds to reach MN from RNC. Here we are talking
to introduce some new concept that will require some better
understanding before we can claim that this will work. That is why I am
little skeptical to include this part of IETF charter at this time. But
as 802.21 will make progress, we may find out that this is an unfounded
concern. At that time we can include this as part of MIPSHOP charter.
Honestly there is no reason to rush on such controversial topic. 

Regards,
Srini

---

From: [email-masked]
Date: Fri, 14 Oct 2005 11:47:40 -0500

Ajoy,
There is no requirement for hard handoff for media independent handovers
in 802.21. Please check the points Stefano made earlier about
"opportunistic handovers". 802.21 community is working towards enabling
exactly such scenarios and hence the delay aspects were not part of the
requirements. This is not going to change over time. 

This is plain simple and I, frankly don't see it as controversial. It is
not clear to me why MIPSHOP WG should wait to decide their work items
until you clear your unfounded concerns.

Regards,
Srini

>Sent: Friday, October 14, 2005 10:26 AM
>milliseconds 
>>to execute. This beats the purpose of handoff command specially for 
>>fast moving mobile devices.
>
>
>Ajoy,
>

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Fri, 14 Oct 2005 12:57:09 -0400

Srini, 

Any L3/higher layer handoff takes place due to hard handoff at L2.
802.21 is defining enabling technologies for L3/ higher layer handover.
Also, I do not believe that there is any concensus in 802.21 itself
about higher transport for command and event service. So, let us wait
till such concensus is reached. 

Regards,
Ajoy 

-----Original Message-----
Sent: Friday, October 14, 2005 11:48 AM

Ajoy,

Regards,
Srini

---

From: [email-masked]
Date: Fri, 14 Oct 2005 23:54:04 -0500

Hi Ajoy,
>Any L3/higher layer handoff takes place due to hard handoff at L2.
Not really, there are make-before-break mechanisms too. 

>Also, I do not believe that there is any concensus in 802.21 
>itself about higher transport for command and event service. 
>So, let us wait till such concensus is reached. 

Granted that ES/CS are not as mature as the IS level discussions are.
Nevertheless, there is good interest among 802.21 participants for this
work item from both vendors and operators alike. L3 ES/CS enable certain
scenarios that are very useful to 3G operators.

Regards,
Srini

>Sent: Friday, October 14, 2005 11:57 AM
>Also, I do not believe that there is any concensus in 802.21 
>itself about higher transport for command and event service. 
>So, let us wait till such concensus is reached. 
>
>Regards,
>Ajoy 
>
>There is no requirement for hard handoff for media independent 
>handovers in 802.21. Please check the points Stefano made 
>earlier about "opportunistic handovers". 802.21 community is 
>working towards enabling exactly such scenarios and hence the 
>delay aspects were not part of the requirements. This is not 
>going to change over time. 
>
>This is plain simple and I, frankly don't see it as 
>controversial. It is not clear to me why MIPSHOP WG should 
>wait to decide their work items until you clear your unfounded 
>concerns.
>
>Regards,
>Srini
>
>>>> not stop (and should have not stopped) IETF from developing SIP,
>>>i.e. the

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Mon, 17 Oct 2005 18:31:22 -0400

Srinivas, 

Please find inline replies.  

Regards,
Ajoy 

Hi Ajoy,

Ajoy-> I think we were discussing cellular handover here. In cellular
Mobile/IP handover takes place due to hard handover. However, it is
possible to support make before break handover for inter-technology
handover at L3. 
But my comment was related to applicability of hard handoff to .21 WG. 

Ajoy-> Agreed 

Nevertheless, there is good interest among 802.21 participants for this
work item from both vendors and operators alike. 

Ajoy-> Ok. Then it will very easy to sale this idea in .21. 

L3 ES/CS enable certain

Ajoy-> Ok. 

Regards,
Srini

---

From: [email-masked]
Date: Mon, 17 Oct 2005 17:41:55 -0500

Hi Ajoy,
Glad to see that we are converging on the issues.  

We are enabling only inter-technology handover and NOT cellular
intra-technology handover in 802.21. WRT hard handover in 802.21, it is
not clear what you mean. 802.21 allows for all kinds of handover (hard
and soft), it is upto the implementation which one to use.

Regards,
Srini

>Sent: Monday, October 17, 2005 5:31 PM
>Mobile/IP handover takes place due to hard handover. However, 
>it is possible to support make before break handover for 
>inter-technology handover at L3. 
>>about higher transport for command and event service.
>Nevertheless, there is good interest among 802.21 participants 
>for this work item from both vendors and operators alike. 
>
>>about higher transport for command and event service.
>earlier about 
>>This is plain simple and I, frankly don't see it as controversial. It 
>>is not clear to me why MIPSHOP WG should wait to decide their work 
>>items until you clear your unfounded concerns.
>>
>>Regards,
>>Srini
>>
>problem well

---

From: "zze-Seamless PERESSE M ext RD-RESA-REN" <[email-masked]>
Date: Thu, 20 Oct 2005 17:42:49 +0200

Ajoy,
ES and CS transport is to be addressed at L3 as soon as possible, at least because of the following:

- L3 (IP) has the strong potential to be the first available mechanism for transporting ES and CS.
- L3 (IP) will have to be used because wireless operators would like the Events and Commands to be transported beyond the existing access networks.

Regards,

Mathieu

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : samedi 15 octobre 2005 06:54
À : [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Hi Ajoy,

Granted that ES/CS are not as mature as the IS level discussions are.
Nevertheless, there is good interest among 802.21 participants for this work item from both vendors and operators alike. L3 ES/CS enable certain scenarios that are very useful to 3G operators.

Regards,
Srini

>handovers in 802.21. Please check the points Stefano made earlier about

---

From: [email-masked]
Date: Thu, 20 Oct 2005 09:01:55 -0700

Colleagues,

To second this message, it is important to the adoption of the .21 standard to have all three services supported by higher layer transports. The ideal is that all three services would have their protocols completed in approximately the same time frame. .21 will work with the IETF to produce the requirements as quickly as possible to facilitate organizing the development of those protocols.

Most of the debating on the requirements in the IETF lists has been helpful. Please continue the good work.

I'm discussing with Ajay Rajkumar now about how to accelerate delivering requirements. Processes that are bound too tightly to the conferences will be too slow.

Best Regards,
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zze-Seamless PERESSE M ext RD-RESA-REN
Sent: Thursday, October 20, 2005 8:43 AM
To: Sreemanthula Srinivas (Nokia-NRC/Dallas); [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; Faccin Stefano (Nokia-NRC/Dallas)
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Regards,

Mathieu

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked] Envoyé : samedi 15 octobre 2005 06:54 À : [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked] Cc : [email-masked] Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Hi Ajoy,

Regards,
Srini

---

From: "Olvera-Hernandez, Ulises" <[email-masked]>
Date: Thu, 20 Oct 2005 12:53:23 -0400

Michel,

I agree with you statement. Addressing ES and CS in parallel with IS help us address intersystem handover in an integral fashion, where al services are considered in a complete solution.

Ulises 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2005 12:02 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Colleagues,

Best Regards,
Michael

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zze-Seamless PERESSE M ext RD-RESA-REN
Sent: Thursday, October 20, 2005 8:43 AM
To: Sreemanthula Srinivas (Nokia-NRC/Dallas); [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; Faccin Stefano (Nokia-NRC/Dallas)
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Regards,

Mathieu

-----Message d'origine-----

Hi Ajoy,

Regards,
Srini

 
Ulises Olvera-Hernandez  
Member Technical Staff
InterDigital Canada Ltée
1000 Sherbrooke Street West
10th Floor
Montreal, Quebec H3A 3G4
Tel.: (514) 904-6282
Fax: (514) 904-6344
Email: [email-masked]
http://www.InterDigital.com

 This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient.  Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 20 Oct 2005 15:07:26 -0400

Mathieu, 

Sure. I agree that using IP based transport is a quicker way to deploy any protocol. I also think it is not difficult to design IP based transport for ES and CS. My concern was mainly related to performance issue. I guess if there is enough concensus and IESG is also ok with it then I do not have any personal objection to define such protocol. But perhaps we should de-couple ES, CS and IS so that we will have flexibility to only deploy IS and not be bound to deploy ES and CS if required. By decoupling I am not suggesting that we need to define completely 3 new protocols. We should still try to re-use encoding, security and other mechanism across IS, ES and CS as much as possible. 

Regards,
Ajoy

-----Original Message-----
From: zze-Seamless PERESSE M ext RD-RESA-REN [mailto:[email-masked]] 
Sent: Thursday, October 20, 2005 10:43 AM
To: [email-masked]; Singh Ajoy-ASINGH1; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] ES and CS within the MIPSHOP charter

Ajoy,

Regards,

Mathieu

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : samedi 15 octobre 2005 06:54
À : [email-masked]; NJEDJOU Eric RD-RESA-REN; [email-masked]; [email-masked]
Cc : [email-masked]
Objet : RE: [Mipshop] ES and CS within the MIPSHOP charter

Hi Ajoy,

Regards,
Srini

---

From: [email-masked]
Date: Fri, 21 Oct 2005 09:39:34 +0300

Hi all,

>Ajoy,
>ES and CS transport is to be addressed at L3 as soon as 
>possible, at least because of the following:
>
>- L3 (IP) will have to be used because wireless operators 
>would like the Events and Commands to be transported beyond 
>the existing access networks.
>
>Regards,
>
>Mathieu

I agree with Mathieu, running ES & CS over IP brings a lot of benefits,
in terms of flexibility
and deployment concerns.

John

---

From: "Gupta, Vivek G" <[email-masked]>
Date: Fri, 21 Oct 2005 09:37:30 -0700

Many emerging networks now support an operator controlled model. As such there is a need to support network initiated mobile assisted type handovers across different networks.

Such type of handovers typically require some kind of negotiation between network and mobile device regarding selection of most appropriate network. 802.21 ES and CS can provide such capabilities and help in this respect. The current 802.21 draft lists some of these events and handover commands but clearly this is still work in progress.

Doing such transfers and exchanges over L2 may not cover all cases. Doing it over L3 may be more practical and feasible and may actually provide support in a common way across different networks.

MIPSHOP should consider supporting such services and provide common mechanisms for enabling this across wide range of networks.

Best Regards,
-Vivek

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of zze-Seamless PERESSE M ext RD-RESA-REN
> To: [email-masked]; [email-masked]; NJEDJOU Eric
> RD-RESA-REN; [email-masked]; [email-masked]
> Cc: [email-masked]
> - L3 (IP) will have to be used because wireless operators would like the
> Events and Commands to be transported beyond the existing access networks.
> 
> Regards,
> 
> Mathieu
>

---

From: [email-masked]
Date: Fri, 21 Oct 2005 23:50:49 +0200

Hi  Vivek,

> Many emerging networks now support an operator controlled 
> model. As such there is a need to support network initiated 
> mobile assisted type handovers across different networks.

Mobopts is going to have a sessions on this in Vancouver
as far as I know. The above is definitely an interesting
area and should be worked on.

Cheers,
	Jouni

---

From: [email-masked]
Date: Sat, 22 Oct 2005 09:07:53 +0300

Hi all,

>> Many emerging networks now support an operator controlled model. As 
>> such there is a need to support network initiated mobile assisted
type 
>> handovers across different networks.
>
>Mobopts is going to have a sessions on this in Vancouver as 
>far as I know. The above is definitely an interesting area and 
>should be worked on.

I'd be much happier with an operator 'influenced' model - not
controlled.
What I mean is that network could tell the mobile node which other
networks are available, meaning ones that have roaming agreements, etc.
so that handovers could be managed better.  3G to WLAN handovers won't
work
if you have to log into a web page and enter your credit card.  However,
I wouldn't a model that inforces this, not allowing for other
possibilities,
like supporting handovers from 3G to my home WLAN. 

But as Jouni pointed out, this is something that is going to be
discussed
in mobopts.

John

---

From: [email-masked]
Date: Sun, 23 Oct 2005 11:35:25 +0200

John, 

> model. As 

Well, of course. For example in 'free' WLAN' case the home operator
does not really have more possibilities than trying to influence the
roaming decisions of the mobile node or then deny the usage of some
network completely.  However, different models apply. Steering of
roaming is already used in cellular networks (e.g. using ss7 in not
that nice way).

> networks are available, meaning ones that have roaming 

Or the other way around the mobile could tell the 'roaming management
point' what networks it sees and using some mechanism asks which of
those are preferred for roaming connection and then handover to some
of those preferred networks (assuming the mobile is already connected
some network).

> like supporting handovers from 3G to my home WLAN. 

Agree. 

> But as Jouni pointed out, this is something that is going to be

Yep.

Cheers,
	Jouni