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]