Internet DRAFT - draft-yafan-fmc-mancho

draft-yafan-fmc-mancho






FMC                                                                Y. An
Internet-Draft                                               Stoke, Inc.
Expires: January 29, 2007                                  July 28, 2006


 Mobile Assisted Handover across VoIP and Cellular Domains Using SIP as
                          Access Call Control
                     draft-yafan-fmc-mancho-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 29, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the use of SIP between the dual mode handset
   (DMH) and the mobility SIP proxy to enable network controlled
   handovers across voice over IP (VoIP) and cellular networks.  The
   mobility SIP proxy has a peering relationship with the cellular
   network.  Mobile assisted and network controlled handovers require
   the exchange of cellular radio parameters between the DMH and the
   mobility SIP proxy.  The set of cellular related parameters is
   collectively called Session Handover Protocol (SHP).  The SHP is a



An                      Expires January 29, 2007                [Page 1]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   residual protocol of SIP, where all of its messages are transported
   as MIME attachment to SIP messages.

   This document describes the requirements, various SIP message flows
   for cross-domain roaming and bidirectional handovers between VoIP and
   cellular domains, and detailed specification of the residual SHP
   protocol.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Cellular Homed Deployment  . . . . . . . . . . . . . . . .  5
     1.2.  Soft Switch Homed Deployment . . . . . . . . . . . . . . .  6
     1.3.  Passing Extra Parameters with SIP Messages . . . . . . . .  6
   2.  Registration in VoIP Domain  . . . . . . . . . . . . . . . . .  7
     2.1.  Registration Message Flow in Cellular-homed Scenario . . .  7
     2.2.  Registration Message Flow in Soft Switch-homed Scenario  .  9
     2.3.  Examples of Registration Messages  . . . . . . . . . . . . 11
     2.4.  Alternative Access Network Information . . . . . . . . . . 12
       2.4.1.  Reporting of P-Access-Network-Info . . . . . . . . . . 12
       2.4.2.  Assignment of P-Access-Network-Info  . . . . . . . . . 13
     2.5.  Cellular Radio Information . . . . . . . . . . . . . . . . 15
       2.5.1.  Cellular Radio Information Reporting . . . . . . . . . 15
       2.5.2.  Cellular Radio Information Acknowledgement . . . . . . 15
     2.6.  TMSI Assignment  . . . . . . . . . . . . . . . . . . . . . 15
       2.6.1.  Use of P-Associated-URI for TMSI Assignment  . . . . . 16
   3.  Rove-Out: From WLAN to Cellular  . . . . . . . . . . . . . . . 17
   4.  Rove-In: From Cellular to WLAN . . . . . . . . . . . . . . . . 20
   5.  Call Setup in VoIP Domain with Cellular Crypto Setup . . . . . 21
     5.1.  Call Origination Message Flow  . . . . . . . . . . . . . . 22
     5.2.  Call Termination Message Flow  . . . . . . . . . . . . . . 23
     5.3.  Examples of Call Setup Messages  . . . . . . . . . . . . . 26
     5.4.  3GPP GSM Crypto Setup  . . . . . . . . . . . . . . . . . . 30
   6.  Hand-Out from WLAN to Cellular . . . . . . . . . . . . . . . . 32
     6.1.  Hand-Out Trigger Detection . . . . . . . . . . . . . . . . 32
     6.2.  Hand-Out Message Flow  . . . . . . . . . . . . . . . . . . 32
     6.3.  Reporting of Cellular Radio Conditions . . . . . . . . . . 33
     6.4.  Network Controlled Hand-out  . . . . . . . . . . . . . . . 35
   7.  Hand-In from Cellular to WLAN  . . . . . . . . . . . . . . . . 38
     7.1.  Hand-In Trigger Detection  . . . . . . . . . . . . . . . . 38
     7.2.  Hand-In Attach Message Flow  . . . . . . . . . . . . . . . 40
     7.3.  Hand-In Message Flow . . . . . . . . . . . . . . . . . . . 42
       7.3.1.  Hand-In Message Flow with Early INVITE . . . . . . . . 43
       7.3.2.  Hand-In Message Flow with Late INVITE  . . . . . . . . 46
       7.3.3.  Early versus Late INVITE in Hand-in  . . . . . . . . . 48
     7.4.  Subsequent Handovers . . . . . . . . . . . . . . . . . . . 48
       7.4.1.  Subsequent Hand-out  . . . . . . . . . . . . . . . . . 48



An                      Expires January 29, 2007                [Page 2]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


       7.4.2.  Subsequent Hand-in . . . . . . . . . . . . . . . . . . 49
   8.  Session Handover Protocol (SHP)  . . . . . . . . . . . . . . . 50
     8.1.  Carrier SIP and Attached SHP Messages  . . . . . . . . . . 50
       8.1.1.  Indication of 3GPP-SHP Support . . . . . . . . . . . . 51
       8.1.2.  SHP Attachment Encoding  . . . . . . . . . . . . . . . 52
     8.2.  SHP Syntax and Functional Descriptions . . . . . . . . . . 52
       8.2.1.  SHP Message Format . . . . . . . . . . . . . . . . . . 52
       8.2.2.  SHP Message Types  . . . . . . . . . . . . . . . . . . 53
       8.2.3.  SHP Message Descriptions . . . . . . . . . . . . . . . 53
       8.2.4.  List of All Information Elements . . . . . . . . . . . 56
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 58
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 60
   Intellectual Property and Copyright Statements . . . . . . . . . . 61





































An                      Expires January 29, 2007                [Page 3]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


1.  Introduction

   [yafan-fmc-arch] describes an architecture framework for providing
   converged services across IP and cellular domains for dual mode
   handset (DMH) users.  DMH refers to certain mobile devices which have
   both cellular and WLAN baseband and radio. [yafan-fmc-arch] also
   describes a basic set of features by utilizing SIP as per [RFC3261].
   The basic feature set includes "cross-domain roving" and "single
   number reach-ability".  This document describes a SIP-based approach
   to support extended features such as bidirectional handovers across
   VoIP and cellular domains.

   The handovers described in this document are called "mobile assisted
   and network controlled" because the handovers are executed by a
   network element such as the mobility SIP proxy (MP-CSCF) or the
   cellular mobile switching center (MSC).  A mobile device (i.e.  DMH)
   assists the handover execution by reporting its measurement of radio
   signal quality of both cellular and WLAN base stations.  However, the
   handset does not have control over whether, when and where-to perform
   the handover.

   The approach described in this document assumes the network utilizes
   "Natural Anchoring" as described in [yafan-fmc-arch], which also
   requires the mobility SIP proxy (MP-CSCF) to have an inter-MSC
   peering relationship with the cellular network via the MAP E
   interface.

   The network diagrams in [yafan-fmc-arch] are reproduced here, with
   the addition of the MAP E/G interfaces.  Reader of this document is
   encouraged to read [yafan-fmc-arch] and be familiar with the
   concepts, and the basic feature set enabled by the framework in
   [yafan-fmc-arch].

   In cellular-homed scenario, the mobility SIP proxy (MP-CSCF) is an
   extension of the cellular network by acting as a full-featured mobile
   switching center (MSC/VLR).  In soft switch-homed scenario, the MP-
   CSCF is acting as an access or edge SIP proxy of the VoIP soft
   switch.  In both cases, SIP is used as the call control protocol in
   the VoIP domain.












An                      Expires January 29, 2007                [Page 4]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


1.1.  Cellular Homed Deployment

   Cellular-Homed System Architecture

                                           C / D          +--------+
                                      +-------------------|  HLR   |
                                      |                   +--------+
                                      |
                                      |    E              +--------+
                                      +-------------------|  SMSC  |
                                      |                   +--------+
      +---------------------------+   |
      | Mobility Proxy   +-----+  |   |    E / G          +---------+
      |                  | CSI |  |---+-------------------|  MSC /  |
      |  +-----------+___+-----+  |      +------+  +------|  VLR    |
      |  | SIP B2BUA |   | PSI |  | SIP  | MGCF |  | ISUP +---------+
      |  +-----------+   +-----+  |------+------+--+ /PRI     |
      +---------------------------+      |  MG  |         +---------+
               |                         +------+         | BSC/BTS |
               | SIP                                      +---------+
               |                                              |
           +-------+                                          |
           |  DMH  |-------------------------------------------
           +-------+

   This diagram does not suggest a particular grouping of functions into
   physical entities.
























An                      Expires January 29, 2007                [Page 5]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


1.2.  Soft Switch Homed Deployment

   Soft Switch-Homed System Architecture

         +---------------+       +-----------+
         |  Soft Switch  |.......| HLR / HSS |
         |    (S-CSCF)   |  Cx   +-----------+
         +---------------+        C/D |
               |                      |           E       +--------+
               | SIP                  +-------------------|  SMSC  |
               |                      |                   +--------+
      +---------------------------+   |
      | Mobility Proxy   +-----+  |   |           E / G   +---------+
      |                  | CSI |  |---+-------------------|  MSC /  |
      |  +-----------+___+-----+  |      +------+  +------|  VLR    |
      |  | SIP B2BUA |   | PSI |  | SIP  | MGCF |  | ISUP +---------+
      |  +-----------+   +-----+  |------+------+--+ /PRI     |
      +---------------------------+      |  MG  |         +---------+
               |                         +------+         | BSC/BTS |
               | SIP                                      +---------+
               |                                              |
           +-------+                                          |
           |  DMH  |-------------------------------------------
           +-------+

   This diagram does not suggest a particular grouping of functions into
   physical entities.

1.3.  Passing Extra Parameters with SIP Messages

   To perform a network-controlled fast handover, the MP-CSCF needs to
   obtain necessary cellular radio parameters from the dual mode
   handset.  In this document, such parameters are passed by utilizing
   MIME attachment to regular SIP messages, and the attached messages
   are collectively referred to as the "Session Handover Protocol
   (SHP)".

   Attaching SHP messages do not alter the basic semantics of SIP
   messages.  The SHP attachment MUST be able to co-exist with other
   existing attachment, such as the Session Description Protocol (SDP),
   and the attachment defined in [yafan-fmc-mcho].

   In this document, the SIP message flows and the functional aspect of
   SHP are presented first.  The detailed syntax definition of SHP is
   later presented in Section 8.






An                      Expires January 29, 2007                [Page 6]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


2.  Registration in VoIP Domain

   When registering to the VoIP network, the handset MUST use its public
   identifier, such as the MSISDN, in the REGISTER request URI.

2.1.  Registration Message Flow in Cellular-homed Scenario

   In cellular-homed deployment, SIP-REGISTER is mapped to Location-
   Update to the HLR in the DMH's home network.  In addition, SIP-
   REGISTER SHALL also configure the DMH in order to allow fast network-
   controlled handovers across VoIP and cellular domains.  In order for
   the MP-CSCF to authenticate the DMH using SIM-based credentials,
   AKAv1-MD5 [RFC3310] SHALL be used as the SIP authentication
   mechanisms in cellular-homed deployment.

   Updated access-type values:

   +-----+                      +----------+                 +---------+
   | DMH |----------------------| Visisted |-----------------|   Home  |
   +-----+                      | MP-CSCF  |                 | Net HLR |
      |      SIP: REGISTER      +----------+                 +---------+
      |------------------------------>|  MAP/D: SEND-AUTH-INFO     |
      |                               |--------------------------->|
      |                               |  MAP/D: SEND-AUTH-INFO res |
      |  SIP: 407 Unauthorized        |<---------------------------|
      |<------------------------------|                            |
      |     SIP: REGISTER             |                            |
      |------------------------------>|  MAP/D: LOCATION-UPDATE    |
      |                               |--------------------------->|
      |                               |  MAP/D: INSERT-SUB-DATA    |
      |                               |<---------------------------|
      |                               |  MAP/D: INSERT-SUB-RESULT  |
      |                               |--------------------------->|
      |                               |  +-------+ MAP/D: CANCEL   |
      |                               |  |MSC/VLR|<--------------->|
      |                               |  +-------+     LOCATION    |
      |                               |  MAP/D: LOC-UPDATE-RESULT  |
      |    SIP: 200 OK                |<---------------------------|
      |<------------------------------|                            |
      |                               |                            |

   REGISTER (DMH --> MP-CSCF) -- The purpose of this request is to
      register the user's SIP URI with the MP-CSCF in the home or
      visited GAN domain.  The MP-CSCF, or visited MP-CSCF authenticates
      the DMH to the VoIP network.  It is routed to the MP-CSCF since it
      is the SIP proxy known to the DMH.





An                      Expires January 29, 2007                [Page 7]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   MAP/D SEND-AUTHENTICATION-INFO exchange -- This optional exchange
      with the HLR is to retrieve the authentication triplets for the
      handset.  Since multiple authentication vectors can be retrieved
      in a single request, this exchange is used when the MP-CSCF has
      exhausted the authentication vectors.

      Noted that the MP-CSCF needs to know the IMSI of the DMH in order
      to retrieve the authentication vector from the HLR.  The DMH
      SHOULD use IMSI as its username during SIP authentication.  If SIP
      authentication is optional, then the IMSI MUST be provided in the
      attached Mobile Identity information element, see Section 8.

      The MAP/D SEND-AUTHENTICATION-INFO exchange can be performed only
      after the MP-CSCF has learned the proclaimed IMSI from the DMH.
      Therefore, the SIP REGISTER SHOULD include its credentials even it
      is not challenged, with its IMSI in the username field.  Please
      refer to [yafan-fmc-arch] for the syntax of username.

   407 -- The MP-CSCF forms a challenge based on the authentication
      vectors obtained from the HLR, and send the AKAv1-MD5 challenge to
      the DMH.

   REGISTER with credentials -- This REGISTER contains the challenge
      response.

   MAP/D LOCATION-UPDATE -- Upon successful authentication, the MP-CSCF
      performs Location-Update towards the HLR.  This transaction
      establishes that mobile-terminating calls are routed through the
      MP-CSCF via the MGCF/MG for terminating in the VoIP domain.

   200 OK -- If the Location-Update MAP exchange with the HLR is
      successful, the MP-CSCF returns 200 OK to the DMH.

      The errors occurred during MP-CSCF's location update procedure
      SHALL be propagated to the DMH.

      IMSI invalid: If the HLR returns error code indicating IMSI
         invalid, the MP-CSCF will return "404 Not Found" SIP message.

      Roaming not allowed: If the HLR returns error code indicating this
         subscriber is not allowed to roam into the GAN area served by
         this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message.

      Other errors: If the Location-Update exchange with the HLR results
         with other errors, such as timed out, the MP-CSCF returns "500
         Internal Server Error" SIP message to the DMH.





An                      Expires January 29, 2007                [Page 8]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


2.2.  Registration Message Flow in Soft Switch-homed Scenario

   In soft switch-homed deployment, SIP-REGISTER is forwarded to the
   soft switch (or S-CSCF) for authentication, and is then mapped to a
   Location-Update to the HLR.  Both S-CSCF and the HLR are in the DMH's
   home network.  In this deployment scenario, the S-CSCF may use non
   SIM-based authentication mechanism, such as the Digest-MD5
   authentication mechanism, for SIP authentication.

   Updated access-type values:

   +-----+                      +----------+                 +---------+
   | DMH |----------------------| Visisted |-----------------|   Home  |
   +-----+                      | MP-CSCF  |                 | Net HLR |
      |      SIP: REGISTER      +----------+                 +---------+
      |------------------------------>|     REGISTER     +--------+ |
      |                               |----------------->| S-CSCF | |
      |                               |     401          +--------+ |
      |      SIP: 401                 |<---------------------|      |
      |<------------------------------|                      |      |
      |      SIP: REGISTER            |                      |      |
      |------------------------------>|     REGISTER         |      |
      |                               |--------------------->|      |
      |                               |     200 OK           |      |
      |      SIP: 200 OK              |<---------------------|      |
      |<------------------------------|                             |
      |                               |  MAP/D: LOCATION-UPDATE     |
      |                               |---------------------------->|
      |                               |  MAP/D: INSERT-SUB-DATA     |
      |                               |<----------------------------|
      |                               |  MAP/D: INSERT-SUB-RESULT   |
      |                               |---------------------------->|
      |                               |  +-------+ MAP/D: CANCEL    |
      |                               |  |MSC/VLR|<---------------->|
      |                               |  +-------+     LOCATION     |
      |                               |  MAP/D: LOC-UPDATE-RESULT   |
      |    SIP: 200 OK                |<----------------------------|
      |<------------------------------|                             |
      |                               |                             |

   REGISTER (DMH --> MP-CSCF --> S-CSCF) -- The purpose of this request
      is to register the user's SIP URI with the S-CSCF in the VoIP
      domain.  The S-CSCF authenticates the DMH to the VoIP network.  It
      is routed to the MP-CSCF since it is the SIP proxy known to the
      DMH.






An                      Expires January 29, 2007                [Page 9]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      Note the AKAv1-MD5 mechanism is still preferred here, in which the
      MP-CSCF performs the authentication using SIM-based credentials.
      However, other existing SIP authentication mechanism, such as
      Digest-MD5, MAY still be used, in which case authentication is
      performed only by the Soft Switch.  The MP-CSCF only stores the
      status of the authentication by monitoring the authentication
      message flows.  A trust relation between the MP-CSCF and the
      S-CSCF SHALL be established.  Such trust relationship can be
      established by multiple means, such as a IPsec association, SSL
      association, or a simple site-wide username/password for all
      users.  Such trust relationship is necessary since, when the DMH
      is roved out, the MP-CSCF is maintaining registration with the
      S-CSCF on behalf of the DMH.  See Section 3 for details.

   MAP/D LOCATION-UPDATE exchange -- The Location-Update exchange is
      performed only when the DMH is successfully authenticated by the
      MP-CSCF or the S-CSCF.  The MP-CSCF must have learned the
      proclaimed IMSI from the DMH.  Therefore, the SIP REGISTER SHOULD
      include its credentials even it is not challenged, with its IMSI
      in the username field.

      The Location-Update transaction establishes that mobile-
      terminating calls are routed through the S-CSCF via the MGCF/MG
      for terminating in the VoIP domain.

   200 OK -- If the Location-Update MAP exchange with the HLR is
      successful, the MP-CSCF returns 200 OK to the DMH.

      The errors occurred during MP-CSCF's location update procedure
      shall be propagated to the DMH.

      IMSI invalid: If the HLR returns error code indicating IMSI
         invalid, the MP-CSCF will return "404 Not Found" SIP message.

      Roaming not allowed: If the HLR returns error code indicating this
         subscriber is not allowed to roam into the GAN area served by
         this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message.

      Other errors: If the Location-Update exchange with the HLR results
         with other errors, such as timed out, the MP-CSCF returns "500
         Internal Server Error" SIP message to the DMH.










An                      Expires January 29, 2007               [Page 10]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


2.3.  Examples of Registration Messages

   Example SIP REGISTER request which reports alternative radio networks
   :

      REGISTER sip:registrar.home1.net SIP/2.0
      Via: SIP/2.0/UDP ip4_adr:ip4_port; branch=z9hG4bKnashds7
      Max-Forwards: 70
      P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
      P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11
      P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF12
      From: <sip:user1_public1@home1.net>;tag=4fa3
      To: <sip:user1_public1@home1.net>
      Contact: <sip:ip4_adr; ip4_port>; expires=600000
      Accept: application/3GPP-SHP
      Call-ID: apb03a0s09dkjdfglkj49111
      CSeq: 1 REGISTER
      Content-Length:(...)
      Content-Type: multipart/mixed; boundary=unique_boundary_1
      MIME-Version: 1.0

      --unique_boundary_1.
         Content-Type: application/3GPP-SHP; version=V0.1
         Content-Disposition: signal; handling=required
         Content-Encoding: binary
         Content-Length=(...)

         01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
         43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
         53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
         0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
      --unique_boundary_1



















An                      Expires January 29, 2007               [Page 11]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Example 200 OK of REGISTER which assigns GAN cell-id:

     SIP/2.0 200 OK
     Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;branch=z9hG4bKnashds7
     P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
     From:
     To:
     Call-ID:
     Contact:
     Accept: application/3GPP-SHP
     CSeq: 1 REGISTER
     Date: Thu, 21 Feb 2005 13:02:03 -700
     Organization: Operator-Long-Name (Short-Name)
     Content-Length: 128
     Content-Type: multipart/mixed; boundary=unique_boundary_1
     MIME-Version: 1.0

     --unique_boundary_1.
        Content-Type: application/3GPP-SHP; version=V0.1
        Content-Disposition: signal; handling=required
        Content-Encoding: binary
        Content-Length=60

        01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
        43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
        53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
        0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
     --unique_boundary_1


   In the following sub-sections, the additional headers and bodies in
   the above message flow are explained.

2.4.  Alternative Access Network Information

   When a dual mode handset (DMH) is deployed for service across
   heterogeneous networks, such as WLAN and cellular, a DMH is involved
   in more than one access network.  Passing the information of the
   alternative access network information between the handset and the
   MP-CSCF is necessary during SIP registration.

2.4.1.  Reporting of P-Access-Network-Info

   The P-Access-Network-Info header is defined in [RFC3455].  SIP User
   Agents use this header to relay information about the access
   technology and location information to SIP proxies that are providing
   services.




An                      Expires January 29, 2007               [Page 12]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   If the DMH detects alternative access networks, such GSM cells, and
   wishes to achieve seamless service across multiple access networks,
   it SHOULD include multiple P-Access-Network-Info headers in the SIP
   REGISTER request.  The first P-Access-Network-Info header should be
   the network through which the SIP REGISTER is sent, the rest of
   multiple P-Access-Network-Info headers shall be in the order of
   preference.  For example, when the DMH detects GSM alternative access
   network, it shall include a separate P-Access-Network-Info header for
   each detected GSM cell, in the order of detected signal strength.  In
   these alternative P-Access-Network-Info headers, 3GPP-GERAN is the
   access-type, and cgi-3gpp is the access-info.

   In the above example, the REGISTER is sent through an IEEE-802.11a
   access point with SSID="ssid".  The DMH also detects two GSM cells,
   first one has a stronger signal than the second one.

   The Cell Global Id (CGI) coding, which is defined in [3GPP.48.008],
   includes the cell id which also represents rough geographical
   location.

   If the access type field is equal to "3GPP-GERAN", the access info
   field shall contain a value of "cgi-3gpp".  Its value includes the
   Cell Global Identity obtained from lower layers of the DMH.  This
   value is made up of a concatenation of the MCC, MNC, LAC and GSM
   cell-id.  Starting with the most significant bit: MCC (3 digits), MNC
   (2 or 3 digits depending on MCC value), LAC (fixed length code of 16
   bits using full hexadecimal representation) and CI (fixed length code
   of 16 bits using full hexadecimal representation).

   If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-
   TDD" or "3GPP-CDMA2000" the access-info field SHALL contain a value
   of "utran-cell-id-3gpp".  This value is made up of a concatenation of
   the MCC, MNC, LAC (as described in [3GPP.23.003]) and the UMTS Cell
   Identity (as described in [3GPP.25.331]), obtained from lower layers
   of the DMH, and is coded as a text string as follows:

   Starting with the most significant bit: MCC (3 digits), MNC (2 or 3
   digits depending on MCC value), LAC (fixed length code of 16 bits
   using full hexadecimal representation) and UMTS Cell Identity (fixed
   length code of 28 bits).

   If the access type is IEEE-802.11a/b/g, the extension-access-info
   field SHOULD contain the SSID of the access point.

2.4.2.  Assignment of P-Access-Network-Info

   Unlike cellular radio technology which broadcasts cell information to
   the handset, the VoIP network is agnostic to radio access



An                      Expires January 29, 2007               [Page 13]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   technologies.  With the reporting of location information as
   described above, the network SHOULD inform the DMH (and the
   subscriber) the network identity of the VoIP MP-CSCF.

   In the mobile assisted and network controlled handover, as described
   in this document, the MP-CSCF should be a local entity which has
   peering relationship with the local cellular network.  Note this
   network id is not the WLAN network id.  It is the pseudo cell-id of
   the MP-CSCF as appeared to the cellular network.

   The MP-CSCF SHOULD insert a P-Access-Network-Info header in the 200
   OK of SIP REGISTER response with the access-type of 3GPP-GAN,
   indicating this is a MP-CSCF which supports converged services with a
   3GPP network; and a 3gpp-cgi, which is the cell-id of the pseudo cell
   of the MP-CSCF as appeared to the cellular network.

   For 3GPP-GAN, the 3gpp-cgi coding SHALL be identical to that of 3GPP-
   GERAN.  It is the cell-id of the MP-CSCF cell that is provisioned in
   the neighbor cell list of the cellular network.

   The syntax of access-type defined in [RFC3455] is expanded:

                access-type = "IEEE-802.11a" / "IEEE-802.11b" /
                              "3GPP-GERAN" / "3GPP-UTRAN-FDD" /
                              "3GPP-UTRAN-TDD" / "3GPP-CDMA2000" /
                              "3GPP-GAN" / token

   When assigning a 3GPP-GAN cell, the MP-CSCF SHOULD also provide
   additional information to the DMH, using the extension-access-info
   field.

   The syntax of extension-access-info for 3GPP-GAN is as follows:

               extension-access-info = kv-pair-series
               kv-pair-series = kv-pair ["," kv-pair-series]
               kv-pair = key EQUAL value
               key = "BSIC" / "BCCH-FREQ" / "HANDOVER"

               value = [0...63] if key="BSIC"
               value = [0...31] if key="BCCH-FREQ"
               value = [0...255] if key="HANDOVER"

   The extension-access-info parameter for 3GPP-GAN is only used for
   network controlled handover.  BSIC is the Base Station Identity Code
   of the GAN cell; BCCH-FREQ is the pseudo frequency number of the GAN-
   cell; HANDOVER is the handover pseudo handover reference number.

   Note, the reporting and assignment of 3GPP-GAN cell information is



An                      Expires January 29, 2007               [Page 14]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   required in the SIP REGISTER transaction.  However, the assignment of
   the extension-access-info is optional during the SIP-REGISTER
   response.  The HANDOVER tag is not used in the SIP-REGISTER
   transaction.  The assignment of extension-access-info is required in
   Hand-Out as described in Section 6.  The syntax is described here for
   convenience reasons.

2.5.  Cellular Radio Information

   In order for the network to initiate a network-controlled handover,
   the VoIP network needs to know the capability of the DMH's cellular
   radio.  In particular, the classmark information of the 3GPP handset
   needs to be reported to the MP-CSCF.

2.5.1.  Cellular Radio Information Reporting

   The reporting of DMH's classmark is achieved by attaching a 3GPP-SHP
   message body to the SIP-REGISTER message.

   To achieve full service, the DMH SHOULD carry an MIME attachment of
   3GPP-SHP's REGISTER-REQUEST message body.  The message body must be
   attached according to [RFC3261] and [RFC3204].  The content of the
   SHP REGISTER-REQUEST message contains the classmark information of
   the handset.  The message format and encoding are described in
   Section 8.

   An example of SIP-REGISTER with 3GPP-SHP REGISTER-REQUEST is shown in
   Section 2.3.

2.5.2.  Cellular Radio Information Acknowledgement

   If the SIP REGISTER request contains an attachment of 3GPP-SHP
   REGISTER REQUEST message body, the 200 OK response to the SIP
   REGISTER request MUST attach a 3GPP-SHP REGISTER-ACCEPT message.  The
   current version of the SHP, the SHP REGISTER-ACCEPT is optional.

   An example of SIP-REGISTER with 3GPP-SHP REGISTER-ACCEPT is shown in
   Section 2.3.

2.6.  TMSI Assignment

   In 3GPP GSM network, a Temporary Mobile Station Identifier (TMSI) is
   assigned to a mobile station for privacy purposes.  When a mobile
   station performs a fresh registration, e.g. during every power-on,
   the handset must send its IMSI to the base station in the clear
   before an encryption key can be generated.

   Since IMSI is a private Id assigned by the network to a mobile



An                      Expires January 29, 2007               [Page 15]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   device, the operators wish to minimize the transmission of the IMSI
   identifier without any encryption being applied.  Therefore, TMSI is
   used when a handset roams from MSC to MSC.

   For a dual mode handset, there are rove-in and rove-out operations,
   where the handset switches network from WLAN to/from cellular in a
   rather frequent manner.  Roving operations may be frequent due to the
   small coverage range of WLAN networks and the coverage might have
   holes.

   To avoid the use of IMSI during rove-out, the MP-CSCF assigns a TMSI
   to the handset during SIP registration.  The TMSI is passed down to
   the DMH in the 200 OK response of SIP REGISTER.  The TMSI allocated
   for the DMH is only valid between the DMH and the MP-CSCF.  As in
   3GPP network, the TMSI is a unique value for the LAC area on the MP-
   CSCF only.

2.6.1.  Use of P-Associated-URI for TMSI Assignment

   In the 200 OK response to SIP REGISTER, the allocated TMSI is
   included in the P-Associated-URI header.  The P-Associated-URI header
   is defined in [RFC3455].  Since the TMSI is only valid between the
   DMH and the MP-CSCF, it SHALL be in the form of

   The syntax of P-Associated-URI:

       P-Associated-URI: <sip:TMSI-ABCDABCD@mp_cscf_adr:mp_cscf_port>

   The string after the TMSI-, i.e.  ABCDABCD, is the hex value of the
   4-byte TMSI value.  Note the URI SHOULD only use the address and port
   of the MP-CSCF, which may be different from that of the SIP URI's
   realm and port.  When this P-Associated-URI is passed from the MP-
   CSCF to the DMH, it means that it is an alternative URI for the
   registered URI, and can be used interchangeably between the DMH and
   the MP-CSCF.

   An example of 200 OK with TMSI assigned is shown in Section 2.3.














An                      Expires January 29, 2007               [Page 16]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


3.  Rove-Out: From WLAN to Cellular

   The Rove-Out message flow between the DMH and the MP-CSCF is
   identical to that of [yafan-fmc-arch].  But, in this document, the
   message flow has extra Information fields exchanged between the DMH
   and the MP-CSCF.

   In particular, when the TMSI and the LAI (i.e., Location Area
   Indicator portion of the GAN cell-id) are available, the handset MUST
   use them, instead of the IMSI, while logging on to the cellular
   network.

   The benefit of using TMSI, instead of IMSI, is that IMSI will not be
   transmitted in the clear, and the cellular MSC will query the MP-CSCF
   to retrieve the IMSI of the handset.  The LAI of the GAN cell-id is
   used by the MSC to derive routing information to the MP-CSCF.

   The message sequence charts below are for information only.  Non-SIP
   messages in the charts are not part of the requirements for
   compliance to this document.































An                      Expires January 29, 2007               [Page 17]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Rove-Out Message Flow for Cellular-Homed DMH:

                         Visited   Target                        Target
    DMH                  MP-CSCF    BSC           HLR            MSC/VLR
     |                      |        |             |                 |
     |  SIP: REGISTER       |        |             |                 |
     |--------------------->|        |             |                 |
     |                      |   < Intermediate messages skipped >    |
     |  SIP 200 OK          |        |             |                 |
     |<---------------------|        |             |                 |
     |  (gan-cgi, tmsi)     |        |             |                 |
     |                      |        |             |                 |
     |  BCCH: Signal==Good  |        |             |                 |
     |<------------------------------|             |                 |
     |  RR: CHAN REQ/ASS    |        |             |                 |
     |<----------------------------->|             |                 |
     |                      |        |             |                 |
     |  MM: LOC UPDATE (previous-LAI=gan-lai, TMSI=tmsi )            |
     |------------------------------>|------------------------------>|
     |                      |       MAP/G: SEND PARMS (tmsi)         |
     |                      |<---------------------------------------|
     |                      |       MAP/G: SEND PARMS res (imsi)     |
     |                      |--------------------------------------->|
     |                      |        |             |  LOC UPD        |
     |                      |        |             |<----------------|
     |               < Intermediate messages skipped >               |
     |                      |        |             |  LOC UPD res    |
     |                      |        |             |---------------->|
     |  MM: LOC UPD ACCEPT  |        |             |                 |
     |<--------------------------------------------------------------|
     |  SIP: de-REGISTER    |        |             |                 |
     |--------------------->|        |             |                 |
     |  SIP: 200 OK         |        |             |                 |
     |<---------------------|        |             |                 |

















An                      Expires January 29, 2007               [Page 18]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Rove-Out Message Flow for Soft Switch-Homed DMH:

                         Visited   Target                        Target
    DMH                  MP-CSCF    BSC           HLR   S-CSCF   MSC/VLR
     |  SIP: REGISTER       |        |             |      |          |
     |--------------------->|       SIP: REGISTER  |      |          |
     |                      |---------------------------->|          |
     |                      |       SIP: 200 OK    |      |          |
     |  SIP 200 OK          |<----------------------------|          |
     |<---------------------|        |             |      |          |
     |  (gan-cgi, tmsi)     |        |             |      |          |
     |                      |        |             |      |          |
     |  BCCH: Signal==Good  |        |             |      |          |
     |<------------------------------|             |      |          |
     |  RR: CHAN REQ/ASS    |        |             |      |          |
     |<----------------------------->|             |      |          |
     |  MM: LOC UPDATE      |        |             |  MAP: LOC UPD   |
     |------------------------------>|------------------------------>|
     |               < The rest of messages are identical >          |
     |               < to the cellular homed case shown above >      |
     |  MM: LOC UPD ACCEPT  |        |             |      |          |
     |<--------------------------------------------------------------|
     |  SIP: de-REGISTER    |        |             |      |          |
     |--------------------->|        | REGISTER (trust)   |          |
     |  SIP: 200 OK         |---------------------------->|          |
     |<---------------------|        | 200 OK      |      |          |
     |                      |<----------------------------|          |
























An                      Expires January 29, 2007               [Page 19]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


4.  Rove-In: From Cellular to WLAN

   Rove-in message flow is identical to the SIP registration flows
   described in Section 2.

   Since it is required to use a secure transport protocol to transmit
   SIP messages, thus it is safe for the DMH to use IMSI as username.












































An                      Expires January 29, 2007               [Page 20]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


5.  Call Setup in VoIP Domain with Cellular Crypto Setup

   Call origination and termination in the VoIP domain follows the same
   message flow as in [yafan-fmc-arch].  However, to be prepared for a
   potential hand-out, cellular (e.g.  GSM) encryption keys SHOULD be
   generated during SIP call setup phase.

   In a normal 3GPP voice call, voice signaling and bearer are
   encrypted.  The encryption key are derived during the handset
   authentication phase.  During handover from one MSC to another, the
   key derivation phase is omitted for performance reasons.  The
   encryption material is instead transferred from the source MSC to the
   target MSC during handover.

   Due to the small coverage range of WLAN, a faster handout is
   perceived as an important requirement.  Therefore, a pair of cellular
   encryption is derived during SIP call setup phase.  The crypto
   material is then transferred from the MP-CSCF to the target MSC
   during hand-out.

   It should be noted that, when AKAv1-MD5 ([RFC3310] is utilized as the
   authentication mechanism between the dual mode handset (DMH) and the
   MP-CSCF, the challenge and response algorithm of AKAv1-MD5 already
   provides a key distribution mechanism that could be used for cellular
   encryption after hand-out.  In which case the mechanism in this
   section may become unnecessary.

   However, AKAv1-MD5 assumes IMS SIM (or ISIM) and the HLR/HSS supports
   the AKA algorithm.  This may pose a deployment restriction for some
   time to come.

   By utilizing the mechanism described in this section, a deployment
   MAY choose to use another authentication mechanism, such as Digest-
   MD5 for authentication, yet still achieve adequate security for hand-
   out.
















An                      Expires January 29, 2007               [Page 21]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


5.1.  Call Origination Message Flow

   Call Origination in VoIP Domain for SS-homed and Cellular-Homed DMH:

                         Visited                        S-CSCF or
     DMH                 MP-CSCF                  HLR   MGCF/MGW    GMSC
      |  SIP: INVITE (sdp)  |                      |      |          |
      |-------------------->| MAP/D: SEND AUTH INFO|      |          |
      |                     |--------------------->|      |          |
      |                     | MAP/D: SAI result    |      |          |
      |                     |<---------------------|      |          |
      |                     |   SIP: INVITE (sdp)  |      |          |
      |                     |---------------------------->|          |
      |               < Intermediate messages skipped >   |          |
      |                     |   SIP: 200 OK (sdp)  |      |          |
      |  SIP: 200 OK (sdp,  |<----------------------------|          |
      |<--------------------|                      |      |          |
      |   SHP-Cipher-CMD)   |                      |      |          |
      |                     |                      |      |          |
      |  SIP: ACK (         |                      |      |          |
      |-------------------->|   SIP: ACK           |      |          |
      |   SHP-Cipher-COM)   |---------------------------->|          |
      |                     |                      |      |          |

   Cellular-homed calls are routed through the MGCF, Soft Switch-homed
   calls are routed through the S-CSCF.

   INVITE (DMH --> MP-CSCF) -- The SIP UA on the DMH send a normal SIP
      INVITE to initiate a call.  The normal SDP offer and answer occurs
      during this INVITE transaction.  Normal authentication challenge
      and responses are omitted in the above diagram.

   MAP/D SEND AUTHENTICATION INFO exchange -- The SAI exchange is
      performed only when MP-CSCF does not have any unused cellular
      authentication vectors.  The purpose of this exchange is to
      retrieve new authentication vectors from the HLR/AuC.  One
      authentication vector is needed for each call setup to derive a
      new cellular encryption/decryption key.

      If no authentication vector is available and SAI failed to obtain
      new authentication vectors, the call MAY still be allowed to set
      up without cellular crypto key prepared.  The MP-CSF may reject
      hand-out request according to security policy settings.

   200 OK -- The 200 OK, which may contain a SDP answer from the called
      party, SHALL contain a SHP-CIPHER-COMMAND body inserted by the MP-
      CSCF.  The SHP-CIPHER-COMMAND SHALL be used by the DMH to
      configure the codec, crypto keys and algorithm for any potential



An                      Expires January 29, 2007               [Page 22]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      handover to the cellular network.

      The SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange follows
      the Request/Response model.  The Request is sent by a network
      element like the MP-CSCF, the Response is sent by a mobile device.
      Once a Request is offered, it MUST be answered by a Response.

   ACK -- If a SHP-CIPHER-COMMAND is attached to the received 200 OK
      message, the DMH MUST attach an SHP-CIPHER-COMPLETE to the SIP
      ACK.  The SHP-CIPHER-COMPLETE message contain a MAC code so that
      the MP-CSCF can verify that the crypto key is successfully
      generated by the DMH for potential hand-out.

      When the DMH generates the SHP-CIPHER-COMPLETE message, it has
      created a crypto key according to the cellular standard.  The DMH
      MUST store this key for use as the crypto key after hand-out.

5.2.  Call Termination Message Flow

   Call Termination in VoIP Domain for SS-homed and Cellular-Homed DMH:































An                      Expires January 29, 2007               [Page 23]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


     Cellular-homed DMH:
                        Visited
    DMH                 MP-CSCF                  HLR   MGCF/MGW    GMSC
     |                     |                      |      |          |
     |                     |                      |   MAP/C: SRI    |<--
     |                     | MAP/D: PRO ROUTE INFO|<----------------|IAM
     |                     |<---------------------|      |          |
     |                     | MAP/D: PRI (msrn)    |      |          |
     |                     |--------------------->| MAP/C: SRI(msrn)|
     |                     |                      |---------------->|
     |                     |  SIP: INVITE (msrn)  |      | IAM      |
     |                     |<----------------------------|<---------|
     |                     |                      |      |          |
     |                     | MAP/D: SEND AUTH INFO|      |          |
     |                     |--------------------->|      |          |
     |                     | MAP/D: SAI result    |      |          |
     |  SIP: INVITE (sdp,  |<---------------------|      |          |
     |<--------------------|                      |      |          |
     |   SHP-Cipher-COM)   |                      |      |          |
     |                     |                      |      |          |
     |  SIP: 200 OK (sdp,  |                      |      |          |
     |-------------------->|    SIP: 200 OK (sdp) |      |          |
     |   SHP-Cipher-COM)   |---------------------------->|          |
     |                     |                      |      |          |
                     <... Intermediate messages skipped ...>

     Soft Switch-homed DMH:
                       Visited                                  Circuit
    DMH                MP-CSCF                  HLR   S-CSCF     Switch
     |                     |                      |      |          |
     |                     |     SIP: INVITE      |      |   IAM    |
     |                     |<----------------------------|<---------|
     |                     | MAP/D: SEND AUTH INFO|      |          |
     |                     |--------------------->|      |          |
     |                     | MAP/D: SAI result    |      |          |
     |  SIP: INVITE (sdp,  |<---------------------|      |          |
     |<--------------------|                      |      |          |
     |   SHP-Cipher-COM)   |                      |      |          |
     |                     |                      |      |          |
     |  SIP: 200 OK (sdp,  |                      |      |          |
     |-------------------->|    SIP: 200 OK (sdp) |      |          |
     |   SHP-Cipher-COM)   |---------------------------->|          |
     |                     |                      |      |          |
                     <... Intermediate messages skipped ...>

   Cellular-homed calls are routed through the MGCF, Soft Switch-homed
   calls are routed through the S-CSCF.




An                      Expires January 29, 2007               [Page 24]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   General routing mechanism for mobile-terminated calls is described in
   [yafan-fmc-arch].

   MP-CSCF Receives INVITE -- The MP-CSCF receives a normal SIP INVITE
      for a mobile-terminated call.  The normal SDP offer and answer
      occurs during this INVITE transaction.

   MAP/D SEND AUTHENTICATION INFO exchange -- In order to prepare the
      crypto key for this call for potential hand-out, the MP-CSCF needs
      a fresh cellular authentication vector.  This SAI exchange is
      performed only when the MP-CSCF does not have any unused cellular
      authentication vectors.  The purpose of this exchange is to
      retrieve new authentication vectors from the HLR/AuC.  One
      authentication vector is needed for each call to derive a new
      cellular encryption/decryption key.

      If no authentication vector is available and SAI failed to obtain
      new authentication vectors, the call may still be allowed to set
      up without cellular crypto key prepared.  The MP-CSF MAY reject
      hand-out request according to security policy settings.

   INVITE (MP-CSCF --> DMH -- The INVITE, which may already contain a
      SDP answer from the called party, SHALL contain a SHP-CIPHER-
      COMMAND body inserted by the MP-CSCF.  The SHP-CIPHER-COMMAND
      SHALL be used by the DMH to configure the codec, crypto key and
      algorithm for any potential handover to the cellular network.

      The SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange follows
      the Request/Response model.  The Request is sent by a network
      element like the MP-CSCF, the Response is sent by a mobile device.
      Once a Request is offered, it MUST be answered by a Response.

   200 OK (DMH --&gt> MP-CSCF -- If a SHP-CIPHER-COMMAND was attached to
      the received INVITE message, the DMH MUST attach an SHP-CIPHER-
      COMPLETE to the 200 OK response.  The SHP-CIPHER-COMPLETE message
      contains a MAC code so that MP-CSCF can verify that crypto key is
      successfully generated by the DMH for potential hand-out.

      When the DMH generates the SHP-CIPHER-COMPLETE message, it creates
      a crypto key according to the cellular standard.  The DMH MUST
      store this key for use as the crypto key after hand-out.










An                      Expires January 29, 2007               [Page 25]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


5.3.  Examples of Call Setup Messages

   INVITE in Call Origination (DMH --> MP-CSCF

       INVITE sip:user2_public1@home2.net SIP/2.0
       Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
       Max-Forwards: 70
       P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
       From: <sip:user1_public1@home1.net>;tag=171828
       To: <sip:user2_public1@home2.net>
       Call-ID: cb03a0s09a2sdfglkj490333
       Cseq: 127 INVITE
       Supported: 100rel
       Contact: <sip:ms_ip4_adr:ms_ip4_port>
       Allow: INVITE, ACK, UPDATE, CANCEL, BYE, REFER
       Accept: application/sdp, application/3GPP-SHP
       Accept-Encoding: base64, binary
       Content-Type: application/sdp
       Content-Length: (.)

       v=0
       o=- 2987933615 2987933615 IN IP4 ms_ip4_adr
       s=-
       c=IN IP4 ms_ip4_adr
       t=0 0
       m=audio 3456 RTP/AVP 97 96
       a=rtpmap:97 AMR
       a=fmtp:97 mode-set=0,2,5,7; maxframes=2
       a=rtpmap:96 telephone-event






















An                      Expires January 29, 2007               [Page 26]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   200 OK in Call Origination (MP-CSCF --> DMH

         SIP/2.0 200 OK
         Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;
                          branch=z9hG4bKnashds7, SIP/2.0/UDP
         From: <sip:user1_public1@home1.net>;tag=171828
         To: <sip:user2_public1@home2.net>
         Call-ID: cb03a0s09a2sdfglkj490333
         CSeq: (.)
         Contact: <sip:user1_public1@mp_cscf_ip_adr:mp_cscf_port>
         Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
         Accept: application/sdp, application/3GPP-SHP
         Content-Length: (...)
         Content-Type: multipart/mixed; boundary=unique_boundary_1
         MIME-Version: 1.0

         --unique_boundary_1
         Content-Type: application/sdp
         Content-Length: (...)

         v=0
         o=- 2987933615 2987933615 IN IP4 internal_ip4_adr
         s=-
         c=IN IP4 peer_ip4_adr
         t=0 0
         m=audio 6544 RTP/AVP 97 96
         a=rtpmap:97 AMR
         a=fmtp:97 mode-set=0,2,5,7; maxframes=2
         a=rtpmap:96 telephone-event

         --unique_boundary_1--
            Content-Type: application/3GPP-SHP; version=V0.1
            Content-Disposition: signal; handling=required
            Content-Encoding: binary
            Content-Length=60

            01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
            43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
            53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
            0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
         --unique_boundary_1--

   The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
   COMMAND message.







An                      Expires January 29, 2007               [Page 27]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   200 OK in Call Origination (MP-CSCF --> DMH

            ACK sip:ms_ip4_adr:ms_ip4_port SIP/2.0
            Via: SIP/2.0/UDP ms_ip_adr:ms_port;
                             branch=z9hG4bKnashds7, SIP/2.0/UDP
            From: <sip:user1_public1@home1.net>;tag=171828
            To: <sip:user2_public1@home2.net>
            Call-ID: cb03a0s09a2sdfglkj490333
            CSeq: (.)
            Contact: <sip:user1_public1@ms_ip_adr:ms_port>
            Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
            Accept: application/sdp, application/3GPP-SHP
            Content-Type: application/3GPP-SHP
            Content-Length: (...)

               Content-Type: application/3GPP-SHP; version=V0.1
               Content-Disposition: signal; handling=required
               Content-Encoding: binary
               Content-Length=60

               01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
               43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
               53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
               0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00


   The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
   COMPLETE message.























An                      Expires January 29, 2007               [Page 28]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   INVITE in Call Termination (MP-CSCF --> DMH

         INVITE sip:user1_public1@home1.net SIP/2.0
         Via: SIP/2.0/UDP mp_cscf_ip4_adr:mp_cscf_ip4_port;
                          branch=z9hG4bKnashds7
         Max-Forwards: 70
         From: <sip:user2_public1@home2.net>;tag=171828
         To: <sip:user1_public1@home1.net>
         Call-ID: cb03a0s09a2sdfglkj490333
         Cseq: 127 INVITE
         Supported: 100rel
         Contact: <sip:user2_public1@mp_cscf_ip_adr:mp_cscf_port>
         Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
         Accept: application/sdp, application/3GPP-SHP
         Content-Type: multipart/mixed; boundary=unique_boundary_1
         MIME-Version: 1.0
         Content-Length: (...)

         --unique_boundary_1
         Content-Type: application/sdp
         Content-Length: (...)

         v=0
         o=- 2987933615 2987933615 IN IP4 peer_ip4_adr
         s=-
         c=IN IP4 peer_ip4_adr
         t=0 0
         m=audio 3456 RTP/AVP 97 96
         a=rtpmap:97 AMR
         a=fmtp:97 mode-set=0,2,5,7; maxframes=2
         a=rtpmap:96 telephone-event

         --unique_boundary_1--
            Content-Type: application/3GPP-SHP; version=V0.1
            Content-Disposition: signal; handling=required
            Content-Encoding: binary
            Content-Length=60

            01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
            43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
            53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
            0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
         --unique_boundary_1--

   The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
   COMMAND message.





An                      Expires January 29, 2007               [Page 29]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   INVITE in Call Termiination (MP-CSCF --> DMH

         SIP/2.0 200 OK
         Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_adr;
                          branch= z9hG4bKnashds7, SIP/2.0/UDP
         From: <sip:user1_public1@home1.net>;tag=171828
         To: <sip:user2_public1@home2.net>
         Call-ID: cb03a0s09a2sdfglkj490333
         CSeq: (.)
         Allow: INVITE, ACK, UPDATE, CANCEL, BYE, REFER
         Accept: application/sdp, application/3GPP-SHP
         Content-Length: (...)
         Content-Type: multipart/mixed; boundary=unique_boundary_1
         MIME-Version: 1.0

         --unique_boundary_1
         Content-Type: application/sdp
         Content-Length: (...)

         v=0
         o=- 2987933615 2987933615 IN IP4 ms_ip4_adr
         s=-
         c=IN IP4 ms_ip4_adr
         t=0 0
         m=audio 6544 RTP/AVP 97 96
         a=rtpmap:97 AMR
         a=fmtp:97 mode-set=0,2,5,7; maxframes=2
         a=rtpmap:96 telephone-event

         --unique_boundary_1--
            Content-Type: application/3GPP-SHP; version=V0.1
            Content-Disposition: signal; handling=required
            Content-Encoding: binary
            Content-Length=60

            01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
            43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
            53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
            0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
         --unique_boundary_1--

   The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
   COMPLETE message.

5.4.  3GPP GSM Crypto Setup

   Crypto setup in preparation for a potential hand-out is carried by
   the SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange.  When the



An                      Expires January 29, 2007               [Page 30]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   hand-out is from WLAN to GSM, the crypto key is prepared according to
   GSM encryption algorithm.

   The SHP-CIPHER-COMMAND is always sent by an network element, such as
   the MP-CSCF, and the SHP-CIPHER-COMPLETE is always responded by the
   mobile device.  During a call setup, either origination or
   termination, the SHP-CIPHER-COMMAND message is attached to the first
   downstream message from MP-CSCF to the DMH, and the SHP-CIPHER-
   COMPLETE is attached to the first upstream message from the DMH to
   the MP-CSCF.

   The key elements in the SHP-CIPHER-COMMAND are the cipher mode
   setting and the RAND, a random number that the MP-CSCF retrieved from
   the HLR/AuC, or generated by itself.  The key element in the SHP-
   CIPHER-COMPLETE message is the Message Authentication Code (MAC)
   computed by the DMH according to cipher mode setting using the RAND
   in the SHP-CIPHER-COMMAND message.  The MAC is verified by the MP-
   CSCF to authenticate that the DMH has the correct key Kc.

































An                      Expires January 29, 2007               [Page 31]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


6.  Hand-Out from WLAN to Cellular

   A hand-out operation is a procedure to transfer an active session
   from a generic access network to a cellular access network.

   After a successful SIP registration with the home or visited MP-CSCF,
   who returned a configured P-Access-Network-Info field, the DMH will
   be able to perform seamless hand-out to a cellular network by
   treating the MP-CSCF as a MSC/BSC.  The CGI field values of MCC, MNC,
   LAC, cell-ID, and TMSI fields obtained during SIP registration MUST
   be used during the hand-out operation.

   During the current or any previous SIP INVITE sequence, the DMH and
   MP-CSCF have also prepared a crypto key to be used by the DMH and the
   target BSC after handover.  Such a crypto key MUST be used by the DMH
   for signaling and voice bearer encryption immediately after hand-out.

6.1.  Hand-Out Trigger Detection

   In network-controlled hand-out, hand-out trigger detection is a two-
   step process:

   Handset Request: While in an active voice call, the DMH must
      periodically scan for cellular signals when the GAN radio signal
      shows any sign of weakening.  The DMH determines to issue a hand-
      out request to the MP-CSCF based on its local hand-out policy.
      The local hand-out policy is outside the scope of this
      specification.

   Network Control: The hand-out request issued to the MP-CSCF is
      further screened by the MP-CSCF.  The MP-CSCF may ignore the
      request, or execute on the request and instructs the DMH to hand-
      out.

   In executing a hand-out, the MP-CSCF selects a target cellular MSC
   based on the hand-out request from the DMH and a network policy (such
   as a overload control policy).  The selection may be different from
   the preferences indicated by the DMH in the request.  The network
   policy is outside the scope of this specification.

6.2.  Hand-Out Message Flow

   From the handset's perspective, hand-out signaling is common for both
   soft switch-homed and cellular-homed subscribers.

   In the example message flow below, it starts with an active call,
   which is a mobile-terminated call from user2_public@home2.net to
   user1_public@home1.net, and the call is active.



An                      Expires January 29, 2007               [Page 32]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Hand-out message flow for SS-homed and Cellular-Homed DMH:

             Target                    S-CSCF    HO      Target     Peer
    DMH      BSC/BTS    MP-CSCF        MGCF-1   MGCF-2   MSC/VLR Network
     |         |           |             |        |        |          |
     | <== active call ==> | <== call ==>|<== active call ==========> |
     |         |           |             |        |        |          |
     |   SIP: INFO         |             |        |        |          |
     |-------------------->| MAP/E: PREPARE-HO (ho_no_req) |          |
     |   (SHP-HO-REQUEST)  |------------------------------>|          |
     |         |           |     A: HO-REQUEST    |        |          |
     |         |<------------------------------------------|          |
     |         |           |     A: HO-REQUEST ACK|        |          |
     |         |------------------------------------------>|          |
     |         |           | MAP/E: PREP-HO res (ho_no)    |          |
     |         |           |<------------------------------|          |
     |         |           | SIP: INVITE (ho_no,  |  IAM   |          |
     |         |           |--------------------->|------->|          |
     |         |           |       peer_sdp)      |        |          |
     |         |           | SIP: 183             |  ACM   |          |
     |         |           |<---------------------|<-------|          |
     |         |           |    <... PRACK omitted ...>   |          |
     |         |           |             |        |        |          |
     |   SIP: REFER        |   SIP: UPDATE/INVITE (ho_sdp) |          |
     |<--------------------|------------>|--------------------------->|
     |    (SHP-HO-CMD)     |             |        |        |          |
     |   SIP: 202 ACCEPTED |   200 OK    |     200 OK (peer_sdp)      |
     |-------------------->|<------------|<---------------------------|
     |    (SHP-HO-COM)     |     A: HO-DETECT, HO-COMPLETE |          |
     |........>|------------------------------------------>|          |
     |         |           | SIP: 200 OK |        |  ANM   |          |
     |         |           |<---------------------|<-------|          |
     |         |           | <== call ==>|<== active call ==========> |
     |         |           | <== active call ===> |        |          |
     |         |           |             |        |        |          |
     |         |           | MAP/E: SEND-END-SIGNAL        |          |
     |         |           |<------------------------------|          |
     |         |           |             |        |        |          |
                     <... Intermediate messages skipped ...>

6.3.  Reporting of Cellular Radio Conditions

   During an active call in the GAN network, the DMH must periodically
   monitor the signal quality of the surrounding cellular cells.  In
   GSM, the broadcast channel is the BCCH.  The BCCH broadcasts the cell
   information of the GSM cell, which includes the Location Area
   Identifier (LAI) and the cell-id.




An                      Expires January 29, 2007               [Page 33]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   If a phase-1 hand-out trigger is detected as described in
   Section 6.1, the DMH SHALL start sending SIP INFO messages to report
   the radio conditions.  Note, the SIP-INFO SHOULD not be generated
   with less than 400ms apart.

   The SIP-INFO message SHOULD contain a single attachment of SHP-HO-
   REQUEST message.  The following shows an example of such a SIP-INFO
   message.

   Example SIP-INFO message with cellular radio reporting:

       INFO sip:user2_public1@home2.net SIP/2.0
       Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
       Max-Forwards: 70
       P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
       From: <sip:user1_public1@home1.net>;tag=171828
       To: <sip:user2_public1@home2.net>
       Call-ID: cb03a0s09a2sdfglkj490333
       Contact: <sip:user2_public1@ms_ip4_adr:ms_ip4_port>
       Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO, REFER
       Cseq: 128 INFO
       Supported: 100rel
       Accept: application/3GPP-SHP
       Accept-Encoding: base64, binary
       Content-Type: application/3GPP-SHP; version=V0.1
       Content-Disposition: signal; handling=optional
       Content-Encoding: binary
       Content-Length=60

          01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
          43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
          53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
          0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00

   The INFO message body is the SHP-HANDOUT-REQUEST message, which
   contains a cell identifier list of the neighboring 3GPP cells and
   their signal strength measurement result.  The "handling" indicator
   in the Content-Disposition header is used to indicate the urgency of
   the request:

   handling=optional-- indicates less urgency for handover.  The DMH
      hopes the message body to be processed and a hand-out be executed.
      If the MP-CSCF is not in an overload situation, it SHOULD process
      the request.  If not processed, the DMH may be expected to send a
      request again should the condition persists.






An                      Expires January 29, 2007               [Page 34]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   handling=required-- indicates urgency for handover.  The DMH request
      the message body to be processed.  If not, it is very likely it
      will send a request again in about 400ms.

   The 200 OK returned for the SIP-INFO does not indicate a hand-out is
   granted.  It only indicates that the SIP-INFO is processed okay.

   Error code for the SIP-INFO method includes:

      481 Call Leg/Transaction Does Not Exist

      415 Unsupported Media Type, if there is error decoding the body,
      or the body is not recognized by any network proxy.

   It is NOT recommended to include other bodies together with the SHP
   bodies because the SHP-HO-REQUEST is intended for a 3GPP-SHP
   application.  This body will be consumed by the proxy in the SIP
   forwarding path which supports the intended application, while other
   bodies might be intended for other applications, which may or may not
   reside together with the 3GPP-SHP application.  Such cases might
   cause confusion in processing the (potentially multiple) responses.

6.4.  Network Controlled Hand-out

   Once the MP-CSCF receives a SIP-INFO with SHP-HANDOUT-REQUEST, it
   processes the SIP-INFO and the attached body based the following
   factors:

   Local Policy -- Local policy as mentioned in Section 6.1;

   Urgency -- Whether "handling=optional/required" was sent by the DMH;

   Network Condition -- Conditions of the network.

   Note this specification does not mandate any particular policy
   implementation.

   Once the MP-CSCF decides to execute a hand-out, it selects a target
   cell from the reported candidate cell list, and uses the CSI function
   of the MP-CSCF to request a handover-number from the target MSC/VLR,
   and starts setting up the handover leg toward the target MSC.

   Once the handover-leg is set up, the MP-CSCF sends a SIP-REFER
   message to the DMH to tear down the previous call-leg and switch to
   the cellular radio immediately.  The REFER message contains a SHP-HO-
   COMMAND message, which specifies cellular radio channel and other
   information.




An                      Expires January 29, 2007               [Page 35]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Example SIP-REFER message with SHP-HO-COMMAND body:

       REFER sip:user1_public1@home1.net SIP/2.0
       Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
       Max-Forwards: 70
       P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
       From: <sip:user1_public1@home1.net>;tag=171828
       To: <sip:user2_public1@home2.net>
       Call-ID: (...)
       Accept: application/3GPP-SHP
       Cseq: 128 REFER
       Refer-To: sip:user1_public1@home1.net
       Contact: <sip:mp_cscf_ip4_adr:mp_cscf_ip4_port>
       Content-Type: application/3GPP-SHP; version=V0.1
       Content-Disposition: signal; handling=required
       Content-Encoding: binary
       Content-Length=60

          01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
          43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
          53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
          0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00

   The Request-URI (the URI that follows the method name, "REFER", in
   the first line) indicates the user this request addresses.  In the
   above example, the MP-CSCF is requesting the user to transfer his own
   session to a different resource; therefore, the Request URI and the
   DMH's SIP URI is the same.

   The Refer-To header indicates the transferred-to URI.  In this
   message, SIP URI is used, but the resource is further qualified by
   the attached SHP-HO-CMD message, which indicates a cellular resource.

   There is no explicit subscription of the refer events.  The DMH
   SHOULD NOT send NOTIFY to the MP-CSCF when the switchover transaction
   occurs.  This is different from [RFC3515], which specifies that a
   REFER implicitly subscribes to notification of the refer events.  The
   rationale for this change is that the refer-to target is the same as
   the referred party.

   Note, this REFER is sent within an INVITE dialog of the ongoing call.
   As described in [RFC3515], when REFER is sent within an existing
   dialog, it induces similar processing of the SIP BYE message.

   The SHP-HANDOUT-COMMAND contains all the information needed for the
   DMH to tune into the specified cellular radio channel.  The
   "handling" indicator of the body MUST always be coded as "required".
   Upon receiving this message, the handset must tune in to the cellular



An                      Expires January 29, 2007               [Page 36]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   radio channel specified by the attached body, and terminate the RTP
   session.

   WLAN radio signal may weaken quickly.  The MP-CSCF may not receive
   the 200 OK response for the SIP-BYE.  The DMH SHALL treat the SIP-BYE
   i (with handover-command body) as the authoritative instruction to
   switch mode.  The MP-CSCF may use the MAP/E: SEND-END-SIGNAL as a
   safe guard against the loss of 200 OK from the DMH.

   The DMH SHOULD not transmit the SIP-INFO unless there is a perceived
   need for handover.  The DMH SHOULD not use SIP-INFO as a periodic
   measurement report.  When needed, the SIP-INFO SHOULD be transmitted
   with a minimal interval of 400ms.






































An                      Expires January 29, 2007               [Page 37]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


7.  Hand-In from Cellular to WLAN

   A hand-in operation is to transfer an active call from cellular
   network to the GAN network.

   Since the DMH is engaged in an active call on the cellular network,
   it is aware of the CGI, such as, MCC, MNC, LAC, and cell-id, of the
   current cellular cell.  These fields must be used during the hand-in
   operation.  The crypto keys of the cellular network will not be used
   during and after hand-in.  The GAN network will use a secure
   transport protocol.  The DMH SHOULD not use its cellular TMSI as its
   ID during hand-in to the GAN network.

7.1.  Hand-In Trigger Detection

   While in cellular network coverage, the DMH must perform the
   following actions in three phases:

   Phase-A: GAN Attach

      1.  The DMH must periodically scan for WLAN or any other GAN radio
          signals.

      2.  The DMH may determine whether to attach to a GAN radio network
          based on a local policy.  Such a policy may includes the
          screening of the broadcasted SSID and signal quality to
          determine whether to attach to such a network.  This procedure
          is called Phase-A trigger detection.  This procedure is out
          side the scope of this specification.

   Phase-B: Service Discovery

      1.  Once the DMH successfully attaches to a GAN radio access
          network, the DMH MAY perform a discovery procedure to obtain
          the address of a MP-CSCF.  In practice, the DMH may need to
          obtain other configuration parameters as well, e.g.  IP
          address, IPsec gateway address etc.  The discovery of MP-CSCF
          may be combined with other discovery procedures.  The
          discovery procedure is outside the scope of this
          specification.

      2.  After the discovery procedure, the DMH SHALL attempt to
          establish IP connectivity including the appropriate security
          associations.  The security association establishment may need
          user authentication.

      3.  Once all steps of Phase-B are successful, the DMH SHALL move
          on to Phase-C.  Any phase-B failure should send the DMH back



An                      Expires January 29, 2007               [Page 38]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


          to phase-A.

   Phase-C: Hand-in Attach and Hand-in

      1.  While in Phase-C, the DMH handset is receiving services from
          both the cellular network and the GAN network.  Before
          Hand-in, the DMH may receive IP access services through the
          GAN network.

      2.  Hand-in Attach: The DMH SHOULD perform a Hand-in Attach (i.e.
          SIP-REFER) procedure to allow the active call to be handed
          into the VoIP domain.  A successful SIP-REFER procedure brings
          the DMH into the "hand-in ready" state.  Only after a
          successful hand-in attach, the DMH MAY include the GAN cell-id
          in its cell-id-list in the "RR Measurement Report" to the
          cellular BSC.  The inclusion of the GAN cell-id indicates to
          the BSC that the GAN cell is a selected candidate cell for
          handover.  The report should be sent periodically until a
          handover has happened.  The DMH MUST report the GAN cell
          signal strength in a normalized fashion.

      3.  Network Control: Phase-C is the phase where a hand-in is
          expected.  The cellular BSC/MSC makes the decision to make a
          handover, which will cause the MP-CSCF to forward the INVITE
          request to the DMH.

   As can be seen, hand-in trigger detection is a two-step process:

   Phase-A trigger: This is a handset action, where DMH decides to
      attach to the GAN network and get ready for a potential hand-in.

   Phase-C trigger: This is a network action, where the network screens
      and controls the hand-in operation.

   The DMH may decide to leave phase-C before a hand-in.  It does so by
   issuing a SIP REFER message with expires=0 to the MP-CSCF to cancel
   the REFER dialog.

   During phase-C, both GAN radio and cellular radio are active on the
   handset.  The handset may wish to shorten the phase-C period by:

      Finishing the handover quickly: the DMH may spoof the signal
      strength of WLAN to influence the BSC to execute a handover.  The
      spoofing mechanism is outside the scope of this specification.

      The DMH may cancel the REFER, leave phase-C and go back to
      phase-A.




An                      Expires January 29, 2007               [Page 39]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


7.2.  Hand-In Attach Message Flow

   The purpose of "hand-in attach" is to set up the network (MP-CSCF,
   and the cellular BSC/MSC) to transfer active calls from cellular to
   GAN domain.

   The reason that hand-in attach uses SIP-REFER, instead of SIP-
   REGISTER, is that, the DMH does not wish to change subsequent call
   termination to the VoIP domain at this time.  As we know, SIP-
   REGISTER would inform the network to route further call terminations
   to the VoIP domain, as a result of which, subsequent calls will be
   anchored differently thus creates undesired implications for
   supplementary services.

   The SIP-REFER will be consumed by the MP-CSCF, which acts as a
   Referrer-Server for active call handovers.  This REFER is sent
   outside of an INVITE dialog.  It creates a dialog of its own, which
   serves as a temporary address of record (AOR at the MP-CSCF) to
   transfer an active call to the contact URI provided in the REFER
   method.

   Hand-in Attach message flow using SIP-REFER.

                            Visited             S-CSCF
    DMH                     MP-CSCF             / MGCF               HLR
     |  SIP: REFER             |                  |                   |
     |------------------------>|      MAP/D: SEND AUTH INFO           |
     |                         |------------------------------------->|
     |                         |      MAP/D: SEND AUTH INFO result    |
     |  SIP: 407 Unauthorized  |<-------------------------------------|
     |<------------------------|                  |                   |
     |  SIP: REFER             |                  |                   |
     |------------------------>|                  |                   |
     |  SIP: 202 ACCEPTED      |                  |                   |
     |<------------------------|                  |                   |

   SIP-REFER -- The MDH sends a REFER message to the MP-CSCF.














An                      Expires January 29, 2007               [Page 40]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      Example SIP-REFER message for Hand-in Attach:

     REFER sip:user1_public1@home1.net SIP/2.0
     Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
     Max-Forwards: 70
     P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
     P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11
     From: <sip:user1_public1@home1.net>
     To: <sip:user1_public1@home1.net>
     Refer-To: <sip:user1_public1@home1.net;method=INVITE>
     Contact: <sip:user1_public1@ms_ip4_adr:ms_ip4_port>;expires=60
     Call-ID: apb03a0s09dkjdfglkj49111
     Accept: application/sdp; application/3GPP-SHP
     Authorization: Digest username="user1_private@home1.net",
         realm="home1.net", nonce="", uri="sip:home1.net", response=""
     CSeq: 1 REFER
     Content-Length: 0


      The use of REFER for hand-in is a special use case of a general
      REFER.  Since the REFER requester and the Refer-to party is the
      same, the identity in the request URI header, Refer-to header, and
      the Contact header is the same.  Because of this, the processing
      of REFER is further simplified from that described in [RFC3515],
      as follows:

      No NOTIFY required-- Since the requester will receive the refer
         event (i.e. the INVITE), it is not necessary to send a NOTIFY
         to the DMH.  In this document, the MP-CSCF SHALL not send a
         NOTIFY to the DMH SIP UA.

      Duration-- Without NOTIFY, the duration of implicit subscription
         (or the referring duration SHALL be according to the Expires
         tag/header in the 202 ACCEPTED response according to standard
         SIP procedures.

      Canceling a REFER Canceling a REFER SHALL be done by issuing a
         REFER with Expires=0 tag/header.

      The use of P-Access-Network-Info header here is identical to that
      described in Section 2.  However, in REFER, there must be one and
      only one alternative access network info header, which represents
      the current cellular cell-id where the call is active.  This
      information is needed by the MP-CSCF to perform potential hand-in
      operation.  In case that the DMH has changed its cellular serving
      cell, i.e. a handover to another cellular cell has happened before
      a hand-in to the GAN cell, the DMH MUST perform a refresh REFER
      with the new serving cell-id.  If, as a result of changing the



An                      Expires January 29, 2007               [Page 41]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      serving cell-id, the DMH receives a 3XX/4XX/5XX/6XX response to
      the REFER request, the DMH SHALL consider the previous REFER as
      cancelled, and performs according to standard SIP procedures.

   MAP/D SEND AUTHENTICATION INFO exchange -- REFER MAY be challenged.
      The MAP SAI is used to retrieve cellular credentials for
      authentication.

   202 ACCEPTED -- The MP-CSCF returns 202 Accepted without performing a
      Location-Update exchange with the HLR.



      Example 202 ACCEPTED message for Hand-in Attach:

          SIP/2.0 200 ACCEPTED
          Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;
                           branch=z9hG4bKnashds7
          P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11;
                  extension-access-info=<BSIC=bsic,BCCH-FREQ=bcch>
          From:
          To:
          Call-ID:
          Contact:
          Accept: application/3GPP-SHP
          CSeq:
          Date: Thu, 21 Feb 2005 13:02:03 -700
          Organization: Operator-Long-Name (Short-Name)
          Content-Length: 0

      Similar to REGISTER in Section 2.4.2, the MP-CSCF returns the
      configured GAN cell-id and extended access information.  The
      extension-access-info includes all the information the DMH needs
      to generate a "Measurement Report".

7.3.  Hand-In Message Flow

   In the "hand-in ready" state, the DMH is sending measurement reports
   to the cellular BSC, and the BSC/MSC MAY issue a handover command at
   any time.

   Note, the handover event MAY be a hand-in to GAN or any other
   cellular cells:

      Normal handover: DMH receives a DTAP HANDOVER-COMMAND through the
      cellular network to switch to another cellular cell.  In this
      case, the DMH MUST refresh its hand-in attach with the new serving
      cell-id.  See Section 7.2.



An                      Expires January 29, 2007               [Page 42]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      Hand-in with Early INVITE: A referred INVITE through GAN, and then
      a DTAP HANDOVER-COMMAND through the cellular network; or

      Hand-in with Late INVITE: A DTAP HANDOVER-COMMAND through the
      cellular network, and then a referred INVITE.

   The two scenarios of hand-in are described in this section.

7.3.1.  Hand-In Message Flow with Early INVITE

   Hand-in message flow for SS-homed and Cellular-Homed DMH:

             Source                    S-CSCF    HO      Source   Peer
    DMH      BSC/BTS    MP-CSCF        MGCF-1   MGCF-2   MSC/VLR Network
     |         |           |             |        |        |          |
     |<= call=>|<============= active call ===============>|<= call =>|
     |         |           |             |        |        |          |
     |   RR: Measurement Report   BSSAP: HO REQUIRED       |          |
     |-------->|------------------------------------------>|          |
     |   (SHP-HO-REQUEST)  | MAP/E: PREP-HO (ho_no_req)    |          |
     |         |           |<------------------------------|          |
     |         |           | MAP/E: PREP-HO (ho_no)        |          |
     |         |           |------------------------------>|          |
     |         |           | SIP: INVITE (ho_no,  |  IAM   |          |
     | SIP: INVITE (msisdn)|<---------------------|<-------|          |
     |<--------------------|         ho_sdp)      |        |          |
     | SIP: 200 OK         |                      |        |          |
     |-------------------->| SIP: 200 OK          |  ANM   |          |
     |         |           |--------------------->|------->|          |
     | RR: HO-CMD          |   BSSAP: HANDOVER COMMAND     |          |
     |<--------|<------------------------------------------|          |
     | SIP: ACK            | SIP: ACK             |        |          |
     |<--------------------|<---------------------|        |          |
     |         |           | MAP/E: SEND END SIGNAL        |          |
     |         |           |------------------------------>|          |
     |         |           |   BSSAP: CLEAR                |          |
     |         |<------------------------------------------|          |
     |         |               BSSAP: CLEAR response       |          |
     |         |-------------------------------------------|          |
     |         |           |             |        |        |          |
     |<=== active call ===>|<== active call =====>|<======>|<= call =>|
     |         |           |             |        |        |          |
                     <... Intermediate messages skipped ...>








An                      Expires January 29, 2007               [Page 43]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Cellular Measurement Report -- During Phase-C, the RR Measurement
      Report message may include the GAN-cell id as a candidate cell-id.
      Once the cellular BSC decides to initiate a handover to the GAN
      cell, the MP-CSCF will allocate a handover number and the MSC will
      issue a circuit connection request, which is then translated to a
      SIP-INVITE request, to the MP-CSCF.

   Referred INVITE -- Once the MP-CSCF receives the INVITE request to
      the handover-number, it SHALL map it the DMH's public URI and fork
      an INVITE to the DMH.  To inform the DMH that this request needs
      to be answered immediately (instead of alerting the phone), the
      INVITE request has a P-Alerting-Mode header with the value of
      "Auto" or "MAO" (Manual Answer Override).  To the handset, this
      INVITE also serves as the final "NOTIFY" to terminates the REFER
      dialog created during hand-in attach.  (Note, the REFER dialog was
      created outside of an INVITE dialog.)



      Example of referred INVITE message for Hand-in:

              INVITE sip:user1_public1@home1.net SIP/2.0
              Via: SIP/2.0/UDP peer_ip4_adr:peer_ip4_port;
                               branch=z9hG4bKnashds7
              Max-Forwards: 70
              From: <sip:unknown@home2.net>;tag=171828
              To: <sip:user1_public1@home1.net>
              Call-ID: cb03a0s09a2sdfglkj490333
              Accept: application/sdp
              Cseq: 1 INVITE
              Supported: 100rel
              Contact: <sip:pm_cscf_ip4_adr:mp_cscf_ip4_port>
              P-Alerting-Mode: MAO
              Content-Type: application/sdp
              Content-Length: (...)

              v=0
              o=- 2987933615 2987933615 IN IP4 peer_ip4_adr
              s=-
              c=IN IP4 peer_ip4_adr
              t=0 0
              m=audio 3456 RTP/AVP 0 96
              a=rtpmap:0 PCMU/8000
              a=rtpmap:96 telephone-event







An                      Expires January 29, 2007               [Page 44]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   200 OK -- Once the DMH receives the INVITE with a P-Alerting-Mode of
      "Auto" or "MAO", the DMH MUST respond with a 200 OK with its SDP-
      answer.  This message will allow the downstream RTP traffic to
      start to be played out to the user.  The DMH SHOULD also start
      transmitting RTP packets as this time.  Recall that the INVITE is
      sent to the DMH as a result of the REFER dialog on the MP-CSCF.
      The DMH should not receive any other INVITE since it has not
      published its contact globally.

   RR HANDOVER COMMAND As a result of the 200 OK/SDP message from the
      DMH, the DMH SHALL expect to receive a RR HANDOVER-COMMAND message
      from the BSC.  Note the DMH may receive the ACK and the RR
      HANDOVER-COMMAND in arbitrary order.  At this point, the DMH MUST
      start transmitting RTP packets if has not already done so, and
      stops playing the GSM voice stream received from the cellular BTS.

   If the hand-in call terminates in the VoIP domain, the DMH MUST
   initiates a SIP-REGISTER according to Section 2 immediately after the
   call terminates.  This REGISTER will publish its contact to the VoIP
   network so that further call termination requests will be routed via
   SIP to the DMH.

   The DMH MAY support a short period of dual transmission during the
   transient period between 200 OK and the HANDOVER COMMAND.



























An                      Expires January 29, 2007               [Page 45]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


7.3.2.  Hand-In Message Flow with Late INVITE

   Hand-in message flow for SS-homed and Cellular-Homed DMH:

             Source                    S-CSCF    HO      Source   Peer
    DMH      BSC/BTS    MP-CSCF        MGCF-1   MGCF-2   MSC/VLR Network
     |         |           |             |        |        |          |
     |<= call=>|<============= active call ===============>|<= call =>|
     |         |           |             |        |        |          |
     |   RR: Measurement Report   BSSAP: HO REQUIRED       |          |
     |-------->|------------------------------------------>|          |
     |   (SHP-HO-REQUEST)  | MAP/E: PREP-HO (ho_no_req)    |          |
     |         |           |<------------------------------|          |
     |         |           | MAP/E: PREP-HO (ho_no)        |          |
     |         |           |------------------------------>|          |
     |         |           | SIP: INVITE (ho_no,  |  IAM   |          |
     |         |           |<---------------------|<-------|          |
     |         |           |         ho_sdp)      |        |          |
     |         |           | SIP: 18X (dummy_sdp) |  ACM   |          |
     |         |           |--------------------->|------->|          |
     | RR: HO-CMD          |   BSSAP: HANDOVER COMMAND     |          |
     |<--------|<------------------------------------------|          |
     | SIP: REFER (ho_ref) |                      |        |          |
     |-------------------->|                      |        |          |
     |<-- 202 ACCEPTED-----|                      |        |          |
     | SIP: INVITE (msisdn)|                      |        |          |
     |<--------------------|                      |        |          |
     | SIP: 200 OK (ms_sdp)| 200 OK (ms_sdp)      |  ANM   |          |
     |-------------------->|--------------------->|------->|          |
     | SIP: ACK            | SIP: ACK             |        |          |
     |<--------------------|<---------------------|        |          |
     |         |           | MAP/E: SEND END SIGNAL        |          |
     |         |           |------------------------------>|          |
     |         |           |   BSSAP: CLEAR                |          |
     |         |<------------------------------------------|          |
     |         |               BSSAP: CLEAR response       |          |
     |         |-------------------------------------------|          |
     |         |           |             |        |        |          |
     |<=== active call ===>|<== active call =====>|<======>|<= call =>|
     |         |           |             |        |        |          |
                     <... Intermediate messages skipped ...>

   Cellular HANDOVER COMMAND -- In this case, the DMH receives the
      HANDOVER COMMAND before the referred INVITE.  This command
      indicates the GAN cell-id as the target cell, together with a
      Handover Reference Number. the radio channel information can be
      ignored.




An                      Expires January 29, 2007               [Page 46]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


      The HANDOVER COMMAND is sent according to the cellular standard of
      the cellular network.  For 3GPP Release 4+, this message is
      defined in [3GPP.08.08].  The message contains a Layer 3
      Information Element from the serving MSC.  Since the MP-CSCF is
      acting as a 3GPP MSC/BSC, the Layer 3 Information Element is the
      Handover Command defined in [3GPP.04.18], which contains, among
      others, a one-byte Handover Reference number field.

   Immediate REFER -- Since this HANDOVER COMMAND is received before the
      referred INVITE, the DMH MUST immediately send an REFER to the MP-
      CSCF.  This REFER not only includes the current serving cell-id,
      but also includes the Handover Reference Number received in the
      HANDOVER COMMAND.



      Example of immediate REFER message for Hand-in:

      REFER sip:user1_public1@home1.net SIP/2.0
      Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;
                       branch=z9hG4bKnashds7
      Max-Forwards: 70
      P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
      P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11;
               extension-access-info=<HANDOVER=ho-ref-no>
      From: <sip:user1_public1@home1.net>
      To: <sip:user1_public1@home1.net>
      Refer-To: <sip:user1_public1@home1.net;method=INVITE>
      Contact: <sip:internal_ip4_adr;internal_ip4_port>;expires=60
      Call-ID: apb03a0s09dkjdfglkj49111
      Authorization: Digest username="user1_private@home1.net",
        realm="home1.net", nonce="", uri="sip:home1.net", response=""
      CSeq: 1 REFER
      Content-Length: 0

      ho-no=[0...255]

      The immediate REFER implies that a handover event has happened,
      and the handover event reference number is provided in
      "ho-ref-no".

   Referred INVITE -- Once the MP-CSCF receives an immediate REFER
      message, the MP-CSCF maps the INVITE request to the handover-
      number to the DMH's public URI and fork an INVITE to the DMH.
      This INVITE is the same as the referred INVITE in Section 7.3.1.






An                      Expires January 29, 2007               [Page 47]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   200 OK -- This completes the hand-in.  The handset SHALL start
      transmitting and playing out RTP packets, and stops audio
      transmission and reception on the cellular radio.

   In the "Late INVITE" case, the actual handover is already underway in
   the network when the handset receives the HANDOVER COMMAND from the
   cellular network.  After the handset sends the immediate REFER
   message, it SHOULD start a timer of 2~3 seconds in anticipating for
   the referred INVITE.  Before the timer expires, the handset SHALL
   maintain relevant state information of the ongoing call.  Should the
   GAN (e.g.  WALN) network signal changes dramatically during this
   period, or the DMH does not receive the referred INVITE within this
   timer period, the handset SHOULD clear the call, perform a SIP-
   REGISTER as described in Section 2, and treat all incoming INVITE as
   a new call termination.

7.3.3.  Early versus Late INVITE in Hand-in

   Whether the network is going to perform an "early" or "late" INVITE
   depends on the version of the cellular network.  Early INVITE is
   performed by the MP-CSCF if the serving cellular network is of 3GPP
   Release 4 or later.  Late INVITE is usually performed if the serving
   cellular network is of 3GPP Release 99 or earlier.

   The reason for this variation is that, in 3GPP Release 99 and
   earlier, the MAP PREPARE-HANDOVER request may not include the IMSI.
   This causes the MP-CSCF inability to correlate the MAP request with
   the handset's URI.  A correlation is achieved immediately when the
   handset reports the handover reference number to the MP-CSCF.

   The trigger detection for hand-in SHOULD be conservative to avoid
   handover oscillation.

7.4.  Subsequent Handovers

   In GSM network, subsequent handovers use different set of messages
   and different set of message flows.  However, the messages between
   the DMH and the MP-CSCF are identical to the initial hand-in or hand-
   out.  Since this document focuses on the interface between the DMH
   and the SIP-based MP-CSCF, subsequent handovers are not described
   here in details.  Readers shall follow the descriptions early in this
   section for subsequent handovers.

7.4.1.  Subsequent Hand-out

   A subsequent hand-out refers to a hand-out which happens after a
   previous hand-in for the same call.  The dual mode handset (DMH)
   SHALL follow the descriptions in Section 6 for subsequent hand-outs.



An                      Expires January 29, 2007               [Page 48]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Note, the parameters, such as GAN pseudo cell-id received during
   hand-in attach SHALL be used for the subsequent hand-out.

7.4.2.  Subsequent Hand-in

   A subsequent hand-in is a hand-back to the previous MP-CSCF who has
   handed out the same call.  A subsequent hand-in to a different MP-
   CSCF is not considered as a subsequent hand-in.  (Note a hand-in
   attach might end up attaching to a different MP-CSCF, although it is
   not recommended.).  The dual mode handset (DMH) SHALL follow the
   descriptions in Section 7 for subsequent hand-outs.  Note, the
   parameters, such as GAN pseudo cell-id, BSIC, BCCH-FREQ received
   during the new hand-in attach SHALL be used for the subsequent
   hand-in.





































An                      Expires January 29, 2007               [Page 49]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


8.  Session Handover Protocol (SHP)

   This document suggests the use of a residual protocol of SIP to pass
   extra parameters to facilitate voice session handovers between GSM
   and VoIP networks.  The residual protocol described in this section
   facilitates voice session handover between VoIP and 3GPP circuit
   switched network.  Therefore, the protocol described in this section
   is called 3GPP Session Handover Protocol (3GPP-SHP).

   SHP messages are attached to SIP messages as MIME bodies.  This
   section describes the carrier SIP messages and the residual SHP
   messages, and specifies the contents and format of the SHP protocol.

8.1.  Carrier SIP and Attached SHP Messages

   Indicating alternative handset radio capabilities:

              DMH                                          MP-CSCF
               |   Carrier Message: SIP REGISTER              |
               |--------------------------------------------->|
               |   Body Message:  SHP REGISTER-REQUEST        |
               |                                              |
               |         Carrier Message: SIP 200 OK          |
               |<---------------------------------------------|
               |         Body Message: SHP REGISTER-ACCEPT    |
               |                                              |

   Body message contains cellular classmark information elements.

   Cellular Crypto Preparedness for Hand-out:

              DMH                                          MP-CSCF
               |   Carrier Message: SIP INVITE / 1XX / 2XX    |
               |--------------------------------------------->|
               |   Body Message:  SHP CIPHER-COMMAND          |
               |                                              |
               |         Carrier Message: SIP 2XX / ACK       |
               |<---------------------------------------------|
               |         Body Message: SHP CIPHER-COMPLETE    |
               |                                              |

   Body message exchange generates cellular crypto key.









An                      Expires January 29, 2007               [Page 50]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   Hand-out Exchange:

              DMH                                          MP-CSCF
               |   Carrier Message: SIP INFO                  |
               |--------------------------------------------->|
               |   Body Message:  SHP HANDOUT-REQUEST         |
               |                                              |
               |         Carrier Message: SIP REFER           |
               |<---------------------------------------------|
               |         Body Message: SHP HANDOUT-COMMAND    |
               |                                              |

   Body messages contain alternative cell info.

   Hand-in Excahnge:

              DMH                                          MP-CSCF
               |   Carrier Message: SIP REFER                 |
               |--------------------------------------------->|
               |                                              |
               |                                              |
               |         Carrier Message: SIP INVITE          |
               |<---------------------------------------------|
               |                                              |
               |                                              |

   No body messages needed.

8.1.1.  Indication of 3GPP-SHP Support

   The handset and the network SIP proxy SHALL indicate to each other of
   its support of 3GPP-SHP by using the Accept header in REGISTER,
   INVITE and other SIP messages.


                        Accept: application/3GPP-SHP

   The handset or network proxy SHOULD NOT attach a SHP body unless it
   has received an indication that the other side supports SHP.

   For example, the handset indicates its support of 3GPP-SHP by
   including it in the Accept header of REGISTER.  The MP-CSCF includes
   its support in 407 response.  Then both entities are informed of each
   other's support of 3GPP-SHP.  Then, SHP bodies may be attached to
   subsequent REGISTER and 200 OK messages.






An                      Expires January 29, 2007               [Page 51]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


8.1.2.  SHP Attachment Encoding

   The SHP MIME attachment encoding SHALL support binary and base64.
   Note base64 will increase the body length by 25% due to 3 to 4
   encoding.

8.2.  SHP Syntax and Functional Descriptions

8.2.1.  SHP Message Format

   All SHP messages MUST include a 4-byte message header and certain
   mandatory and optional information elements (IEs).  IEs are formatted
   as (Type, Length, Value) tuples.  The SHP messages MUST be
   transmitted in network byte order.

   SHP Message Header Definition:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Length                   |Prot   | Skip  | Message Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             ....                              |
     |                   Information Elements                        |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Length: the length of the message
        Protocol: protocol discriminator, MUST be set to 0010B for SHP
            Skip: skip indicator, MUST be set to 0000B
        Msg Type: the message type

   Each information element in an SHP message is a tuple of (Type,
   Length, Value).  The length may be zero, where the IE is only two-
   byte long.

















An                      Expires January 29, 2007               [Page 52]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   SHP Information Element Format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      IEI      |   Length      |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                             ....                              |
     |                   optional, variable length data              |
     |                             ....                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             IEI: information element identifier
        Protocol: length of data field, starting from next octet

8.2.2.  SHP Message Types

   SHP Message Type Values:

     +---------------------+-----------------------------------------+
     | Message name        |value | Comments                         |
     +---------------------+-----------------------------------------+
     | REGISTER REQUEST    |  16  | Same as UMA REGISTER REQUEST     |
     | REGISTER ACCEPT     |  17  | Same as UMA REGISTER ACCEPT      |
     | CIPHER SDP COMMAND  |  32  | Same as UMA CIPHER-MODE-COMMAND  |
     | CIPHER SDP COMPLETE |  33  | Same as UMA CIPHER-MODE-COMPLETE |
     | HANDOUT REQUEST     |  83  | Similar to UMA HANDOVER-REQUIRED |
     | HANDOUT COMMAND     |  84  | Similar to UMA HANDOVER-COMMAND  |
     +---------------------------------------------------------------+

8.2.3.  SHP Message Descriptions

8.2.3.1.  SHP REGISTER REQUEST

   During the service-attach process, a SHP REGISTER-REQUEST message
   body is attached to the SIP REGISTER request.  The DMH MAY expect a
   SHP REGISTER-ACCEPT message body from the MP-CSCF in 200 OK.

   SHP REGISTER REQUEST

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  28  | MS Classmark 2           | Mandatory   | TLV  |   5    |
     |  56  | MS Classmark 3           | Conditional | TLV  |  3-14  |
     |   1  | Mobile Identity (IMSI)   | Conditional | TLV  |  10~11 |
     +---------------------------------------------------------------+

   MS Classmark 3 is included when the value of MS classmark2 indicates



An                      Expires January 29, 2007               [Page 53]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   that it is required.  The Mobile Identity SHALL be included to
   present the IMSI when IMSI is not used as SIP credential.

8.2.3.2.  SHP REGISTER ACCEPT

   SHP REGISTER ACCEPT

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  13  | GAN Cell Description     | Optional    | TLV  |   5    |
     +---------------------------------------------------------------+

   The SHP REGISTER ACCEPT message body is optional in the 200 OK
   message from the MP-CSCF to DMH.  It is processed when it is
   attached.  A 200 OK message indicates a successful service-attach.

   The GAN Cell Description IE contains information of the assigned GAN
   cell.  When provided, it overrides the same information that is
   already provided in the P-Access-Network-Info header.

   The "GAN Cell Description" IE contains parameters of the assigned GAN
   cell, i.e.

      BSIC (base station id code) = NCC (network colour code) | BCC
      (base station colour code)

      BCCH ARFCN (absolute radio frequency channel)

   The handset must provide the following default values, is such
   information is not provided in the 200 OK message, as follows:

      NCC=000B (3-bit binary zero)

      BCC=000B (3-bit binary zero)

      ARFCN=0000000000B (10-bit binary zero)

   The above information has no significance for the operation of the
   GAN cell.  However, it is used by the DMH when reporting the GAN cell
   signal strength to the cellular network, and the cellular network use
   these codes to ensure compatibility for handover.  Before every fresh
   service-attach, the DMH shall use the default values.  If this IE is
   included during a successful service-attach response, the DMH must
   set the colour codes accordingly, and keep those values until the
   session is terminated or a new IE is received during a new service-
   attach.




An                      Expires January 29, 2007               [Page 54]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


8.2.3.3.  SHP CIPHER COMMAND

   The SHP CIPHER COMMAND/COMPLETE exchange is attached to SIP messages
   during call setup time to prepare the crypto keys for potential hand-
   out to cellular network.  This ensures that the DMH and the BSC to
   have an agreed crypto key for encryption after handover.

   SHP CIPHER COMMAND

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  30  | CIPHER MODE SETTING      | Mandatory   | TLV  |   3    |
     +---------------------------------------------------------------+
     |  45  | CIPHER RESPONSE          | Mandatory   | TLV  |   3    |
     +---------------------------------------------------------------+
     |  46  | RAND (Random Number)     | Mandatory   | TLV  |  18    |
     +---------------------------------------------------------------+

8.2.3.4.  SHP CIPHER COMPLETE

   Once challenged by a SHP CIPHER COMMAND message, the DMH MUST return
   a CIPHER COMPLETE and store the generated keys for use after hand-
   out.  Failure to respond with a CIPHER COMPLETE body will result in
   "no encryption applied" after hand-out.  The MP-CSCF MAY disallow
   such hand-out due to security concerns.

   SHP CIPHER COMPLETE

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  47  | Message Auth Code (MAC)  | Mandatory   | TLV  |  14    |
     +---------------------------------------------------------------+
     |   1  | Mobile Identity (IMEI)   | Conditional | TLV  |  10~11 |
     +---------------------------------------------------------------+

   The mobile identity IE is included when it is requested in the CIPHER
   COMMAND message.

8.2.3.5.  SHP HAND-OUT REQUEST

   This is handset's radio measurement report that is attached to a SIP-
   INFO message, indicating a handout request.  The "handling" field in
   the MIME attachment header indicates the urgency of the request.
   "handling=optional" means non-urgent request; "handling=required"
   indicates urgent request.




An                      Expires January 29, 2007               [Page 55]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   SHP HANDOUT REQUEST

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  15  | Cell Identifier List     | Mandatory   | TLV  |        |
     +---------------------------------------------------------------+
     | 106  | GERAN Measurement Result | Mandatory   | TLV  |  10~11 |
     +---------------------------------------------------------------+
     | 107  | UTRAN Measurement Result | Mandatory   | TLV  |  10~11 |
     +---------------------------------------------------------------+

   The Measurement Result is a list if signal levels whose order MUST
   follow the order of cells in the Cell Identifier List IE in the same
   message.

8.2.3.6.  SHP HAND-OUT COMMAND

   The hand-out command is received in the SIP-REFER message.

   SHP HANDOUT COMMAND

     +---------------------------------------------------------------+
     | IEI  | Information Element Name | Presence    |Format| Length |
     +---------------------------------------------------------------+
     |  32  | Handover From GAN Command| Mandatory   | TLV  |        |
     +---------------------------------------------------------------+

8.2.4.  List of All Information Elements

   SHP does not define new information elements.  All information
   elements used by SHP are defined by [UMA] and its associated 3GPP
   specifications.  This section provides a list of all IEs used by the
   residual SHP protocol, and the source of their definitions.

















An                      Expires January 29, 2007               [Page 56]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


   List of All IEs used by 3GPP-SHP:

    +-----------------------------------------------------------------+
    | IEI  | Information Element Name | Reference in [UMA] | Comments |
    +-----------------------------------------------------------------+
    |   1  | Mobile Equipment Id(IMEI)| Section 11.2.1     |          |
    |  13  | GAN Cell Description     | Section 11.2.13    |          |
    |  15  | Cell Identifier List     | Section 11.2.15    |          |
    |  28  | MS Classmark 2           | Section 11.2.28    |          |
    |  30  | CIPHER MODE SETTING      | Section 11.2.30    |          |
    |  32  | Handover From GAN Command| Section 11.2.32    |          |
    |  45  | CIPHER RESPONSE          | Section 11.2.45    |          |
    |  46  | RAND (Randome Number)    | Section 11.2.46    |          |
    |  47  | Message Auth Code (MAC)  | Section 11.2.47    |          |
    |  56  | MS Classmark 3           | Section 11.2.56    |----------|
    | 106  | GERAN Measurement Result | Section 11.2.70    |Added in  |
    | 107  | UTRAN Measurement Result | Section 11.2.70    | ver 1.04 |
    +-----------------------------------------------------------------+

































An                      Expires January 29, 2007               [Page 57]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


9.  Security Considerations

   This document specifies the usage of the SIP protocol for converged
   services across VoIP and cellular networks.  It also specifies
   additional message bodies and extends the usage of certain existing
   messages and headers of the SIP protocol.  These present certain
   security requirements to the use of specifications presented in this
   document.

   Since IMSI and other network information are transmitted inside the
   SIP messages, the operator may not wish these parameters to be seen
   by unauthorized entities in the network.  For this reason, SIP
   messages between the DMH and the MP-CSCF SHALL use a secure transport
   protocol, such as TLS or IPsec.  Secure MINE may also satisfy this
   requirement; however, the Authorization header must be inside the
   encrypted SMINE body.

10.  References

   [3GPP.04.18]
              3GPP, "Mobile radio interface layer 3 specification; Radio
              Resource Control (RRC) protocol", 3GPP TS 04.18 8.27.0,
              May 2006.

   [3GPP.08.08]
              3GPP, "Mobile-services Switching Centre - Base Station
              system (MSC-BSS) Interface Layer 3 Specification", 3GPP
              TS 08.08 3.10.1, January 1995.

   [3GPP.23.003]
              3GPP, "Numbering, addressing and identification", 3GPP
              TS 23.003 3.14.0, January 2004.

   [3GPP.25.331]
              3GPP, "Radio Resource Control (RRC); Protocol
              specification", 3GPP TS 25.331 3.21.0, December 2004.

   [3GPP.48.008]
              3GPP, "Mobile Switching Centre - Base Station system (MSC-
              BSS) interface; Layer 3 specification", 3GPP TS 48.008
              4.10.0, September 2003.

   [RFC3204]  Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
              F., Watson, M., and M. Zonoun, "MIME media types for ISUP
              and QSIG Objects", RFC 3204, December 2001.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.



An                      Expires January 29, 2007               [Page 58]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3310]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
              Protocol (HTTP) Digest Authentication Using Authentication
              and Key Agreement (AKA)", RFC 3310, September 2002.

   [RFC3455]  Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
              Header (P-Header) Extensions to the Session Initiation
              Protocol (SIP) for the 3rd-Generation Partnership Project
              (3GPP)", RFC 3455, January 2003.

   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
              Method", RFC 3515, April 2003.

   [UMA]      UMA Participating Companies, "Unlicensed Mobile Access
              (UMA) Protocols (Stage 3)", May 2005.

   [yafan-fmc-arch]
              An, Y., "The Architecture Framework For Fixed Mobile
              Convergence Using SIP as Access Call Control",
              draft-yafan-fmc-arch-01 (work in progress), July 2006.

   [yafan-fmc-mcho]
              An, Y., "Mobile Controlled Handover Across VoIP and
              Cellular Domains Using SIP as Access Call Control",
              draft-yafan-fmc-mcho-01 (work in progress), July 2006.
























An                      Expires January 29, 2007               [Page 59]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


Author's Address

   Yafan An
   Stoke, Inc.
   5403 Betsy Ross Drive
   Santa Clara, CA  95054
   US

   Email: yafan@stoke.com
   URI:   http://www.stoke.com/









































An                      Expires January 29, 2007               [Page 60]

Internet-Draft     SIP-based Mobile Assisted Handover          July 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




An                      Expires January 29, 2007               [Page 61]