Progress of Voice Call Continuity Service Standardization

As the development tendency for telecommunication networks, Fixed Mobile Convergence (FMC) can implement full-service and converged-service operation, so as to provide subscribers with rich and continuous service experience.

    FMC has several implementation solutions, including Unlicensed Mobile Access (UMA), Voice Call Continuity (VCC), and IP Multimedia Subsystem (IMS) solution for the entire network. The mobile-handover-focused UMA solution does not need to change the mobile core network, but uses the current mobile switches to process calls. The IMS-based VCC solution introduces the VCC application server into the IMS, and can provide cross-network operation support without modifying the mobile network. However, the IMS-based entire core network is regarded as the final solution to FMC[1-3].

    In the current mobile network, voice communication adopts the mode of  Circuit Switching (CS). The IMS-based VCC solution can realize FMC without changing the mobile network, and can support the transition and evolution from the circuit-switching mode to the IMS mode. Therefore, it wins wide attention from the industry.

    The VCC service has the following advantages:

    (1) Enhancing the indoor coverage of wireless services

    (2) Transferring some voice calls to the WLAN so as to relieve the burden for the mobile cellular network with insufficient wireless resources in WLAN-covered areas

    (3) Offering multiple service modes to meet subscribers’ demands and boost service income

    (4) Providing converged services

1 Progress of VCC Service Standardization
The 3GPP and 3GPP2 are making standards for VCC.

    The 3GPP SA2 (Architecture Working Group) initiated the study of VCC services. The VCC working group was established to research the scope of VCC, its general requirements, application scenario, architecture and supplementary service support, on the 44th conference of 3GPP SA2, held at the end of January 2005. According to the schedule, the VCC working group was supposed to complete Stage 2 and 3 in the first and third quarters of 2006, respectively. However, due to unexpected technical difficulties and various conflicts in opinions, the progress was slowed down. With the concerted efforts from all members of the VCC working group, the VCC Stage 2 was accomplished in the fourth quarter of 2006, and the VCC Stage 3 would be completed in the first quarter of 2007.

    In the phase of technical research, the working group members proposed many implementation solutions which mainly include the IMS control model, initial domain control model and handover application server model. On the 49th conference of 3GPP SA2, held in November 2005, the working group determined to end all work of technical reports, and listed the IMS control model as the highest priority, and began to compile the technical specifications.

    While making the specifications, the current architecture for IMS emergency calls was found out to be unable to support domain transfer, but the North American telecom carriers, led by AT&T, insisted on VCC to support emergency calls.

    Therefore, 3GPP SA2 established a working group for the Feasibility Study on VCC supporting Emergency Calls (FSVCCEm) on the 52nd conference, held in May 2006.

    There are two solutions for supplementary service support: the distributed service control model and centralized service control model. The former allows users to subscribe the supplementary services in both the CS domain and the IMS; however, it is complicated to fulfill, and it cannot provide subscribers with consistent experiences. The latter centralizes the supplementary services in the IMS, but the corresponding specifications could not be completed in Release 7 (R7). After great compromises between the two solutions, it was decided that the distributed processing model is adopted in R7, while a new working group is established to study the centralized service control model in R8, which should be compatible with
R7-specification-based VCC terminals.

    On the 54th conference of 3GPP SA2, held in August 2006, it was decided to set up the IMS Centralized Supervision (ICS) working group, concentrating on the research of the service continuity and network evolution of different access modes (such as circuit domain access and packet domain access) in the IMS centralized control mode.

    3GPP2 is also in the mid of research on VCC service. The Technical Specification Group-Core Networks (TSG-X) has set up “X.P0042 Voice Call Continuity IMS-Circuit” working group. The progress of its VCC research is equivalent to that of 3GPP. 3GPP2 is currently in the process of compiling Stage-2 specification X.P0042-001 and Stage-3 specification X.P0042-002. The completed X.P0042-001 draft deals little with the aspect of services, but only considers call forwarding services[4-7].

2 Basic Process forImplementing VCC Services
The IMS centralized control model fulfills the centralized control on VCC calls and sessions by introducing the VCC application function entity into the IMS domain. The VCC processing flow mainly includes the following stages:

    (1)   Anchoring
    In the IMS centralized control model, all the subscribers’ calls and sessions must pass the VCC application in the IMS domain to prepare for domain transfer control. This process is called “Anchoring in IMS”. When the VCC subscriber initiates a call from the CS or a voice session from the IMS domain, it first routes to the VCC application to execute the anchoring process. Similarly, any calls and sessions initiated from the CS domain or the IMS to the VCC subscriber will also be routed to the VCC application for anchoring. During the anchoring process, initial Filtering Criteria (iFC) is employed to control the session routing in the IMS, while the mechanism already available in the CS domain, such as the redirection mechanism of the Customized Application of Mobile Enhanced Logic (CAMEL) service, is used to control the routing of the CS call.

    (2)   Domain Selection
    When VCC user equipment makes a call, it will choose an appropriate domain according to the network condition, subscriber’s preferences and operator’s policy, and will then make the call within that domain. If the VCC application receives a call sent to the VCC user equipment, it will choose the domain for the terminating call according to the subscriber’s preferences, operator’s policy, as well as the subscriber’s registration status and session status. It will then initiate the call to the subscriber from that domain to establish the voice connection. According to the standard protocol, the term “domain selection” generally indicates the selection process during the terminating call.

    (3)   Domain Transfer
    When the VCC user equipment during a call detects changes in the surrounding wireless environment or any other changes, it performs the transfer operation according to the pre-defined transfer policy. The VCC user equipment initiates the transfer request from the new domain to the VCC application; the VCC application will then establish the connection between the new domain and the VCC user equipment, transfer the remote session to the new connection, and at the same time release the session in the original domain.

    There are other processes such as registration, originating call, terminating call, release, and the likes, which are basically the same as those of the CS domain and the IMS, and shall not be elaborated in this article.

3 VCC System Architecture
The reference architecture of VCC service system and its relationship with other Network Elements (NE) are illustrated in Figure 1.

    The VCC application includes four logical function entities as listed below:

    (1)CAMEL Service Function
    The CAMEL service function can either work independently, or work together with the CS Adaptation Function, performing the following operations:

• Executing the policy of redirecting CS calls to the IMS
• Assisting in allocating and cancelling IMS routing numbers, which will be used to route the originating call from the CS to the IMS
• Transferring CS call information to the IMS, (such as the calling number and called number of the CS originating call)
• Resolving the public service ID of the VCC application from the transferring number of the VCC domain during the domain transfer.
  

    (2) Domain Transfer Function
    This function can choose an appropriate domain for the incoming call of the VCC user equipment, including the following operations:

• Checking the registration status of the IMS
• Checking the registration status of the CS domain
• Acquiring domain information of the current active session from the domain transfer function
• Deciding the CS routing number during CS selection, and routing the call to the CS by this number
  

    (3) CS Adaptation Function
    On behalf of the VCC user equipment that originates a call in the CS in the IMS, the CS adaptation function establishes the call connection with the CS, performing the following operations:

• Establishing the connection with the CS, and identifying the user in the IMS as the Session Initiation Protocol (SIP) user agent client
• Transferring the CS call-related information to the IMS domain, such as the calling number and called number of the CS call
• Managing the IMS routing numbers and sending them to subscribers via the CAMEL service function.
  

    (4) Domain Transfer Function
    This function executes the session anchoring and domain transfer, including the following operations:

• Implementing domain transfer upon the request of VCC user equipment
• Performing the third-party call control function during the period of call establishment, preparing for domain transfer
• Maintaining information of the domain transfer policy
• Maintaining the domain information of VCC subscribers’ current active session, and providing information for domain selection
• Supporting the charging accuracy of domain transfer
  

    (5) VCC User Equipment
    It refers to the terminal which is capable of VCC and has subscribed to the VCC services. It has the following functions:

• Saving the domain selection and transfer policies for outgoing calls
• Choosing the domain for outgoing calls based on domain selection policy
• Initiating domain transfer
  

4 Existing Problems of VCC Standards
The specifications of VCC services in R7 have the following problems:

    (1) In VCC services, the reasonability of the operator’s policy and the subscribers’ preferences has great impact on subscriber experiences, but relevant specific definitions and interaction modes are yet undetermined.

    (2) There are still some problems with the details of supplementary service support. For example, the distributed model does not support domain transfer of intermediate call services such as call waiting, call hold and conferencing. There also exist mutual influences between supplementary service support and such call transfer functions as call barring, call deflection and Explicit Call Transfer (ECT). It impacts VCC session establishment and domain transfer.

    (3) The functions, interface mode and management entity of the V3 interface are yet undefined.

    (4) Further research is necessary for the interactive VCC support capability between VCC user equipment and the network, as well as the necessity and method of anchoring result interaction.

    (5) Under the roaming status, especially international roaming, the voice circuit roundabout is very serious and occupies the trunking resources. This problem should be solved. Bearer optimization also needs further research.

    (6) There exist different solutions for the management and application of domain transfer number, which should be studied further.

    (7) Emergency calls are not supported.

5 Conclusions
Great progress has been made in the standardization of VCC, but problems still exist. These problems will be further discussed and improved in R8 by the VCC, ICS and FSVCCEm working groups, so as to lay a solid foundation for the application of VCC and FMC[8-10].

References
[1] 3GPP TS 22.101. Service aspects: Service principles (Release 7) [S]. 2006.
[2] Wei Leping. Strategic Cogitation on NGN [J]. ZTE Communications, 2004,10(1)：１－４。
[3] Cao Shumin. Trends of Wireless Communications- Broadbandization and Mobilization [J]. ZTE Communications, 2006,12(1):1-3
[4] 3GPP TS 23.206. Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) stage2 [S]. 2006.
[5] 3GPP TS 24.206. Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) stage3 [S]. 2006.
[6] Lei Zhenzhou. Two Trends of NGN: Network Convergence and M2M Application [J]. ZTE Communications, 2005,11(4):6-9.
[7] Relationship among NGN, Softswitch and IMS [J]. ZTE Communications, 2006,12(5):1-4.
[8] 3GPP TR 23.806. Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) study (Release 7) [S]. 2006.
[9] Zhang Yanhong. Convergence and Development of Fixed and Mobile Services [J]. ZTE Communications, 2005,11(3):57-60.
[10] Zhao Huiling. Next Generation Network and Softswitch [J]. ZTE Communications, 2005,11(3):30-33.

Manuscript received: 2006-11-15

[Abstract] The Voice Call Continuity (VCC) solution adopts the IP Multimedia Subsystem (IMS) control model, and introduces VCC application into the IMS to control voice calls and realize their continuity. Without changing the mobile network, the IMS-based VCC solution can fulfill Fixed Mobile Convergence (FMC), and supports the transition and evolution from the Circuit Switching (CS) mode to the IMS mode.