Chapter 27
Voice Call Continuity
This chapter is devoted to the Voice Call Continuity (VCC) feature in the IMS. VCC, which
is specified in 3GPP TS 23.206 [27] and 24.206 [26], allows smooth transitions of voice calls
executed over the IMS and Circuit-Switched (CS) calls and vice versa. The feature allows a
double IMS/CS terminal to initiate or receive a voice call in either the IMS or CS domain and
move it to the other domain during the duration of the call.
VCC considers voice calls exclusively. At the time of writing, 3GPP is standardizing an
enhanced version of VCC that includes other types of media streams different than audio.
This is known as the Multimedia Session Continuity (MMSC), which it is not considered in
this chapter.
VCC fills an important gap in the transition of CS to IMS. Consider a user that is accessing
the IMS over a narrow bandwidth packet data channel. For example, this narrow bandwidth
channel can be a regular GSM cellular access over GPRS. The GPRS connectivity is used for
signaling and, thus, for SIP signaling towards the IMS. Voice over IP (e.g., RTP packets) will
not have the appropriate quality of service, mostly due to the delays and lack of bandwidth.
However, CS connections are available, and working reasonably well. So, with the VCC
feature enabled, the user can establish audio communications that use a regular CS bearer.
The session is controlled with SIP in the IMS. Assume now that, at a later time, the user
initiates another packet data IP-CAN access with higher bandwidth, perhaps Wireless LAN,
or perhaps cellular High Speed Packet Access. He can then move the CS audio stream over
the packet data IP-CAN, and perhaps enrich the session with video or some other data stream.
The goal of VCC is thus: maintain existing audio calls at any cost when the user moves
between areas with different connectivity characteristics. This is achieved by handing the
audio stream from CS to IMS or vice versa. The feature can be implemented transparently
from the point of view of the user. However, the feature requires VCC-enabled dual-mode
IMS/CS terminals and network support.
Because of the interaction between IMS and CS networks, this chapter assumes that the
reader has basic knowledge of the GSM architecture and its evolution into 3G networks.
27.1 Overview of Voice Call Continuity
Figure 27.1 presents a high-level overview of the VCC architecture. The figure shows
two VCC-enabled dual-mode IMS/CS terminals. Both can have access to packet-switched
accesses, which leads to an IMS core network, and CS accesses, which leads to the CS core
´ıa- M ar t´ın
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
560
CHAPTER 27. VOICE CALL CONTINUITY
network. A PSTN gateway composed of an MGCF and MGW interfaces the IMS domain
with the CS domain. While Figure 27.1 shows two VCC-enabled terminals, the feature
applies to each terminal in an independent way, so each terminal can use either of the CS
or IMS domains in its own call leg without support from the remote terminal.
VCC is always implemented in the home network of the served user. VCC introduces the
notion of anchoring, which consist of splitting the call into two call legs, and introducing a
fixed point in the network where the two legs are anchored. This allows to hand one leg from
one domain to the other without creating interferences with the remaining leg.
Figure 27.1: Overview of the VCC architecture
Figure 27.2 shows a possible usage of a call established between two VCC-enabled
terminals. One terminal is using the IMS signaling and media to make the call; the other
is using the CS signaling and media. At any point in time, either of the two terminals can
transfer its own leg to the other domain without disrupting the communication.
Other more complex combinations are also possible. For example, a VCC-enabled
terminal can initiate IMS signaling to establish a call that uses CS media. Then, later, the
terminal can replace the CS audio stream with an RTP audio stream that uses the IMS.
VCC also introduces the notion of routing numbers, which are intermediate telephone
numbers that are used to route the call appropriately via the nodes that provide the
VCC function. The CS Domain Routing Number (CSRN) is a dynamic routing number
that provides routing from the IMS to the CS domain. The IP Multimedia Routing
Number (IMRN) is a routable number that points to the IMS from the CS point of view.
Effectively, the IMRN is a Tel URL that is considered as a Public Service Identity (PSI) in
the IMS.
VCC also introduces the notion of a VCC Domain Transfer Number (VDN), which is
an E.164 number that the terminal can used to request a domain transfer from IMS to the
CS domain. The VDN is not a number that resolves to any of the VCC nodes; it is merely
a regular E.164 number whose semantics is “activate a domain transfer”. There is also a
counterpart VCC Domain Transfer URI (VDI), which is a SIP URI that the UE can use to
perform a domain transfer from the CS domain to the IMS domain. Like the IMRN, the VDI
is also a PSI. The VDI has the semantics of “activate a domain transfer”. The VDI and VDN
are assumed to be pre-provisioned to the terminal.
27.2. VCC ARCHITECTURE
561
Figure 27.2: Example of signaling and media path with VCC-enabled terminals
27.2 VCC Architecture
The VCC feature introduces the concept of a VCC-enabled terminal, which is a terminal
that has access to traditional CS voice and IMS applications. The VCC-enabled terminal
implements domain selection policies for both originating calls and domain transfers. This
policy is used when selecting a domain for originating calls. On the terminating side, it
controls the user preferences for terminating calls. The VCC-enabled terminal stores the
VDN and VDI to be used for domain transfer execution. In addition, a VCC-enabled terminal
implements procedures for transferring a leg from circuit-switched to IMS or vice versa.
The VCC-enabled terminal is configured with an E.164 number, so that it is reachable
from the CS domain, as well as a TEL URL and a SIP URI to be reachable from the IMS
side. Thus, there is a correlation between these numbers in different domains.
VCC also introduces the concepts of the VCC application, which is a collection of
functional entities that provide all of the required functionality for selecting the domain (CS
or IMS) for terminating calls and to assist the VCC-enabled phone for transferring a leg from
one domain to the other. The VCC application also provides the anchoring point to enabling
transfer of domains during active calls.
Figure 27.3 shows the general architecture of the VCC application and the related
interfaces. The VCC application is composed of four main functions: the Domain Transfer
Function (DTF), the Domain Selection Function (DSF), the CS Adaptation Function (CSAF),
and the service for Customized Applications for Mobile network Enhanced Logic (CAMEL
service). The interfaces between these four functions are not standardized, so implementa-
tions either implement proprietary interfaces or combine several functions in the same node.
The Domain Transfer Function (DTF) is responsible for executing the transfer of an
access leg from the CS domain to the IMS domain or vice verse. From the point of view of
SIP and IMS, the DTF acts as an Application Server (AS) configured as a Back-to-Back User
Agent (B2BUA) operating as a third-party call controller. In addition, the DTF maintains
policies related to the transfer of domains. The DTF interfaces the S-CSCF via the ISC
interface, the I-CSCF via the Ma, and the HSS via the Sh interface.
The Domain Selection Function (DSF) is involved in terminating calls. The DSF selects
the domain over which the terminating leg of an incoming call will be delivered. To take this
562
CHAPTER 27. VOICE CALL CONTINUITY
Figure 27.3: VCC architecture
decision, the DSF considers operator policy and user preferences. However, it is also helped
by the user’s registration status in the IMS and CS domains, so, for example, if a user is not
registered to the IMS but it is to the CS domain, the call will be delivered over the CS domain.
The DSF interfaces the S-CSCF via the ISC interface and the HSS via the Sh interface.
The CS Adaptation Function (CSAF) is responsible for allocating and de-allocating the
IMRN for CS originated calls. The CSAF communicates call related data from CS to IMS
(such as called an calling party numbers). The CSAF acts as a SIP proxy for CS originated
calls and CS legs established for domain transfer to CS. The CSAF acts as a SIP User Agent
towards the IMS. The CSAF interfaces the S-CSCF via the ISC interface and the I-CSCF via
the Ma interface.
CAMEL is a set of mobile networks standards for providing services in CS networks.
CAMEL is based on the Intelligent Networks (IN) standards. One of the nodes of the CAMEL
architecture is the gsmSCF, which is able to monitor the status of a call and provide certain
services. Well, in VCC, the CAMEL service function provides an alternative for routing calls
using CAMEL services. The functions of the CAMEL service overlap those of the CSAF,
and include allocating IMRN for routing CS calls to IMS, communicating call related data
from CS to IMS (such as called an calling party numbers). However, it also provides unique
functions, such as enforcing the CS redirection policy. The CAMEL service interfaces the
CAMEL gsmSCF via an unspecified interface. This mostly indicates that the CAMEL service
is essentially an extension to the existing gsmSCF.
27.3. REGISTRATION
563
In addition to the interfaces between the individual functions of the VCC application, a
VCC-enabled terminal implements the V3 interface towards the VCC application (or any of
the individual functions). The V3 interface is used for configuration settings and uses XCAP.
We described XCAP in Chapter 17.
Other relevant nodes for the VCC service include a standard PSTN/CS gateway, further
composed of an MGCF and MGW. In addition, a visited MSC has also a role when the access
leg traverses the circuit-switched domain. In the IMS domain, a P-CSCF is also involved
when the access leg uses the IMS.
27.3 Registration
There are no requirements for the VCC terminal with respect registrations. The IMS side
of a VCC-enabled terminal registers to the IMS as per regular procedures (see Section 5.5).
In addition, the CS side of the VCC-enabled terminal performs the regular attachment to the
network.
The VCC application needs to become aware of the IMS registration of the VCC-enabled
terminal. This is done by configuring an initial Filter Criterion that triggers a third-party
registration towards the VCC application when the S-CSCF receives a regular REGISTER
request from the VCC enabled terminal. In addition, the VCC application can subscribe to
the reg event package at the S-CSCF, which keeps the VCC application informed whenever
the VCC-enabled terminal re-registers or deregisters (see Section 5.6 for a description of the
reg event state package). An alternative to notifications of the reg event package is to use
the Sh interface to subscribe to the user’s registration state at the HSS.
27.4 Call Origination and Anchoring
Prior to executing a domain transfer of an ongoing voice call, the call must have been setup
(either in the IMS or the CS domain), and it has to be anchored, so that it can be transferred
to the other domain at a later stage. This section presents call flows for the originating side
indicating the involved entities in the call anchoring and revealing the details of it. The flows
only show the relevant nodes involved in the call anchoring for the originating VCC-enabled
terminal, so, for example, the originating P-CSCF is never shown, neither are any of the
terminating nodes.
27.4.1 IMS Originated Call Leg
Figure 27.4 shows the call flow of an IMS originated call anchored in the network for enabling
a potential domain transfer at a later stage. When the user initiates the call, the VCC-
enabled terminal performs a domain selection that takes into consideration the access network
availability and user preferences. In this example, the result of the domain selection leads to
setting up the call via the IMS domain. Therefore, the VCC-enabled terminal sends a regular
INVITE request (1) that traverses the P-CSCF (not shown in the figure) and other IMS nodes
until it eventually reaches the S-CSCF allocated to the user in the originating home network.
This S-CSCF evaluates the initial filter criteria and as a result of that evaluation, it forwards
the INVITE request (3) to the DTF, as per regular procedures over the ISC interface. Of
importance, the S-CSCF adds a Route header field whose value is a URI that resolves to the
same S-CSCF and contains (e.g., in the user part of the URI) a unique identifier of the dialog.