Internet DRAFT - draft-yafan-fmc-mancho
draft-yafan-fmc-mancho
FMC Y. An
Internet-Draft Stoke, Inc.
Expires: January 29, 2007 July 28, 2006
Mobile Assisted Handover across VoIP and Cellular Domains Using SIP as
Access Call Control
draft-yafan-fmc-mancho-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 29, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the use of SIP between the dual mode handset
(DMH) and the mobility SIP proxy to enable network controlled
handovers across voice over IP (VoIP) and cellular networks. The
mobility SIP proxy has a peering relationship with the cellular
network. Mobile assisted and network controlled handovers require
the exchange of cellular radio parameters between the DMH and the
mobility SIP proxy. The set of cellular related parameters is
collectively called Session Handover Protocol (SHP). The SHP is a
An Expires January 29, 2007 [Page 1]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
residual protocol of SIP, where all of its messages are transported
as MIME attachment to SIP messages.
This document describes the requirements, various SIP message flows
for cross-domain roaming and bidirectional handovers between VoIP and
cellular domains, and detailed specification of the residual SHP
protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Cellular Homed Deployment . . . . . . . . . . . . . . . . 5
1.2. Soft Switch Homed Deployment . . . . . . . . . . . . . . . 6
1.3. Passing Extra Parameters with SIP Messages . . . . . . . . 6
2. Registration in VoIP Domain . . . . . . . . . . . . . . . . . 7
2.1. Registration Message Flow in Cellular-homed Scenario . . . 7
2.2. Registration Message Flow in Soft Switch-homed Scenario . 9
2.3. Examples of Registration Messages . . . . . . . . . . . . 11
2.4. Alternative Access Network Information . . . . . . . . . . 12
2.4.1. Reporting of P-Access-Network-Info . . . . . . . . . . 12
2.4.2. Assignment of P-Access-Network-Info . . . . . . . . . 13
2.5. Cellular Radio Information . . . . . . . . . . . . . . . . 15
2.5.1. Cellular Radio Information Reporting . . . . . . . . . 15
2.5.2. Cellular Radio Information Acknowledgement . . . . . . 15
2.6. TMSI Assignment . . . . . . . . . . . . . . . . . . . . . 15
2.6.1. Use of P-Associated-URI for TMSI Assignment . . . . . 16
3. Rove-Out: From WLAN to Cellular . . . . . . . . . . . . . . . 17
4. Rove-In: From Cellular to WLAN . . . . . . . . . . . . . . . . 20
5. Call Setup in VoIP Domain with Cellular Crypto Setup . . . . . 21
5.1. Call Origination Message Flow . . . . . . . . . . . . . . 22
5.2. Call Termination Message Flow . . . . . . . . . . . . . . 23
5.3. Examples of Call Setup Messages . . . . . . . . . . . . . 26
5.4. 3GPP GSM Crypto Setup . . . . . . . . . . . . . . . . . . 30
6. Hand-Out from WLAN to Cellular . . . . . . . . . . . . . . . . 32
6.1. Hand-Out Trigger Detection . . . . . . . . . . . . . . . . 32
6.2. Hand-Out Message Flow . . . . . . . . . . . . . . . . . . 32
6.3. Reporting of Cellular Radio Conditions . . . . . . . . . . 33
6.4. Network Controlled Hand-out . . . . . . . . . . . . . . . 35
7. Hand-In from Cellular to WLAN . . . . . . . . . . . . . . . . 38
7.1. Hand-In Trigger Detection . . . . . . . . . . . . . . . . 38
7.2. Hand-In Attach Message Flow . . . . . . . . . . . . . . . 40
7.3. Hand-In Message Flow . . . . . . . . . . . . . . . . . . . 42
7.3.1. Hand-In Message Flow with Early INVITE . . . . . . . . 43
7.3.2. Hand-In Message Flow with Late INVITE . . . . . . . . 46
7.3.3. Early versus Late INVITE in Hand-in . . . . . . . . . 48
7.4. Subsequent Handovers . . . . . . . . . . . . . . . . . . . 48
7.4.1. Subsequent Hand-out . . . . . . . . . . . . . . . . . 48
An Expires January 29, 2007 [Page 2]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
7.4.2. Subsequent Hand-in . . . . . . . . . . . . . . . . . . 49
8. Session Handover Protocol (SHP) . . . . . . . . . . . . . . . 50
8.1. Carrier SIP and Attached SHP Messages . . . . . . . . . . 50
8.1.1. Indication of 3GPP-SHP Support . . . . . . . . . . . . 51
8.1.2. SHP Attachment Encoding . . . . . . . . . . . . . . . 52
8.2. SHP Syntax and Functional Descriptions . . . . . . . . . . 52
8.2.1. SHP Message Format . . . . . . . . . . . . . . . . . . 52
8.2.2. SHP Message Types . . . . . . . . . . . . . . . . . . 53
8.2.3. SHP Message Descriptions . . . . . . . . . . . . . . . 53
8.2.4. List of All Information Elements . . . . . . . . . . . 56
9. Security Considerations . . . . . . . . . . . . . . . . . . . 58
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 61
An Expires January 29, 2007 [Page 3]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
1. Introduction
[yafan-fmc-arch] describes an architecture framework for providing
converged services across IP and cellular domains for dual mode
handset (DMH) users. DMH refers to certain mobile devices which have
both cellular and WLAN baseband and radio. [yafan-fmc-arch] also
describes a basic set of features by utilizing SIP as per [RFC3261].
The basic feature set includes "cross-domain roving" and "single
number reach-ability". This document describes a SIP-based approach
to support extended features such as bidirectional handovers across
VoIP and cellular domains.
The handovers described in this document are called "mobile assisted
and network controlled" because the handovers are executed by a
network element such as the mobility SIP proxy (MP-CSCF) or the
cellular mobile switching center (MSC). A mobile device (i.e. DMH)
assists the handover execution by reporting its measurement of radio
signal quality of both cellular and WLAN base stations. However, the
handset does not have control over whether, when and where-to perform
the handover.
The approach described in this document assumes the network utilizes
"Natural Anchoring" as described in [yafan-fmc-arch], which also
requires the mobility SIP proxy (MP-CSCF) to have an inter-MSC
peering relationship with the cellular network via the MAP E
interface.
The network diagrams in [yafan-fmc-arch] are reproduced here, with
the addition of the MAP E/G interfaces. Reader of this document is
encouraged to read [yafan-fmc-arch] and be familiar with the
concepts, and the basic feature set enabled by the framework in
[yafan-fmc-arch].
In cellular-homed scenario, the mobility SIP proxy (MP-CSCF) is an
extension of the cellular network by acting as a full-featured mobile
switching center (MSC/VLR). In soft switch-homed scenario, the MP-
CSCF is acting as an access or edge SIP proxy of the VoIP soft
switch. In both cases, SIP is used as the call control protocol in
the VoIP domain.
An Expires January 29, 2007 [Page 4]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
1.1. Cellular Homed Deployment
Cellular-Homed System Architecture
C / D +--------+
+-------------------| HLR |
| +--------+
|
| E +--------+
+-------------------| SMSC |
| +--------+
+---------------------------+ |
| Mobility Proxy +-----+ | | E / G +---------+
| | CSI | |---+-------------------| MSC / |
| +-----------+___+-----+ | +------+ +------| VLR |
| | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+
| +-----------+ +-----+ |------+------+--+ /PRI |
+---------------------------+ | MG | +---------+
| +------+ | BSC/BTS |
| SIP +---------+
| |
+-------+ |
| DMH |-------------------------------------------
+-------+
This diagram does not suggest a particular grouping of functions into
physical entities.
An Expires January 29, 2007 [Page 5]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
1.2. Soft Switch Homed Deployment
Soft Switch-Homed System Architecture
+---------------+ +-----------+
| Soft Switch |.......| HLR / HSS |
| (S-CSCF) | Cx +-----------+
+---------------+ C/D |
| | E +--------+
| SIP +-------------------| SMSC |
| | +--------+
+---------------------------+ |
| Mobility Proxy +-----+ | | E / G +---------+
| | CSI | |---+-------------------| MSC / |
| +-----------+___+-----+ | +------+ +------| VLR |
| | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+
| +-----------+ +-----+ |------+------+--+ /PRI |
+---------------------------+ | MG | +---------+
| +------+ | BSC/BTS |
| SIP +---------+
| |
+-------+ |
| DMH |-------------------------------------------
+-------+
This diagram does not suggest a particular grouping of functions into
physical entities.
1.3. Passing Extra Parameters with SIP Messages
To perform a network-controlled fast handover, the MP-CSCF needs to
obtain necessary cellular radio parameters from the dual mode
handset. In this document, such parameters are passed by utilizing
MIME attachment to regular SIP messages, and the attached messages
are collectively referred to as the "Session Handover Protocol
(SHP)".
Attaching SHP messages do not alter the basic semantics of SIP
messages. The SHP attachment MUST be able to co-exist with other
existing attachment, such as the Session Description Protocol (SDP),
and the attachment defined in [yafan-fmc-mcho].
In this document, the SIP message flows and the functional aspect of
SHP are presented first. The detailed syntax definition of SHP is
later presented in Section 8.
An Expires January 29, 2007 [Page 6]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
2. Registration in VoIP Domain
When registering to the VoIP network, the handset MUST use its public
identifier, such as the MSISDN, in the REGISTER request URI.
2.1. Registration Message Flow in Cellular-homed Scenario
In cellular-homed deployment, SIP-REGISTER is mapped to Location-
Update to the HLR in the DMH's home network. In addition, SIP-
REGISTER SHALL also configure the DMH in order to allow fast network-
controlled handovers across VoIP and cellular domains. In order for
the MP-CSCF to authenticate the DMH using SIM-based credentials,
AKAv1-MD5 [RFC3310] SHALL be used as the SIP authentication
mechanisms in cellular-homed deployment.
Updated access-type values:
+-----+ +----------+ +---------+
| DMH |----------------------| Visisted |-----------------| Home |
+-----+ | MP-CSCF | | Net HLR |
| SIP: REGISTER +----------+ +---------+
|------------------------------>| MAP/D: SEND-AUTH-INFO |
| |--------------------------->|
| | MAP/D: SEND-AUTH-INFO res |
| SIP: 407 Unauthorized |<---------------------------|
|<------------------------------| |
| SIP: REGISTER | |
|------------------------------>| MAP/D: LOCATION-UPDATE |
| |--------------------------->|
| | MAP/D: INSERT-SUB-DATA |
| |<---------------------------|
| | MAP/D: INSERT-SUB-RESULT |
| |--------------------------->|
| | +-------+ MAP/D: CANCEL |
| | |MSC/VLR|<--------------->|
| | +-------+ LOCATION |
| | MAP/D: LOC-UPDATE-RESULT |
| SIP: 200 OK |<---------------------------|
|<------------------------------| |
| | |
REGISTER (DMH --> MP-CSCF) -- The purpose of this request is to
register the user's SIP URI with the MP-CSCF in the home or
visited GAN domain. The MP-CSCF, or visited MP-CSCF authenticates
the DMH to the VoIP network. It is routed to the MP-CSCF since it
is the SIP proxy known to the DMH.
An Expires January 29, 2007 [Page 7]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
MAP/D SEND-AUTHENTICATION-INFO exchange -- This optional exchange
with the HLR is to retrieve the authentication triplets for the
handset. Since multiple authentication vectors can be retrieved
in a single request, this exchange is used when the MP-CSCF has
exhausted the authentication vectors.
Noted that the MP-CSCF needs to know the IMSI of the DMH in order
to retrieve the authentication vector from the HLR. The DMH
SHOULD use IMSI as its username during SIP authentication. If SIP
authentication is optional, then the IMSI MUST be provided in the
attached Mobile Identity information element, see Section 8.
The MAP/D SEND-AUTHENTICATION-INFO exchange can be performed only
after the MP-CSCF has learned the proclaimed IMSI from the DMH.
Therefore, the SIP REGISTER SHOULD include its credentials even it
is not challenged, with its IMSI in the username field. Please
refer to [yafan-fmc-arch] for the syntax of username.
407 -- The MP-CSCF forms a challenge based on the authentication
vectors obtained from the HLR, and send the AKAv1-MD5 challenge to
the DMH.
REGISTER with credentials -- This REGISTER contains the challenge
response.
MAP/D LOCATION-UPDATE -- Upon successful authentication, the MP-CSCF
performs Location-Update towards the HLR. This transaction
establishes that mobile-terminating calls are routed through the
MP-CSCF via the MGCF/MG for terminating in the VoIP domain.
200 OK -- If the Location-Update MAP exchange with the HLR is
successful, the MP-CSCF returns 200 OK to the DMH.
The errors occurred during MP-CSCF's location update procedure
SHALL be propagated to the DMH.
IMSI invalid: If the HLR returns error code indicating IMSI
invalid, the MP-CSCF will return "404 Not Found" SIP message.
Roaming not allowed: If the HLR returns error code indicating this
subscriber is not allowed to roam into the GAN area served by
this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message.
Other errors: If the Location-Update exchange with the HLR results
with other errors, such as timed out, the MP-CSCF returns "500
Internal Server Error" SIP message to the DMH.
An Expires January 29, 2007 [Page 8]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
2.2. Registration Message Flow in Soft Switch-homed Scenario
In soft switch-homed deployment, SIP-REGISTER is forwarded to the
soft switch (or S-CSCF) for authentication, and is then mapped to a
Location-Update to the HLR. Both S-CSCF and the HLR are in the DMH's
home network. In this deployment scenario, the S-CSCF may use non
SIM-based authentication mechanism, such as the Digest-MD5
authentication mechanism, for SIP authentication.
Updated access-type values:
+-----+ +----------+ +---------+
| DMH |----------------------| Visisted |-----------------| Home |
+-----+ | MP-CSCF | | Net HLR |
| SIP: REGISTER +----------+ +---------+
|------------------------------>| REGISTER +--------+ |
| |----------------->| S-CSCF | |
| | 401 +--------+ |
| SIP: 401 |<---------------------| |
|<------------------------------| | |
| SIP: REGISTER | | |
|------------------------------>| REGISTER | |
| |--------------------->| |
| | 200 OK | |
| SIP: 200 OK |<---------------------| |
|<------------------------------| |
| | MAP/D: LOCATION-UPDATE |
| |---------------------------->|
| | MAP/D: INSERT-SUB-DATA |
| |<----------------------------|
| | MAP/D: INSERT-SUB-RESULT |
| |---------------------------->|
| | +-------+ MAP/D: CANCEL |
| | |MSC/VLR|<---------------->|
| | +-------+ LOCATION |
| | MAP/D: LOC-UPDATE-RESULT |
| SIP: 200 OK |<----------------------------|
|<------------------------------| |
| | |
REGISTER (DMH --> MP-CSCF --> S-CSCF) -- The purpose of this request
is to register the user's SIP URI with the S-CSCF in the VoIP
domain. The S-CSCF authenticates the DMH to the VoIP network. It
is routed to the MP-CSCF since it is the SIP proxy known to the
DMH.
An Expires January 29, 2007 [Page 9]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Note the AKAv1-MD5 mechanism is still preferred here, in which the
MP-CSCF performs the authentication using SIM-based credentials.
However, other existing SIP authentication mechanism, such as
Digest-MD5, MAY still be used, in which case authentication is
performed only by the Soft Switch. The MP-CSCF only stores the
status of the authentication by monitoring the authentication
message flows. A trust relation between the MP-CSCF and the
S-CSCF SHALL be established. Such trust relationship can be
established by multiple means, such as a IPsec association, SSL
association, or a simple site-wide username/password for all
users. Such trust relationship is necessary since, when the DMH
is roved out, the MP-CSCF is maintaining registration with the
S-CSCF on behalf of the DMH. See Section 3 for details.
MAP/D LOCATION-UPDATE exchange -- The Location-Update exchange is
performed only when the DMH is successfully authenticated by the
MP-CSCF or the S-CSCF. The MP-CSCF must have learned the
proclaimed IMSI from the DMH. Therefore, the SIP REGISTER SHOULD
include its credentials even it is not challenged, with its IMSI
in the username field.
The Location-Update transaction establishes that mobile-
terminating calls are routed through the S-CSCF via the MGCF/MG
for terminating in the VoIP domain.
200 OK -- If the Location-Update MAP exchange with the HLR is
successful, the MP-CSCF returns 200 OK to the DMH.
The errors occurred during MP-CSCF's location update procedure
shall be propagated to the DMH.
IMSI invalid: If the HLR returns error code indicating IMSI
invalid, the MP-CSCF will return "404 Not Found" SIP message.
Roaming not allowed: If the HLR returns error code indicating this
subscriber is not allowed to roam into the GAN area served by
this MP-CSCF, the MP-CSCF returns "603 Forbidden" SIP message.
Other errors: If the Location-Update exchange with the HLR results
with other errors, such as timed out, the MP-CSCF returns "500
Internal Server Error" SIP message to the DMH.
An Expires January 29, 2007 [Page 10]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
2.3. Examples of Registration Messages
Example SIP REGISTER request which reports alternative radio networks
:
REGISTER sip:registrar.home1.net SIP/2.0
Via: SIP/2.0/UDP ip4_adr:ip4_port; branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF12
From: <sip:user1_public1@home1.net>;tag=4fa3
To: <sip:user1_public1@home1.net>
Contact: <sip:ip4_adr; ip4_port>; expires=600000
Accept: application/3GPP-SHP
Call-ID: apb03a0s09dkjdfglkj49111
CSeq: 1 REGISTER
Content-Length:(...)
Content-Type: multipart/mixed; boundary=unique_boundary_1
MIME-Version: 1.0
--unique_boundary_1.
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=(...)
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique_boundary_1
An Expires January 29, 2007 [Page 11]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Example 200 OK of REGISTER which assigns GAN cell-id:
SIP/2.0 200 OK
Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;branch=z9hG4bKnashds7
P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
From:
To:
Call-ID:
Contact:
Accept: application/3GPP-SHP
CSeq: 1 REGISTER
Date: Thu, 21 Feb 2005 13:02:03 -700
Organization: Operator-Long-Name (Short-Name)
Content-Length: 128
Content-Type: multipart/mixed; boundary=unique_boundary_1
MIME-Version: 1.0
--unique_boundary_1.
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique_boundary_1
In the following sub-sections, the additional headers and bodies in
the above message flow are explained.
2.4. Alternative Access Network Information
When a dual mode handset (DMH) is deployed for service across
heterogeneous networks, such as WLAN and cellular, a DMH is involved
in more than one access network. Passing the information of the
alternative access network information between the handset and the
MP-CSCF is necessary during SIP registration.
2.4.1. Reporting of P-Access-Network-Info
The P-Access-Network-Info header is defined in [RFC3455]. SIP User
Agents use this header to relay information about the access
technology and location information to SIP proxies that are providing
services.
An Expires January 29, 2007 [Page 12]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
If the DMH detects alternative access networks, such GSM cells, and
wishes to achieve seamless service across multiple access networks,
it SHOULD include multiple P-Access-Network-Info headers in the SIP
REGISTER request. The first P-Access-Network-Info header should be
the network through which the SIP REGISTER is sent, the rest of
multiple P-Access-Network-Info headers shall be in the order of
preference. For example, when the DMH detects GSM alternative access
network, it shall include a separate P-Access-Network-Info header for
each detected GSM cell, in the order of detected signal strength. In
these alternative P-Access-Network-Info headers, 3GPP-GERAN is the
access-type, and cgi-3gpp is the access-info.
In the above example, the REGISTER is sent through an IEEE-802.11a
access point with SSID="ssid". The DMH also detects two GSM cells,
first one has a stronger signal than the second one.
The Cell Global Id (CGI) coding, which is defined in [3GPP.48.008],
includes the cell id which also represents rough geographical
location.
If the access type field is equal to "3GPP-GERAN", the access info
field shall contain a value of "cgi-3gpp". Its value includes the
Cell Global Identity obtained from lower layers of the DMH. This
value is made up of a concatenation of the MCC, MNC, LAC and GSM
cell-id. Starting with the most significant bit: MCC (3 digits), MNC
(2 or 3 digits depending on MCC value), LAC (fixed length code of 16
bits using full hexadecimal representation) and CI (fixed length code
of 16 bits using full hexadecimal representation).
If the access type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-
TDD" or "3GPP-CDMA2000" the access-info field SHALL contain a value
of "utran-cell-id-3gpp". This value is made up of a concatenation of
the MCC, MNC, LAC (as described in [3GPP.23.003]) and the UMTS Cell
Identity (as described in [3GPP.25.331]), obtained from lower layers
of the DMH, and is coded as a text string as follows:
Starting with the most significant bit: MCC (3 digits), MNC (2 or 3
digits depending on MCC value), LAC (fixed length code of 16 bits
using full hexadecimal representation) and UMTS Cell Identity (fixed
length code of 28 bits).
If the access type is IEEE-802.11a/b/g, the extension-access-info
field SHOULD contain the SSID of the access point.
2.4.2. Assignment of P-Access-Network-Info
Unlike cellular radio technology which broadcasts cell information to
the handset, the VoIP network is agnostic to radio access
An Expires January 29, 2007 [Page 13]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
technologies. With the reporting of location information as
described above, the network SHOULD inform the DMH (and the
subscriber) the network identity of the VoIP MP-CSCF.
In the mobile assisted and network controlled handover, as described
in this document, the MP-CSCF should be a local entity which has
peering relationship with the local cellular network. Note this
network id is not the WLAN network id. It is the pseudo cell-id of
the MP-CSCF as appeared to the cellular network.
The MP-CSCF SHOULD insert a P-Access-Network-Info header in the 200
OK of SIP REGISTER response with the access-type of 3GPP-GAN,
indicating this is a MP-CSCF which supports converged services with a
3GPP network; and a 3gpp-cgi, which is the cell-id of the pseudo cell
of the MP-CSCF as appeared to the cellular network.
For 3GPP-GAN, the 3gpp-cgi coding SHALL be identical to that of 3GPP-
GERAN. It is the cell-id of the MP-CSCF cell that is provisioned in
the neighbor cell list of the cellular network.
The syntax of access-type defined in [RFC3455] is expanded:
access-type = "IEEE-802.11a" / "IEEE-802.11b" /
"3GPP-GERAN" / "3GPP-UTRAN-FDD" /
"3GPP-UTRAN-TDD" / "3GPP-CDMA2000" /
"3GPP-GAN" / token
When assigning a 3GPP-GAN cell, the MP-CSCF SHOULD also provide
additional information to the DMH, using the extension-access-info
field.
The syntax of extension-access-info for 3GPP-GAN is as follows:
extension-access-info = kv-pair-series
kv-pair-series = kv-pair ["," kv-pair-series]
kv-pair = key EQUAL value
key = "BSIC" / "BCCH-FREQ" / "HANDOVER"
value = [0...63] if key="BSIC"
value = [0...31] if key="BCCH-FREQ"
value = [0...255] if key="HANDOVER"
The extension-access-info parameter for 3GPP-GAN is only used for
network controlled handover. BSIC is the Base Station Identity Code
of the GAN cell; BCCH-FREQ is the pseudo frequency number of the GAN-
cell; HANDOVER is the handover pseudo handover reference number.
Note, the reporting and assignment of 3GPP-GAN cell information is
An Expires January 29, 2007 [Page 14]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
required in the SIP REGISTER transaction. However, the assignment of
the extension-access-info is optional during the SIP-REGISTER
response. The HANDOVER tag is not used in the SIP-REGISTER
transaction. The assignment of extension-access-info is required in
Hand-Out as described in Section 6. The syntax is described here for
convenience reasons.
2.5. Cellular Radio Information
In order for the network to initiate a network-controlled handover,
the VoIP network needs to know the capability of the DMH's cellular
radio. In particular, the classmark information of the 3GPP handset
needs to be reported to the MP-CSCF.
2.5.1. Cellular Radio Information Reporting
The reporting of DMH's classmark is achieved by attaching a 3GPP-SHP
message body to the SIP-REGISTER message.
To achieve full service, the DMH SHOULD carry an MIME attachment of
3GPP-SHP's REGISTER-REQUEST message body. The message body must be
attached according to [RFC3261] and [RFC3204]. The content of the
SHP REGISTER-REQUEST message contains the classmark information of
the handset. The message format and encoding are described in
Section 8.
An example of SIP-REGISTER with 3GPP-SHP REGISTER-REQUEST is shown in
Section 2.3.
2.5.2. Cellular Radio Information Acknowledgement
If the SIP REGISTER request contains an attachment of 3GPP-SHP
REGISTER REQUEST message body, the 200 OK response to the SIP
REGISTER request MUST attach a 3GPP-SHP REGISTER-ACCEPT message. The
current version of the SHP, the SHP REGISTER-ACCEPT is optional.
An example of SIP-REGISTER with 3GPP-SHP REGISTER-ACCEPT is shown in
Section 2.3.
2.6. TMSI Assignment
In 3GPP GSM network, a Temporary Mobile Station Identifier (TMSI) is
assigned to a mobile station for privacy purposes. When a mobile
station performs a fresh registration, e.g. during every power-on,
the handset must send its IMSI to the base station in the clear
before an encryption key can be generated.
Since IMSI is a private Id assigned by the network to a mobile
An Expires January 29, 2007 [Page 15]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
device, the operators wish to minimize the transmission of the IMSI
identifier without any encryption being applied. Therefore, TMSI is
used when a handset roams from MSC to MSC.
For a dual mode handset, there are rove-in and rove-out operations,
where the handset switches network from WLAN to/from cellular in a
rather frequent manner. Roving operations may be frequent due to the
small coverage range of WLAN networks and the coverage might have
holes.
To avoid the use of IMSI during rove-out, the MP-CSCF assigns a TMSI
to the handset during SIP registration. The TMSI is passed down to
the DMH in the 200 OK response of SIP REGISTER. The TMSI allocated
for the DMH is only valid between the DMH and the MP-CSCF. As in
3GPP network, the TMSI is a unique value for the LAC area on the MP-
CSCF only.
2.6.1. Use of P-Associated-URI for TMSI Assignment
In the 200 OK response to SIP REGISTER, the allocated TMSI is
included in the P-Associated-URI header. The P-Associated-URI header
is defined in [RFC3455]. Since the TMSI is only valid between the
DMH and the MP-CSCF, it SHALL be in the form of
The syntax of P-Associated-URI:
P-Associated-URI: <sip:TMSI-ABCDABCD@mp_cscf_adr:mp_cscf_port>
The string after the TMSI-, i.e. ABCDABCD, is the hex value of the
4-byte TMSI value. Note the URI SHOULD only use the address and port
of the MP-CSCF, which may be different from that of the SIP URI's
realm and port. When this P-Associated-URI is passed from the MP-
CSCF to the DMH, it means that it is an alternative URI for the
registered URI, and can be used interchangeably between the DMH and
the MP-CSCF.
An example of 200 OK with TMSI assigned is shown in Section 2.3.
An Expires January 29, 2007 [Page 16]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
3. Rove-Out: From WLAN to Cellular
The Rove-Out message flow between the DMH and the MP-CSCF is
identical to that of [yafan-fmc-arch]. But, in this document, the
message flow has extra Information fields exchanged between the DMH
and the MP-CSCF.
In particular, when the TMSI and the LAI (i.e., Location Area
Indicator portion of the GAN cell-id) are available, the handset MUST
use them, instead of the IMSI, while logging on to the cellular
network.
The benefit of using TMSI, instead of IMSI, is that IMSI will not be
transmitted in the clear, and the cellular MSC will query the MP-CSCF
to retrieve the IMSI of the handset. The LAI of the GAN cell-id is
used by the MSC to derive routing information to the MP-CSCF.
The message sequence charts below are for information only. Non-SIP
messages in the charts are not part of the requirements for
compliance to this document.
An Expires January 29, 2007 [Page 17]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Rove-Out Message Flow for Cellular-Homed DMH:
Visited Target Target
DMH MP-CSCF BSC HLR MSC/VLR
| | | | |
| SIP: REGISTER | | | |
|--------------------->| | | |
| | < Intermediate messages skipped > |
| SIP 200 OK | | | |
|<---------------------| | | |
| (gan-cgi, tmsi) | | | |
| | | | |
| BCCH: Signal==Good | | | |
|<------------------------------| | |
| RR: CHAN REQ/ASS | | | |
|<----------------------------->| | |
| | | | |
| MM: LOC UPDATE (previous-LAI=gan-lai, TMSI=tmsi ) |
|------------------------------>|------------------------------>|
| | MAP/G: SEND PARMS (tmsi) |
| |<---------------------------------------|
| | MAP/G: SEND PARMS res (imsi) |
| |--------------------------------------->|
| | | | LOC UPD |
| | | |<----------------|
| < Intermediate messages skipped > |
| | | | LOC UPD res |
| | | |---------------->|
| MM: LOC UPD ACCEPT | | | |
|<--------------------------------------------------------------|
| SIP: de-REGISTER | | | |
|--------------------->| | | |
| SIP: 200 OK | | | |
|<---------------------| | | |
An Expires January 29, 2007 [Page 18]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Rove-Out Message Flow for Soft Switch-Homed DMH:
Visited Target Target
DMH MP-CSCF BSC HLR S-CSCF MSC/VLR
| SIP: REGISTER | | | | |
|--------------------->| SIP: REGISTER | | |
| |---------------------------->| |
| | SIP: 200 OK | | |
| SIP 200 OK |<----------------------------| |
|<---------------------| | | | |
| (gan-cgi, tmsi) | | | | |
| | | | | |
| BCCH: Signal==Good | | | | |
|<------------------------------| | | |
| RR: CHAN REQ/ASS | | | | |
|<----------------------------->| | | |
| MM: LOC UPDATE | | | MAP: LOC UPD |
|------------------------------>|------------------------------>|
| < The rest of messages are identical > |
| < to the cellular homed case shown above > |
| MM: LOC UPD ACCEPT | | | | |
|<--------------------------------------------------------------|
| SIP: de-REGISTER | | | | |
|--------------------->| | REGISTER (trust) | |
| SIP: 200 OK |---------------------------->| |
|<---------------------| | 200 OK | | |
| |<----------------------------| |
An Expires January 29, 2007 [Page 19]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
4. Rove-In: From Cellular to WLAN
Rove-in message flow is identical to the SIP registration flows
described in Section 2.
Since it is required to use a secure transport protocol to transmit
SIP messages, thus it is safe for the DMH to use IMSI as username.
An Expires January 29, 2007 [Page 20]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
5. Call Setup in VoIP Domain with Cellular Crypto Setup
Call origination and termination in the VoIP domain follows the same
message flow as in [yafan-fmc-arch]. However, to be prepared for a
potential hand-out, cellular (e.g. GSM) encryption keys SHOULD be
generated during SIP call setup phase.
In a normal 3GPP voice call, voice signaling and bearer are
encrypted. The encryption key are derived during the handset
authentication phase. During handover from one MSC to another, the
key derivation phase is omitted for performance reasons. The
encryption material is instead transferred from the source MSC to the
target MSC during handover.
Due to the small coverage range of WLAN, a faster handout is
perceived as an important requirement. Therefore, a pair of cellular
encryption is derived during SIP call setup phase. The crypto
material is then transferred from the MP-CSCF to the target MSC
during hand-out.
It should be noted that, when AKAv1-MD5 ([RFC3310] is utilized as the
authentication mechanism between the dual mode handset (DMH) and the
MP-CSCF, the challenge and response algorithm of AKAv1-MD5 already
provides a key distribution mechanism that could be used for cellular
encryption after hand-out. In which case the mechanism in this
section may become unnecessary.
However, AKAv1-MD5 assumes IMS SIM (or ISIM) and the HLR/HSS supports
the AKA algorithm. This may pose a deployment restriction for some
time to come.
By utilizing the mechanism described in this section, a deployment
MAY choose to use another authentication mechanism, such as Digest-
MD5 for authentication, yet still achieve adequate security for hand-
out.
An Expires January 29, 2007 [Page 21]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
5.1. Call Origination Message Flow
Call Origination in VoIP Domain for SS-homed and Cellular-Homed DMH:
Visited S-CSCF or
DMH MP-CSCF HLR MGCF/MGW GMSC
| SIP: INVITE (sdp) | | | |
|-------------------->| MAP/D: SEND AUTH INFO| | |
| |--------------------->| | |
| | MAP/D: SAI result | | |
| |<---------------------| | |
| | SIP: INVITE (sdp) | | |
| |---------------------------->| |
| < Intermediate messages skipped > | |
| | SIP: 200 OK (sdp) | | |
| SIP: 200 OK (sdp, |<----------------------------| |
|<--------------------| | | |
| SHP-Cipher-CMD) | | | |
| | | | |
| SIP: ACK ( | | | |
|-------------------->| SIP: ACK | | |
| SHP-Cipher-COM) |---------------------------->| |
| | | | |
Cellular-homed calls are routed through the MGCF, Soft Switch-homed
calls are routed through the S-CSCF.
INVITE (DMH --> MP-CSCF) -- The SIP UA on the DMH send a normal SIP
INVITE to initiate a call. The normal SDP offer and answer occurs
during this INVITE transaction. Normal authentication challenge
and responses are omitted in the above diagram.
MAP/D SEND AUTHENTICATION INFO exchange -- The SAI exchange is
performed only when MP-CSCF does not have any unused cellular
authentication vectors. The purpose of this exchange is to
retrieve new authentication vectors from the HLR/AuC. One
authentication vector is needed for each call setup to derive a
new cellular encryption/decryption key.
If no authentication vector is available and SAI failed to obtain
new authentication vectors, the call MAY still be allowed to set
up without cellular crypto key prepared. The MP-CSF may reject
hand-out request according to security policy settings.
200 OK -- The 200 OK, which may contain a SDP answer from the called
party, SHALL contain a SHP-CIPHER-COMMAND body inserted by the MP-
CSCF. The SHP-CIPHER-COMMAND SHALL be used by the DMH to
configure the codec, crypto keys and algorithm for any potential
An Expires January 29, 2007 [Page 22]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
handover to the cellular network.
The SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange follows
the Request/Response model. The Request is sent by a network
element like the MP-CSCF, the Response is sent by a mobile device.
Once a Request is offered, it MUST be answered by a Response.
ACK -- If a SHP-CIPHER-COMMAND is attached to the received 200 OK
message, the DMH MUST attach an SHP-CIPHER-COMPLETE to the SIP
ACK. The SHP-CIPHER-COMPLETE message contain a MAC code so that
the MP-CSCF can verify that the crypto key is successfully
generated by the DMH for potential hand-out.
When the DMH generates the SHP-CIPHER-COMPLETE message, it has
created a crypto key according to the cellular standard. The DMH
MUST store this key for use as the crypto key after hand-out.
5.2. Call Termination Message Flow
Call Termination in VoIP Domain for SS-homed and Cellular-Homed DMH:
An Expires January 29, 2007 [Page 23]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Cellular-homed DMH:
Visited
DMH MP-CSCF HLR MGCF/MGW GMSC
| | | | |
| | | MAP/C: SRI |<--
| | MAP/D: PRO ROUTE INFO|<----------------|IAM
| |<---------------------| | |
| | MAP/D: PRI (msrn) | | |
| |--------------------->| MAP/C: SRI(msrn)|
| | |---------------->|
| | SIP: INVITE (msrn) | | IAM |
| |<----------------------------|<---------|
| | | | |
| | MAP/D: SEND AUTH INFO| | |
| |--------------------->| | |
| | MAP/D: SAI result | | |
| SIP: INVITE (sdp, |<---------------------| | |
|<--------------------| | | |
| SHP-Cipher-COM) | | | |
| | | | |
| SIP: 200 OK (sdp, | | | |
|-------------------->| SIP: 200 OK (sdp) | | |
| SHP-Cipher-COM) |---------------------------->| |
| | | | |
<... Intermediate messages skipped ...>
Soft Switch-homed DMH:
Visited Circuit
DMH MP-CSCF HLR S-CSCF Switch
| | | | |
| | SIP: INVITE | | IAM |
| |<----------------------------|<---------|
| | MAP/D: SEND AUTH INFO| | |
| |--------------------->| | |
| | MAP/D: SAI result | | |
| SIP: INVITE (sdp, |<---------------------| | |
|<--------------------| | | |
| SHP-Cipher-COM) | | | |
| | | | |
| SIP: 200 OK (sdp, | | | |
|-------------------->| SIP: 200 OK (sdp) | | |
| SHP-Cipher-COM) |---------------------------->| |
| | | | |
<... Intermediate messages skipped ...>
Cellular-homed calls are routed through the MGCF, Soft Switch-homed
calls are routed through the S-CSCF.
An Expires January 29, 2007 [Page 24]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
General routing mechanism for mobile-terminated calls is described in
[yafan-fmc-arch].
MP-CSCF Receives INVITE -- The MP-CSCF receives a normal SIP INVITE
for a mobile-terminated call. The normal SDP offer and answer
occurs during this INVITE transaction.
MAP/D SEND AUTHENTICATION INFO exchange -- In order to prepare the
crypto key for this call for potential hand-out, the MP-CSCF needs
a fresh cellular authentication vector. This SAI exchange is
performed only when the MP-CSCF does not have any unused cellular
authentication vectors. The purpose of this exchange is to
retrieve new authentication vectors from the HLR/AuC. One
authentication vector is needed for each call to derive a new
cellular encryption/decryption key.
If no authentication vector is available and SAI failed to obtain
new authentication vectors, the call may still be allowed to set
up without cellular crypto key prepared. The MP-CSF MAY reject
hand-out request according to security policy settings.
INVITE (MP-CSCF --> DMH -- The INVITE, which may already contain a
SDP answer from the called party, SHALL contain a SHP-CIPHER-
COMMAND body inserted by the MP-CSCF. The SHP-CIPHER-COMMAND
SHALL be used by the DMH to configure the codec, crypto key and
algorithm for any potential handover to the cellular network.
The SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange follows
the Request/Response model. The Request is sent by a network
element like the MP-CSCF, the Response is sent by a mobile device.
Once a Request is offered, it MUST be answered by a Response.
200 OK (DMH -->> MP-CSCF -- If a SHP-CIPHER-COMMAND was attached to
the received INVITE message, the DMH MUST attach an SHP-CIPHER-
COMPLETE to the 200 OK response. The SHP-CIPHER-COMPLETE message
contains a MAC code so that MP-CSCF can verify that crypto key is
successfully generated by the DMH for potential hand-out.
When the DMH generates the SHP-CIPHER-COMPLETE message, it creates
a crypto key according to the cellular standard. The DMH MUST
store this key for use as the crypto key after hand-out.
An Expires January 29, 2007 [Page 25]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
5.3. Examples of Call Setup Messages
INVITE in Call Origination (DMH --> MP-CSCF
INVITE sip:user2_public1@home2.net SIP/2.0
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel
Contact: <sip:ms_ip4_adr:ms_ip4_port>
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, REFER
Accept: application/sdp, application/3GPP-SHP
Accept-Encoding: base64, binary
Content-Type: application/sdp
Content-Length: (.)
v=0
o=- 2987933615 2987933615 IN IP4 ms_ip4_adr
s=-
c=IN IP4 ms_ip4_adr
t=0 0
m=audio 3456 RTP/AVP 97 96
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
An Expires January 29, 2007 [Page 26]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
200 OK in Call Origination (MP-CSCF --> DMH
SIP/2.0 200 OK
Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;
branch=z9hG4bKnashds7, SIP/2.0/UDP
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
CSeq: (.)
Contact: <sip:user1_public1@mp_cscf_ip_adr:mp_cscf_port>
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
Accept: application/sdp, application/3GPP-SHP
Content-Length: (...)
Content-Type: multipart/mixed; boundary=unique_boundary_1
MIME-Version: 1.0
--unique_boundary_1
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933615 2987933615 IN IP4 internal_ip4_adr
s=-
c=IN IP4 peer_ip4_adr
t=0 0
m=audio 6544 RTP/AVP 97 96
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
--unique_boundary_1--
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique_boundary_1--
The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
COMMAND message.
An Expires January 29, 2007 [Page 27]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
200 OK in Call Origination (MP-CSCF --> DMH
ACK sip:ms_ip4_adr:ms_ip4_port SIP/2.0
Via: SIP/2.0/UDP ms_ip_adr:ms_port;
branch=z9hG4bKnashds7, SIP/2.0/UDP
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
CSeq: (.)
Contact: <sip:user1_public1@ms_ip_adr:ms_port>
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
Accept: application/sdp, application/3GPP-SHP
Content-Type: application/3GPP-SHP
Content-Length: (...)
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
COMPLETE message.
An Expires January 29, 2007 [Page 28]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
INVITE in Call Termination (MP-CSCF --> DMH
INVITE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP mp_cscf_ip4_adr:mp_cscf_ip4_port;
branch=z9hG4bKnashds7
Max-Forwards: 70
From: <sip:user2_public1@home2.net>;tag=171828
To: <sip:user1_public1@home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 127 INVITE
Supported: 100rel
Contact: <sip:user2_public1@mp_cscf_ip_adr:mp_cscf_port>
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO
Accept: application/sdp, application/3GPP-SHP
Content-Type: multipart/mixed; boundary=unique_boundary_1
MIME-Version: 1.0
Content-Length: (...)
--unique_boundary_1
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933615 2987933615 IN IP4 peer_ip4_adr
s=-
c=IN IP4 peer_ip4_adr
t=0 0
m=audio 3456 RTP/AVP 97 96
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
--unique_boundary_1--
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique_boundary_1--
The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
COMMAND message.
An Expires January 29, 2007 [Page 29]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
INVITE in Call Termiination (MP-CSCF --> DMH
SIP/2.0 200 OK
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_adr;
branch= z9hG4bKnashds7, SIP/2.0/UDP
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
CSeq: (.)
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, REFER
Accept: application/sdp, application/3GPP-SHP
Content-Length: (...)
Content-Type: multipart/mixed; boundary=unique_boundary_1
MIME-Version: 1.0
--unique_boundary_1
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933615 2987933615 IN IP4 ms_ip4_adr
s=-
c=IN IP4 ms_ip4_adr
t=0 0
m=audio 6544 RTP/AVP 97 96
a=rtpmap:97 AMR
a=fmtp:97 mode-set=0,2,5,7; maxframes=2
a=rtpmap:96 telephone-event
--unique_boundary_1--
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
--unique_boundary_1--
The Binary-encoded 3GPP-SHP attachment body contains a SHP-CIPHER-
COMPLETE message.
5.4. 3GPP GSM Crypto Setup
Crypto setup in preparation for a potential hand-out is carried by
the SHP-CIPHER-COMMAND and SHP-CIPHER-COMPLETE exchange. When the
An Expires January 29, 2007 [Page 30]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
hand-out is from WLAN to GSM, the crypto key is prepared according to
GSM encryption algorithm.
The SHP-CIPHER-COMMAND is always sent by an network element, such as
the MP-CSCF, and the SHP-CIPHER-COMPLETE is always responded by the
mobile device. During a call setup, either origination or
termination, the SHP-CIPHER-COMMAND message is attached to the first
downstream message from MP-CSCF to the DMH, and the SHP-CIPHER-
COMPLETE is attached to the first upstream message from the DMH to
the MP-CSCF.
The key elements in the SHP-CIPHER-COMMAND are the cipher mode
setting and the RAND, a random number that the MP-CSCF retrieved from
the HLR/AuC, or generated by itself. The key element in the SHP-
CIPHER-COMPLETE message is the Message Authentication Code (MAC)
computed by the DMH according to cipher mode setting using the RAND
in the SHP-CIPHER-COMMAND message. The MAC is verified by the MP-
CSCF to authenticate that the DMH has the correct key Kc.
An Expires January 29, 2007 [Page 31]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
6. Hand-Out from WLAN to Cellular
A hand-out operation is a procedure to transfer an active session
from a generic access network to a cellular access network.
After a successful SIP registration with the home or visited MP-CSCF,
who returned a configured P-Access-Network-Info field, the DMH will
be able to perform seamless hand-out to a cellular network by
treating the MP-CSCF as a MSC/BSC. The CGI field values of MCC, MNC,
LAC, cell-ID, and TMSI fields obtained during SIP registration MUST
be used during the hand-out operation.
During the current or any previous SIP INVITE sequence, the DMH and
MP-CSCF have also prepared a crypto key to be used by the DMH and the
target BSC after handover. Such a crypto key MUST be used by the DMH
for signaling and voice bearer encryption immediately after hand-out.
6.1. Hand-Out Trigger Detection
In network-controlled hand-out, hand-out trigger detection is a two-
step process:
Handset Request: While in an active voice call, the DMH must
periodically scan for cellular signals when the GAN radio signal
shows any sign of weakening. The DMH determines to issue a hand-
out request to the MP-CSCF based on its local hand-out policy.
The local hand-out policy is outside the scope of this
specification.
Network Control: The hand-out request issued to the MP-CSCF is
further screened by the MP-CSCF. The MP-CSCF may ignore the
request, or execute on the request and instructs the DMH to hand-
out.
In executing a hand-out, the MP-CSCF selects a target cellular MSC
based on the hand-out request from the DMH and a network policy (such
as a overload control policy). The selection may be different from
the preferences indicated by the DMH in the request. The network
policy is outside the scope of this specification.
6.2. Hand-Out Message Flow
From the handset's perspective, hand-out signaling is common for both
soft switch-homed and cellular-homed subscribers.
In the example message flow below, it starts with an active call,
which is a mobile-terminated call from user2_public@home2.net to
user1_public@home1.net, and the call is active.
An Expires January 29, 2007 [Page 32]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Hand-out message flow for SS-homed and Cellular-Homed DMH:
Target S-CSCF HO Target Peer
DMH BSC/BTS MP-CSCF MGCF-1 MGCF-2 MSC/VLR Network
| | | | | | |
| <== active call ==> | <== call ==>|<== active call ==========> |
| | | | | | |
| SIP: INFO | | | | |
|-------------------->| MAP/E: PREPARE-HO (ho_no_req) | |
| (SHP-HO-REQUEST) |------------------------------>| |
| | | A: HO-REQUEST | | |
| |<------------------------------------------| |
| | | A: HO-REQUEST ACK| | |
| |------------------------------------------>| |
| | | MAP/E: PREP-HO res (ho_no) | |
| | |<------------------------------| |
| | | SIP: INVITE (ho_no, | IAM | |
| | |--------------------->|------->| |
| | | peer_sdp) | | |
| | | SIP: 183 | ACM | |
| | |<---------------------|<-------| |
| | | <... PRACK omitted ...> | |
| | | | | | |
| SIP: REFER | SIP: UPDATE/INVITE (ho_sdp) | |
|<--------------------|------------>|--------------------------->|
| (SHP-HO-CMD) | | | | |
| SIP: 202 ACCEPTED | 200 OK | 200 OK (peer_sdp) |
|-------------------->|<------------|<---------------------------|
| (SHP-HO-COM) | A: HO-DETECT, HO-COMPLETE | |
|........>|------------------------------------------>| |
| | | SIP: 200 OK | | ANM | |
| | |<---------------------|<-------| |
| | | <== call ==>|<== active call ==========> |
| | | <== active call ===> | | |
| | | | | | |
| | | MAP/E: SEND-END-SIGNAL | |
| | |<------------------------------| |
| | | | | | |
<... Intermediate messages skipped ...>
6.3. Reporting of Cellular Radio Conditions
During an active call in the GAN network, the DMH must periodically
monitor the signal quality of the surrounding cellular cells. In
GSM, the broadcast channel is the BCCH. The BCCH broadcasts the cell
information of the GSM cell, which includes the Location Area
Identifier (LAI) and the cell-id.
An Expires January 29, 2007 [Page 33]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
If a phase-1 hand-out trigger is detected as described in
Section 6.1, the DMH SHALL start sending SIP INFO messages to report
the radio conditions. Note, the SIP-INFO SHOULD not be generated
with less than 400ms apart.
The SIP-INFO message SHOULD contain a single attachment of SHP-HO-
REQUEST message. The following shows an example of such a SIP-INFO
message.
Example SIP-INFO message with cellular radio reporting:
INFO sip:user2_public1@home2.net SIP/2.0
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: cb03a0s09a2sdfglkj490333
Contact: <sip:user2_public1@ms_ip4_adr:ms_ip4_port>
Allow: INVITE, ACK, UPDATE, CANCEL, BYE, INFO, REFER
Cseq: 128 INFO
Supported: 100rel
Accept: application/3GPP-SHP
Accept-Encoding: base64, binary
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=optional
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
The INFO message body is the SHP-HANDOUT-REQUEST message, which
contains a cell identifier list of the neighboring 3GPP cells and
their signal strength measurement result. The "handling" indicator
in the Content-Disposition header is used to indicate the urgency of
the request:
handling=optional-- indicates less urgency for handover. The DMH
hopes the message body to be processed and a hand-out be executed.
If the MP-CSCF is not in an overload situation, it SHOULD process
the request. If not processed, the DMH may be expected to send a
request again should the condition persists.
An Expires January 29, 2007 [Page 34]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
handling=required-- indicates urgency for handover. The DMH request
the message body to be processed. If not, it is very likely it
will send a request again in about 400ms.
The 200 OK returned for the SIP-INFO does not indicate a hand-out is
granted. It only indicates that the SIP-INFO is processed okay.
Error code for the SIP-INFO method includes:
481 Call Leg/Transaction Does Not Exist
415 Unsupported Media Type, if there is error decoding the body,
or the body is not recognized by any network proxy.
It is NOT recommended to include other bodies together with the SHP
bodies because the SHP-HO-REQUEST is intended for a 3GPP-SHP
application. This body will be consumed by the proxy in the SIP
forwarding path which supports the intended application, while other
bodies might be intended for other applications, which may or may not
reside together with the 3GPP-SHP application. Such cases might
cause confusion in processing the (potentially multiple) responses.
6.4. Network Controlled Hand-out
Once the MP-CSCF receives a SIP-INFO with SHP-HANDOUT-REQUEST, it
processes the SIP-INFO and the attached body based the following
factors:
Local Policy -- Local policy as mentioned in Section 6.1;
Urgency -- Whether "handling=optional/required" was sent by the DMH;
Network Condition -- Conditions of the network.
Note this specification does not mandate any particular policy
implementation.
Once the MP-CSCF decides to execute a hand-out, it selects a target
cell from the reported candidate cell list, and uses the CSI function
of the MP-CSCF to request a handover-number from the target MSC/VLR,
and starts setting up the handover leg toward the target MSC.
Once the handover-leg is set up, the MP-CSCF sends a SIP-REFER
message to the DMH to tear down the previous call-leg and switch to
the cellular radio immediately. The REFER message contains a SHP-HO-
COMMAND message, which specifies cellular radio channel and other
information.
An Expires January 29, 2007 [Page 35]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Example SIP-REFER message with SHP-HO-COMMAND body:
REFER sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11
From: <sip:user1_public1@home1.net>;tag=171828
To: <sip:user2_public1@home2.net>
Call-ID: (...)
Accept: application/3GPP-SHP
Cseq: 128 REFER
Refer-To: sip:user1_public1@home1.net
Contact: <sip:mp_cscf_ip4_adr:mp_cscf_ip4_port>
Content-Type: application/3GPP-SHP; version=V0.1
Content-Disposition: signal; handling=required
Content-Encoding: binary
Content-Length=60
01 00 49 00 00 03 02 00 07 04 10 00 33 63 21
43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63
53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b
0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00
The Request-URI (the URI that follows the method name, "REFER", in
the first line) indicates the user this request addresses. In the
above example, the MP-CSCF is requesting the user to transfer his own
session to a different resource; therefore, the Request URI and the
DMH's SIP URI is the same.
The Refer-To header indicates the transferred-to URI. In this
message, SIP URI is used, but the resource is further qualified by
the attached SHP-HO-CMD message, which indicates a cellular resource.
There is no explicit subscription of the refer events. The DMH
SHOULD NOT send NOTIFY to the MP-CSCF when the switchover transaction
occurs. This is different from [RFC3515], which specifies that a
REFER implicitly subscribes to notification of the refer events. The
rationale for this change is that the refer-to target is the same as
the referred party.
Note, this REFER is sent within an INVITE dialog of the ongoing call.
As described in [RFC3515], when REFER is sent within an existing
dialog, it induces similar processing of the SIP BYE message.
The SHP-HANDOUT-COMMAND contains all the information needed for the
DMH to tune into the specified cellular radio channel. The
"handling" indicator of the body MUST always be coded as "required".
Upon receiving this message, the handset must tune in to the cellular
An Expires January 29, 2007 [Page 36]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
radio channel specified by the attached body, and terminate the RTP
session.
WLAN radio signal may weaken quickly. The MP-CSCF may not receive
the 200 OK response for the SIP-BYE. The DMH SHALL treat the SIP-BYE
i (with handover-command body) as the authoritative instruction to
switch mode. The MP-CSCF may use the MAP/E: SEND-END-SIGNAL as a
safe guard against the loss of 200 OK from the DMH.
The DMH SHOULD not transmit the SIP-INFO unless there is a perceived
need for handover. The DMH SHOULD not use SIP-INFO as a periodic
measurement report. When needed, the SIP-INFO SHOULD be transmitted
with a minimal interval of 400ms.
An Expires January 29, 2007 [Page 37]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
7. Hand-In from Cellular to WLAN
A hand-in operation is to transfer an active call from cellular
network to the GAN network.
Since the DMH is engaged in an active call on the cellular network,
it is aware of the CGI, such as, MCC, MNC, LAC, and cell-id, of the
current cellular cell. These fields must be used during the hand-in
operation. The crypto keys of the cellular network will not be used
during and after hand-in. The GAN network will use a secure
transport protocol. The DMH SHOULD not use its cellular TMSI as its
ID during hand-in to the GAN network.
7.1. Hand-In Trigger Detection
While in cellular network coverage, the DMH must perform the
following actions in three phases:
Phase-A: GAN Attach
1. The DMH must periodically scan for WLAN or any other GAN radio
signals.
2. The DMH may determine whether to attach to a GAN radio network
based on a local policy. Such a policy may includes the
screening of the broadcasted SSID and signal quality to
determine whether to attach to such a network. This procedure
is called Phase-A trigger detection. This procedure is out
side the scope of this specification.
Phase-B: Service Discovery
1. Once the DMH successfully attaches to a GAN radio access
network, the DMH MAY perform a discovery procedure to obtain
the address of a MP-CSCF. In practice, the DMH may need to
obtain other configuration parameters as well, e.g. IP
address, IPsec gateway address etc. The discovery of MP-CSCF
may be combined with other discovery procedures. The
discovery procedure is outside the scope of this
specification.
2. After the discovery procedure, the DMH SHALL attempt to
establish IP connectivity including the appropriate security
associations. The security association establishment may need
user authentication.
3. Once all steps of Phase-B are successful, the DMH SHALL move
on to Phase-C. Any phase-B failure should send the DMH back
An Expires January 29, 2007 [Page 38]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
to phase-A.
Phase-C: Hand-in Attach and Hand-in
1. While in Phase-C, the DMH handset is receiving services from
both the cellular network and the GAN network. Before
Hand-in, the DMH may receive IP access services through the
GAN network.
2. Hand-in Attach: The DMH SHOULD perform a Hand-in Attach (i.e.
SIP-REFER) procedure to allow the active call to be handed
into the VoIP domain. A successful SIP-REFER procedure brings
the DMH into the "hand-in ready" state. Only after a
successful hand-in attach, the DMH MAY include the GAN cell-id
in its cell-id-list in the "RR Measurement Report" to the
cellular BSC. The inclusion of the GAN cell-id indicates to
the BSC that the GAN cell is a selected candidate cell for
handover. The report should be sent periodically until a
handover has happened. The DMH MUST report the GAN cell
signal strength in a normalized fashion.
3. Network Control: Phase-C is the phase where a hand-in is
expected. The cellular BSC/MSC makes the decision to make a
handover, which will cause the MP-CSCF to forward the INVITE
request to the DMH.
As can be seen, hand-in trigger detection is a two-step process:
Phase-A trigger: This is a handset action, where DMH decides to
attach to the GAN network and get ready for a potential hand-in.
Phase-C trigger: This is a network action, where the network screens
and controls the hand-in operation.
The DMH may decide to leave phase-C before a hand-in. It does so by
issuing a SIP REFER message with expires=0 to the MP-CSCF to cancel
the REFER dialog.
During phase-C, both GAN radio and cellular radio are active on the
handset. The handset may wish to shorten the phase-C period by:
Finishing the handover quickly: the DMH may spoof the signal
strength of WLAN to influence the BSC to execute a handover. The
spoofing mechanism is outside the scope of this specification.
The DMH may cancel the REFER, leave phase-C and go back to
phase-A.
An Expires January 29, 2007 [Page 39]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
7.2. Hand-In Attach Message Flow
The purpose of "hand-in attach" is to set up the network (MP-CSCF,
and the cellular BSC/MSC) to transfer active calls from cellular to
GAN domain.
The reason that hand-in attach uses SIP-REFER, instead of SIP-
REGISTER, is that, the DMH does not wish to change subsequent call
termination to the VoIP domain at this time. As we know, SIP-
REGISTER would inform the network to route further call terminations
to the VoIP domain, as a result of which, subsequent calls will be
anchored differently thus creates undesired implications for
supplementary services.
The SIP-REFER will be consumed by the MP-CSCF, which acts as a
Referrer-Server for active call handovers. This REFER is sent
outside of an INVITE dialog. It creates a dialog of its own, which
serves as a temporary address of record (AOR at the MP-CSCF) to
transfer an active call to the contact URI provided in the REFER
method.
Hand-in Attach message flow using SIP-REFER.
Visited S-CSCF
DMH MP-CSCF / MGCF HLR
| SIP: REFER | | |
|------------------------>| MAP/D: SEND AUTH INFO |
| |------------------------------------->|
| | MAP/D: SEND AUTH INFO result |
| SIP: 407 Unauthorized |<-------------------------------------|
|<------------------------| | |
| SIP: REFER | | |
|------------------------>| | |
| SIP: 202 ACCEPTED | | |
|<------------------------| | |
SIP-REFER -- The MDH sends a REFER message to the MP-CSCF.
An Expires January 29, 2007 [Page 40]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Example SIP-REFER message for Hand-in Attach:
REFER sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11
From: <sip:user1_public1@home1.net>
To: <sip:user1_public1@home1.net>
Refer-To: <sip:user1_public1@home1.net;method=INVITE>
Contact: <sip:user1_public1@ms_ip4_adr:ms_ip4_port>;expires=60
Call-ID: apb03a0s09dkjdfglkj49111
Accept: application/sdp; application/3GPP-SHP
Authorization: Digest username="user1_private@home1.net",
realm="home1.net", nonce="", uri="sip:home1.net", response=""
CSeq: 1 REFER
Content-Length: 0
The use of REFER for hand-in is a special use case of a general
REFER. Since the REFER requester and the Refer-to party is the
same, the identity in the request URI header, Refer-to header, and
the Contact header is the same. Because of this, the processing
of REFER is further simplified from that described in [RFC3515],
as follows:
No NOTIFY required-- Since the requester will receive the refer
event (i.e. the INVITE), it is not necessary to send a NOTIFY
to the DMH. In this document, the MP-CSCF SHALL not send a
NOTIFY to the DMH SIP UA.
Duration-- Without NOTIFY, the duration of implicit subscription
(or the referring duration SHALL be according to the Expires
tag/header in the 202 ACCEPTED response according to standard
SIP procedures.
Canceling a REFER Canceling a REFER SHALL be done by issuing a
REFER with Expires=0 tag/header.
The use of P-Access-Network-Info header here is identical to that
described in Section 2. However, in REFER, there must be one and
only one alternative access network info header, which represents
the current cellular cell-id where the call is active. This
information is needed by the MP-CSCF to perform potential hand-in
operation. In case that the DMH has changed its cellular serving
cell, i.e. a handover to another cellular cell has happened before
a hand-in to the GAN cell, the DMH MUST perform a refresh REFER
with the new serving cell-id. If, as a result of changing the
An Expires January 29, 2007 [Page 41]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
serving cell-id, the DMH receives a 3XX/4XX/5XX/6XX response to
the REFER request, the DMH SHALL consider the previous REFER as
cancelled, and performs according to standard SIP procedures.
MAP/D SEND AUTHENTICATION INFO exchange -- REFER MAY be challenged.
The MAP SAI is used to retrieve cellular credentials for
authentication.
202 ACCEPTED -- The MP-CSCF returns 202 Accepted without performing a
Location-Update exchange with the HLR.
Example 202 ACCEPTED message for Hand-in Attach:
SIP/2.0 200 ACCEPTED
Via: SIP/2.0/UDP mp_cscf_ip_adr:mp_cscf_port;
branch=z9hG4bKnashds7
P-Access-Network-Info: 3GPP-GAN; cgi-3gpp=432515DCDCF11;
extension-access-info=<BSIC=bsic,BCCH-FREQ=bcch>
From:
To:
Call-ID:
Contact:
Accept: application/3GPP-SHP
CSeq:
Date: Thu, 21 Feb 2005 13:02:03 -700
Organization: Operator-Long-Name (Short-Name)
Content-Length: 0
Similar to REGISTER in Section 2.4.2, the MP-CSCF returns the
configured GAN cell-id and extended access information. The
extension-access-info includes all the information the DMH needs
to generate a "Measurement Report".
7.3. Hand-In Message Flow
In the "hand-in ready" state, the DMH is sending measurement reports
to the cellular BSC, and the BSC/MSC MAY issue a handover command at
any time.
Note, the handover event MAY be a hand-in to GAN or any other
cellular cells:
Normal handover: DMH receives a DTAP HANDOVER-COMMAND through the
cellular network to switch to another cellular cell. In this
case, the DMH MUST refresh its hand-in attach with the new serving
cell-id. See Section 7.2.
An Expires January 29, 2007 [Page 42]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Hand-in with Early INVITE: A referred INVITE through GAN, and then
a DTAP HANDOVER-COMMAND through the cellular network; or
Hand-in with Late INVITE: A DTAP HANDOVER-COMMAND through the
cellular network, and then a referred INVITE.
The two scenarios of hand-in are described in this section.
7.3.1. Hand-In Message Flow with Early INVITE
Hand-in message flow for SS-homed and Cellular-Homed DMH:
Source S-CSCF HO Source Peer
DMH BSC/BTS MP-CSCF MGCF-1 MGCF-2 MSC/VLR Network
| | | | | | |
|<= call=>|<============= active call ===============>|<= call =>|
| | | | | | |
| RR: Measurement Report BSSAP: HO REQUIRED | |
|-------->|------------------------------------------>| |
| (SHP-HO-REQUEST) | MAP/E: PREP-HO (ho_no_req) | |
| | |<------------------------------| |
| | | MAP/E: PREP-HO (ho_no) | |
| | |------------------------------>| |
| | | SIP: INVITE (ho_no, | IAM | |
| SIP: INVITE (msisdn)|<---------------------|<-------| |
|<--------------------| ho_sdp) | | |
| SIP: 200 OK | | | |
|-------------------->| SIP: 200 OK | ANM | |
| | |--------------------->|------->| |
| RR: HO-CMD | BSSAP: HANDOVER COMMAND | |
|<--------|<------------------------------------------| |
| SIP: ACK | SIP: ACK | | |
|<--------------------|<---------------------| | |
| | | MAP/E: SEND END SIGNAL | |
| | |------------------------------>| |
| | | BSSAP: CLEAR | |
| |<------------------------------------------| |
| | BSSAP: CLEAR response | |
| |-------------------------------------------| |
| | | | | | |
|<=== active call ===>|<== active call =====>|<======>|<= call =>|
| | | | | | |
<... Intermediate messages skipped ...>
An Expires January 29, 2007 [Page 43]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Cellular Measurement Report -- During Phase-C, the RR Measurement
Report message may include the GAN-cell id as a candidate cell-id.
Once the cellular BSC decides to initiate a handover to the GAN
cell, the MP-CSCF will allocate a handover number and the MSC will
issue a circuit connection request, which is then translated to a
SIP-INVITE request, to the MP-CSCF.
Referred INVITE -- Once the MP-CSCF receives the INVITE request to
the handover-number, it SHALL map it the DMH's public URI and fork
an INVITE to the DMH. To inform the DMH that this request needs
to be answered immediately (instead of alerting the phone), the
INVITE request has a P-Alerting-Mode header with the value of
"Auto" or "MAO" (Manual Answer Override). To the handset, this
INVITE also serves as the final "NOTIFY" to terminates the REFER
dialog created during hand-in attach. (Note, the REFER dialog was
created outside of an INVITE dialog.)
Example of referred INVITE message for Hand-in:
INVITE sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP peer_ip4_adr:peer_ip4_port;
branch=z9hG4bKnashds7
Max-Forwards: 70
From: <sip:unknown@home2.net>;tag=171828
To: <sip:user1_public1@home1.net>
Call-ID: cb03a0s09a2sdfglkj490333
Accept: application/sdp
Cseq: 1 INVITE
Supported: 100rel
Contact: <sip:pm_cscf_ip4_adr:mp_cscf_ip4_port>
P-Alerting-Mode: MAO
Content-Type: application/sdp
Content-Length: (...)
v=0
o=- 2987933615 2987933615 IN IP4 peer_ip4_adr
s=-
c=IN IP4 peer_ip4_adr
t=0 0
m=audio 3456 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event
An Expires January 29, 2007 [Page 44]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
200 OK -- Once the DMH receives the INVITE with a P-Alerting-Mode of
"Auto" or "MAO", the DMH MUST respond with a 200 OK with its SDP-
answer. This message will allow the downstream RTP traffic to
start to be played out to the user. The DMH SHOULD also start
transmitting RTP packets as this time. Recall that the INVITE is
sent to the DMH as a result of the REFER dialog on the MP-CSCF.
The DMH should not receive any other INVITE since it has not
published its contact globally.
RR HANDOVER COMMAND As a result of the 200 OK/SDP message from the
DMH, the DMH SHALL expect to receive a RR HANDOVER-COMMAND message
from the BSC. Note the DMH may receive the ACK and the RR
HANDOVER-COMMAND in arbitrary order. At this point, the DMH MUST
start transmitting RTP packets if has not already done so, and
stops playing the GSM voice stream received from the cellular BTS.
If the hand-in call terminates in the VoIP domain, the DMH MUST
initiates a SIP-REGISTER according to Section 2 immediately after the
call terminates. This REGISTER will publish its contact to the VoIP
network so that further call termination requests will be routed via
SIP to the DMH.
The DMH MAY support a short period of dual transmission during the
transient period between 200 OK and the HANDOVER COMMAND.
An Expires January 29, 2007 [Page 45]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
7.3.2. Hand-In Message Flow with Late INVITE
Hand-in message flow for SS-homed and Cellular-Homed DMH:
Source S-CSCF HO Source Peer
DMH BSC/BTS MP-CSCF MGCF-1 MGCF-2 MSC/VLR Network
| | | | | | |
|<= call=>|<============= active call ===============>|<= call =>|
| | | | | | |
| RR: Measurement Report BSSAP: HO REQUIRED | |
|-------->|------------------------------------------>| |
| (SHP-HO-REQUEST) | MAP/E: PREP-HO (ho_no_req) | |
| | |<------------------------------| |
| | | MAP/E: PREP-HO (ho_no) | |
| | |------------------------------>| |
| | | SIP: INVITE (ho_no, | IAM | |
| | |<---------------------|<-------| |
| | | ho_sdp) | | |
| | | SIP: 18X (dummy_sdp) | ACM | |
| | |--------------------->|------->| |
| RR: HO-CMD | BSSAP: HANDOVER COMMAND | |
|<--------|<------------------------------------------| |
| SIP: REFER (ho_ref) | | | |
|-------------------->| | | |
|<-- 202 ACCEPTED-----| | | |
| SIP: INVITE (msisdn)| | | |
|<--------------------| | | |
| SIP: 200 OK (ms_sdp)| 200 OK (ms_sdp) | ANM | |
|-------------------->|--------------------->|------->| |
| SIP: ACK | SIP: ACK | | |
|<--------------------|<---------------------| | |
| | | MAP/E: SEND END SIGNAL | |
| | |------------------------------>| |
| | | BSSAP: CLEAR | |
| |<------------------------------------------| |
| | BSSAP: CLEAR response | |
| |-------------------------------------------| |
| | | | | | |
|<=== active call ===>|<== active call =====>|<======>|<= call =>|
| | | | | | |
<... Intermediate messages skipped ...>
Cellular HANDOVER COMMAND -- In this case, the DMH receives the
HANDOVER COMMAND before the referred INVITE. This command
indicates the GAN cell-id as the target cell, together with a
Handover Reference Number. the radio channel information can be
ignored.
An Expires January 29, 2007 [Page 46]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
The HANDOVER COMMAND is sent according to the cellular standard of
the cellular network. For 3GPP Release 4+, this message is
defined in [3GPP.08.08]. The message contains a Layer 3
Information Element from the serving MSC. Since the MP-CSCF is
acting as a 3GPP MSC/BSC, the Layer 3 Information Element is the
Handover Command defined in [3GPP.04.18], which contains, among
others, a one-byte Handover Reference number field.
Immediate REFER -- Since this HANDOVER COMMAND is received before the
referred INVITE, the DMH MUST immediately send an REFER to the MP-
CSCF. This REFER not only includes the current serving cell-id,
but also includes the Handover Reference Number received in the
HANDOVER COMMAND.
Example of immediate REFER message for Hand-in:
REFER sip:user1_public1@home1.net SIP/2.0
Via: SIP/2.0/UDP ms_ip4_adr:ms_ip4_port;
branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: IEEE-802.11a; extension-access-info=ssid
P-Access-Network-Info: 3GPP-GERAN; cgi-3gpp=432515DCDCF11;
extension-access-info=<HANDOVER=ho-ref-no>
From: <sip:user1_public1@home1.net>
To: <sip:user1_public1@home1.net>
Refer-To: <sip:user1_public1@home1.net;method=INVITE>
Contact: <sip:internal_ip4_adr;internal_ip4_port>;expires=60
Call-ID: apb03a0s09dkjdfglkj49111
Authorization: Digest username="user1_private@home1.net",
realm="home1.net", nonce="", uri="sip:home1.net", response=""
CSeq: 1 REFER
Content-Length: 0
ho-no=[0...255]
The immediate REFER implies that a handover event has happened,
and the handover event reference number is provided in
"ho-ref-no".
Referred INVITE -- Once the MP-CSCF receives an immediate REFER
message, the MP-CSCF maps the INVITE request to the handover-
number to the DMH's public URI and fork an INVITE to the DMH.
This INVITE is the same as the referred INVITE in Section 7.3.1.
An Expires January 29, 2007 [Page 47]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
200 OK -- This completes the hand-in. The handset SHALL start
transmitting and playing out RTP packets, and stops audio
transmission and reception on the cellular radio.
In the "Late INVITE" case, the actual handover is already underway in
the network when the handset receives the HANDOVER COMMAND from the
cellular network. After the handset sends the immediate REFER
message, it SHOULD start a timer of 2~3 seconds in anticipating for
the referred INVITE. Before the timer expires, the handset SHALL
maintain relevant state information of the ongoing call. Should the
GAN (e.g. WALN) network signal changes dramatically during this
period, or the DMH does not receive the referred INVITE within this
timer period, the handset SHOULD clear the call, perform a SIP-
REGISTER as described in Section 2, and treat all incoming INVITE as
a new call termination.
7.3.3. Early versus Late INVITE in Hand-in
Whether the network is going to perform an "early" or "late" INVITE
depends on the version of the cellular network. Early INVITE is
performed by the MP-CSCF if the serving cellular network is of 3GPP
Release 4 or later. Late INVITE is usually performed if the serving
cellular network is of 3GPP Release 99 or earlier.
The reason for this variation is that, in 3GPP Release 99 and
earlier, the MAP PREPARE-HANDOVER request may not include the IMSI.
This causes the MP-CSCF inability to correlate the MAP request with
the handset's URI. A correlation is achieved immediately when the
handset reports the handover reference number to the MP-CSCF.
The trigger detection for hand-in SHOULD be conservative to avoid
handover oscillation.
7.4. Subsequent Handovers
In GSM network, subsequent handovers use different set of messages
and different set of message flows. However, the messages between
the DMH and the MP-CSCF are identical to the initial hand-in or hand-
out. Since this document focuses on the interface between the DMH
and the SIP-based MP-CSCF, subsequent handovers are not described
here in details. Readers shall follow the descriptions early in this
section for subsequent handovers.
7.4.1. Subsequent Hand-out
A subsequent hand-out refers to a hand-out which happens after a
previous hand-in for the same call. The dual mode handset (DMH)
SHALL follow the descriptions in Section 6 for subsequent hand-outs.
An Expires January 29, 2007 [Page 48]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Note, the parameters, such as GAN pseudo cell-id received during
hand-in attach SHALL be used for the subsequent hand-out.
7.4.2. Subsequent Hand-in
A subsequent hand-in is a hand-back to the previous MP-CSCF who has
handed out the same call. A subsequent hand-in to a different MP-
CSCF is not considered as a subsequent hand-in. (Note a hand-in
attach might end up attaching to a different MP-CSCF, although it is
not recommended.). The dual mode handset (DMH) SHALL follow the
descriptions in Section 7 for subsequent hand-outs. Note, the
parameters, such as GAN pseudo cell-id, BSIC, BCCH-FREQ received
during the new hand-in attach SHALL be used for the subsequent
hand-in.
An Expires January 29, 2007 [Page 49]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
8. Session Handover Protocol (SHP)
This document suggests the use of a residual protocol of SIP to pass
extra parameters to facilitate voice session handovers between GSM
and VoIP networks. The residual protocol described in this section
facilitates voice session handover between VoIP and 3GPP circuit
switched network. Therefore, the protocol described in this section
is called 3GPP Session Handover Protocol (3GPP-SHP).
SHP messages are attached to SIP messages as MIME bodies. This
section describes the carrier SIP messages and the residual SHP
messages, and specifies the contents and format of the SHP protocol.
8.1. Carrier SIP and Attached SHP Messages
Indicating alternative handset radio capabilities:
DMH MP-CSCF
| Carrier Message: SIP REGISTER |
|--------------------------------------------->|
| Body Message: SHP REGISTER-REQUEST |
| |
| Carrier Message: SIP 200 OK |
|<---------------------------------------------|
| Body Message: SHP REGISTER-ACCEPT |
| |
Body message contains cellular classmark information elements.
Cellular Crypto Preparedness for Hand-out:
DMH MP-CSCF
| Carrier Message: SIP INVITE / 1XX / 2XX |
|--------------------------------------------->|
| Body Message: SHP CIPHER-COMMAND |
| |
| Carrier Message: SIP 2XX / ACK |
|<---------------------------------------------|
| Body Message: SHP CIPHER-COMPLETE |
| |
Body message exchange generates cellular crypto key.
An Expires January 29, 2007 [Page 50]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Hand-out Exchange:
DMH MP-CSCF
| Carrier Message: SIP INFO |
|--------------------------------------------->|
| Body Message: SHP HANDOUT-REQUEST |
| |
| Carrier Message: SIP REFER |
|<---------------------------------------------|
| Body Message: SHP HANDOUT-COMMAND |
| |
Body messages contain alternative cell info.
Hand-in Excahnge:
DMH MP-CSCF
| Carrier Message: SIP REFER |
|--------------------------------------------->|
| |
| |
| Carrier Message: SIP INVITE |
|<---------------------------------------------|
| |
| |
No body messages needed.
8.1.1. Indication of 3GPP-SHP Support
The handset and the network SIP proxy SHALL indicate to each other of
its support of 3GPP-SHP by using the Accept header in REGISTER,
INVITE and other SIP messages.
Accept: application/3GPP-SHP
The handset or network proxy SHOULD NOT attach a SHP body unless it
has received an indication that the other side supports SHP.
For example, the handset indicates its support of 3GPP-SHP by
including it in the Accept header of REGISTER. The MP-CSCF includes
its support in 407 response. Then both entities are informed of each
other's support of 3GPP-SHP. Then, SHP bodies may be attached to
subsequent REGISTER and 200 OK messages.
An Expires January 29, 2007 [Page 51]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
8.1.2. SHP Attachment Encoding
The SHP MIME attachment encoding SHALL support binary and base64.
Note base64 will increase the body length by 25% due to 3 to 4
encoding.
8.2. SHP Syntax and Functional Descriptions
8.2.1. SHP Message Format
All SHP messages MUST include a 4-byte message header and certain
mandatory and optional information elements (IEs). IEs are formatted
as (Type, Length, Value) tuples. The SHP messages MUST be
transmitted in network byte order.
SHP Message Header Definition:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |Prot | Skip | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
| Information Elements |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: the length of the message
Protocol: protocol discriminator, MUST be set to 0010B for SHP
Skip: skip indicator, MUST be set to 0000B
Msg Type: the message type
Each information element in an SHP message is a tuple of (Type,
Length, Value). The length may be zero, where the IE is only two-
byte long.
An Expires January 29, 2007 [Page 52]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
SHP Information Element Format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IEI | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| .... |
| optional, variable length data |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IEI: information element identifier
Protocol: length of data field, starting from next octet
8.2.2. SHP Message Types
SHP Message Type Values:
+---------------------+-----------------------------------------+
| Message name |value | Comments |
+---------------------+-----------------------------------------+
| REGISTER REQUEST | 16 | Same as UMA REGISTER REQUEST |
| REGISTER ACCEPT | 17 | Same as UMA REGISTER ACCEPT |
| CIPHER SDP COMMAND | 32 | Same as UMA CIPHER-MODE-COMMAND |
| CIPHER SDP COMPLETE | 33 | Same as UMA CIPHER-MODE-COMPLETE |
| HANDOUT REQUEST | 83 | Similar to UMA HANDOVER-REQUIRED |
| HANDOUT COMMAND | 84 | Similar to UMA HANDOVER-COMMAND |
+---------------------------------------------------------------+
8.2.3. SHP Message Descriptions
8.2.3.1. SHP REGISTER REQUEST
During the service-attach process, a SHP REGISTER-REQUEST message
body is attached to the SIP REGISTER request. The DMH MAY expect a
SHP REGISTER-ACCEPT message body from the MP-CSCF in 200 OK.
SHP REGISTER REQUEST
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 28 | MS Classmark 2 | Mandatory | TLV | 5 |
| 56 | MS Classmark 3 | Conditional | TLV | 3-14 |
| 1 | Mobile Identity (IMSI) | Conditional | TLV | 10~11 |
+---------------------------------------------------------------+
MS Classmark 3 is included when the value of MS classmark2 indicates
An Expires January 29, 2007 [Page 53]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
that it is required. The Mobile Identity SHALL be included to
present the IMSI when IMSI is not used as SIP credential.
8.2.3.2. SHP REGISTER ACCEPT
SHP REGISTER ACCEPT
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 13 | GAN Cell Description | Optional | TLV | 5 |
+---------------------------------------------------------------+
The SHP REGISTER ACCEPT message body is optional in the 200 OK
message from the MP-CSCF to DMH. It is processed when it is
attached. A 200 OK message indicates a successful service-attach.
The GAN Cell Description IE contains information of the assigned GAN
cell. When provided, it overrides the same information that is
already provided in the P-Access-Network-Info header.
The "GAN Cell Description" IE contains parameters of the assigned GAN
cell, i.e.
BSIC (base station id code) = NCC (network colour code) | BCC
(base station colour code)
BCCH ARFCN (absolute radio frequency channel)
The handset must provide the following default values, is such
information is not provided in the 200 OK message, as follows:
NCC=000B (3-bit binary zero)
BCC=000B (3-bit binary zero)
ARFCN=0000000000B (10-bit binary zero)
The above information has no significance for the operation of the
GAN cell. However, it is used by the DMH when reporting the GAN cell
signal strength to the cellular network, and the cellular network use
these codes to ensure compatibility for handover. Before every fresh
service-attach, the DMH shall use the default values. If this IE is
included during a successful service-attach response, the DMH must
set the colour codes accordingly, and keep those values until the
session is terminated or a new IE is received during a new service-
attach.
An Expires January 29, 2007 [Page 54]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
8.2.3.3. SHP CIPHER COMMAND
The SHP CIPHER COMMAND/COMPLETE exchange is attached to SIP messages
during call setup time to prepare the crypto keys for potential hand-
out to cellular network. This ensures that the DMH and the BSC to
have an agreed crypto key for encryption after handover.
SHP CIPHER COMMAND
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 30 | CIPHER MODE SETTING | Mandatory | TLV | 3 |
+---------------------------------------------------------------+
| 45 | CIPHER RESPONSE | Mandatory | TLV | 3 |
+---------------------------------------------------------------+
| 46 | RAND (Random Number) | Mandatory | TLV | 18 |
+---------------------------------------------------------------+
8.2.3.4. SHP CIPHER COMPLETE
Once challenged by a SHP CIPHER COMMAND message, the DMH MUST return
a CIPHER COMPLETE and store the generated keys for use after hand-
out. Failure to respond with a CIPHER COMPLETE body will result in
"no encryption applied" after hand-out. The MP-CSCF MAY disallow
such hand-out due to security concerns.
SHP CIPHER COMPLETE
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 47 | Message Auth Code (MAC) | Mandatory | TLV | 14 |
+---------------------------------------------------------------+
| 1 | Mobile Identity (IMEI) | Conditional | TLV | 10~11 |
+---------------------------------------------------------------+
The mobile identity IE is included when it is requested in the CIPHER
COMMAND message.
8.2.3.5. SHP HAND-OUT REQUEST
This is handset's radio measurement report that is attached to a SIP-
INFO message, indicating a handout request. The "handling" field in
the MIME attachment header indicates the urgency of the request.
"handling=optional" means non-urgent request; "handling=required"
indicates urgent request.
An Expires January 29, 2007 [Page 55]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
SHP HANDOUT REQUEST
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 15 | Cell Identifier List | Mandatory | TLV | |
+---------------------------------------------------------------+
| 106 | GERAN Measurement Result | Mandatory | TLV | 10~11 |
+---------------------------------------------------------------+
| 107 | UTRAN Measurement Result | Mandatory | TLV | 10~11 |
+---------------------------------------------------------------+
The Measurement Result is a list if signal levels whose order MUST
follow the order of cells in the Cell Identifier List IE in the same
message.
8.2.3.6. SHP HAND-OUT COMMAND
The hand-out command is received in the SIP-REFER message.
SHP HANDOUT COMMAND
+---------------------------------------------------------------+
| IEI | Information Element Name | Presence |Format| Length |
+---------------------------------------------------------------+
| 32 | Handover From GAN Command| Mandatory | TLV | |
+---------------------------------------------------------------+
8.2.4. List of All Information Elements
SHP does not define new information elements. All information
elements used by SHP are defined by [UMA] and its associated 3GPP
specifications. This section provides a list of all IEs used by the
residual SHP protocol, and the source of their definitions.
An Expires January 29, 2007 [Page 56]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
List of All IEs used by 3GPP-SHP:
+-----------------------------------------------------------------+
| IEI | Information Element Name | Reference in [UMA] | Comments |
+-----------------------------------------------------------------+
| 1 | Mobile Equipment Id(IMEI)| Section 11.2.1 | |
| 13 | GAN Cell Description | Section 11.2.13 | |
| 15 | Cell Identifier List | Section 11.2.15 | |
| 28 | MS Classmark 2 | Section 11.2.28 | |
| 30 | CIPHER MODE SETTING | Section 11.2.30 | |
| 32 | Handover From GAN Command| Section 11.2.32 | |
| 45 | CIPHER RESPONSE | Section 11.2.45 | |
| 46 | RAND (Randome Number) | Section 11.2.46 | |
| 47 | Message Auth Code (MAC) | Section 11.2.47 | |
| 56 | MS Classmark 3 | Section 11.2.56 |----------|
| 106 | GERAN Measurement Result | Section 11.2.70 |Added in |
| 107 | UTRAN Measurement Result | Section 11.2.70 | ver 1.04 |
+-----------------------------------------------------------------+
An Expires January 29, 2007 [Page 57]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
9. Security Considerations
This document specifies the usage of the SIP protocol for converged
services across VoIP and cellular networks. It also specifies
additional message bodies and extends the usage of certain existing
messages and headers of the SIP protocol. These present certain
security requirements to the use of specifications presented in this
document.
Since IMSI and other network information are transmitted inside the
SIP messages, the operator may not wish these parameters to be seen
by unauthorized entities in the network. For this reason, SIP
messages between the DMH and the MP-CSCF SHALL use a secure transport
protocol, such as TLS or IPsec. Secure MINE may also satisfy this
requirement; however, the Authorization header must be inside the
encrypted SMINE body.
10. References
[3GPP.04.18]
3GPP, "Mobile radio interface layer 3 specification; Radio
Resource Control (RRC) protocol", 3GPP TS 04.18 8.27.0,
May 2006.
[3GPP.08.08]
3GPP, "Mobile-services Switching Centre - Base Station
system (MSC-BSS) Interface Layer 3 Specification", 3GPP
TS 08.08 3.10.1, January 1995.
[3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 3.14.0, January 2004.
[3GPP.25.331]
3GPP, "Radio Resource Control (RRC); Protocol
specification", 3GPP TS 25.331 3.21.0, December 2004.
[3GPP.48.008]
3GPP, "Mobile Switching Centre - Base Station system (MSC-
BSS) interface; Layer 3 specification", 3GPP TS 48.008
4.10.0, September 2003.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP
and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
An Expires January 29, 2007 [Page 58]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication
and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3455] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private
Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project
(3GPP)", RFC 3455, January 2003.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[UMA] UMA Participating Companies, "Unlicensed Mobile Access
(UMA) Protocols (Stage 3)", May 2005.
[yafan-fmc-arch]
An, Y., "The Architecture Framework For Fixed Mobile
Convergence Using SIP as Access Call Control",
draft-yafan-fmc-arch-01 (work in progress), July 2006.
[yafan-fmc-mcho]
An, Y., "Mobile Controlled Handover Across VoIP and
Cellular Domains Using SIP as Access Call Control",
draft-yafan-fmc-mcho-01 (work in progress), July 2006.
An Expires January 29, 2007 [Page 59]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Author's Address
Yafan An
Stoke, Inc.
5403 Betsy Ross Drive
Santa Clara, CA 95054
US
Email: yafan@stoke.com
URI: http://www.stoke.com/
An Expires January 29, 2007 [Page 60]
Internet-Draft SIP-based Mobile Assisted Handover July 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
An Expires January 29, 2007 [Page 61]
