RE: [More] Session Mobility

[James Kempf <James.Kempf@Sun.COM>]

I don't know, but I imagine it might be more difficult because
of basic differences in the protocol between analog and cellular.
With IP, the base protocol at which the handoff is occuring is IP
on both sides. The details of the link layer are hidden.

		jak

>From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
>To: more@psg.com
>Subject: RE: [More] Session Mobility
>Date: Wed, 19 Sep 2001 12:35:09 -0500
>
>Is anyone currently able to hand off a cell phone call from a digital cell to 
an analog cell? Seems like a comparable problem. Chris
>
>-----Original Message-----
>From: James Kempf [mailto:James.Kempf@Sun.COM]
>Sent: Wednesday, September 19, 2001 10:16 AM
>To: more@psg.com; Chris.Burke
>Subject: RE: [More] Session Mobility
>
>
>If by "session mobility" you are talking about moving a mobile host's
>traffic from one interface to another (e.g. GSM to 802.11), then
>this is currently a topic of active discussion and debate in the 
>Mobile IP and Seamoby working groups. There has been some preliminary
>work, but the problem is by no means completely understood.
>
>If you mean moving a SIP session from
>one host to another, then I believe SIP has mechanisms for this
>(REGISTER with the new host as the SIP URL), though I am not that familiar with
>the details of SIP that I could provide an outline of how it might
>work.
>
>If you mean something different from the above, then I need to
>refer back to Erik Nordmark's comments on this requirement
>from earlier this year,  namely that implementing some sort
>of generalized session mobility may be very difficult especially
>if it is not clearly defined what is meant by session mobility.
>
>		jak
>
>>From: Burke Chris-CCB007 <Chris.Burke@motorola.com>
>>To: more@psg.com
>>Subject: RE: [More] Session Mobility
>>Date: Wed, 19 Sep 2001 10:17:51 -0500
>>
>>There are various ways of implementing mobility.
>>
>>Consider a cell phone - it has a kind of session mobility in that the route 
>used by the voice traffic virtual circuit changes as the user moves among cell 
>sites. Currently the cell sites are homogeneous but theoretically a mix of 
>different technologies could be used (e.g. GSM and 802.11) and similar hand-off 
>techniques could be employed regardless of the access technology. There's still 
>only one administrative domain ("the carrier") and the entire system looks like 
>"one network". Handoff would be under control of infrastructure equipment, but 
>would require coordinated execution of handoff protocols within the subscriber 
>equipment. This scheme is appealing to some carriers.
>>
>>One can also, as you suggest, make session mobility the responsibility of the 
>subscriber equipment and design the solution for multiple administrative 
domains 
>and multiple access technologies using multi-homing etc.
>>
>>Research effort (and even product development) is ongoing at various companies 
>and universities around both approaches.
>>
>>Chris
>>
>>-----Original Message-----
>>From: amish.chana@orange.co.uk [mailto:amish.chana@orange.co.uk]
>>Sent: Wednesday, September 19, 2001 2:52 AM
>>To: more@psg.com
>>Subject: [More] Session Mobility
>>
>>
>>
>>Hi,
>>
>>With reference to the section on session mobility, which requires the ability 
>to
>>transfer and maintain sessions across different access technologies. What
>>thoughts do others on this mailing list have with respect to the requirements
>>and complexity potential solutions may have on the network?
>>Are these requirements really necessary?
>>Should session mobility (depending on the type of service) not be the
>>responsibility of the mobile terminal rather than the network?
>>
>>IMHO somes of these requirements could be addressed and realised by some of 
the
>>work on end-point multi-homing being performed by other WGs. SCTP,
>>draft-ohta-e2e-multihoming-02.txt and the multi6 WG may offer solutions to the
>>Session Mobility requirments without requiring the need for additional network
>>functionality.
>>
>>As an example, the application sessions mentioned in the draft (http, ssl, 
tcp,
>>telnet, ftp) and the ability to transfer them from
>>a IMT-2000 RAN to a 802.11 LAN or other access technology could be achieved 
>with
>> multi-homing. Supporting, session
>>transfers within the network requires a network element to maintain session
>>state information. Failure of this element
>>would impact all currently active sessions. In a multi-homed end-point 
scenario
>>the failure of the access network elements
>>does not impact sessions.
>>
>>
>>Regards,
>>Amish
>>
>>
>>
>>
>>******************************************************************************
*
>>Important. This E-mail is intended for the above named person and may be
>>confidential and/or legally privileged. If this has come to you in error you
>>must take no action based on it, nor must you copy or show it to anyone; 
please
>>inform the sender immediately.
>>******************************************************************************
*
>>
>>
>