RE: [More] Session Mobility

["Dolan, Michael F (Mike)" <mfdolan@lucent.com>]

Chris,

I am not sure about implementation, but handoff from IS-95 to analog is
specified in the 3GPP2 IOS.  Handoff in the reverse direction is not
supported.

Mike Dolan

-----Original Message-----
From: Burke Chris-CCB007 [mailto:Chris.Burke@motorola.com]
Sent: Wednesday, September 19, 2001 12:35 PM
To: more@psg.com
Subject: RE: [More] Session Mobility


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