Internet DRAFT - draft-itsumo-sipping-mobility-multimedia
draft-itsumo-sipping-mobility-multimedia
Internet Engineering Task Force F. Vakil
INTERNET DRAFT A. Dutta
draft-itsumo-sipping-mobility-multimedia-00.txt J-C. Chen
Date: July 2001 M. Tauil
Expires: December 2001 Telcordia Technologies
S. Baba
N. Nakajima
Y. Shobatake
Toshiba America Research, Inc.
H. Schulzrinne
Columbia University
Supporting Mobility for Multimedia with SIP
<draft-itsumo-sipping-mobility-multimedia-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet- Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
itsumo-sip-app-mobility-multimedia-00.txt>, and expires June 2001.
Please send comments to farm@research.telcordia.com or
sbaba@tari.toshiba.com or schulzrinne@cs.columbia.edu.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
ABSTRACT
ITSUMO Group [Page 1]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
Session Initiation Protocol (SIP) is rapidly gaining widespread
acceptance as the signaling protocol of choice for fixed and mobile
Internet multimedia and telephony services. This document focuses on
how one can utilize SIP to support real-time multimedia applications
of roaming users on an end-to-end basis from users' terminals without
reliance on network elements.
1. Introduction
1.1 The Rationale
The rapid growth of the Internet and the increasing demand for
ubiquitous mobile wireless services are the driving forces behind
intense activities towards the design of all IP wireless networks in
different standard and technical forums. Several forums, e.g., 3GPP,
3GPP2, and MWIF, are actively working on specifications of all IP
wireless networks that allow roaming users to access integrated data,
voice and multimedia services of the Internet via their wireless IP
terminals or appliances.
As of this writing, it is safe to say that all of these forums have
selected Session Initiation Protocol (SIP) [1] for session
management, and utilize a network layer protocol to support terminal
mobility. For instance, 3GPP2 and MWIF plan to use Mobile IP [17,
18] with additional enhancements for supporting terminal mobility,
and may utilize SIP to provide means of personal as well as service
mobility. Similarly, 3GPP will very likely use a variant of the GPRS
(General Packet Radio Service) mobility management mechanism for
terminal mobility [2] and may use SIP or other protocols for
supporting personal or service mobility. The primary advantages of
using a network layer terminal mobility are that it supports
applications that are not "mobility aware" (e.g., TCP-based
applications) efficiently, and reuses existing protocols for terminal
mobility. However, disadvantages of this approach are that:
i. The use of multiple protocols for terminal, service, and
personal mobility may increase terminal complexity.
iii. It uses multiple different protocols in the network to
perform similar functions for different users. For instance,
in case of a Mobile IP and SIP combination, wireless users
use mobile IP registration and HA or FA, while wireline users
utilize SIP REGISTER and SIP Registrar for a similar
functions. Hence, there is a need for ensuring proper
interworking of mobile IP with SIP.
iii. Network layer mobility management protocols (e.g., mobile IP)
relies on network elements (i.e., home agents) for packet
ITSUMO Group [Page 2]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
interception and forwarding to mobiles, as well as sending
necessary binding messages to corresponding hosts.
Since several wireless technical forums have agreed upon SIP as the
basis of the session management of the mobile Internet, it appears
that SIP will certainly be an integral part of the mobile Internet's
protocol architecture. Thus, we believe that it is desirable to use
SIP to provide means of terminal [16], service as well as personal
mobility for all applications. The underlying rationales for seeking
such a solution are the expected growth of Internet multimedia
services, particularly, the expected migration of voice telephony
(i.e., VoIP) onto the Internet, and strong likelihood of using SIP
for supporting service and personal mobility. The premises of using
SIP for supporting mobility are that it
** allows users to depend on their appliances rather than the network
for supporting mobility on an end-to-end basis without reliance on
and knowledge about abilities of network elements for packet
interception and forwarding, i.e., mobile users can roam into SIP
environments without concern about whether they support network
layer mobility or not,
** provides a means of route optimization and improved performance
for real-time services via SIP signaling messages for address
binding, registration, etc., and
** allows dealing with mobility at a semantic level above IP
terminals (e.g., moving of a media stream from one terminal to
another).
1.2 Purpose and Scope
The objective of this document is to use SIP to provide means of
terminal mobility for multimedia applications of roaming users on a
mobile Internet. This document exclusively focuses on terminal
mobility with multimedia applications. Supporting Terminal mobility
for TCP-based applications [4] and service mobility in a SIP
environment [5] will be discussed elsewhere.
We describe an approach that uses a combination of SIP, DHCP, and an
AAA protocol (e.g., DIAMETER) to support terminal mobility for users
multimedia applications. This approach uses
** DHCP or one of its fast variants for MS configuration,
** SIP REGISTER and SIP registrars as well as an appropriate AAA
protocol (e.g., DIAMETER) for MS registration with home or
ITSUMO Group [Page 3]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
visited network, and
** SIP INVITE method for redirection and address binding during
hand-off.
This approach supports domain hand-off (i.e., movement between
subnets that belong to different administrative domains), as well as
subnet hand-off (i.e., movement between subnets that belong to the
same administrative domain). However, it primarily relies on the
link layer to support the cell hand-off (i.e., micro-mobility).
This document is one in a series of four (others are [3], [4], and
[5]) Internet Drafts on supporting mobility with SIP. It exclusively
focuses on using SIP to provide means of terminal mobility for
multimedia applications. The document is organized as follows: Our
assumptions on the underlying network environment are summarized in
Section 2 where we describe the structure of a mobile Internet and
its signaling and control architecture, as well as the use of DHCP
for the MS configuration. Section 3 describes different alternatives
that use SIP to register the MS with either its home or visited
network as necessary. Supporting location services with SIP are
described in Section 4, while Section 5 focuses on the hand-off
process. Finally, Section 6 summarizes the discussion and concludes
the document with open issues for further study.
2. Assumptions
2.1 Architecture of a Mobile Internet
Figure 1 depicts the end-to-end packet platform of a mobile Internet
which comprises all IP wireless access networks and a packet switched
IP backbone network. The IP backbone network is an end-to-end
wireline IP infrastructure that will comprise regional providers'
wireline IP networks that are connected through the Internet. Besides
mobile stations/terminals, a wireless access network also comprises a
radio access network (RAN), and an edge router and controller (ERC)
[7]. In order to support the needs of its users, a wireless access
network interacts with the network control entities that are shown
as Domain Control Agent (DCA) in Figure 1. What follows is a brief
description of these elements and their functions.
2.1.1 Mobile Station (MS)
It is the user mobile terminal that allows users to communicate, and
also provides means of interactions and control between users and the
network.
2.1.2 Radio Access Network (RAN)
ITSUMO Group [Page 4]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
The radio access network (RAN) represents the wireless and back-haul
infrastructure that provides MSs with wireless access to the wireline
infrastructure. A RAN usually comprises a set of base stations and
base station controllers. In IMT-2000 [8, 9], RANs use programmable
software radios to provide flexibility across frequency bands at
the MS and across the RAN. It is desirable to remain independent
from the underlying RAN technology and to minimize the
restriction (or requirements) that it places on (or expects from) a
RAN.
2.1.3 Edge Router & Controller (ERC)
An ERC is a routing and control system that connects a wireless
access network to a regional wireline IP network. Although Figure 1
depicts one RAN per ERC, in practice, each ERC may support several
RANs. An ERC comprises two functional entities, an edge router (ER)
and an edge control agent (ECA). The ER is an IP router, while the
ECA is an intelligent agent that interacts with the domain control
agent (DCA) to control the RANs as well as support necessary
network-wide control tasks. In the IP parlance, each ERC is the
default gateway of all IP MSs that are supported by RANs that are
connected to it.
2.1.4 Domain Control Agent (DCA)
The domain control agent (DCA) provides session management as well as
means for interaction between users and network control system and
interaction among network control entities. Furthermore, the DCA also
supports: (1) Mobility management, (2) Authentication, Authorization,
and Accounting (AAA), and (3) QoS management, in summary MAAAQ,
functions for mobile users. These functional entities usually reside
on the wireline backbone, and are part of the overall control system
of the end-to-end platform. As Figure 1 indicates the home and
visited DCA entities may either interact directly or via a third
party Inter-Domain Control Agent (IDCA) on the global Internet. In
the latter case, the IDCA entity serves as a trusted broker between
the home and visited network DCAs.
<-- Visited Network --> <---- Home Network ---->
+-----+
| IDR |
+-----+
|
| Inter-Domain
| Control Agent
ITSUMO Group [Page 5]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
| +---------------+
+--| MAAAQ |
|---------------|
| SIP Server |
+---------------+
+----+ | +----+
| VR | | | HR |
+----+ | +----+
| | |
| | |
Domain| | Domain|
Control|Agent | Control|Agent
+---------------+ | +---------------+
| MAAAQ | | | MAAAQ |
|---------------| | |---------------|
| SIP Server |---+ | +---| SIP Server |
+---------------+ | | | +---------------+
| +----+ | +----+ |
| |DHCP| | |DHCP| |
| +----+ | +----+ |
___|___ | ___|___ | ___|___
/ \--------+ / \ +---------/ \
/ \ / \ / \
/Regional IP\___________/ Internet \___________/Regional IP\
\ Network / \ / \ Network /
\ / \ / \ /
---\_______/--- \_______/ ---\_______/---
| | | |
+-----+ +-----+ +-----+ +-----+
| ERC | | ERC | | ERC | | ERC |
+-----+ +-----+ +-----+ +-----+
| | | |
| | | |
| | | |
__|__ __|__ +----+ __|__ __|__
/ \ / \ | CH |---/ \ / \
/ Radio \ / Radio \ +----+ / Radio \ / Radio \
/ Access \ / Access \ / Access \ / Access \
\ Network / \ Network / \ Network / \ Network /
\ / \ / \ / \ /
\_____/ \_____/ \_____/ \_____/
| | | |
ITSUMO Group [Page 6]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
| | | |
+----+ +----+ +----+ +----+
| MS | | MS | | MS | | MS |
+----+ +----+ +----+ +----+
D C B A
Movement from A to B: Subnet Hand-off
Movement from B to C: Domain Hand-off
Figure 1. Architecture of a mobile Internet
It is worth noting that in a SIP environment, the call state can be
either stored in stateful proxies within the network or at the SIP UA
on the MS [22].
2.2 MS Configuration
The MS uses DHCP [11] or one of its fast variants to configure
itself. The MS configuration process follows the basic operation of
DHCP. The MS broadcasts a DHCPDISCOVER message to the DHCP servers.
Several servers offer a new address to MS via DHCPOFFER that contains
IP address, address of default gateway, subnet mask, domain name,
address of the local SIP proxy, etc.; the MS selects one and sends a
DHCPREQUEST to the selected DHCP server. The DHCP server send a
DHCPACK to confirm the assignment of the address to the MS. Figure 1
depicts the configuration signaling flow.
MS DHCP
| DHCP DISCOVER |
|---------------------->|
| DHCP OFFER |
|<----------------------|
| DHCP REQUEST |
|---------------------->|
| DHCP ACK |
|<----------------------|
| |
Figure 1. MS Configuration with DHCP
Note that one may also use DRCP (Dynamic Registration and
Configuration Protocol) [14] to configure the MS. DRCP does not
perform address collision resolution process (i.e., similar to fast
DHCP), and it is more bandwidth efficient than DHCP because its
messages are smaller than those of DHCP.
ITSUMO Group [Page 7]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
2.3 MS and CH Identifiers and Domain Names in Message Details
In all detailed messages throughout the rest of this document we
assume that
** Alice (sip:Alice@MS.home.com) is the mobile user who is communicating
with Bob (sip: Bob@CH.wondernet.com),
** the domain name for a visited subnet within the same administrative
domain is still "home.com", and
** the domain name for a visited network within a different administrative
domain is denoted as "visited_adm.com".
Furthermore, in the message details, we assume that AAA entity is
built around DIAMETER [12].
3. User and MS Registration
Registration is the process by which a network becomes aware of the
existence and the location of an MS and its associated user. It is
also the tenet of supporting service mobility with SIP [19, and 4],
and is usually invoked upon each MS reconfiguration. SIP can be used
to support both expedited and complete registration processes.
3.1 Expedited Registration
The expedited registration process is invoked when a MS moves from
one subnet to another within the same administrative domain. In
general, it does not require the AAA process, and is used to update
the location server. It is the same as a contact list update with SIP
[6], and is performed as follows: The MS's SIP client sends a SIP
REGISTER message with the MS's new address in its CONTACT field to
the SIP registrar (F1). The SIP registrar verifies user's
credentials and registers the MS in its contact database, updates its
contact list, and returns a 200 OK message to the MS's SIP client.
Figure 2, depicts the signaling flow for the expedited registration
process.
MS SIP Registrar
| SIP REGISTER F1 |
|----------------------------->|
| |
| 200 OK F2 |
|<-----------------------------|
| |
ITSUMO Group [Page 8]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
Figure 2. Expedited registration
*** Message Details for Figure 2
F1 REGISTER MS --> SIP Server (Registrar)
REGISTER sip:reg.home.com SIP/2.0
Via: SIP/2.0/UDP venus.home.com:5060
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 82946@venus.home.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600,
Alice@10.8.3.243; expires 0
Content Length: 0
F2 200 OK SIP Registrar --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP venus.home.com
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 82946@venus.home.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600
Content Length: 0
It is worth noting that there are two Contacts in the REGISTER
message. The first is Ailce@(new MS address), e.g.,
Alice@10.12.14.16, that expires in an hour (or whenever Alice
desires). The second is Alice@(old MS address), e.g.,
Alice@10.8.3.243, whose expiration time is set to zero, and expires
upon the successful completion of the registration process. Such a
use of Contact field allows the MS to send only a single REGISTER
message on the wireless link to make a new registration as well as
erase the previous one so that the registrars have up to date and
unique information about the MS location, and expedites location
services.
3.2 Complete Registration
A complete registration occurs when a MS attaches to a network (i.e.,
a MS is turned on) or roams into a new administrative domain (i.e.,
during domain hand-off). If the home network always maintains the
control of sessions and services, the MS does complete registration
with the home registrar. Otherwise, the MS registers with a local
ITSUMO Group [Page 9]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
registrar in the visited network.
3.2.1 With the Home Network
Figure 3 depicts the signaling flow of complete registration with the
home network. An MS initiates a complete registration, upon
attachment to a network (home or visited) or upon a domain hand-off
while roaming. The complete registration with the home network
proceeds as follows:
** The MS sends a SIP REGISTER message to the home registrar (HR) with
appropriate values in the To, From, and Contact fields of the REGISTER
message as well as the MS's (or user's) profile in the REGISTER message
body (F1). If the MS is at home, then the To, From, and Contact fields
are are set to the user's SIP URL. Otherwise, the To, and From are set
to the user's SIP URL, while the Contact field contains the user's
temporary address in the visited network.
** the HR sends a query containing the MS's profile to the home network AAA
requesting verification of the MS credentials and rights (F2), and
** upon receiving a positive (or negative) response from AAA (F3), the HR
sends a 200 OK (or a 401 unauthorized) response to the MS (F4).
MS HR AAA(h)
| SIP REGISTER F1 | |
|----------------------------->| Query F2 |
| |--------------------->|
| | |
| | |
| | Response F3 |
| |<---------------------|
| 200 OK F4 | |
|<-----------------------------| |
| | |
AAA(h): AAA entity of the home network
Figure 3. Complete registration with the home network.
Figure 3 indicates that a complete registration with the home network
takes a round trip delay, and requires interactions between AAA and
SIP server (e.g., HR) entities as well as the MS's ability to
discover its HR while in a visited network. Further study is needed
to determine how AAA and SIP entities interact, and a MS discovers
its own home registrar from a visited network.
ITSUMO Group [Page 10]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
Assuming that the AAA is built around DIAMETER [7], then the Query
(F2) and Response (F3) messages should contain the required Attribute
Value Parameters (AVP) for completing the registration. Further study
is needed to specify the Attributes Value Parameters (AVP) for the
complete registration process
*** Message Details for Figure 3
F1 REGISTER MS --> Home Registrar
REGISTER sip:reg.home.com SIP/2.0
Via: SIP/2.0/UDP venus.home.com:5060
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 82946@venus.home.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600,
Alice@10.8.3.243; expires 0
Content Length: 0
F2 DIAMETER_Query HR --> AAA(h)
Query_AAA (AVP)
F3 DIAMETER_Response AAA(h) --> HR
Response_AAA (Results)
Examples AVP parameters are user URL, MS hostname, MS IP address, and
MS's requested service(s), while examples of "Results" parameters
include Yes (or No), list of subscriber's rights (e.g., subscribed
services).
F4 200 OK Home Registrar --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP venus.home.com
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 82946@venus.home.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600
Content Length: 0
Note that if the registration is for attachment to a network the
Contact is set to "Alice@MS.home.com" in F1 and F4. The above
ITSUMO Group [Page 11]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
messages show registration during a hand-off process.
3.2.2 With the Visited Network
The signaling flow for complete registration with a visited network
is depicted in Figure 4. It proceeds as follows:
a. The MS sends a REGISTER request with its new (temporary) IP
as the CONTACT in the header and MS's profile in the body of
the REGISTER request to the VR (F1). Note that the MS has obtained
the address of the local SIP proxy from DHCP upon its configuration
(reconfiguration) in the visited network.
b. The VR queries the AAA entity of the visited network to
verify MS credentials and rights (F2).
c. The AAA entity of the visited network sends a request to the
AAA entity of the home network to verify the MS's credentials
and rights (F3).
d. The home AAA entity queries HR as necessary (F4 and F5), and
sends appropriate answer to the visited network AAA entity (F6).
e. The AAA entity of visited network sends appropriate response to
the VR (F7).
f. VR sends either a 200 OK response to the MS upon success, or
a 401 Unauthorized response upon failure of the registration (F8).
MS VR AAA(v) AAA(h) HR
| REGISTER F1 | | | |
|------------->| Query F2 | | |
| |------------>| Request F3 | |
| | |------------>| Query F4 |
| | | |-------------->|
| | | | |
| | | |<--------------|
| | |<------------| Response F5 |
| |<------------| Answer F6 | |
|<-------------| Response F7 | | |
| 200 OK F8 | | | |
AAA(h): AAA entity of the home network
AAA(v): AAA entity of the visited network.
Figure 4. Complete registration with the visited network
ITSUMO Group [Page 12]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
As described in Schulzrinne [19], when a user or an MS registers with
the visited network, the VR assigns a new temporary canonical
identifier, Alice%40MS.home.com@visited_adm.com, to the mobile user
that allows it to identify the in-bound requests for the visited user
or MS.
*** Message Details for Figure 4
F1 REGISTER MS --> Visited Registrar
REGISTER sip:regv.visited_adm.com SIP/2.0
Via: SIP/2.0/UDP plato.visited_adm.com:5060
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 8294628@ara.visited_adm.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600,
Alice@10.8.3.243; expires 0
Content-Type: Application/DIAMETER
Content-Length: ....
.
.
DIAMETER AVP for complete registration with visited network and
distributed state management.
.
.
F2 DIAMETER_Query VR --> AAA(v)
Query_AAA (AVP)
F3 DIAMETER_Request AAA(v) --> AAA(h)
Request_AAA (AVP)
F4 DIAMETER_Query AAA(h) --> HR
Query_AAA (AVP)
F5 DIAMETER_Response HR --> AAA(h)
Response_AAA (Results)
F6 DIAMETER_Response AAA(h) --> AAA(v)
Answer_AAA (Results)
ITSUMO Group [Page 13]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
F7 DIAMETER_Response AAA(v) --> VR
Response_AAA (Results)
Examples parameters of DIAMETER AVP for complete registration with
state management in the network are user URL, MS hostname, MS IP
address, and MS's requested service(s), while examples of "Results"
parameters include Yes (or No), and the list of user's rights (e.g.,
subscribed services).
F4 200 OK Visited Registrar --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP ara.visited_adm.com
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 8294628@ara.visited_adm.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600
Content-Type:Application/DIAMETER
Content-Length: ...
.
.
AAA Response, and user's rights
.
.
The rationale for registration with a visited network is to reduce
the delay of complete registration and improve hand-off performance,
particularly for real-time interactive services. However, Figure 5
shows no such improvement. The registration delay is still a round
trip delay and equal to that of Figure 3. In order to reduce the
registration delay, one has to ensure that the whole registration
process takes place in the visited network, and minimize the direct
interaction with the home AAA entity during the registration process.
One approach for reducing the delay of complete registration with the
visited network is to use a distributed registration and call state
management (see Figure 5), i.e.,
** the home and visited network have identical private keys, and
** an encrypted and signed copy of the user's registration with its
home network in the MS.
As the MS moves into a visited network it sends the encrypted signed
result of its original registration to the VR within the body of the
ITSUMO Group [Page 14]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
REGISTER message (F1). The VR forwards this information to the AAA(v)
entity (F2). Since AAA(v) shares the same private key with AAA(h), it
can use this encrypted data to complete the registration by itself in
the visited network. Note that AAA(v) updates the registration
results as necessary, and sends an encrypted signed copy of it to VR
in the Response (F3) for forwarding to the MS in the body of 200 OK
(F4).
MS VR AAA(v)
| REGISTER F1 | |
|---------------->| Query F2 |
| |--------------->|
| | |
| | |
| | |
| | |
| | |
| |<---------------|
|<----------------| Response F3 |
| 200 OK F4 | |
AAA(v): AAA entity of the visited network.
Figure 5. Fast complete registration process with the visited network
Another approach for fast registration is to allow that the MS's
profile and registration result is replicated either through
interaction of the AAA(v) with AAA(h) or by pre-planned profile
replications [13] in the neighboring AAA(s). The profile and
registration replications expedites the complete registration
process, though it reflects the mobility pattern of the MS, and its
effective realization requires continuous monitoring of users'
mobility patterns. We favor the former approach, i.e., distributed
registration and call state management because it is simpler to
implement and operate.
*** Message Details for Figure 5
F1 REGISTER MS --> Visited Registrar
REGISTER sip:regv.visited_adm.com SIP/2.0
Via: SIP/2.0/UDP plato.visited_adm.com:5060
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 8294628@ara.visited_adm.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600,
ITSUMO Group [Page 15]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
Alice@10.8.3.243; expires 0
Content-Type: Application/DIAMETER
Content-Length: ....
.
.
DIAMETER AVP for the complete registration with visited
network and distributed state management.
.
.
F2 DIAMETER_Query VR --> AAA(v)
Query_AAA (AVP)
F3 DIAMETER_Response AAA(v) --> VR
Response_AAA (Results)
Examples parameters of DIAMETER AVP for complete registration with
distributed state management are user URL, MS hostname, MS IP
address, and MS's requested service(s) and encrypted results of the
recent call and/or registration state, while examples of "Results"
parameters include Yes (or no), list of user's rights (e.g.,
subscribed services), and an encrypted copy of the new
call/registration state.
F4 200 OK Visited Registrar --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP ara.visited_adm.com
From: Alice <sip:Alice@MS.home.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 8294628@ara.visited_adm.com
Cseq: 1 REGISTER
Contact:Alice@10.12.14.16; expires 3600
Content-Type:Application/DIAMETER
Content-Length: ...
.
.
AAA Response, user's rights, and encrypted registration state
.
.
3.3 Remarks
Couple of points are worth noting. First, registrars of different
administrative domains, should be able to communicate, most likely
ITSUMO Group [Page 16]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
via the AAA entities of these domains, so that they can locate users
(or MSs). Second in version 00 of this document, we suggested that
because the registration process in SIP is additive, the MS should
send a SIP REGISTER message with wildcard "*" option in the CONTACT
field to erase all of its previous registrations, and then proceeds
with one of the registration schemes described above. However, as
already discussed in Section 3.1, we believe using a single REGISTER
message with two Contacts is more efficient on the wireless link.
4. Location Service
The MS has moved to a new location when a corresponding host (CH)
initiates a session. In this case, SIP sets up the session as
follows:
- The CH invites the MS,
- A SIP redirect server (SIP-RS) answers that the MS is moved to a
temporary address,
- The CH re-invites the MS at the temporary address, and
- a session is set up between the CH and the MS and the data
transfer begins.
Figure 6 depicts the signaling flow for location service.
CH SIP-RS MS
| | |
| SIP INVITE F1 | |
|------------------------------>| |
| 302: Moved Temporarily F2 | |
|<------------------------------| |
| SIP INVITE F3 | |
|-------------------------------+----------------------------->|
| F4 | SIP OK |
|<------------------------------+------------------------------|
| ACK F5 | |
|-------------------------------+----------------------------->|
| User Data | |
|<============================================================>|
| | |
Figure 6. The signaling flow for location service
The CH sends a SIP INVITE message to the MS. A redirect server that
has intercepted the INVITE message sends a 302 (i.e., moved
temporarily) redirection message to the CH with the MS's
new/temporary address as its Contact header field. The CH sends a SIP
INVITE message to the new address, the MS responds with a SIP OK, and
the data transfer begins. Since the DHCP dynamically updates the DNS
mappings, new TCP connections are established using the most recent
ITSUMO Group [Page 17]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
IP address of the MS.
*** Message Details for Figure 6
F1 INVITE CH --> SIP Redirect Server
INVITE sip:Alice@MS.home.com SIP/2.0
Via: SIP/2.0/UDP gemini.wondernet.com:5060
From: Bob <sip:Bob@CH.wondernet.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 7816037@gemini.wondernet.com
Cseq: 1 INVITE
Contact:Bob@CH.wondernet.com
Content-Type: Application/sdp
Content Length: ...
v=0
o=Bob 2890844526 2890844526 IN IP4 CH@wondernet.com
s=Happy birthday
t= 0 0
c=IN IP4 CH.wondernet.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
F2 302 Moved Temporarily SIP Redirect Server --> CH
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP gemini.wondernet.com:5060
From: Bob <sip:Bob@CH.wondernet.com>
To: Alice <sip:Alice@MS.home.com>
Call_ID: 7816037@gemini.wondernet.com
Cseq: 1 INVITE
Contact:Alice@10.15.20.25
F3 INVITE CH --> MS
INVITE sip:Alice@10.15.20.25
Via: SIP/2.0/UDP gemini.wondernet.com:5060
From: Bob <sip:Bob@CH.wondernet.com>
To: Alice <sip:10.15.20.25>
Call_ID: 7816037@gemini.wondernet.com
Cseq: 2 INVITE
Contact:Bob@CH.wondernet.com
Content-Type: Application/sdp
Content Length: ...
ITSUMO Group [Page 18]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
v=0
o=Bob 2890844526 2890844526 IN IP4 CH@wondernet.com
s=Happy birthday
t= 0 0
c=IN IP4 CH.wondernet.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
F4 200 OK MS --> CH
SIP/2.0 200 OK
Via: SIP/2.0/UDP gemini.wondernet.com:5060
From: Bob <sip:Bob@CH.wondernet.com>
To: Alice <sip:10.15.20.25>
Call-ID: 781637@gemini.wondernet.com
Cseq: 2 INVITE
Contact:Bob@CH.wondernet.com
Content-Type: Application/sdp
Content Length: ...
v=0
o=Bob 2890844526 2890844526 IN IP4 CH@wondernet.com
s=Happy birthday
t= 0 0
c=IN IP4 CH.wondernet.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
F5 ACK CH --> MS
ACK sip:Alice@sip:10.15.20.25
Via: SIP/2.0/UDP gemini@wondernet.com
From: Bob <sip:Bob@CH.wondernet.com>
To: Alice@10.15.20.25
Call-ID: 7816037@gemini.wondernet.com
Cseq: 2 ACK
5. Hand-off
We use SIP to support subnet and domain hand-off and leave cell
hand-off to the link layer. This Section focuses on how the MS
detects subnet and domain hand-off processes and distinguishes them
from one another, and describes the signaling flows for both of these
processes.
5.1 Hand-off Detection and Recognition
ITSUMO Group [Page 19]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
The hand-off detection and recognition scheme is built upon the fact
that a cell hand-off is a pre-requisite for a subnet or a domain
hand-off. It works as follows:
** Upon every cell hand-off the DHCP client in an MS initiates a
reconfiguration process. Its DHCP client requests for new IP
address, domain name, etc.
** the MS examines the DHCP response according to the following rules
to identify the hand-off process.
i. If the new IP address is the same as the current one, then
a cell hand-off has occurred and the MS needs to do nothing.
ii. If the new IP address is different from though the domain
name is the same as the current one, the MS invokes the subnet
hand-off process.
iii. If the new IP address and new domain name both differ from
current ones, the MS invokes a domain hand-off process.
5.2 Subnet hand-off
The MS moves from one subnet to another within the same
administrative domain. SIP supports such a subnet hand-off (i.e.,
macro mobility) during the session as follows.
i. The MS interacts with DHCP to reconfigure itself (See Figure 1).
This process takes a round-trip <MS-DHCP-MS) propagation delay.
ii. The MS re-invites the corresponding host to its new temporary
address. The identifier of the outbound proxy in the visited
network should be inserted in the Record-Route field of this
SIP INVITE message.
When resource reservation is mandatory for real-time services
(e.g., voice), the session is not modified and redirected to the
MS's new location (i.e., the re-invite is practically placed "on
hold") until an end-to-end bidirectional bearer path with sufficient
resources is set up between MS and the CH [20]. Thus, the MS (or
the network reservation scheme) should concurrently send message
to terminate the previous bear-path of the session as well as
initiate a new resource allocation request to ensure a successful
re-invitation of the CH to the new location.
iii. The MS also initiates an expedited registration involving
ITSUMO Group [Page 20]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
no AAA to update its location information in the home
registrar (HR).
Figure 7 shows the signaling flow of subnet hand-off with SIP.
MS Proxies CH
| +----------------+ | |
|-------| MS Reconfigures| | |
| | (Figure 1) | | |
| +----------------+ | |
| | |
|===> Release Old Bearer Path | |
| | |
| | |
| INVITE F1 | |
|----------------------------------------------------->|
| | |
|===> Reserve New Bearer Path | |
| | |
| COMET F2 | |
|<-----------------------------------------------------|
| | |
| OK (of COMET) F3 | |
|----------------------------------------------------->|
| | |
| COMET F4 | |
|----------------------------------------------------->|
| | |
| OK (of COMET) F5 | |
|<-----------------------------------------------------|
| | |
| OK (of INVITE ) F6 | |
|<-----------------------------------------------------|
| | |
| ACK F7 | |
|----------------------------------------------------->|
| | |
| | |
| +----------------+ | |
|-------| Expedited Reg. | | |
| | (Figure 2) | | |
| +----------------+ | |
Figure 7. The signaling flow of subnet hand-off
*** Message Details for Figure 7
ITSUMO Group [Page 21]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
F1 INVITE MS --> CH
INVITE Bob@CH.wondernet.com SIP/2.0
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 INVITE
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F2 COMET CH --> MS
SIP/2.0 COMET
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 COMET
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F3 200 OK MS --> CH
ITSUMO Group [Page 22]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
SIP/2.0 200 OK
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 COMET
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F4 COMET MS --> CH
SIP/2.0 COMET
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 COMET
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=SDP Session
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F5 200 OK CH --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
ITSUMO Group [Page 23]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 COMET
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=The Project
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F6 200 OK CH --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 INVITE
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=The Project
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F7 ACK MS --> CH
ACK sip:Bob@CH.wondernet.com SIP/2.0
Via: SIP/2.0/UDP plato.home.com; branch 7c77a332e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
ITSUMO Group [Page 24]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 777844@plato.home.com
Cseq: 7 ACK
5.3 Domain Hand-off (Roaming)
Except for the fact that the MS requires to perform complete
registration (see [3]) upon domain hand-off, roaming support with SIP
similar to subnet hand-off described before. As the mobile moves from
a subnet to another in a different administrative domain, the MS
operates as follows:
a. The MS reconfigures itself using DHCP. Simulatneously, DHCP
updates the DNS.
b. The MS initiates a complete registration with its new address
in the new domain (i.e., visited network) as described in
Section 3.
c. The MS re-invites the corresponding host to its new temporary
address. The identifier of the outbound proxy in the visited
network should be inserted in the Record-Route field of this
SIP INVITE message.
When Resource reservation is mandatory for real-time services
(e.g., voice), the session is not modified and redirected to the
MS's new location (i.e., the re-invite is practically placed "on
hold") until an end-to-end bidirectional bearer path with sufficient
resources is set up between MS and the CH [20]. Thus, the MS (or
the network reservation scheme) should concurrently send message
to terminate the previous bear-path of the session as well as
initiate a new resource allocation request to ensure a successful
re-invitation of the CH to the new location.
Figure 8 depicts the signaling flow of domain hand-off with SIP
MS Proxies CH
| +----------------+ | |
|-------| MS Reconfigures| | |
| | (Figure 1) | | |
| +----------------+ | |
| | |
| +----------------+ | |
|-------| Complete Reg. | | |
ITSUMO Group [Page 25]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
| | (Figure 5) | | |
| +----------------+ | |
| | |
|===> Release Old Bearer Path | |
| | |
| | |
| INVITE F1 | |
|---------------------------------------------------------->|
| | |
|===> Reserve New Bearer Path | |
| | |
| COMET F2 | |
|<----------------------------------------------------------|
| | |
| OK (of COMET) F3 | |
|---------------------------------------------------------->|
| | |
| COMET F4 | |
|---------------------------------------------------------->|
| | |
| OK (of COMET) F5 | |
|<----------------------------------------------------------|
| | |
| OK (of INVITE) F6 | |
|<----------------------------------------------------------|
| | |
| ACK F7 | |
|-----------------------------------------------------------|
| | |
Figure 8. The signaling flow of domain hand-off
As Figure 8 indicates it takes SIP four times of (MS-CH-MS) round
trip propagation delay to complete the re-invitation of CH to MS's
new address during domain hand-off for sessions with real-time
applications. This delay comprises one round trip for the resource
reservation, 2 for COMETs and their ACKs, and one for the re-
invitation and its ACK. Thus, in the continental US, the maximum re-
invitation delay is about 200 msec. The total domain hand-off delay
is sum of reconfiguration, registration, old bearer path release
(i.e., one round trip MS_CH_MS), and re-invitation delays. Since one
can reconfigure and register the MS locally, the total domain hand-
off delay across continental US (250 ms plus registration and
reconfiguration) should be significantly less than the 1 sec upper
bound set forward in [3]. Note that in the message details that
ITSUMO Group [Page 26]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
follows Alice still uses her own home URL.
*** Message Details for Figure 8
F1 INVITE MS --> CH
INVITE Bob@CH.wondernet.com SIP/2.0
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 INVITE
Contact:Alice@12.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F2 COMET CH --> MS
SIP/2.0 COMET
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 COMET
Contact:Alice@12.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
ITSUMO Group [Page 27]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
a=qos: mandatory sendrecv
F3 200 OK MS --> CH
SIP/2.0 200 OK
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 COMET
Contact:Alice@12.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@visited_adm.com
s=Session SDP
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F4 COMET MS --> CH
SIP/2.0 COMET
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 COMET
Contact:Alice@12.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=SDP Session
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
ITSUMO Group [Page 28]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
F5 200 OK CH --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 COMET
Contact:Alice@12.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=The Project
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F6 200 OK CH --> MS
SIP/2.0 200 OK
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 INVITE
Contact:Alice@10.15.20.25
Content-Type:Application/sdp
Content-Length: ...
v=0
o=Alice 2890844526 2890844526 IN IP4 MS@home.com
s=The Project
t= 0 0
c=IN IP4 MS@home.com
m=audio 5004 RTP/AVP 0 3
a=qos: mandatory sendrecv
F7 ACK MS --> CH
ITSUMO Group [Page 29]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
ACK sip:Bob@CH.wondernet.com SIP/2.0
Via: SIP/2.0/UDP ara.visited_adm.com; branch 7c73d32e7e.1
;maddr=10.15.15.254; ttl=4
Via: SIP/2.0/UDP gemini.wondernet.com
From: Alice <Alice@MS.home.com>
To: Bob <Bob@CH.wondernet.com>
Call-ID: 31456@ara.visited_adm.com
Cseq: 1 ACK
5.4 Discussions
First, since the identifier of the outbound proxy in the visited
network is inserted into Record-Route field of the INVITE messages,
the subnet and domain hand-off processes converge even if both MS and
CH move.
Second, in an early version of this work, <draft-itsumo-hmmp-00 the
previous and current ERCs to reduce the loss of transient data and
ensure a smooth hand-off. However, we have dropped such a short lived
tunneling idea because
** Real-time applications can tolerate some loss and non-real-time
reliable (e.g., TCP based) applications can always retransmit the
lost transient data,
** the realization of short lived tunnels require existence of SIP
UAs in all ERCs, as well as address translation within them
for forwarding transient data on these tunnels,
** short lived tunnels are redundant and unnecessary for CDMA RANs
that provide soft hand-off mechanisms, and increase the
complexity of the ERCs.
6. Summary and Open Issues
We have shown how one can use SIP to SIP to support terminal mobility
for real-time and multimedia applications. We have also depicted the
signaling flows and their message details, and have identified some
open issues for further study. The key open issues are
** the interaction of SIP servers with the AAA and specifications of
DIAMETER AVP for complete registration with home or visited network,
** resource release and reservation during hand-off,
** exact descriptions of call and registration states for distributed
state management,
7. Acknowledgments
ITSUMO Group [Page 30]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
The authors wish to acknowledge the contributions of other members of
the ITSUMO(TM) team from Telcordia (P. Agrawal, , S. Das, D.
Famolari, A. McAuley, P. Ramanathan, and R. Wolff) and Toshiba
America Research Incorporated (T. Kodama, and Y. Ohba).
(TM): ITSUMO (Internet Technology Supporting Universal Mobile
Operation) is a trademark of Telcordia. It is a joint research
project of Telcordia Technologies and Toshiba America Research Inc.
(TARI). It envisions an end-to-end wireless/wireline IP platform for
supporting real-time and non-real-time multimedia services in the
future. Its goal is to use IP and third generation wireless
technologies to design a wireless platform that allows mobile users
to access multimedia services on a next generation Internet. In
Japanese, ITSUMO means anytime, always.
8. References
1. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP: Session Initiation Protocol", <draft-ietf-sip-rfc2543bis
-03.pdf>, work in progress, May 2001.
2. GSM 03.60 v6.6.0, "General Packet Radio Service (GPRS): Service
Description; Stage 2", 1997.
3. F. Vakil, A. Dutta, J-C. Chen, S. Baba, N. Nakajima, and
H. Schulzrinne, "Mobility Management in a SIP Environment,
Requirements, Functions, and Issues", <draft-itsumo-sipping-
mobility-req-00.txt>, work in progress, July 2001.
4. F. Vakil, A. Dutta, J-C. Chen, M. Tauil, S. Baba, N. Nakajima,
and H. Schulzrinne, "Supporting Mobility for TCP with SIP",
<draft- itsumo-sipping-mobility-tcp-00.txt>, work in progress,
July 2001.
5. F. Vakil, A. Dutta, S. Baba, N. Nakajima, and H. Schulzrinne,
"Service Mobility with SIP", <draft-itsumo-sipping-mobility-
service-00.txt>, work in progress, July 2001.
6. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis,
J. Rosenberg, K. Summers, and H. Schulzrinne, "SIP Telephony
Call Flow Examples", <draft-ietf-sip-call-flows-05.txt>, work
in progress, June 2001.
7. ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless
Architecture", mwif2000.28, January 28, 2000.
8. ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000
(IMT-2000)", 1997.
ITSUMO Group [Page 31]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
9. ITU-R Rec. M.817, "International Mobile Telecommunications-2000
(IMT-2000)", Network Architectures", 1992.
10. M. Handley, and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
11. R. Droms, "Dynamic Host Reconfiguration Protocol", RFC 2131,
March 1997.
12. P. R. Calhoun, G. Zorn, P. Pan, and H. Akhtar, "DIAMETER
Framework Document", <draft-calhoun-diameter-framework-09.txt>,
work in progress, February 2001.
13. D. Lam, Y. Cui, D.C. Cox, and J. Widom, "A Location Management
Technique To Support Lifelong Numbering in Personal
Communications", January 1998.
14. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic
Registration and Configuration Protocol for Mobile Hosts",
Internet Draft, <draft-itsumo-drcp-01.txt>, work in progress,
July 2000.
15. M. Stapp, and Y. Rekhter, "The DHCP Client FQDN Option", <draft
-ietf-dhc-FQDN-option-01.txt>, work in progress, March 2001.
16. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP", ACM
Multimedia Workshop, Seattle, August 1999.
17. C. Perkins, "IP Mobility Support", RFC 2002, October 1996.
18. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP",
<draft-ietf-mobileip-optim-10.txt>, November 2000.
19. H Schulzrinne, "SIP Registration", <draft-schulzrinne-sip-
register-01.txt>, work in progress, April 2001.
20. W. Marshall, K. Ramakrishnan, E. Miller, G. Russel, B. Beser,
M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens,
P. Lalwaney, J. Fellows, E. Evans, K. Kelly, A. Roach,
J. Rosenberg, H. Schulzrinne, and S. Donovan, "Integration of
Resource Management and SIP for IP Telephony", <draft-ietf-sip-
manyfolks-resource-01.txt>, work in progress, February 2001.
9. Authors' Addresses
ITSUMO Group [Page 32]
Internet-Draft Supporting Mobility for Multimedia with SIP July 2001
Faramak Vakil
Telcordia Technologies, Rm 1C-135B
445 South Street, Morristown, NJ 07960-6438
farm@research.telcordia.com
Ashutosh Dutta
Telcordia Technologies, Rm 1C-227B
445 South Street, Morristown, NJ 07960-6438
adutta@research.telcordia.com
Jyh-Cheng Chen
Telcordia Technologies, Rm 1G-236B
445 South Street, Morristown, NJ 07960-6438
jcchen@research.telcordia.com
Miriam Tauil
Telcordia Technologies, Rm 1E-209R
445 South Street, Morristown, NJ 07960-6438
miriam@research.telcordia.com
Shinichi Baba
Toshiba America Research Inc. (TARI)
P. O. BOX 136
Convent Station, NJ 07961-0136
sbaba@tari.toshiba.com
Nobuyasu Nakajima
Toshiba America Research Inc. (TARI)
P. O. BOX 136
Convent Station, NJ 07961-0136
nobuyasu@tari.research.telcordia.com
Henning Schulzrinne
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY, 10027
schulzrinne@cs.columbia.edu
ITSUMO Group [Page 33]
