SRVCC Ensuring voice service continuity in VoLTE/IMS White Paper 2013 Author : Binu K G 1
Wireless service has turned a full circle and voice remains the most popular and killer application for any mobile network service. As more and more CSP s deploy LTE network, the main challenge would be the delivery of voice services. This issue has been addressed with VoLTE using IMS solution, but, there will be still areas without LTE coverage. The challenge for CSP will be to provide service continuity, though CSFB has been an interim solution, SRVCC is the technology that has been recommended and widely accepted. SRVCC will enable seamless voice communication between VoLTE and CS networks using a single radio in the user s device along with upgrades to the supporting network infrastructure. This solution transfers VoLTE calls in progress from LTE to legacy voice networks, while meeting the rigorous QoS standards. It supports emergency call requirements as well. In a nutshell, for an operator with a legacy cellular network who wishes to deploy voice services in combination with the LTE/IMS network, SRVCC offers the subscribers with coverage over a much larger area than would typically be available during the rollout of a new network. Comparison of 3gpp releases for SRVCC GSMA has provided a set of guidelines for SRVCC (GSMA IR.64), detailing the requirements for networks to ensure interoperability with legacy networks. SRVCC is introduced in Release 8 (3gpp TS 23.216), and has evolved with each new release, a brief summary of SRVCC capability and enhancements. 3GPP R8 3GPP R9 3GPP R10 3GPP R11 Introduces SRVCC for voice calls that are anchored in the IMS core: E UTRAN access to 3GPP2 1xCS E UTRAN/UTRAN (HSPA) access to 3GPP UTRAN/GERAN CS accesses Sv interface between MME and MSC enhanced with SR-VCC SCC AS in home network anchors session (signaling) No RTP anchor for the session SCC AS initiates RTP updates at both endpoints Transfer of held sessions Interruption time 800-1000 ms ATCF and ATGW introduced Session anchor moved from SCC AS to serving network ATCF anchors signaling ATGW anchors bearer Advantage is lower handover time, less voice disruption <300 ms Transfer of sessions in alerting state SR-VCC for video sessions Reverse SR-VCC (CS to PS) Fig 1. 3gpp Release comparison. SRVCC architecture has evolved in phases, SRVCC was introduced in rel 8 and support for emergency services incorporated in Rel 9. One of the main issues with both the SRVCC was long voice interruption time and this was addresses in rel 10. Long voice setup time was mainly due to following two procedures: 1. The interaction between MSC Server and SCC AS for transferring the session and the update of the remote end with new media information (Session Description Protocol (SDP). 2
2. The interaction between the MSC Server and SCC AS is in roaming cases over the NNI and the remote end update requires an SDP offer/answer exchange towards the remote party. With the introduction of ATCF/ATGW in rel 10 this has been addressed which ensures that the session transfer request send by MSC Server enhanced for SRVCC does not need to be routed to the HPLMN, and by eliminating the need for updating session information at remote end. SRVCC can be broadly classified as below. esrvcc (Enhanced SRVCC): Increases handover performance by eliminating the need to reestablish the bearer and signaling on both sides of the call leg and only requiring an update of the local call leg and keeping the remote leg of the call unchanged. rsrvcc (reverse SRVCC) Single Radio Voice Call Continuity from UTRAN/GERAN to E- UTRAN/HSPA vsrvcc(video SRVCC): Video Call Continuity for 3G-CS. SRVCC network architecture GSMA guidelines recommend 3GPP Release 10 architecture for SRVCC (shown in Figure), as it reduces both voice interruption delay during handover and the dropped call rate compared with earlier configurations. SRVCC requires the following elements: MSC Server that has been enhanced for SRVCC IMS network and SCC-AS in which the call is anchored MME,HSS,EUTRAN upgrades ATCF/ATGW in IMS UE that has IMS Service Continuity capabilities with single radio access. SRVCC is agnostic as to the whether S3 or GnGP is used for the SGSN interface. In the below diagram GnGP could be used instead of S3 Fig 2. Rel 10 Architecture for SRVCC 3
The IMS sessions from and to a UE are anchored at the SCC AS in the home IMS and at the ATCF in the serving (visited if roaming) network to provide Service Continuity for the user during transition between two Access Networks. Sessions are anchored at the SCC AS in the home IMS, based on ifc. IMS media sessions will be anchored by the ATCF during session establishment. Apart from EPC, IMS,CS core and HSS,the important functional nodes that need to support SRVCC are explained below, SR-VCC-IWF Single Radio Voice Call Continuity - Interworking Function: It supports mobility across IMS and CS Core, eliminating the need for MSC upgrades. It connects MME on one side and MSC on the other side. ATCF Access Transfer Control Function: The architecture implements the ATCF enhancement with the additional functions provided by the ATCF/ATGW in the serving (visited if roaming) network (as explained in 3GPP TS 23.237 R10). It is a signaling controller that facilitates handover from LTE to circuit 2G/3G networks and update the VCC application server after the access transfer. These ATCF/ATGW enhancements will be implemented in the SBC. ATGW Access Transfer Gateway: It acts as an anchor for the IMS media traffic to allow media traffic to be switched quickly from the PS access network to the CS access network via the MSC. UE with SRVCC 3GPP SRVCC UE shall support UE assisted T-ADS functionality for selecting the CS domain for terminating voice calls, and 3GPP SRVCC UE indicates to the network that the UE is SRVCC capable when being configured for using IMS speech service supported by the home operator. MSC Server MSC Server handles the Relocation Preparation procedure for the voice component from MME via Sv reference point; session transfer procedure from IMS to CS CS Handover and session transfer procedures. E-UTRAN E-UTRAN selects a target cell for SRVCC handover, and sends an indication to MME that this handover procedure requires SRVCC. No additional functionality is required for the E-UTRAN between UE and E-UTRAN. 4
MME For SRVCC related procedure the MME shall support, the PS bearer splitting function by separating the voice PS bearer from the non-voice PS bearers, and handling the non-voice PS bearers handover with the target cell as according to Inter RAT handover procedure. New Interfaces for SRVCC: To support SRVCC functionality 3GPP introduced a new protocol interface and procedures between MME and MSC (Sv Interface) for SRVCC from E-UTRAN to 3GPP UTRAN/GERAN, between SGSN and MSC (Sv Interface) for SRVCC from UTRAN (HSPA) to 3GPP UTRAN/GERAN and between the MME and the 1x CS IWS (S102 Interface) for SRVCC from E-UTRAN to CDMA 2000 1xRTT. The Sv messages are based on GTP. Interface Messages changes: Attach and TAU NAS Changes: SRVCC UE includes the SRVCC capability indication as part of the "MS Network Capability" in the Attach Request message and in Tracking Area Updates. This capability needs to be accessed and stored on the MME. S1-MME Changes SRVCC Operation Possible IE Support Changes: When SRVCC is supported and available on the MME, the SRVCC Operation Possible IE needs to be sent in the INITIAL CONTEXT SETUP request. SRVCC HO Indication IE and PS Service Not Available IE Support: This IE indicates which SRVCC callflows needs to be triggered. The enb includes the SRVCC HO Indication IE in the HANDOVER REQUIRED message if the SRVCC operation is needed. The SRVCC HO Indication IE is set according to the target cell DTM capability and UE DTM capability. S6A Changes: ICS Capability: If the UE is ICS (IMS Centralized Service) capable, this capability is sent by the MME to the MSC. The ICS Capable flag is downloaded from the HSS during the Attach procedure. MME sets the ICS Capable bit in the Sv Flags IE as part of the Sv PS to CS request. SRVCC Identities Few identities are introduced to support the operation of SRVCC STN-SR This STN-SR is sent by the MME to the MSC for all non-emergency calls. It is downloaded from the HSS during the Attach procedure. If the STN-SR is not present in the HSS during the Attach procedure, SRVCC handover will not be allowed for non-emergency calls. 5
STN-SR is sent to the MSC as part of the Sv PS to CS request. C-MSISDN Correlation MSISDN (C-MSISDN) is an MSISDN that is used for correlation of sessions at access transfer and to route a call from the IM CN subsystem to the same user in the CS domain. The C- MSISDN is equal to the MSISDN or the basic MSISDN if multinumbering option is used of the CS access. Any MSISDN of a user that can be used for TS11 (telephony) in the CS domain which is not shared by more than one IMS Private Identity in an IMS CN subsystem, can serve as the user's C- MSISDN. The C-MSISDN is bound to the IMS Private User Identity and is uniquely assigned per IMSI and IMS Private User Identity. Session Transfer Identifier for reverse SRVCC (STI-rSR) A dynamic identifier used by the UE to request the IMS network to perform Session Transfer for CS to PS SRVCC (reverse SRVCC). The STI-rSR is used by the network to correlate two access legs, and is unique for each access transfer control function within an ATCF Voice Bearers It is assumed that voice bearer(s) for SRVCC calls will be QCI 1. SRVCC Access transfer Below given is a brief description of access transfer in Rel 10 architecture. Fig 3. Call established in IMS network UE periodically scans the neighbouring cells and sends measurement report to E-UTRAN, and E- UTRAN initiates access transfer 1. E-UTRAN sends HO Required to MME (Target ID, SRVCC Indication) 6
2. MME sends session transfer request to SRVCC IWF via Sv (IMSI, Target ID, STN-SR, C- MSIDN) 3. SRVCC IWF triggers Inter-MSC HO and MSC sends Prepare HO Request (Target Cell) 4. Target RAN initiates HO Procedure, once the access side is reserved MSC sends : Prepare HO Response(HO number) 5. Setup CS Leg and Respond to EPC SRVCC PS to CS response -> HO Command to UE 6. Session Transfer Request: IWF sends INVITE (STN-SR, C-MSISDN, SDP-MGW) to ATCF 7. ATCF Session Transfer Procedure ATCF sends INVITE(ATU-STI, SDP-ATGW) to SCC-AS: SCC AS coordinates release of old Access leg in PS (sends BYE) 8. ATGW updates Bearer Path (as result of ATCF reconfigure) 9. UE Retunes to GERAN/UTRAN: HO detect to MSC MSC MAP PAS (HO Detected) to SRVCC IWF ANM to MGCF; 200 OK to IWF 10. SRVCC IWF notifies MME about successful PS to CS transfer 11. SRVCC IWF triggers TMSI Reallocation (via MSC) to UE and LU to HLR Fig 4: UE moves to CS after executing SRVCC 7
SRVCC for Emergency calls: SRVCC for emergency calls must be supported in any deployment supporting SRVCC and is specified in 3GPP Release9. A logical function Emergency Access Transfer Function (EATF) is required in the VPLMN in addition to the functions needed for SRVCC and IMS emergency calls.the MSC uses the Mw interface to the Interrogating Call Session Control Function and includes the equipment identifier into the session transfer request; the equipment identified is used by the EATF to correlate the call legs. SRVCC for emergency calls does not make use of the ATCF and ATGW. Conclusion As more and more operators roll out LTE and adopt VoLTE/IMS as platform for providing voice services, SRVCC will be an option for addressing the gaps in LTE coverage while providing continuous coverage for voice service. To ensure service continuity and success, GSMA has provided the industry with set of guidelines and recommendations. 3gpp has also ensured that interruption time is minimum and user experience of SRVCC is par with traditional voice services. For those operators who deploy LTE and VoLTE in phased manner, SRVCC is a key functionality which can interoperate with legacy networks, while meeting the service continuity and standards for voice services. References 1. GSMA, IR.92 IMS Profile for Voice and SMS. 2. GSMA, IR.94 IMS Profile for Conversational Video Service. 3. 3GPP, TS.23.216, Single Radio Voice Call Continuity (SRVCC). 4. GSMA,IR.64 IMS Service Centralization and Continuity Guidelines V6.0 5. 3GPP, TS22.278, Service Requirements for the Evolved Packet System (EPS) 6. 3GPP, TS23.237 IP Multimedia Subsystem (IMS) Service Continuity;Stage 2 8
www.techmahindra.com connect@techmahindra.com www.youtube.com/user/techmahindra09 www.facebook.com/techmahindra www.twitter.com/tech_mahindra www.linkedin.com/company/tech-mahindra 9