Subject: [SIP] SIP Mobility

From: "Brian Stucker" <[email-masked]>
Date: Thu, 5 Oct 2000 16:29:05 -0500

Email problems necessitates clipping the original response a bit, sorry.

Yes, for new sessions, it's not as big of a deal. The race conditions
regarding the REGISTER are handled fairly well with the CSeq. My main point
of concern isn't with new sessions though. It's with session muting problems
associated with re-INVITEs.

If it takes a couple of seconds on a network to get a SIP session setup,
then you're going to have a mute period of a couple of seconds which is
going to be very audible no matter what sort of codec you use. On very
high-speed mobile networks (which I believe may have been the primary focus
of development thus far), that session latentcy is a lot lower, so it's not
as big of a deal. But those levels of bandwidth aren't going to be widely
available to the public for a long time. They haven't even started the
license allocation yet here in the states. If you had a 1 second mute on
your cell phone every time it handed off, you'd quickly stop moving around
very much while you were in a conversation.

That's why I refer to SIP as a relatively "slow" protocol because everyone
involved in the network has to get the change propagated to them, and then
acknowledge it in order for it to take affect. What I'm referring to places
no burden on the proxy or any SIP entity. I'm suggesting that it would be
better to RECOMMEND that at all where possible, that a layer 3 solution that
is completely transparent to SIP (and thus the proxy, the UA, and the
registrar) be used.

Now, you could use an INFO from the affected UA to tell anyone that he's in
a session with to switch their endpoint information, and that would cut down
the latentcy quite considerably, but it wouldn't eliminate it.

Brian

---
From: hammer michael:
Brian,

My main point was that the scope of control of the transport network extends
only as far as the end of the transport connection. If that connection
bypasses the proxy, then the proxy would not be informed of the subsequent
location of the user. If the proxy was one of the end-points, then the flow
of messages would probably keep in informed. But it is best left to the
transport network to maintain those connections once established, for all
the reasons you pointed out, i.e. handoffs every few seconds.

But the question still remains in the bypass situation, as in the function
of an HLR, if a new person were to want to contact the moving user, how does
the proxy know where he is at any given time. (As you know, from the VLR on
down to the radio site, the serving network maintains the call path until
the call ends. At which point the user re-registers in the new network. The
home network has no idea until that time.) 

If the user gets handed-off to another network operator and uses a new IP
address:
- Either the user tells the proxy directly by message to/through the proxy,
or 
- the user tells some registration device (which may be at the network
layer), or
- the network nodes inform the registration device, and the proxy pulls it
from there. 

Else, as far as the proxy is concerned, the user is incommunicado.

Mike

---

From: "Ashutosh Dutta" <[email-masked]>
Date: Sat, 7 Oct 2000 11:09:34 -0400

Few months back there was a big discussion about this particular issue often
known as "soft handoff" in the SIP list, you can take a look at the mailing list
archive, there is one relevant draft applicable to CDMA  e.g.,
draft-kempf-cdma-appl-01.txt.

Thanks
Ashutosh

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Anubhav Srivastav <[email-masked]>
Date: Tue, 10 Oct 2000 01:58:10 -0700 (PDT)

Thanks Samir and Farhan,

  I am still going thru the refrences you have given. 
I agree that user mobility is well taken care at
application level with SIP etc. Now SIP uses (though
it can use other mechanisms also) transport layer L4
for data transfer (UDP, TCP). Now SIP is worried about
terminal mobility (giving rise to continuous mobility
as discussed earlier). Now the existing solutions for
IP domain (Mobile IP) seems to be inefficient to lot
of us and that happens because M-IP tries to solve the
problem at L3. Other approaches also try to solve the
problem at L2. Both of above lead to the actual data
transfer path getting unnecessarily long just to keep
the L4 unchanged. 

   According to me the hand-off problem is best solved
at L4 where L4 knows that its L3 SAP (service access
point) is being changed and hence can actually make
use of the most efficient data path. I would like to
know if there has been any work in this area..
  This solution should not affect SIP at all as it is
anyway using L4 only.

Thanks
Anubhav

--- Samir Chatterjee <[email-masked]> wrote:
> We may be unnecessarily complicating things here.
> Most of what you
> mention below is happening at link layer (L2) and
> below and even L3 may
> be oblivious. Keep in mind that SIP is an
> application layer signaling
> protocol that works over IP (L3). IP addresses has 2
> parts (NetID,
> hostID). A host attached to a network will get the
> same netID prefix. In
> case of mobility, there are 2 cases. First, the host
> may be hopping
> between networks (discrete mobility) and gets a
> dynamic IP address each
> time it connects. Mobile IP takes care of most
> things in this case. The
> other difficult case is continuous mobility in which
> the host computer
> is using some kind of wireless interface and is
> moving around. Again
> typically you may be inside a wireless LAN domain in
> which even though
> you are roaming around a BS connected to a wired
> network, you are still
> assigned the same netID prefix, that of the wireless
> LAN. In another
> case, you may be roaming within a city and then you
> are most probably
> using cellular IP or CDPD in which case even though
> you may move between
> cells (L2 connectivity is preserved by handoff), I
> believe you still
> retain one IP address. In a continuous mobility
> case, if your host IP
> address changes, there could be lots of problems to
> handle. I think that
> there are still open challenges in the case when you
> have switched from
> a wireless LAN domain to a WAN domain inside a city.
> Can your networking
> software automatically switch to the necessary
> wireless technology? See
> some interesting work in this regard being done at
> CMU (Wirelss Andrew
> Project).
> If L3 and below takes care of most mobility issues,
> then anything
> running higher up should remain oblivious and should
> run smoothly
> without change. (This was the basic design principle
> of TCP/IP BTW, and
> the designers chose not to provide application layer
> connectivity.)
> However, since SIP also addresses the case of user
> mobility (not
> necessarily terminal mobility) there could be some
> issues about
> registration etc that may need some extra research
> and digging. I
> believe Radhika's attempt in this thread is just to
> come up with such
> issues, if at all they exist.
> 
> Samir Chatterjee
> Georgia State University
> 
> farhan wrote:
> > 
> > srivastav -
> > 
> > a wireless network has a few more design issues as
> compared to wire network.
> > 
> > 1. minimise the air time. there is only ether for
> the whole of universe.
> > therefore, each node should only use as much as is
> absolutely essential.
> > this is another way of saying, dont use excessive
> handshake and bandwidth.
> > 2. minmise the erp (effective radiated power).
> this is required to keep the
> > handsets of Alpine mountaineers from gettng jammed
> by teenagers at a Munich
> > disco.
> > 3. keep things private. anyone with a ham set can
> snoop on you.keep your
> > data payload encrypted.
> > 4. co-operate. give right of way to other packets.
> take your chance when
> > given. behave.
> > 
> > okay, now what happens at L3 is something like
> this:
> > 1. when a node comes up, it searches for a
> controller node (equivalent of a
> > base station in cell phones) on particular
> channels (note that i dont say
> > frequencies. channels can be made by
> round-robining access among various
> > channels on the same frequency or moving various
> channels out into a band of
> > individual frequencies or spatter all the signals
> of a channel across the
> > band in a pseudo random pattern that the channel
> member nodes can correlate
> > to and others can avoid).
> > 2. once a controller node is found, the controller
> will allocate a slot to
> > the newly inducted node. This is optional, the
> pure aloha implementations
> > dont do this. anyway, once a node in in the
> 'ring'. the power levels
> > required to sustain communications with the remote
> peer are continuously
> > varied in a negative feedback loop with fair
> amount of damping. This is done
> > to conserve battery as well as RFI (radio
> frequency interference) with other
> > services.
> > 3. when a node starts loosing signal strength with
> another peer. the QoS
> > monitor through protocols like RTCP on app layer
> or L3 notices the fading
> > (QSB) and another better path is negotiated. the
> new path is selected on the
> > basis of best signal to noise ratio and least cost
> routing. The algorithms
> > are extremely deployment critical. A space
> application (like satellite
> > telemetry) may have a totally different approach
> from a cell phone handoff.
> > 4. It is a possiblity that in such a case,
> isomorphic requests may arrive
> > through multiple routes. protocols like SIP or TCP
> discard the identical
> > packets in anycase. So should the RTP handlers.
> During the process of
> > handoff from one coverage area to another, it is
> expected and always a good
> > idea to have an overlap of coverage from two
> different 'cells' until the new
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/