Contents
1 Introduction
This document describes how to configure the Single Radio Voice Call Continuity (SRVCC) service in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the O&M area, in general.
1.1.1 Licenses
To enable the SRVCC service in the MTAS, the SRVCC license must be installed.
For more information about the SRVCC license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
This document describes the SRVCC function of the Service Centralization and Continuity Application Server (SCC-AS) based on the MTAS architecture.
The SRVCC function allows voice call continuity between IMS over Packet Switched (PS) access and Circuit Switched (CS) access for calls that are anchored in IMS when the User Equipment (UE) is capable of transmitting or receiving on only one of those access networks at a given time.
SRVCC access transfer is supported for the following calls:
- Ongoing active calls
- Calls in alerting state
- Calls in originating pre-alerting state
For more information about the SRVCC function, refer to the following specifications:
The naming of the various legs and charging sessions are shown in Figure 1.
The following notations are used in the signaling charts for identifying the charging sessions:
| PSC | PS charging session (original)
| |
| CSC | CS charging session (for the target access leg) | |
2.1 Subfunctions
The subfunctions included in the SRVCC service are described in this section.
2.1.1 Registration Procedure
During SIP registration procedures, the SRVCC service stores the C-MSISDN value of the served UE. The C-MSISDN value is used during access transfer for identifying the session to be transferred.
If the SRVCC R10 procedure is deployed in the corresponding IMS network, then the SRVCC service also stores the Session Transfer Number - Single Radio (STN-SR) value allocated dynamically to the C-MSISDN. The SCC-AS updates the Home Subscriber Server (HSS) with the new dynamic STN-SR value during the registration procedures. The HSS propagates the new STN-SR / C-MSISDN allocation in the network. The stored STN-SR value is used in the subsequent registrations for identifying if it is changed and is propagated again.
SCC-AS updates the ATCF with the ATU-STI associated with the C-MSISDN of the registering contact. The update is done by sending a MESSAGE directly to the ATCF. If routing through I-CSCF is needed, DNS must be configured to resolve ATCF name to I-CSCF IP address. Transport protocol in DNS SRV request is in accordance to mtasSipProtocolMtasOrigCall parameter.
The registration information could be lost by a node restart or an SCC-AS failover. In these cases, the registration information is obtained during the call setup by the registration event subscription method. The registration information is retrieved from the S-CSCF which acts as a notifier. After processing the registration information, the registration procedures are the same as at third-party registration.
SCC-AS supports the Ericsson-specific extension of the registration event subscription to be able to perform the SRVCC R10 handover after a restart or failover.
The registration information extension is based on the 3GPP TS 24.237 V12.6.0 specification.
2.1.2 Service Unavailable during Access Transfer
The served UE in the PS domain can terminate an existing session owing to service unavailability with BYE(503) request or an early dialog with CANCEL(503) request with a Reason header containing protocol "SIP" and reason parameter "cause" with value "503". Such a request is not immediately forwarded by SCC-AS to the remote UE. It is delayed by the SRVCC service for an operator-defined time. If during that time an access transfer is initiated by the served UE in CS domain, then the BYE or CANCEL request is not forwarded but the access transfer procedures are started, see Section 2.1.3 Access Transfer of Outgoing Calls.
2.1.3 Access Transfer of Outgoing Calls
The served UE in CS domain initiates the access transfer by sending an INVITE request to the SCC-AS. When access transfer is initiated, the UE that is the subject to the transfer is identified by its Mobile Correlation Subscriber Integrated Services Digital Network (C-MSISDN) value that is specified by the P-Asserted-Identity header of the INVITE request.
A UE can have multiple sessions but only one session is transferred according to the applied SRVCC R9 or R10 procedures as follows:
- The R9 procedure has an active full-duplex speech media component that was most recently activated.
- The R10 procedure is pointed by the Target-Dialog header in the received INVITE.
Only the speech media is transferred, the other media components are terminated by the SCC-AS.
Before the access transfer SCC-AS acts as a Back-to-Back User Agent (B2BUA), it forwards the SIP signaling between the source access leg and the remote leg. After successful access transfer, the SIP signaling is forwarded between the target access leg and the remote leg. There is a transient period during the access transfer when the source access leg and the target access leg coexist. During that transient period the served UE in PS domain has the possibility to revert the access transfer. This is initiated by a re- INVITE request sent by the served UE in PS domain. During successful access transfer, a new charging session is created for the target access leg and the original charging session is kept as well. The two charging sessions are terminated when the transferred session is terminated.
2.1.4 Access Transfer of Calls in Alerting State
When SRVCC Rel-10 architecture applies, and the session subject to access transfer is in alerting state, the access transfer INVITE is proxied by the ATCF and there is no Target-Dialog header. In this case, the session to be transferred is, as in Rel-9 procedure, found by the C-MSISDN in the access transfer INVITE. If SRVCC for alerting is enabled in the SCC-AS and the MSC and served UE supports SRVCC for calls in alerting state, the transfer procedures for call in alerting state in accordance with 3GPP Rel-10 apply in the SCC-AS.
2.1.5 Access Transfer of Originating Calls in PreAlerting State
When SRVCC Rel-12 architecture applies and the session subject to access transfer is in originating pre-alerting state, the access transfer INVITE with Target-Dialog header pointing to the PS session is proxied by the ATCF. If SRVCC release is R12 and support for access transfer of originating pre-alerting call is enabled in SCC-AS, ATCF, MSC, and served UE, the access transfer of calls in originating pre-alerting state is performed as per the transfer procedure mentioned in 3GPP TS 24.237 version 12.6.0.
2.1.6 Post-transfer Procedures
After successful access transfer, SCC-AS acts as a simple B2BUA but it has to maintain two related charging sessions; the original charging session and the charging session for the target access leg.
2.1.7 Fallback to Rel-9
SRVCC will fallback to Rel-9 procedure if the STN-SR stored in HSS has same value as mtasSrvccStnSr, or the access transfer INVITE from the served UE in CS domain does not have a Target-Dialog, or the Request URI in the access transfer INVITE does not point to the ATU-STI PSI.
2.1.8 Operation and Maintenance Operations
The O&M operations specific to the SRVCC service are as follows:
- Configuration of node level parameters
- Collection of measurement data
- Management of the alarm raised by SCC-AS
2.2 Interaction with Other Services
This section describes how the SRVCC service interacts with other services.
2.2.1 Terminating Access Domain Selection
After successful access transfer, the access type of the served UE is changed from PS to CS. If Terminating Access Domain Selection (T-ADS) procedures are applied after successful access transfer T-ADS service is aware of the new access type.
3 SRVCC Configuration
The SRVCC service is controlled by the MtasSrvcc Managed Object (MO). An overview of the SRVCC MO structure is shown in Figure 2.
For configurable MOs and attributes related to general SRVCC configuration, refer to Managed Object Model (MOM).
3.1 Configuration Activities
This section describes configuration activities.
3.1.1 SRVCC Configuration
The configuration activities are listed in Table 1.
|
Activity |
Attribute |
|---|---|
|
Sets or changes the STN-SR for SRVCC value assigned to the SCC-AS node that is used for initiating access transfer using SRVCC R9 procedures. The value cannot be set same as the STN-SR number that is dynamically allocated in ATCF when SRVCC R10 applies. |
mtasSrvccStnSr |
|
Sets or changes the Access Transfer Update Session Transfer Identification (ATU-STI) for SRVCC value assigned to the SCC-AS node that is used for initiating access transfer using SRVCC R10 procedures. |
mtasSrvccAtuSti |
|
Sets or changes the value of the timer that is used to delay the BYE request containing Reason header with protocol "SIP" and reason parameter "cause" with value "503" as defined in section 12.3.3.2 in 3GPP TS 24.237. |
mtasSrvccByeDelayTime |
|
Sets or changes the value of the timer that is used to delay the termination of the source access leg in case of successful access transfer using SRVCC procedures as defined in section 12.3.1 in 3GPP TS 24.237. |
mtasSrvccFallbackTime |
|
Sets or changes the support for SRVCC of calls in alerting state in MTAS. When enabled, calls anchored in SCC-AS in alerting state are subject for access transfer when an INVITE owing to access transfer is received from MSC. It is assumed that all MSC servers in the network where the UE is registered – which can be involved in the SRVCC procedures –, support SRVCC for calls in alerting phase. |
mtasSrvccAlerting |
|
Sets or changes the value of the timer that is used to delay the CANCEL request from PS domain containing Reason header with protocol "SIP" and reason parameter "cause" with value "503" as defined in 3GPP TS 24.237 IMS Service continuity. |
mtasSrvccCancelDelayTime |
|
Sets the mode of media check during R10 SRVCC access transfer. When set to 0 (MEDIA CHECK DISABLED), the speech media components of negotiated SDP and new access transfer SDP are assumed being the same, no comparison and no renegotiation of remote side. When set to 1 (FULL MEDIA CHECK) the a, b, c, and m-lines of the SDP are compared, and in case of any difference the remote side is renegotiated. |
mtasSrvccMediaCheck |
|
Controls the backward compatibility of 3GPP release 12.6.0 compatible SRVCC feature support in MTAS. When set to 0, 3GPP release 12.6.0 SRVCC support is disabled and legacy release 10 SRVCC functionality applies. When set to 1, 3GPP release 12 SRVCC support is enabled. |
mtasR12SrvccSupport |
|
Sets or changes the support for SRVCC of calls in originating prealerting state in MTAS. When enabled, calls anchored in SCC-AS in originating prealerting state is subject for access transfer when an INVITE because of access transfer is received from MSC. It is assumed that all MSC Servers in the network where the UE is registered which can be involved in the SRVCC procedures support SRVCC for calls in originating prealerting phase. |
mtasSrvccOriginatingPreAlerting |
3.1.2 SIP Configuration
The configuration activities are listed in Table 2.
|
Activity |
Attribute |
|---|---|
|
Sets transport protocol for originating requests, including protocol for DNS SRV query needed in MESSAGE routing during registration |
mtasSipProtocolMtasOrigCall |
3.2 SRVCC Administrative State Configuration
The SRVCC service is enabled by setting the mtasSrvccAdministrativeState attribute in the MtasSrvcc MO to 1 (Unlocked). If the mtasSrvccAdministrativeState is set to 0 (Locked), no SRVCC service is provided by the MTAS.
4 Performance Management
For measurements related to the SRVCC service, refer to Managed Object Model (MOM).
5 Fault Management
For alarms related to the SRVCC service, refer to MTAS Alarm List.