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 cases:
- Ongoing active calls
- Calls in alerting state
- Calls in originating pre-alerting state
- MSC assisted Mid-call feature
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.
If HSS based ATCF Info storage and restoration function is enabled, then SCC AS stores the ATCF Info of the registered user in HSS as transparent data during the registration procedure and removes it during the deregistration procedure.
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.
SCC-AS supports the enhanced registration procedure as of 3GPP Release 12, where ATCF advertises towards S-CSCF that all MSCs in the same serving network as ATCF support access transfer of calls in alerting and pre-alerting phase and MSC assisted mid-call feature. This is made through the feature tags in the Feature-Caps header of the REGISTER message, g.3gpp.srvcc-alerting, g.3gpp.ps2cs-srvcc-orig-pre-alerting and g.3gpp.mid-call.
Those feature tags are stored internally in SCC-AS with the registered contact, to be used later together with feature tag indication from SC UE at session anchoring and operator policy configured in SCC AS to determine if the SRVCC pre-alerting, alerting and mid-call features can be applied.
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. If there is no Ericsson-specific extension of the registration event subscription and HSS-based ATCF Info storage and restoration function is enabled, then SCC AS restores the ATCF Info from HSS.
For more information about the SRVCC registration procedure, refer to MTAS Subscriber Data Management Guide.
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 Ongoing Active Calls.
2.1.3 Access Transfer of Ongoing Active 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 (originating or terminating), the access transfer INVITE with Target-Dialog header pointing to the PS session to transfer is proxied by the ATCF to SCC AS. If support for access transfer of alerting call is enabled in SCC AS, ATCF, MSC, and the served UE, the access transfer of calls in alerting state is performed as per the transfer procedure mentioned in 3GPP TS 24.237 version 10 and onwards.
2.1.5 Media Update at AccessTransfer
When access transfer happens according to the SRVCC R10 architecture where the media is anchored in ATCF/ATGW in the serving network, normally, any differences in the speech media component between currently used media on PS session and the media offered in the access transfer INVITE from MSC is handled and transcoded in the ATGW. The same speech media can be used in the offer from the ATCF to the SCC AS at the access transfer as currently used, and the remote UE does not have to be re-negotiated from SCC AS. This is also the idea with SRVCC R10 architecture. However, this is not always the case. The used ATCF/ATGW maybe not support a specific codec or the call case does not allow for selecting a specific media to be used in the access transfer INVITE, for example, originating (pre-)alerting case with multiple early sessions to transfer. For this purpose, a media comparison procedure is supported in SCC AS at access transfer to judge if remote side need to be re-negotiated or not. When the comparison results in "false" (no match) the remote side is re-negotiated using the SDP from access transfer INVITE. The procedure is controlled with the CM attributes mtasSrvccMediaCheck, mtasSrvccMediaCheckAttributes, and mtasSrvccMediaCheckBandwidth.
2.1.6 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.7 Access Transfer with MSC Assisted Mid-Call Feature
If support of MSC assisted mid-call feature is enabled in SCC AS, ATCF, MSC and the served UE, the following use cases can be supported during SRVCC access transfer:
- Access transfer single Held call
- Access transfer Active call and additional Held call
- Access transfer Held call and additional outgoing call in (pre-)alerting state
- Access transfer Active call and additional Held call
2.1.8 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.9 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.10 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 |
|
This attribute is used to set or change the SCC AS URI (SIP URI or E.164 international number) that is used as PSI when transferring additional sessions (held and alerting) during SRVCC access transfer procedure. The URI must be set different than mtasSrvccAtuSti. |
mtasSrvccSccAsUri |
|
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:
|
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 |
|
Sets which bandwidth type (bwtype) parameters to be included in the media comparison procedure when mtasSrvccMediaCheck=2. The supported bwtype parameters are AS, RR, and RS. When configured to be included in media comparison, the value in access transfer media must be equal or less than corresponding bwtype value in currently used media. |
mtasSrvccMediaCheckBandwidth |
|
Sets which media attributes to be included in the media comparison procedure when mtasSrvccMediaCheck=2. The supported media attributes are _maxptime_, _mode-set and _octet-aligned_. When configured to be included in media comparison, the attribute value in access transfer media must be equal to corresponding attribute value in currently used media. |
mtasSrvccMediaCheckAttributes |
|
Sets or changes the support for MSC assisted SRVCC Mid-call feature in MTAS. When enabled, single Held call, Held call in addition to active call, and (pre-)Alerting call in addition to Active or Held call can be transferred during SRVCC access transfer. |
mtasSrvccMidCall |
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.