Subject: RE: [SIP] SIP Mobility

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

Hi all,
	In the current context, I have a query. Can somebody
point out the details of what exactly happens at L3
while point of attachments change? I am talking about
intra-session (mid-call) handoff here i.e. suppose my
current IP address is A and due to my movement into
another domain my new IP address will become B. My
question is whether this change of address is abrupt
or continuous i.e. if at any time (however brief) I
have both addresses A as well as B as active. Further,
do I know the address B being asigned to me *before*
my original address A becomes inactive?

Any pointers relating to details of such handoff would
be appreciated.

Thanks
Anubhav

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/

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

---

From: "farhan" <[email-masked]>
Date: Sat, 7 Oct 2000 16:51:33 -0600

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
cell's path is completely ascertained. This has to be done at L3 or maybe
even L2 as it involves measurements of movement of the mobile units,
resolving the access path between competing routings, etc based on signal
strengths, network loading among the various cells as well as the power
budget of the UA.

a. The key issue from a SIP implementor's point of view is that a set of
messages with a completely different via headers may arrive within a session
(under the same callid, to and from). these have to be handled without
distinction.
b. there CAN be an overlap the when your point of attachment maybe
multihomed. This should not upset your UA.
c. there is no guarenttee that there will always be an overlap. in such
cases, the rtp should continue with comfort noise.

The actual handoff procedure can be extremely simple to extremely complex.
You can refer to the documents at www.etsi.org on GSM algorithms,
bluetooth.org for bluetooth approach. However, the most elaborate
discussions with rich field data is more easily available from the logs of
amateurs who pioneered wireless digital communications in the first place. i
am hunting up these resources on the net and i will soon post the urls here.

- farhan

---

From: Samir Chatterjee <[email-masked]>
Date: Sun, 08 Oct 2000 21:11:00 -0400

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