You are on page 1of 5

Voice Call Continuity – A novel mobility scheme for voice on call control level

Ralf Keller, Marc Vorwerk, and Colin Barschel
Ericsson Research, Corporate Unit Ericsson GmbH, Eurolab Research and Development 52134 Herzogenrath, Germany e-mail address





Abstract— Voice Call Continuity (VCC) is a novel mobility scheme for voice communication on call control level. One main use case is to transfer a voice session between CS access and WLAN, however, the solution as currently discussed in standardization is not limited to WLAN, but is restricted to make-before-break type of operation for a domain transfer. This paper provides a description of the current capabilities and limitations of the VCC standards. A possible evolution of the VCC solution has been implemented in a prototype, which realized the transfer of a voice session and a video session in parallel between WLAN and WCDMA, whereby on WCDMA a CS bearer is used for the voice session and a PS bearer is used for the video session. (Abstract) Keywords- Circuit Switched, IMS, Telephony, Voice Call Continuity



A. VCC architecture The VCC architecture as depicted in Error! Reference source not found. includes a VCC user equipment (UE) which can be in contact with both CS and IMS domain and there especially a VCC application. The VCC application is comprised of a set of functional entities required for a VCC UE to establish voice calls and to switch the VCC UE’s Access Leg between CS domain and IMS while maintaining active session(s), namely: • • • • Domain Transfer Function (DTF) Domain Selection Function (DSF) CS Adaptation Function (CSAF) CAMEL Service Function (CSF)

I. INTRODUCTION Voice Call Continuity (VCC) is a novel mobility scheme for voice communication on call control level [4]. It is targeted for users having both a GSM/UMTS and an IMS subscription and allows to transfer1 a voice session (call) while switching access from CS to IP and vice versa with complete transparency and seamlessness from an end-user point of view, and ideally without noticeable voice disruption. VCC enables to transfer an ongoing voice call between GSM/UMTS CS (circuit-switched) access and other IP based access technologies like WLAN, and UMTS PS (packetswitched) access. Therefore the end-user device has to support besides CS access at least one IP access technology which supports IMS telephony calls. Note that for IMS telephony certain delay and bandwidth requirements have to be fulfilled. The solution needs to work regardless of the access on which the call was originated or terminated initially. The following aspects are relevant to the VCC: VCC architecture, domain transfer mode, trigger functions and service control, all of which will be addressed in the following sections.


IP PLMN/ Multimedia PSTN Networks




gsm SCF
Unspecified interface


FE-C Camel Svc App VCC Application

FE-D Domain Selection



FE-B CS Adaptation

FE-A Domain Transfer















Fig. 1: 3GPP VCC Reference Architecture
Within the scope of VCC, the terms “handoff”, “handover”, “domain transfer” and “call transfer” are used synonymously. However, the term “domain transfer” is preferred to differentiate from handover procedures at or close to radio-link level.

The DTF has the key role in the domain transfer procedure. Indeed it is the anchor point in any call subject to domain

1-4244-0063-5/06/$20.00 ©2006 IEEE

and Fig. For IMS origination calls. 5 is for a call that initiated in the IMS domain and is handed over to the CS domain. domain transfer is not supported for that call. The UE sends a setup request that is resolved in the VCC application. but has been not selected because of higher complexity.g. C. 2. which in turn is used to route the call to an MGCF (Mobile Gateway Control Function) in the home network. The CSAF acts as the VCC UE’s proxy into IMS for CS originated calls established using CS domain and CS legs established for domain transfer to CS. it is linked into the call chain at call initiation for any call that is subject to domain transfer. Another important function in the architecture is the DSF. The DTF inserts itself as an anchor. The calling party number and /or original calling number are included in the SIP INVITE if they are received from the PSTN call setup signaling. the CS leg of the call (step 1. As can be observed from the figures. because it is the only standardized option which works also in case of roaming subscribers in visited CS domains. Second. it identifies the VCC user in IMS for CS originations and CS legs established for domain transfer to CS. e. Standard call setup procedures as per [6] are followed to continue the call setup. B. TAS (user A) UE MSC MGCF/ MGW I-CSCF S-CSCF (PSI) S-CSCF (user A) “PSI” routing AS originating call normal call origination Fig. existing mobile origination procedures as described in [6] are used to establish a session. It is used to redirect CS calls to IMS and assists the CSAF in call data management.. The DSF is used to determine whether to send the call to WLAN. 3. Fig. then a terminating call should be delivered to IMS even if the user has preference for CS domain in case he is reachable in both domains. The CSF implements CAP (CAMEL Application Part). The necessary subscriber data such that originating calls from VCC users are routed from CS domain to IMS domain is provisioned in a standard HSS (Home Subscriber Server). 4). A voice call originated by a VCC subscriber in the CS domain may or may not be anchored in the IMS to facilitate domain transfer of the call to IMS – a subject to operator policies.g. Either the INVITE is directly routed to the VCC application or via the S-CSCF. The applications anchored via the remote leg are not impacted by this domain transfer. Originating filter criteria for the VCC user result in routing of the IMS originating sessions to the VCC application in the home IMS network. 5) is cleared. communication of original called and calling party numbers (see also the next section). the communication is switched over from the IMS leg to the CS leg during access leg update (step 2. If a call from a VCC subscriber is not anchored in the IMS. As such. Amongst other functions. In the following. the anchoring in IMS is described in more detail. For that purpose the DSF has to determine the IMS registration status and the CS registration status and to communicate with the DTF to retrieve the current domain used for VCC UE active calls. Domain transfer Modes There are basically two modes of operation for a domain transfer to be successfully completed: make-before-break (MBB) and break-before-make (BBM). The later is needed if a VCC user has an active call e. The I-CSCF routes the INVITE based on one of the following standard procedures “PSI based Application Server termination – direct” and “PSI based Application Server termination – indirect” specified in [6]. The architecture chosen for VCC in 3GPP is IMS centric [2]. or in case in which radio coverage is not overlapping. The VCC application may retrieve the original called party number and the calling party number from CSF. CAP is used by the MSC-S (Mobile Switching Center Server) to retrieve a routing number. more details are provided only for the CS origination. 2: CS Origination call chain . 4. e. when the VCC user is simultaneously registered in CS domain and IMS. calls need to be anchored in the DSF. CAP [5] is the recommended option. then the functionality is accessed through the IP multimedia Service Control (ISC).transfer. behaving thereby as a SIP User Agent (UA). The domain transfer procedure shown in Fig.g. Fig. For routing from CS domain to IMS. independently whether they originated in CS domain or in IMS domain..g. For the sake of brevity of this paper. and regardless if any domain transfer will actually take place during that call (this is sometimes referred to as static anchoring in IMS). Call Cases As above mentioned. e. If the VCC application is realized as part of an IMS application server. VCC Application CAP The CS origination call chain is depicted in Fig. hence it is natural that this functionality resides in the IMS domain. Fig. in IMS domain. where the DTF uses 3rd party call control to initiate a call to the remote party on behalf of the user. then BBM support is required. Finally the original IMS leg of the call (step 3. Fig. 3) is established in the transferring-in domain while the IMS leg (transferring-out domain) is still active. whenever it is required to perform an action. Its role is to decide on whether a terminating call to a subscriber is to be routed via the IMS or CS domain. The DTF uses then the original called number and the calling party number to setup the outgoing call to B party via the A party’s S-CSCF (serving CSCF). or to CS domain for termination. In case end-user devices can have only one radio active for communication at the same time (single-radio). MBB mode is required for scenarios in which end-user devices can have two radios active for communication at the same time (dual-radio) which implies also overlapping coverage. Note that the remote leg to B party is also updated in order to forward the U-Plane data to the transferring in domain. Note that a dynamic anchoring of calls has been discussed in standardization [1]. The MGCF initiates a SIP INVITE towards the I-CSCF (Interworking Call State Control Function) in the home IMS of the originating VCC user.

A protocol state is considered as being stable if the domain transfer can be completed without loosing the call. 6: Break-before-Make GMSC MSC UE Remote Leg And finally. This process can be controlled by policies. but especially for mid-call services this leads to the problem that the state of these mid-call services has to be transferred between CS and IMS domain. Note that only services which have correspondents in both CS and IMS domain can be handled during call transfer at all. the initial IMS leg of the call is broken once the terminal realizes that it is about to domain transfer to the CS domain. B. when the domain transfer procedure is completed. “please hold the line” (step 2). centralized service control after domain transfer in IMS. which includes the control of mid-call services. namely distributed service control in both CS and IMS domain. 2) Access Leg Update Access leg transferring out domain Fig. which require a complete service set independent of the underlying transmission technology. It is simply more convenient for the end-user to hear an announcement when the domain transfer procedure takes . the VCC application in the end-user device may start to perform the procedure associated with domain transfer. 5: Domain Transfer Call Chain IMSÆCS Step 3 As above-stated. One option is to have complete service sets in both CS and IMS domain.. the only triggers that are currently identified to initiate VCC are end-user device initiated. C(IMS): call parties I-CSCF S-CSCF (user B) MGCF/ MGW P-CSCF (user B) Fig.g. E. This basically implies that as soon as radio conditions and coverage for one access type starts to fade away or starts to appear. 3: Domain Transfer Call Chain IMSÆCS Step 1 TAS VCC Application 1 A WLAN A WLAN A 3 Access leg transferring in domain C A(CS). Otherwise there is a certainty that the call will be disconnected by the other call party because he is unaware that a domain transfer is taking place. But here simplicity has to be balanced with end-user expectations. Service Control Multiple options for service control. One of the biggest contributors to the total voice call interruption time is the time needed by the user terminal to switch from one radio access to another. depending on which domain is currently used for voice communication. mid-call services are supported in the CS domain. the DTF reconnects the terminating user back to the CS side of the call (step 3) and disconnects the announcement machine (step 4). CS B 2 DTF 4 Announc. the less interaction between CS domain and IMS domains are necessary the better. 6.TAS VCC Application 1) Access leg transferring in domain established I-CSCF S-CSCF (user B) MGCF/ MGW P-CSCF (user B) GMSC MSC UE longer than 1 to 3 seconds. D. implementing rules like “WLAN preferred when available” or “cellular preferred when available”. In the figure. etc. Mach. Note that the announcement device is included for end-user convenience. this option is referred to as AGCF (Access Gateway Control Function) centralized control. have been studied in 3GPP. The DTF connects the terminating user of the call to an announcement device for voice announcements like e. and permanent 2 service control in IMS. In the current 3GPP approach for VCC the user can receive services from the CS or the IMS domain. For example. 4: Domain Transfer Call Chain IMSÆCS Step 2 TAS VCC Application Access leg transferring in domain I-CSCF S-CSCF (user B) MGCF/ MGW P-CSCF (user B) GMSC MSC UE Remote Leg 3) Access leg transferring out domain released Fig. The domain transfer procedure for the BBM case is illustrated in Fig. CS B 4 DTF Remote Leg Access leg transferring out domain CS CCCF IMS IMS 3 IMS Fig. Trigger Functions From a standard point of view [2]. whereby in case of WLAN the detection of a degrading WLAN signals strength must be early enough to allow the MBB domain transfer mode to be in a stable state before WLAN coverage is actually lost. 2 In [1]. MBB mode requires dual radio terminals but also dual-radio coverage. B 1 2 Announc. Mach. while the domain transfer procedure is ongoing. Simplicity of the standard means also shorter time to market. or even manually by a “one-click”. For simplicity of the standard.

During the demonstration the mobile connection is used to carry a bidirectional video stream to demonstrate the additional IMS service video-telephony. called nr. the handling of all supplementary services in IMS (“centralization”) will be solved. which has not yet been studied and which can be deployed later. 8: Call flow sequence diagram CCCF VoIP/SIP/WLAN Dual mode terminal WCDMA/PSTN CN Incoming call CS or PS The CCCF can switch between terminations Fig. 7: CS . The first left part on the graph shows the traffic history of an ongoing PS call over IMS. 9: Data packet throughput before. In the setup. VCC prototype setup in the core network The VCC server prototype implementing the CCCF is placed inside the UMTS core network and is directly connected to the GMSC. VCC PROTOTYPICAL REALIZATION the VoIP and video traffic can be seen in sum as a continuous data flow. compared to the described features in the previous sections. both PS and CS termination are independent of each other as shown in Fig. a node was included implementing functionality similar to the DTF and which is called CCCF (Call Continuity Control Function 3 ) with additional IMS functionalities. 10 and Fig. Call 1 is setup CS to CS call is setup DMT picks preferred termination and answers For ex. The prototype CCCF switches between both terminations as if they were separate calls. The second vertical red line now demarks the switch back to WLAN. Thus any network connection can be switched between UMTS and WLAN without interruption. In an enhancement phase. 7. CCCF is a term which was used in 3GPP before DTF was introduced. measurements of the data packet throughput of the dual mode terminal and voice call interruption time have been performed. In addition to the two voice terminations and switching capability the terminal is connected to the operator network with an encrypted mobile virtual private network (VPN) similar to Mobile IP combined with a transport layer security (TLS)[7]. 8 and was part of the presentations and the tests that have been performed. The graphs in Fig. CS programmed logic in the terminal programmed logic in the CCCF DMT triggers call transfer Trigger CS to PS CCCF builds PS call in parallel while CS still active A VCC prototype has been built up and was demonstrated to the press in July 2005 [3]. the architecture blocks described in Fig.PS domain transfer In the setup. The necessary IMS functionalities for VoIP are built into the prototype. 7. 9 show the data-packet throughput of the dual mode terminal before. during and after the user-initiated domain transfer. a call is waiting or when having one call on hold (and another call in progress). Hereby Fig. Call flow direction PS termination CS termination DMT accepts PS call automatically Call 2 is setup “seamlessly” CS to PS call is setup CCCF connect PS termination with CN & drops CS Fig. 11 are simultaneously in use. Therefore the CCCF can manage circuit switched calls on the GMSC and VoIP calls over the IMS. Note that at the time of implementation. The implemented VCC function used the MBB scheme and provided a fully seamless domain transfer between WLAN and UMTS without voice interruption. III. The IP path used by the video stream is shown in Fig. Tablet PCs where used as dual mode terminals as no suitable terminal was available at this stage. The call flow sequence is shown in Fig. Indeed 3 Fig. A. Note that in this enhanced demonstration. During the demonstrations. Further it is proposed to not perform domain transfer when in 3-party call. managed by CCCF Dual Mode Terminal (DMT) CCCF connects both termination. Correspondent CCCF Node (CN) CCCF calls DMT on both CS and PS CN initiate call.when CS access is used and vice versa in IMS. 10 shows the IP traffic part and Fig. Now the voice is carried via the UMTS/CS radio bearer as a normal circuit switched call. the discussion in 3GPP was in a very early stage. Accordingly the video stream is transferred from the UMTS link to WLAN and the “additional” VoIP call traffic can be seen again in Fig. during and after domain transfer from PS/WLAN to CS/UMTS The first vertical red line demarks the first switch from WLAN/PS to UMTS/CS. . when PS access is used. Here the traffic flowing in the mobile VPN tunnel is transported by the WLAN link. 11 the voice path using either the WLAN link or UMTS/CS. 9 on the mobile VPN and WLAN interface. Consequently the traffic load generated by the VoIP data is dropped and only the video stream is carried by the UMTS PS data link what can also be seen on the VPN link.

3GPP TS 23.html [2] [3] [4] [5] [6] Fig.806. it has been motivated that besides the currently standardized MBB mode also a BBM mode for domain transfer is needed to cover call cases in which terminals can be active only on one radio at a time or in which overlapping coverage is not guaranteed. there are more studies needed before a complete solution is available which overcomes all addressed limitations. a WLAN access is preferred for telephony at home or in the office. We have described the current VCC architecture and have also shown details for call flows for originated calls and the principles of domain transfer. Upon receiving the transfer request the CCCF identifies the user call termination and places the correspondent party on a “temporary hold” mode to protect the termination against a call break but still let the voice pass through. Stage 2 (Release 7).0 Transport Layer Security (TLS) press release. 42. The dual mode terminal recognizes the CCCF number ID and accepts the call. However.0 3rd Generation Partnership Project. IP Multimedia Subsystem (IMS). "What Layer does Mobility belong?" IEEE Communication Magazine. Technical Specification Group Services and System Aspects. our real-life implementation has shown the technical possibility to support use cases in which multiple media are used at the same time and in which CS access has to be used because no suitable packet access is available. CONCLUSION AND OUTLOOK [7] VCC enables the MBB transfer of a voice session between CS access and WLAN. Meanwhile the CCCF initiates a new parallel call towards the terminal using the other free transport (either CS or IMS) and waits for the line acknowledgment. R. 2006. http://www. John Wiley & The successful new call setup triggers the final part of the transfer on the CCCF. This MBB scheme makes it possible to switch between IMS and CS without voice interruption.need to be addressed in future work. Voice Call Continuity between CS and IMS Study (Release 7).0 Ericsson and BB Mobile show IMS service handover between 3G and WLAN. Trigger and transfer procedure The trigger to start a call transfer is initiated by the user terminal and is implemented with a simple message sent to the CCCF over the IP path. Moreover. Version 0. 3rd Generation Partnership Project.5. while calls should not be dropped when leaving the building. 3GPP TR 23. Eddy.html. vol. 11: Voice path using either WLAN/PS or UMTS/CS B. which can now switch the old termination with the new one and removes the ”temporary hold” for the other call party. Stage 2 (Release 7). 10. Noldus. Ltd. but also other IP accesses are supported. Technical Specification Group Services and System Aspects. M. 26 July 2006 W. 155-159. In the same way the dual-mode terminal will hang up the old line.ietf. This functionality is useful in situations where e. Version 1. REFERENCES Fig. Technical Specification Group Services and System Aspects. GRPS and UMTS network. CAMEL: Intelligent networks for the GSM. 2004. Also the limitations with regard to supplementary services handling . Voice Call Continuity between CS and IMS. 3GPP TS 23. However.g. At this stage the call is still ongoing but the other call party (the called party in the test scenario) would not be dropped in case of a BBM scenario.206. pp. 10: IP traffic path with WLAN and UMTS [1] 3rd Generation Partnership Project.228 V7.2.