Internet DRAFT - draft-yafan-fmc-arch
draft-yafan-fmc-arch
FMC Y. An
Internet-Draft Stoke, Inc.
Expires: January 29, 2007 July 28, 2006
An Architecture Framework For Fixed Mobile Convergence Using SIP as
Access Call Control Protocol
draft-yafan-fmc-arch-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 an architecture framework for achieving
converged mobile services across alternative radio access networks
(GAN, or Generic Access Network), such as WLAN, WiMax, and the
cellular network, while utilizing SIP for media session control
between the dual mode handset (DMH) and a network SIP proxy. The key
benefits of this architecture include (1) fast and flexible service
deployment in the IP domain, and (2) allow seamless voice call
continuity services across IP and circuit-switched cellular domains.
An Expires January 29, 2007 [Page 1]
Internet-Draft SIP-based FMC Architecture July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Objectives . . . . . . . . . . . . . . . . . . 4
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Cellular Homed Deployment . . . . . . . . . . . . . . . . 7
3.1.1. Mobility Proxy (MP-CSCF) . . . . . . . . . . . . . . . 7
3.1.2. Dual Mode Handset . . . . . . . . . . . . . . . . . . 8
3.1.3. Media Gateways and Media Gateway Controllers . . . . . 9
3.1.4. Home Location Registrar . . . . . . . . . . . . . . . 9
3.1.5. Mobile Switching Center (MSC/VLR) . . . . . . . . . . 9
3.1.6. Short Message Service Center . . . . . . . . . . . . . 9
3.1.7. Supplementary Services Support . . . . . . . . . . . . 9
3.2. Soft Switch Homed Deployment . . . . . . . . . . . . . . . 10
3.2.1. Soft Switch (S-CSCF) . . . . . . . . . . . . . . . . . 11
3.2.2. HLR . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Supplementary Services Support . . . . . . . . . . . . 11
4. Basic Feature Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Registration and Nomadic Mobility . . . . . . . . . . . . 12
4.1.1. Global versus Local Registration . . . . . . . . . . . 12
4.1.2. Nomadic versus Local Mobility . . . . . . . . . . . . 13
4.1.3. Registration Message Flow in Cellular-homed
Scenario . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Registration Message Flow in Soft Switch-homed
Scenario . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.5. Dual Registration and Domain Selection . . . . . . . . 17
4.2. Roving Across Domains . . . . . . . . . . . . . . . . . . 18
4.2.1. Rove-out Trigger Detection . . . . . . . . . . . . . . 18
4.2.2. Rove-out Message Flow . . . . . . . . . . . . . . . . 18
4.2.3. Rove-in Trigger Detection . . . . . . . . . . . . . . 19
4.2.4. Rove-in Message Flow . . . . . . . . . . . . . . . . . 19
4.3. Single Number Reach-ability . . . . . . . . . . . . . . . 19
4.3.1. Call Termination in VoIP Domain . . . . . . . . . . . 20
4.3.2. Call Termination in Cellular Domain . . . . . . . . . 21
5. Session Mobility and Session Anchoring . . . . . . . . . . . . 23
5.1. Mobile Controlled Handovers . . . . . . . . . . . . . . . 23
5.2. Mobile Assisted and Network Controlled Handovers . . . . . 23
5.3. Session Anchor . . . . . . . . . . . . . . . . . . . . . . 24
5.3.1. Natural Anchoring . . . . . . . . . . . . . . . . . . 24
5.3.2. Anchor Migration . . . . . . . . . . . . . . . . . . . 25
5.3.3. Forced Anchor Selection . . . . . . . . . . . . . . . 25
6. Use of SIP Headers for Converged Services . . . . . . . . . . 27
6.1. Time Zone Indication . . . . . . . . . . . . . . . . . . . 27
6.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
An Expires January 29, 2007 [Page 2]
Internet-Draft SIP-based FMC Architecture July 2006
1. Introduction
There has been increasingly more and more dual mode handsets (DMH)
coming to the market recently. These DMH have both cellular baseband
and radio and WLAN baseband and radio. Voice over IP (VoIP) services
has started to utilize these WLAN capabilities on the handsets.
Achieving converged mobiles services across VoIP and cellular is the
goal of fixed mobile convergence (FMC). The objective of this
document is to outline a generic framework to so that specific
protocols, methods and algorithms can be specified without repeating
the generic framework. The cellular network considered is the 3GPP
GSM circuit switched network, although such framework may be adapted
to support other cellular networks.
There has been other frameworks defined or being defined, such as the
Unlicensed Mobile Access (UMA) technology which is standardized in
[3GPP.43.318], and the Voice Call Continuity (VCC) approach currently
being standardized in [3GPP.23.206]. UMA dost not use SIP as access
call control in GAN domain. VCC uses SIP as call control protocol in
GAN in an Internet Multimedia Sub-system (IMS) centric fashion.
The framework described in this document is more generic than UMA or
VCC. The framework is defined for the purposes of defining the SIP-
based protocol interface between the dual mode handset (DMH) and the
network SIP proxy to achieve seamless services across VoIP and
circuit-switched cellular domains. This framework does not define
individual product nor does it suggest functional groupings of
network elements.
This architecture framework is intended to be compatible with the
Internet Multimedia Sub-System (IMS) architecture, but the focus of
this framework is to address incremental requirements in the current
VoIP and cellular infrastructure to achieve converged services in the
near term.
These incremental requirements are represented as incremental
capabilities in the SIP interface between the DMH and the SIP proxy,
and extra CSI inter-working capabilities on the network SIP proxy (or
a separate entity in the network). This document only focuses on the
SIP interface between the DMH and the SIP proxy.
In order to put the focus only on the SIP interface between the DMH
and the SIP proxy, this framework is described with only existing
cellular and VoIP infrastructure elements to achieve converged
services.
An Expires January 29, 2007 [Page 3]
Internet-Draft SIP-based FMC Architecture July 2006
2. Terminology and Objectives
The target capability set of this framework includes the following:
1. Rove-in: a DMH in an idle state to leave the cellular network and
register with the GAN network
2. Rove-out: a DMH in an idle state to leave the GAN network and
attaches to the cellular network
3. Single number reach-ability across GAN and cellular networks
4. Hand-in: a DMH in an active call in the cellular network to carry
over the call into a GAN network
5. Hand-out: a DMH in an active call in the GAN network to carry
over the call into a GAN network
The first 3 items above are also referred to as the "basic feature
set". The basic feature set is achieved with only the requirements
described in this document. The last 2 items above referred to as
the "extended feature set". The extended feature set can be achieved
with the method described in [yafan-fmc-mancho], or the method
described in Section 5.1, or other methods.
The following introduces additional terminologies used in this
document:
Back-To-Back (B2B) Proxy: A logical entity that maintains state
information for the entire duration of a SIP dialog, and is in the
signaling path of all messages of a subscriber's transactions, see
[RFC3261].
Soft Switch Homed Subscriber : Refers to a subscriber whose home
network is a SIP-enabled soft switching network. The public
identities of a soft switched homed subscriber are routed to a
soft switch in the home network. Its private identities (such as
IMSI) is provisioned on a cellular HLR.
Cellular Homed Subscriber : Refers to a subscriber whose home network
is a cellular network. The public identity of a cellular homed
subscriber is routed to a mobile switching centre (MSC, or GMSC)
in the cellular network. Its private identity is provisioned on a
cellular HLR.
An Expires January 29, 2007 [Page 4]
Internet-Draft SIP-based FMC Architecture July 2006
Home Network : Refers to the home network where a subscriber is
provisioned. Typically, an inter-network call termination request
is routed to the home network for routing decisions.
Visited Network : Refers to a network where a subscriber is not
provisioned, but a user is gaining access according to a roaming
agreement. Typically, an inter-network call termination request
is routed to the home network for routing decisions.
GAN-Attach : Refers to the procedure where a handset achieving access
to a GAN radio network.
Service Attach : Refers to a procedure where a handset's SIP user
agent registers with the VoIP network to receives FMC services.
Hand-in Attach : Refers to a procedure where a handset's SIP user
agent establishes a local relationship with a SIP proxy to receive
hand-in of active sessions.
An Expires January 29, 2007 [Page 5]
Internet-Draft SIP-based FMC Architecture July 2006
3. System Overview
The framework described in this document supports two deployment
options:
Cellular-homed deployment: In this deployment model, new dual-mode
handset users are provisioned on an existing cellular network,
which include at least two parts:
The dual-mode handset's SIM card (or IMSI) is provisioned on
the cellular network's HLR; and
The dual-mode handset's MSISDN number is a routable number, and
the MSISDN number is routed to a Gateway MSC (GMSC) in the
cellular network for call termination. This implies that
supplementary services, such as voicemail, call forwarding
services, etc. for the dual-mode handset subscribers are
provided by the cellular network.
Soft switch-homed : In this deployment model, the carrier is assumed
to have a class-5 soft switch (CSCF, or S-CSCF), and the dual-mode
handset users are provisioned in the VoIP infrastructure as
follows:
The dual-mode handset's SIM card (or IMSI) is provisioned on a
cellular network's HLR belonging to the VoIP infrastructure,
and is accessible by the cellular networks for roaming
purposes; and
The dual-mode handset's MSISDN number is a routable number, and
the MSISDN number is routed to the soft switch for call
termination. This implies that supplementary services, such as
voicemail, call forwarding services, etc. for the dual-mode
handset subscribers are provided by the VoIP infrastructure.
Cellular-homed deployment allows the carrier to start offering FMC
services with minimal and less-sophisticated VoIP service
infrastructure.
Soft switch-homed deployment allows the carrier to start offering FMC
services by leveraging existing VoIP service infrastructure.
An Expires January 29, 2007 [Page 6]
Internet-Draft SIP-based FMC Architecture July 2006
3.1. Cellular Homed Deployment
Cellular-Homed System Architecture
C / D +--------+
+-------------------| HLR |
| +--------+
|
| E +--------+
+-------------------| SMSC |
| +--------+
+---------------------------+ |
| Mobility Proxy +-----+ | | +---------+
| | CSI | |---+ | MSC / |
| +-----------+___+-----+ | +------+ +------| VLR |
| | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+
| +-----------+ +-----+ |------+------+--+ /PRI |
+---------------------------+ | MG | +---------+
| +------+ | BSC/BTS |
| SIP +---------+
| |
+-------+ |
| DMH |-------------------------------------------
+-------+
This diagram does not suggest the grouping of functions into physical
entities.
3.1.1. Mobility Proxy (MP-CSCF)
The Mobility Proxy, or Mobility Proxy CSCF (MP-CSCF), is a key
element to facilitate converged services across WLAN and cellular
networks. From the pespective of the IP network, the MP-CSCF serves
as Breakout Gateway Control Function (BGCF) plus voice session
continuity support. For the purpose of this document, the term MP-
CSCF is used, and it includes three functional elements:
o The back-to-back SIP user agent allows a DMH SIP UA to register,
originate and terminate calls, send and receive instant messages,
using the SIP protocol. It is a B2B UA in order to perform call
bridging in the cases of handing over call-legs between WLAN and
cellular domains, in a manner similar to third party call control
(3PCC).
o The Circuit Switched Interworking (CSI) function allows the MP-
CSCF to initiates handover call-leg setup to the cellular domain.
For the basic feature set, the CSI uses the MAP C and D interface
with the HLR. In the method of [yafan-fmc-mancho], the MAP E
An Expires January 29, 2007 [Page 7]
Internet-Draft SIP-based FMC Architecture July 2006
interface is also used to facilitate bidirectional handover.
o The Packet Switched Interworking (PSI) function allows the MP-CSCF
to accept bridging request from the cellular network via the MGCF.
The PSI manages a set of mobile station roaming numbers (MSRN)
that are routable from the cellular network.
The Mobility Proxy (MP-CSCF), together with the MGCF/MG appears to
the cellular network as a peering MSC. It shall be provisioned with
at least one Location Area Code (LAC) and a cell-id.
The MP-CSCF MAY authenticate the DMH SIP UA using its cellular
credentials, such as using MD5-AKAv1 as per [RFC3310], or other
authentication mechanisms.
The MP-CSCF may also serve as a Gateway MSC (GMSC), in which case,
the network is configured to route the MSISDN of the DMH to this MP-
CSCF via MGCF.
3.1.2. Dual Mode Handset
A DMH SHALL support the appropriate attachment and security mechanism
in the GAN network. This aspect of the framework is not described in
this document. For security related discussions, please refer to
Section 7 of this document.
Prior to SIP registration to a MP-CSCF, the DMH SHOULD also perform a
provisioning and discovery procedures to obtain the addresses of the
local (home or visited) MP-CSCF and various other parameters. The
provisioning and discovery procedures are not discussed in this
document.
The DMH MUST also support the following capabilities:
Singular Registration -- Singular registration refers to the fact
that a DMH is actively logged on to only one network, i.e. either
cellular or the MP-CSCF. Although this framework does not exclude
the support of dual registration, i.e. a DMH is logged on to both
the IP-based MP-CSCF and the cellular network at the same time, it
is assumed in order to simplify the discussions.
Idle Scan -- While in cellular idle state, the handset must be able
to scan for WLAN wireless signal, at an interval that is defined
by the handset. While in GAN idle state, the handset must be able
to scan for cellular signal, at an interval that is defined by the
cellular standards.
An Expires January 29, 2007 [Page 8]
Internet-Draft SIP-based FMC Architecture July 2006
Monitor GAN -- While in an active cellular session, the handset must
be able to scan for GAN wireless signal, at an interval that is
defined by the handset.
Monitor Cellular -- While in an active GAN session, the handset must
be able to scan for cellular signal, at an interval that is
defined by the handset.
Transient Dual Transmission -- During an active handover, the handset
should be able to maintain both wireless and cellular sessions for
a short period, the due-radio period can be terminated once the
handover transaction is terminated.
3.1.3. Media Gateways and Media Gateway Controllers
MG and MGCF are the media and signaling conversion functions to
connect the IP packet switched network and the circuit switched
cellular network. It usually connects to the cellular network using
ISUP or PRI trunks; and connects to the IP packet network with SIP
and RTP.
These MGCF and MG do not need to be mobility-aware.
3.1.4. Home Location Registrar
The HLR in the cellular network is the subscriber database which
hosts the IMSI of the DMH. The MP-CSCF connects to the HLR using the
C/D interface.
In this framework, this HLR does not need extra features as compared
to a regular cellular HLR.
3.1.5. Mobile Switching Center (MSC/VLR)
For the basic feature set of this document, the MP-CSCF do not have
direct connections to the MSC/VLR.
3.1.6. Short Message Service Center
The MP-CSCF connects to the SMSC via the MAP E interface for SMS
interworking. The PSI/CSI performs conversion between SIP MESSAGE
requests to/from SMS.
3.1.7. Supplementary Services Support
It is expected that supplementary services of DMH would have similar
"look and feel" of the cellular network. The MP-CSCF, including the
CSI/PSI functions, is expected to be implemented according to
An Expires January 29, 2007 [Page 9]
Internet-Draft SIP-based FMC Architecture July 2006
cellular network's definition of supplementary features. As an
example, the MP-CSCF SHOULD implement call barring policy according
to policy data retrieved from the HLR, and to support CAMEL triggers
for compliance to supplementary services of the cellular network.
3.2. Soft Switch Homed Deployment
Soft Switch-Homed System Architecture
+---------------+ +-----------+
| Soft Switch |.......| HLR / HSS |
| (S-CSCF) | Cx +-----------+
+---------------+ C/D |
| | E +--------+
| SIP +-------------------| SMSC |
| | +--------+
+---------------------------+ |
| Mobility Proxy +-----+ | | +---------+
| | CSI | |---+ | MSC / |
| +-----------+___+-----+ | +------+ +------| VLR |
| | SIP B2BUA | | PSI | | SIP | MGCF | | ISUP +---------+
| +-----------+ +-----+ |------+------+--+ /PRI |
+---------------------------+ | MG | +---------+
| +------+ | BSC/BTS |
| SIP +---------+
| |
+-------+ |
| DMH |-------------------------------------------
+-------+
This diagram does not suggest the grouping of functions into physical
entities.
As can be seen, soft switch-homed deployment utilizes similar
entities and functions as compared to cellular-homed deployment, with
only the following differences:
o A Soft Switch (S-CSCF) to serve the needs of switching and
supplementary services in VoIP domain. There may be other
application servers (AS) or media servers, which are not shown for
simplicity.
o This HLR is associated with the VoIP network, or the cellular
network via a co-hosting agreement. This HLR does not require
extra features as compared to a cellular HLR.
An Expires January 29, 2007 [Page 10]
Internet-Draft SIP-based FMC Architecture July 2006
3.2.1. Soft Switch (S-CSCF)
In soft switch-homed deployment, supplementary services is expected
to have similar "look and feel" of the VoIP network. The MP-CSCF
serves as an outbound SIP proxy which is transparent to supplementary
services. Supplementary features are implemented by the Soft Switch
and the application servers (AS) in the VoIP network.
The MSISDN (or the DMH's telephony SIP URI or telephony URI) must be
provisioned on this soft switch.
The MP-CSCF (together with the S-CSCF) also serves as a Gateway MSC
for VoIP domain.
3.2.2. HLR
The HLR must be provisioned with the DMH's IMSI. As mentioned
earlier, this HLR does not require additional features as compared to
a normal cellular HLR. However, in the soft switch-homed deployment,
the HLR provisioning of IMSI must be coordinated with the
provisioning of MSISDN on the soft switch. Therefore, the HLR may be
owned or closely associated with the VoIP carrier.
As the network evolves to IMS, the Cx interface between the S-CSCF
and the HSS will ensure consistency of subscriber and service
profiles to be consistent across different domains.
3.2.3. Supplementary Services Support
It is expected that supplementary services of DMH would have similar
"look and feel" of the VoIP network. Supplementary features are
implemented by the Soft Switch and the application servers (AS) in
the VoIP network.
An Expires January 29, 2007 [Page 11]
Internet-Draft SIP-based FMC Architecture July 2006
4. Basic Feature Set
As already known, the cellular network and the VoIP networks define
different sets of terminologies and concepts. To facilitate the
understanding of the architecture framework presented in this
document, a few important concepts and terminologies are described in
order to fully understand the design of this framework.
4.1. Registration and Nomadic Mobility
In a VoIP network, nomadic mobility is supported via the SIP REGISTER
transaction. A SIP Registrar stores the contact information of the
SIP client after it registered with the Registrar. Due to the global
nature of IP-based SIP contact address, a SIP client has built-in
nomadic mobility capability. Such capability is exhibited in the
fact that the SIP server can deliver a terminating request to the SIP
client wherever it registers from.
In a cellular network, nomadic mobility is largely supported by the
Home Location Registrar (HLR). The HLR stores the location of the
handset when it performs a Location-Update request.
Recognizing the similarities of SIP-REGISTER and cellular Location-
Update, the SIP-REGISTER and Location-Update are both referred to as
the registration procedures to their perspective networks.
4.1.1. Global versus Local Registration
It is well-known that the cellular network HLR serves as the global
registrar of a handset, while a local MSC or Visiting Location
Registrar (VLR) serves as the local registrar of a handset. The
global registrar is consulted for call termination on a global scale,
while the MSC/VLR, which has temporary subscriber data, serves to
control micro bearer mobility for best mobility performance. This
hierarchical partition of responsibility has benefited the mobility
implementation well.
In VoIP or SIP, there is no explicit separation of global versus
local registration. However, a hierarchical registration is
naturally supported by SIP. For example, when a B2BUA or a stateful
proxy is traversed between a SIP client and SIP Registrar, the proxy
also stores temporary state data of the client. An access Session
Border Controller (SBC) is a good example of such scenario, in which
an SBC may acknowledge REGISTER on behalf of the global Registrar,
provided that the global registration has not timed out.
In this architecture framework, the MP-CSCF serves as a local
registrar (or VLR) for DMH. The MP-CSCF also manages handover call-
An Expires January 29, 2007 [Page 12]
Internet-Draft SIP-based FMC Architecture July 2006
legs in the most efficient manners locally (such as shortest bearer
detour). Therefore, this framework supports clear separation of
global versus local registration.
Further, local registration and global registration may be supported
by different protocols. For example, in cellular-homed deployment of
this framework, local registration is manifested by SIP-REGISTER to
the MP-CSCF, while MP-CSCF performs global registration via cellular
Location-Update to the HLR.
4.1.2. Nomadic versus Local Mobility
The separation of nomadic versus local mobility also simplifies the
impact of mobility on the implementation of supplementary services.
The basic feature set deals monadic mobility. Local mobility that
involves session anchoring and call-leg switching are described in
[yafan-fmc-mancho] and [yafan-fmc-mcho].
4.1.3. Registration Message Flow in Cellular-homed Scenario
In cellular-homed deployment, SIP-REGISTER is mapped to Location-
Update to the HLR. MD5-AKAv1 ([RFC3310] allows SIP authentication
based on SIM credentials.
An Expires January 29, 2007 [Page 13]
Internet-Draft SIP-based FMC Architecture July 2006
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.
MAP/D SEND-AUTHENTICATION-INFO exchange -- This exchange with the HLR
is to retrieve the authentication credentials for the handset.
Since multiple authentication vectors can be retrieved in a single
request, this exchanged is needed only when the MP-CSCF has
exhausted authentication vectors.
The MP-CSCF needs to know the IMSI of the DMH in order to retrieve
the authentication vector from the HLR. The DMH MUST use IMSI as
its username.
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, i.e. assuming nonce=''.
An Expires January 29, 2007 [Page 14]
Internet-Draft SIP-based FMC Architecture July 2006
407 -- The MP-CSCF forms a challenge based on the authentication
vectors obtained from the HLR, and sends a AKAv1-MD5 challenge to
the DMH.
SIP/2.0 407 Proxy Unauthorized
From:
To:
Contact:
Call-ID:
Authorization: Digest username="imsi@home1.net",
realm="home1.net",uri="sip:home1.net",
nonce="5bc80c48", algorithm=AKAv1-MD5
CSeq: 1 REGISTER
REGISTER with credentials -- This REGISTER contains 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 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 MS.
Errors occurred during MP-CSCF's location update procedure shall
be propagated to the MS:
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 that
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, e.g. timed out, the MP-CSCF returns "500
Internal Server Error" SIP message to the DMH.
The identity is composed compliant with the Network Access Identifier
(NAI) format specified in [RFC2486]. The format of NAI is
username@realm [3GPP.23.003]. The username in SIP authentication
SHALL also be composed according to the following format
1<IMSI>@imsi.mnc<MNCi>.mcc<MCC>.3gppnetwork.org or
1<IMSI>@myprovider.com
An Expires January 29, 2007 [Page 15]
Internet-Draft SIP-based FMC Architecture July 2006
For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),
the NAI then takes the form of
1234150999999999@uma.mnc015.mcc234.3gppnetwork.org or
1234150999999999@myprovider.com. The preceding "1" indicate IMSI is
used as identifier.
4.1.4. 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
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 |<----------------------------|
|<------------------------------| |
| | |
An Expires January 29, 2007 [Page 16]
Internet-Draft SIP-based FMC Architecture July 2006
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.
The AKAv1-MD5 mechanism is still preferred here, in which case the
MP-CSCF performs the authentication using SIM-based credentials.
A trust relation between the MP-CSCF and the S-CSCF SHALL be
established. Such trust relationship can be based on multiple
means, such as a IPsec or TLS security association, or a simple
site-wide username/password for all users.
MAP/D LOCATION-UPDATE exchange -- The Location-Update exchange is
performed only when the DMH is successfully authenticated. 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 exchange with the HLR is successful,
the MP-CSCF returns 200 OK to the MS.
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 that
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, e.g. timed out, the MP-CSCF returns "500
Internal Server Error" SIP message to the DMH.
4.1.5. Dual Registration and Domain Selection
Concurrent registration in both VoIP and cellular domains is not a
focus of this framework, although its support is not excluded. It is
envisioned that the HLR (or HSS) may be expanded so that it maintains
two location records: one for cellular location and one for VoIP
location. Then, a domain selection for terminating requests can also
An Expires January 29, 2007 [Page 17]
Internet-Draft SIP-based FMC Architecture July 2006
be supported on the HLR.
4.2. Roving Across Domains
The DMH will be able to rove in and out across cellular and VoIP
networks by treating the MP-CSCF as an MSC. In this document, i.e.
to support only the "basic feature set" described in this document,
roving has two parts (1) registration in the target domain, and (2)
stop refreshing registration in the source domain.
4.2.1. Rove-out Trigger Detection
Rove-out is a handset's operation to leave VoIP domain and to
register onto the cellular domain.
Similar to roaming in a cellular network, rove-out trigger detection
is a pure handset matter. The handset must periodically monitor the
cellular cell radio signals, and compare its quality to the current
GAN (e.g. IEEE 802.1a/b/g) radio signal, and initiates a rove-out
operation when it decides to log on to a target cellular network to
continue service. It is important to note that the rove-out
operation is strictly compliant to the cellular standards.
4.2.2. Rove-out Message Flow
Rove-Out Message Flow for Cellular-Homed DMH:
Visited Target Target
DMH MP-CSCF BSC HLR MSC/VLR
| BCCH: Signal==Good | | | |
|<------------------------------| | |
| RR: CHAN REQ/ASS | | | |
|<----------------------------->| | |
| MM: LOC UPDATE | | | MAP: LOC UPD |
|------------------------------>|------------------------------>|
| < Intermediate messages skipped > |
| MM: LOC UPD ACCEPT | | | |
|<--------------------------------------------------------------|
| SIP: de-REGISTER | | | |
|--------------------->| | | |
| SIP: 200 OK | | | |
|<---------------------| | | |
The above message flow intends to show the high-level exchanges only.
Various flavors of the message flows are described in [XX], [XX], and
[XX].
An Expires January 29, 2007 [Page 18]
Internet-Draft SIP-based FMC Architecture July 2006
Rove-Out Message Flow for Soft Switch-Homed DMH:
Visited Target Target
DMH MP-CSCF BSC HLR S-CSCF MSC/VLR
| BCCH: Signal==Good | | | | |
|<------------------------------| | | |
| RR: CHAN REQ/ASS | | | | |
|<----------------------------->| | | |
| MM: LOC UPDATE | | | MAP: LOC UPD |
|------------------------------>|------------------------------>|
| < Intermediate messages skipped > | |
| MM: LOC UPD ACCEPT | | | | |
|<--------------------------------------------------------------|
| SIP: de-REGISTER | | | | |
|--------------------->| | REGISTER (trust) | |
| SIP: 200 OK |---------------------------->| |
|<---------------------| | 200 OK | | |
| |<----------------------------| |
The above message flow intends to show the high-level exchanges only.
For soft switch-homed DMH, the MP-CSCF does not de-REGISTER from the
S-CSCF, but it instead registers with the S-CSCF via a pre-defined
trust relationship, such as a site-wide credential.
After rove-out, the MP-CSCF transitions into a Gateway MSC for the
DMH. The VoIP domain has the flexibility of designating one or
multiple MP-CSCF as GMSC depending on network configuration.
4.2.3. Rove-in Trigger Detection
Rove-in is handset's operation to leave cellular domain and register
onto the VoIP domain.
As in cellular roaming, rove-in trigger detection is a pure handset
matter. The handset must periodically monitor the GAN radio signals,
and compare its quality to the current cellular radio signal, and
initiates a rove-in operation when it decides to log on to a VoIP
network to continue service.
4.2.4. Rove-in Message Flow
Rove-in message flows are identical to SIP registration flows
described in Section 4.1.4 and Section 4.1.3.
4.3. Single Number Reach-ability
It is obvious that, with the support of MP-CSCF, especially the CSI/
An Expires January 29, 2007 [Page 19]
Internet-Draft SIP-based FMC Architecture July 2006
PSI functions of the MP-CSCF, a DMH is reachable with a single
telephone number (or URI) across VoIP and cellular domains.
4.3.1. Call Termination in VoIP Domain
There is slight difference for call termination between a cellular-
homed and soft switch-homed DMH.
When a DMH is homed in the cellular domain, a call termination
request is first routed to the Gateway MSC of the cellular network.
The GMSC is then queries the HLR for routing information. The HLR
returns the ISUP routing information of the MGCF/MG associated with
the MP-CSCF. The MGCF then routes the INVITE to the MP-CSCF for
termination. Recall that, in cellular homed deployment, the MP-CSCF
is the serving MSC and SHOULD possess logics for supplementary
services.
When a DMH is homed on a VoIP soft switch, a call termination request
is first routed to the soft switch. There are two scenarios:
SS-homed DMH registered in VoIP domain: This case is straight-
forward. The INVITE is forwarded to the DMH via the MP-CSCF.
SS-homed DMH roaming in cellular domain: When a DMH is not currently
registered in the VoIP domain, a designated MP-CSCF is designated
as the Gateway MSC on behalf of the DMH. Recall Section 4.2.2
that a MP-CSCF transitions into a GMSC for the DMH during rove-out
by maintaining a registration with the S-CSCF on behalf of the
DMH. The S-CSCF forwards the INVITE to the MP-CSCF who shall then
query the HLR to obtain a Mobile Station Roaming Number (MSRN),
and the termination request is sent to the cellular network for
termination. This scenario will be discussed in more details in
Section 4.3.2.
An Expires January 29, 2007 [Page 20]
Internet-Draft SIP-based FMC Architecture July 2006
Call Termination in VoIP Domain for SS-homed and Cellular-Homed DMH:
Cellular-homed DMH:
Visited
DMH MP-CSCF HLR MGCF/MGW GMSC
| | | MAP/C: SRI |<--
| | MAP/D: PRI |<----------------|IAM
| |<---------------------| | |
| | MAP/D: PRI (MSRN) | | |
| |--------------------->| C: SRI res |
| | |---------------->|
| SIP: INVITE | SIP: INVITE | | IAM |
|<--------------------|<----------------------------|<---------|
| | | | |
<... Intermediate messages skipped ...>
Soft Switch-homed DMH:
Visited Circuit
DMH MP-CSCF HLR S-CSCF Switch
| | | | |
| SIP: INVITE | SIP: INVITE | | IAM |
|<--------------------|<----------------------------|<---------|
<... Intermediate messages skipped ...>
The above message flow intends to show the high-level exchanges only.
4.3.2. Call Termination in Cellular Domain
There are slight difference when a DMH is homed in the cellular
domain or in the VoIP domain.
When a DMH is homed in the cellular domain, a call termination
request MAY be routed according to cellular network, unless its
routing is changed by using other means such as those described in
[3GPP.23.206].
When a DMH is homed on a VoIP soft switch, a call termination request
is first routed to the soft switch. There are two scenarios:
SS-homed DMH is registered in VoIP domain: This case is straight-
forward. The INVITE is forwarded to the DMH via the MP-CSCF.
SS-homed DMH roaming in cellular domain: When a DMH is not currently
registered in the VoIP domain, a designated MP-CSCF is designated
as the Gateway MSC on behalf of the DMH. Recall Section 4.2.2
that a MP-CSCF transitions into a GMSC for the DMH during rove-out
by maintaining a registration with the S-CSCF on behalf of the
DMH. The S-CSCF forwards the INVITE to the MP-CSCF who shall then
An Expires January 29, 2007 [Page 21]
Internet-Draft SIP-based FMC Architecture July 2006
query the HLR to obtain a Mobile Station Roaming Number (MSRN),
and the termination request is sent to the cellular network for
termination.
Call Termination in Cellular Doamin for SS-homed and Cellular-Homed
DMH:
Cellular-homed DMH in Cellular Domain:
Visited Visited
DMH BSC MSC/VLR HLR S-CSCF GMSC
| | | | | C: SRI |<--
| | | D: PRI |<----------------|IAM
| | |<---------------------| | |
| | | D: PRI (MSRN) | | |
| | |--------------------->| C: SRI (MSRN) |
| | | |---------------->|
| CC: SETUP | ISUP: IAM | | IAM |
|<--------|<----------|<---------------------------------------|
| | | | | |
<... Intermediate messages skipped ...>
Soft Switch-homed DMH Roaming in Cellular Domain:
Visited Gateway Visited Circuit
DMH BSC MP-CSCF MSC/VLR HLR S-CSCF Switch
| | | | | | |
| | | SIP: INVITE | | IAM |
| | |<----------------------------|<---------|
| | | MAP/C: SRI | | |
| | |--------------------->| | |
| | MAP/D: PRI | | |
| |<---------------------------------| | |
| | | MAP/D: PRI (MSRN) | |
| |--------------------------------->| |
| | | MAP/C: SRI(MSRN) | |
| | |<---------------------| MGCF/MG |
| | | SIP: INVITE(MSRN) | |
| | |---------------------------->| |
| | | | | | |
| CC: SETUP | | ISUP: IAM | |
|<--------------------------------|<----------------| |
| | | | | | |
<... Intermediate messages skipped ...>
The above message flow intends to show the high-level exchanges only.
An Expires January 29, 2007 [Page 22]
Internet-Draft SIP-based FMC Architecture July 2006
5. Session Mobility and Session Anchoring
Earlier in this document, a basic set of features enabled by this
architecture framework has been described. The basic feature can be
categorized by the term called Single Number Services.
The framework can enable a much larger set of features on top of the
basic set of features. The extended features are fully described in
[yafan-fmc-mancho] and [yafan-fmc-mcho].
One of the extended features is dynamic session handover across VoIP
and cellular domains. This feature is sometimes called voice call
continuity (VCC) service. This document describes certain concepts
and brief introduction of the extended features enabled by this
framework.
5.1. Mobile Controlled Handovers
Mobile controlled handover refers to a handover that is initiated and
executed by the handset based on handset's logic and decisions. In a
network where heterogeneous radio access networks are totally
independent, converged services are achieved by handset's capability
of utilizing multiple radio access technologies. The converged
network has no comparative intelligence of the radio access networks.
The handset is in the driver seat with respect to which network to
use and to switch services among different access networks.
The framework in this document naturally supports mobile controlled
handovers.
5.2. Mobile Assisted and Network Controlled Handovers
Mobile assisted, network controlled handover refers to a handover
that is initiated and executed by a network element based on
handset's report or network element's measurement of radio
characteristics and consult certain network policies. The handover
is assisted by the handset for completion. In a network where a
network element can obtain comparative intelligence about
heterogeneous radio access networks, converged services can be
achieved by the intelligent network element executing its logic to
complete a handover procedure.
Mobile assisted but network controlled handovers offer more
flexibility, controllability, and more predictable network behaviors.
It allows the network element a chance to manages faults during
handovers.
The framework in this document naturally supports mobile controlled
An Expires January 29, 2007 [Page 23]
Internet-Draft SIP-based FMC Architecture July 2006
handovers.
5.3. Session Anchor
To achieve session stream continuity, an anchor point is required.
This is true in all the mobile network designs. A degradation of
this model is that one or both endpoints act as the anchor, which is
the case where binding update is sent to the endpoint in Mobile IP.
Session anchoring at endpoint is not feasible in many networks.
When the endpoints of a session stream is not able to perform the
anchor function, an anchor point in the network is necessary. In the
framework of this document, the MP-CSCF is designed as a session
anchor point. Since the MP-CSCF can be deployed in a distributed and
geographically distributed fashion, this architecture allows network
designers to design the network to minimize handover control message
latency and to reduce bearer detour, to achieve desired handover
performances.
Handover is treated as a bearer path transfer procedure, and is
intended to be independent to supplementary services. This is in
contrast to certain alternative approaches where session anchor is
designed as a centralized server function, e.g. [3GPP.23.206]
Session anchoring is an important aspect of a design for session
continuity. When dealing with session continuity across VoIP and
cellular domains, there may be multiple choices for selecting an
anchor. Multiple anchoring options are introduced later in this
Section. A key objective of this framework is to any combination of
the anchoring choices, concurrently if so desired.
When a DMH is involved in a voice session, a single anchor is
selected. When a DMH is involved in an active multimedia session,
the framework in this document naturally allows each media stream to
select a different anchor and be handed over independently.
Based on the selected anchoring choice, handover mechanism is
selected accordingly. Mobile controlled handover is described in
Section 5.1. Mobile assisted and controlled handover is described in
Section 5.2.
5.3.1. Natural Anchoring
Natural anchoring refers to the utilization of the existing anchoring
mechanism for each media stream that is already established by the
original domain where the session stream is established. The CSI/PSI
functions are the facilitator for handing over the session stream
across domains.
An Expires January 29, 2007 [Page 24]
Internet-Draft SIP-based FMC Architecture July 2006
When a voice call is established in the cellular network, either
mobile originated or mobile terminated, the cellular MSC naturally
becomes the anchor of the voice stream. When a voice call is
established in the VoIP domain, the MP-CSCF becomes the anchor of the
voice stream.
Natural anchoring refers to the above scenario where converged
services do not require the altering of the natural anchors. Natural
anchoring and mobile assisted and controlled handover are described
in detail in [yafan-fmc-mancho].
5.3.2. Anchor Migration
Natural anchor selection, as described in Section 5.3.1 and in
[yafan-fmc-mancho] requires the MP-CSCF to implements mobility
interworking function utilizing the MAP E interface, which in turn
requires the VoIP domain to configure peering topologies such as the
neighbor cell list on both the MP-CSCF and the cellular MSC.
In order to alleviate the burden of configuring the peering topology,
the network may choose to use mobile-controlled handovers, as
described in Section 5.1 and [yafan-fmc-mcho]. However, with natural
anchoring in Section 5.3.1, only hand-out can be performed, while
hand-in cannot be always performed if the natural anchor is in the
cellular domain.
When the handover is between WLAN and cellular, hand-out is obviously
more critical than hand-in for the purpose of maintaining voice
services. Therefore, mobile-controlled handover is a valuable
option.
It should be noted that a side effect of mobile-controlled handover
is the shifting of the anchor point during handover, and anchoring
migration is not always bidirectional.
Mobile-controlled handover with anchor migration is described in
detail in [yafan-fmc-mcho].
5.3.3. Forced Anchor Selection
As described in Section 5.3.2, mobile-controlled hand-in cannot
always be performed when the natural anchor is in the cellular
domain. In order to alleviate this issue, the network may choose to
select an alternative anchor point for handover. To establish an
alternative anchor point in the VoIP domain, a call's signaling and
bearer path must be routed through a VoIP element. Such routing must
be done at the call establishment phase, not at the time of handover.
The MP-CSCF is also designed to be such an alternative anchor point.
An Expires January 29, 2007 [Page 25]
Internet-Draft SIP-based FMC Architecture July 2006
Obviously, calls originated or terminated to a DMH in the VoIP domain
is already routed through an MP-CSCF, so alternative anchoring does
not apply. However, it applies for mobile originated or terminated
calls in the cellular domain, where they may or may not be routed
through an MP-CSCF.
There are many ways that call routing in the cellular domain can be
altered to pass through an MP-CSCF. The following lists a few
possible methods:
Mobile-Terminated Call in Cellular Domain -- Since mobile-terminated
calls are first routed to a GMSC (cellular-homed DMH) or the Soft
Switch (soft switched-homed DMH), termination routing can be
controlled by the HLR or the Soft Switch to pass through a local
MP-CSCF. This is called "termination tandem".
hangText="Mobile-Originated Call in Cellular Domain --">Call
origination could be placed to designated destination number on
the MP-CSCF, which again originates the call on behalf of the DMH
to its original destination. This is called "origination tandem".
Static routing configured for DMH users based on its class of
service types.
Use of pre-defined tandem numbers for tandem routing.
Use Service Control Point (SCP) and CAMEL triggers to control
tandem routing.
USSD exchange to control tandem routing.
Not every method can be applied in every network or in every region
within a network without investing in legacy cellular networks.
Therefore, architecture SHOULD support multiple methods in a non-
exclusive fashion.
An alternative anchor point does not replace or remove the natural
anchor point, it is used only for session handover across VoIP and
cellular domains. Forced anchor selection is also described in
[yafan-fmc-mcho].
An Expires January 29, 2007 [Page 26]
Internet-Draft SIP-based FMC Architecture July 2006
6. Use of SIP Headers for Converged Services
In order to improve the quality of the converged services, certain
convention should be established. This section describes these
conventions.
6.1. Time Zone Indication
The Date header in SIP ([RFC3261]) indicates the time and time zone
of the user agent client or server. However, [RFC3261] restricts the
time zone to "GMT", and let the SIP client to find out its local time
zone. In cellular networks, the time and time zone is often passed
down by the network element to the handsets. This is useful for the
handset to be aware of the local time and time zone due to the mobile
nature of the service.
In this document, this Date header, when passed down from the MP-
CSCF, it indicates the time zone, date and time of the LAC area of
the local GAN cell.
In this specification, the time zone parameter SHALL expanded to be
compatible with [RFC0822] and [RFC1123], which includes the support
of numeric time zones. (
The local SIP proxy is therefore able to pass down the time and
timezone information of the approximate location to the handset. The
handset SHOULD display the time according to the timezone information
obtained from the network.
For example, -700 means Pacific Standard Time.
6.2. Operator Name
Due to the mobility nature of converged services, a handset may
sometimes use a visited MP-CSCF for services. The use of foreign MP-
CSCF is necessary when handover and roaming depends on an existing
peering relationship between the MP-CSCF and the local cellular
network.
The visited MP-CSCF is comparable with a P-CSCF in the Internet
Multimedia Sub-systems (IMS) terminologies. Utilizing foreign GAN
network MAY has cost impact, therefore it is beneficial to inform the
user about the identity of the local operator.
The Organization header of SIP SHOULD be used by the SIP proxy to
inform the handset of the identity of local network.
To allow the passing of the both the long and short names of the
An Expires January 29, 2007 [Page 27]
Internet-Draft SIP-based FMC Architecture July 2006
local MP-CSCF operator, the header is formatted as follows:
Organization: Operator-Long-Name (Short-Name)
The name outside of the bracket is the Long Name of the operator, the
name inside the bracket is the short form of the same operator. The
DMH SHOULD display the name to the user, similar to a cellular phone.
An Expires January 29, 2007 [Page 28]
Internet-Draft SIP-based FMC Architecture July 2006
7. Security Considerations
This document does not define a protocol, but still presents some
security requirements in the presented framework.
Since IMSI and other network information is transmitted inside SIP
messages, the operator may not wish them to be seen by unauthorized
entities in the network. For this reason, SIP messages between the
DMH and the MP-CSCF SHALL be transmitted over 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.
8. References
[3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 3.14.0, January 2004.
[3GPP.23.206]
3GPP, "Voice call continuity between Circuit Switched (CS)
and IP Multimedia Subsystem (IMS); Stage 2", 3GPP
TS 23.206 1.0.0, June 2006.
[3GPP.43.318]
3GPP, "Generic access to the A/Gb interface; Stage 2",
3GPP TS 43.318 6.7.0, July 2006.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
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.
[yafan-fmc-mancho]
An, Y., "Mobile Assisted Handover Across VoIP and Cellular
An Expires January 29, 2007 [Page 29]
Internet-Draft SIP-based FMC Architecture July 2006
Domains Using SIP as Access Call Control",
draft-yafan-fmc-mancho-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 30]
Internet-Draft SIP-based FMC Architecture 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 31]
Internet-Draft SIP-based FMC Architecture 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 32]
