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: ;tag=4fa3 To: Contact: ; 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: 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 -->> 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Supported: 100rel Contact: 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 CSeq: (.) Contact: 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 CSeq: (.) Contact: 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Supported: 100rel Contact: 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: ;tag=171828 To: 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Contact: 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: ;tag=171828 To: Call-ID: (...) Accept: application/3GPP-SHP Cseq: 128 REFER Refer-To: sip:user1_public1@home1.net Contact: 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: To: Refer-To: Contact: ;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= 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: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Accept: application/sdp Cseq: 1 INVITE Supported: 100rel Contact: 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= From: To: Refer-To: Contact: ;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]