Contents

1   Introduction

This document describes how to configure the IMS Centralized Services (ICS) functions for the Service Centralization and Continuity Application Server (SCC-AS) in the MTAS. The functions are as follows:

• Service Domain Selection (SDS).

  To select IMS as service domain for calls originated from VoLTE User Equipment (UE) on 2G/3G CS access, and for terminating VoLTE calls from Circuit Switched (CS) domain.

• Terminating Access Domain Selection (T-ADS).

  For calls terminating at Long Term Evolution Packet Switched (LTE PS, or Wi-Fi PS, or both) access or 2G/3G CS access.

The SCC-AS is based on the architecture and components of the MTAS and can be collocated with the Multimedia Telephony AS (MMTel Telephony AS) or standalone.

1.1   Prerequisites

It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.

1.1.1   Licenses

To enable the ICS functions for the SCC-AS the SCC Base license, the SCC T-ADS license, and the SCC SDS license must be installed.

To enable Wi-Fi Support in T-ADS, the Wi-Fi Calling license must be installed.

For more information about the licenses for the ICS functions for the SCC-AS, refer to MTAS Licenses.

Note:  

SCC-AS deployed without interface to IMS HSS is not supported in the 15A releases.

1.1.2   Documents

Before starting any procedure in this document, ensure that the following documents are available:

• Ericsson Command-Line Interface User Guide
• Managed Object Model (MOM)
• MTAS Country Code Mapping Management Guide

1.1.3   Conditions

Before starting any procedure in this document, ensure that the following condition is met:

• An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
• Country Code Mapping (CCM) service has been configured on MTAS, refer to MTAS Country Code Mapping Management Guide for the configuration.

2   Overview

This section gives an overview of the ICS functions for the SCC-AS in the MTAS.

2.1   Solution Overview

The SCC-AS is a central node in IMS to support IMS services to ICS users and to select terminating access domain (CS or PS) to VoLTE mobiles camping in networks with a mix of CS, Wi-Fi, and continuous LTE coverage, where it can be expected that the mobile moves between LTE, Wi-Fi, and 2G/3G accesses.

The functionality provided by the SCC-AS is the support for ICS, which is needed for a single telephony service engine (IMS) for ICS User's terminals accessing the network over LTE PS, Wi-Fi PS, and 2G/3G CS, and Single Radio Voice Call Continuity (SRVCC) support, needed for the transfer of ongoing sessions when the mobile moves from LTE PS to 2G/3G CS coverage.

This document provides information about the ICS part. For more information about SRVCC, refer to MTAS SRVCC Management Guide.

2.1.1   MSC Not Enhanced for ICS

The SCC-AS can be deployed in solutions where the Mobile Switching Center (MSC) server is not enhanced for ICS, that is legacy MSC where IMS is selected as service domain for Mobile Originated (MO) and Mobile Terminated (MT) calls based on provisioned CAMEL triggers and CAP interface to SCC-AS and Mg interface to IMS. The solution overview is illustrated in Figure 1.

SCC-AS can be deployed in solutions with a mixture of ICS enhanced and not-ICS enhanced MSC.

2.1.2   MSC Enhanced for ICS

The SCC-AS can also be deployed in solutions where the Mobile Switching Center Server (MSC) is enhanced for ICS, in this case the MSC server is equipped with an ICS User Agent which performs registrations on behalf of the VoLTE UE on CS and mobile call originations and terminations to IMS over the SIP I2 interface. The solution overview is illustrated in Figure 2.

2.1.3   Deployment with Mix of VoLTE and 2G/3G Subscribers

SCC-AS is normally used to offer ICS to VoLTE users with LTE, Wi-Fi, and CS access, where T-ADS selection criteria is based on registration status, HSS parameters (MSISDN, TADS information) and so on. However, SCC-AS can also be used for traditional 2G/3G CS only mobiles, in which case terminating calls are always broken out to CS. SCC-AS supports a mix of VoLTE and 2G/3G CS deployment. The configuration of this process is further described in Section 2.4.5 Deployment Supporting Mix of 2G/3G and VoLTE Subscribers.

2.1.4   SCC-AS without Interface to HSS(IMS)

SCC-AS can be deployed without an interface to HSS(IMS) meaning that the data normally fetched from HSS(IMS) by SCC-AS during registration (IRS and C-MSISDN/MSISDN) is obtained from the 3PTY Registration message, and SCC-AS acting as a GMSC in the T-ADS service when requesting the MSRN allocation for CS breakout directly to HLR over an ETSI MAP interface. The configuration of this process is further described in Section 2.4.6 Terminating Access Domain Selection.

An interface to HSS(EPC) is required for the SCC-related data, STN-SR, and TADS information.

2.2   SCC-AS Overview

The SCC-AS is an MTAS node handling the ICS and SRVCC functions, using the existing architecture and components in the MTAS.

SCC-AS supports geographical redundancy meaning that the IMS system can be configured with two SCC AS-s. If the primary SCC-AS is restarting or unavailable the secondary SCC-AS can be used in the system. Although if restart or the failover is performed during a call setup, the call is not established; the subsequent calls are successfully handled by the backup SCC-AS.

The SCC-AS and the MMTel Telephony AS can be collocated in a node, which means that SCC and MMTel sessions can be active simultaneously in the node.

The SCC and MMTel sessions are triggered from CSCF by separate Initial Filter Criteria (IFC). There are specific ports on which the initial SIP message is received for the SCC, and MMTel session cases. As the Subscriber Data function, common to the SCC-AS and the MMTel Telephony AS registration, handles both the SCC-AS and the MMTel Telephony AS data the solution can be optimized, regarding registration, by only triggering the SCC-AS at registration. This process is illustrated in Figure 3.

The SCC-AS is deployed as the first AS for originating calls and registration, and as the last AS for terminating calls.

2.3   ICS Function Overview

The ICS functions for the SCC-AS consist of the following:

• Collection and storage of subscriber Contacts Data and Session Data for the T-ADS procedure.
• SDS for Mobile Originating (MO) calls and Mobile Terminating (MT) calls when the MSC/GMSC is not enhanced for ICS.
• T-ADS procedure to select terminating access domain for terminating VoLTE calls.

The subfunctions are briefly described in the following sections.

2.4   Subfunctions

This section describes the following subfunctions:

• Handle UE registration
• Service Domain Selection for MO and MT calls
• Handle originating call setup
• Handle terminating call setup
• Mix of VoLTE and 2G/3G subscribers
• T-ADS
• Network Provided Location Information (NPLI) retrieval
• End call

2.4.1   Handle UE Registration

A VoLTE UE can be registered over LTE PS, Wi-Fi PS, or fixed UE can be registered over LTE PS, and the VoLTE UE when attached to CS can be registered by the ICS Enhanced MSC on behalf of the UE.

The third-party registration for the SCC-AS contains a "message/sip" body with the REGISTER request and 200 OK response. This is ensured in the iFC configuration for SCC-AS in HSS and in MTAS by setting the mtasSubsDataCacheContactData to enabled. MTAS is then able to retrieve and cache Contact Data from the third-party REGISTER. If caching is enabled but the Contact Data cannot be fetched from the body of third-party REGISTER for some reason (for example, the body or a part of it is missing or broken), the SCC-AS rejects the third-party REGISTER with a SIP 400 Bad Request response with the Warning header set to 399: "MIME body message/sip content not sufficient".

A VoLTE UE can be registered simultaneously on PS and CS for a short time at SRVCC access transfer, and simultaneously registered by two MSCs during handover between ICS enhanced MSCs.

The UE can also be registered during originating or terminating call setup if there is no registration or contact information because of a restart or failover. In that case the same registration and caching Contact Data procedures must be executed after receipt of "reg" event notification as on receipt of a third-party registration. The T-ADS, HSS, and ATCF are updated with the registration and contact information in order the call is established and to make an SRVCC release 10 call handover during a call.

A UE can be deregistered by the domain or by the ICS Enhanced MSC in the CS domain, depending on the access network that the UE is attached to. This process includes both user-initiated and network-initiated deregistration.

2.4.2   Service Domain Selection

This function implements the GSM Service Control Function (gsmSCF) for InitialDP (IDP) requests from gsmSSF over the CAP interface. The IDP request can be received from a non-ICS enhanced MSC gsmSSF on O-CSI or N-CSI trigger for Originating Service Domain Selection (O-SDS), or from a non-ICS enhanced GMSC gsmSSF on T-CSI trigger for Terminating Service Domain Selection (T-SDS).

2.4.2.1   Originating Service Domain Selection

This section describes the O-SDS subfunction.

Originating Service Domain Selection applies when CAP InitialDP request with event DP collectedInfo is received by the SCC AS/gsmSCF from a non-ICS enhanced MSC gsmSSF on O-CSI or N-CSI trigger.

Note:  

In the case N-CSI triggers SCC-AS gsmSCF, the called party number subject for O-SDS is passed in the calledPartyNumber parameter in CAP InitialDP. This configuration must be coordinated in the solution; in SCC-AS by setting the parameter mtasSdsCalledPartyNumberPreference accordingly.

The aim of O-SDS in SCC-AS is to select IMS as service domain for the call by allocating an IMS Routing Number (IMRN) and return it to MSC in a CAP Connect response.

However, the anchoring in IMS is conditional based on the configuration of dynamic SDS in SCC-AS, the media type of the call, if subscriber is roaming or not, if the called party number qualifies as a local number and if called party number entered with an Escape code. The result of dynamic SDS is then to either continue the call in CS domain or to anchor in IMS with the IMRN.

2.4.2.1.1   Conditional Anchoring with Dynamic SDS

The dynamic SDS function decides whether to anchor the call in IMS or not based on the following conditions, executed in that order:

1. Validation of the CAP InitialDP parameters.

   Mandatory parameters for O-SDS must be present. For more information, refer to MTAS CAP Support.

2. If condition to check if Media call type supported is enabled, the media type of the call is obtained (audio, video, data, fax, and so on) from CAP InitialDP parameters, and if it is supported by SCC-AS based on SDS configuration.
3. If condition to check Service profile if roaming user is allowed to anchor in IMS or not is enabled, the roaming status of the served user is obtained from CAP InitialDP parameters, and in the case the user is roaming a check if the call is allowed to be anchored in IMS or not based on a configured Service profile for the HPLMN of the users.
4. Validation of the calling and called party number formats.
5. If condition to check for local number is enabled, check if the called party number qualifies as a local number, as configured for the PLMN, and call can be continued in CS domain.
6. If condition to check for local number is enabled, a check for escape code in called party number is performed in addition to the local number check. If it matches with the configured escape code for the HPLMN, the escape code is removed and the resulting called party number is returned as destination address to MSC; else if no match, the call is anchored in IMS.

In the case, the condition is not satisfied in Step 1 to Step 5, a CAP CONTINUE response is sent to gsmSSF, and no further execution in SCC-AS.

The escape code procedure in Step 6 results in a CAP CONNECT response being sent to gsmSSF with a destination address in the CS domain.

In the other case IMS anchoring applies, an IMRN is allocated and returned in CAP Connect.

2.4.2.1.2   Allocate IMRN

An IP Multimedia Routing Number (IMRN) is allocated from a central pool in SCC-AS, as defined by a configured IMRN range (MtasImrnRange MO). It is stored internally with the calling party number, calledPartyNumber, or calledPartyBCDNumber (depending on mtasSdsCalledPartyNumberPreference), calling party Privacy indication, and calling party location information (LAI or CGI and Country Code). A lifetime timer (mtasSdsImrnLifetime) is started and the allocated IMRN is returned in CAP Connect message to MSC/gsmSSF.

2.4.2.1.3   IMRN Pool Dimensioning

IMRN ranges are to be configured in SCC-AS to support Originating Service Domain Selection (O-SDS) procedures. The cumulative size of the IMRN range pool depends on the expected maximum lifetime of any individual IMRN (limited by the CM parameter mtasSdsImrnLifetime) and by the maximum handled call throughput per Traffic Processor (regardless whether in overload condition or not).

A safe guideline for IMRN pool size dimensioning therefore, is to have the pool size larger than the value resulting from the following formula:

2 * (mtasSdsImrnLifetime/1000) x 300 x Nr of Traffic Processors

2.4.2.1.4   Route IMRN Call Setup

As part of the O-SDS from MSC, an IMRN PSI routed INVITE is received from I-CSCF.

The SCC-AS acts as an initiating Back-to-Back User Agent (B2BUA), constructing an originating INVITE out of the blue with parameters according to the ICS standard and the stored IMRN association.

In the case the called party number was indicated as a local number, the phone-context is set to the home Country Code of the calling subscriber (from IMSI). In the case, the calling party number was in national format, it is normalized by adding the home Country Code, and then used as the P-Asserted-Identity. The home Country Code (CC) is obtained from configuration, MtasSdsServedHplmn, keyed by the MCC as obtained from IMSI in the CAP InitialDP request.

For more information about the ICS standard, refer to 3GPP TS 24.292 v10.6.0, IMS Centralized Services.

2.4.2.2   Terminating Service Domain Selection

T-SDS is applied when CAP InitialDP request with event DP termAttemptAuthorized (12) is received by the SCC AS/gsmSCF from a GMSC gsmSSF on T-CSI trigger.

The aim of T-SDS in SCC-AS is to select IMS as service domain for the call by allocating an IMS Routing Number (IMRN) and return it to MSC in a CAP Connect response. In this case, the IMRN is defined as the calledPartyNumber with a configured prefix (mtasSdsImrnPrefix) and is returned in a CAP Connect message to MSC/gsmSSF.

However, the anchoring in IMS is conditional based on the configuration of dynamic SDS in SCC-AS; whether the media type of the call is supported or not in the IMS domain. The result of dynamic SDS is then to either continue the call in CS domain or to anchor in IMS with the IMRN.

2.4.2.2.1   Conditional Anchoring with Dynamic SDS

The dynamic SDS function decides whether to anchor the call in IMS or not based on the following conditions, executed in that order:

1. Validation of the CAP InitialDP parameters.

   Mandatory parameters for T-SDS must be present. For more information, refer to MTAS CAP Support.

2. If condition to check if Media call type supported is enabled, the media type of the call is obtained (audio, video, data, fax, and so on) from CAP InitialDP parameters, and if it is supported by SCC-AS based on SDS configuration.
3. Validation of the called party number formats.

In case, the validation of the parameters condition is not satisfied in Step 1 to Step 3, a CAP CONTINUE response is sent to gsmSSF, and no further execution in SCC-AS.

In other case IMS anchoring applies, an IMRN is allocated and returned in CAP Connect.

2.4.3   Handle Originating Call Setup

A call setup from a VoLTE UE can originate over the PS LTE/WiFi domain or the CS domain. The access domain for VoLTE UE (PS or CS), based on PANI header and Contact header feature tags, is stored with the session data when INVITE is received.

2.4.4   Handle Terminating Call Setup

A terminating call setup to an ICS subscriber is triggered to SCC-AS through terminating iFC. A call case, VoLTE, or 2G/3G, is determined and calls to a VoLTE UE are then routed according to T-ADS decision to PS or CS domain. The T-ADS procedure is applied to calls destined to VoLTE UE only, that is, calls to 2G/3G subscribers are always broken out to CS and calls explicitly routed to fixed devices are forwarded to the S-CSCF. The T-ADS procedure is described in detail in Section 2.4.6 Terminating Access Domain Selection.

Deployments with SCC-AS supporting a mix of 2G/3G subscribers and VoLTE subscribers is detailed in Section 2.4.5 Deployment Supporting Mix of 2G/3G and VoLTE Subscribers.

For more information about how to handle explicit distribution of calls to fixed and VoLTE devices in Fixed and Mobile Convergence (FMC) scenarios, refer to MTAS Flexible Communication Distribution Management Guide.

The access domain for VoLTE UE session is stored with the session data when 200 OK is received, based on PANI header and Contact header feature tags.

2.4.5   Deployment Supporting Mix of 2G/3G and VoLTE Subscribers

Deployment with mix of VoLTE and 2G/3G users is supported by SCC-AS ICS, where calls to VoLTE users undertake normal T-ADS handling with HSS access for MSISDN and TADS information, as opposed to 2G/3G calls, where no HSS interactions regarding MSISDN and T-ADS take place.

This option can be achieved with HSS configuration for the subscriber, ServerName property in the iFC for SCC-AS to indicate the type of user. The ServerName property is added in the Route header when INVITE is routed from S-CSCF to SCC-AS where it is matched with a preconfigured VoLTE case name (mtasSubsDataVolteCaseName).

The matching is done by comparing mtasSubsDataVolteCaseName with the start of Route header URI (after sip:) meaning that the ServerName property must start with the VoLTE case name string for a match. If it is matched, ICS user is considered as VoLTE user. Otherwise, it is considered as 2G/3G user.

Default, when mtasSubsDataVolteCaseName is not configured, is to treat all calls as VoLTE.

2.4.6   Terminating Access Domain Selection

The T-ADS procedure is executed to select the terminating access domain for the VoLTE UE, CS, or PS. It is based on:

• Cached Contact Data for registered terminals.
• Access type for ongoing VoLTE session and most recent VoLTE session.
• T-ADS information (if the current location access network supports IMS Voice over PS) obtained from the Home Subscriber Server (HSS).

2.4.6.1   Update Contact Data for Terminating Access Domain Selection

The registered contact information is retrieved either from the "message/sip" body of the third-party registration or from the "application/reginfo+xml" formatted XML body of the relevant notification and is stored internally in the SCC-AS for later use by the T-ADS procedure for terminating calls.

2.4.6.2   Update Session Data for Terminating Access Domain Selection

The VoLTE UE access domain for current session and for the most recent session, together with session termination time, is stored internally in the SCC-AS to be used in the T-ADS procedure for terminating calls.

2.4.6.3   TADS Selects PS and Retry with CS Breakout

When mtasTadsSelectionPolicy =3 or 5, two timers (mtasTadsNotReachableTimer and mtasTadsNoResponseTimer) are started and INVITE is routed to the PS contact.

In the following cases, a retry with CS breakout is performed:

• If the UE is not reached and does not respond with 183, and mtasTadsNotReachableTimer times out.
• If the UE is reached and responds with 183, preconditions signaling continues end-to-end, but media resources not properly reserved at B or QoS are not met, so that B is not alerted and 180 is not responded to SCC-AS, and mtasTadsNoResponseTimer times out.
• If the call is rejected with 4xx (except 486 User Busy), 5xx, 6xx, if the call is rejected with 4xx, 5xx or 6xx and the rejection code is within mtasTadsCsRetryPsSipErrorCodes, or if the 200 response times out.

2.4.6.4   TADS Selects CS and Retry with CS Breakout

When mtasTadsSelectionPolicy = 4 or 5, and a call that is delivered to CS contact over I2 interface is rejected with a SIP 500 Server Internal Error and cause = 20 (subscriber absent), a retry with CS breakout is performed.

2.4.6.5   TADS Selects CS Breakout

If breakout to CS is selected, and mtasTadsBreakoutPolicy is set to 0, the Request-URI is set to CSRN defined as in the HSS provisioned MSISDN with a prefix (mtasTadsCsrnPrefix) and an optional "rn=" parameter (mtasTadsRoutingNumber), and the calling party prefixed with an optional prefix (mtasTadsCallingPartyPrefix). The prefix on called party number is used for the breakout and normally to suppress the T-CSI trigger in GMSC, the prefix on calling party number can be used in some solutions to suppress T-CSI trigger in GMSC. If no MSISDN is available from HSS, the incoming Request URI can be used instead of MSISDN.

When mtasTadsBreakoutPolicy is set to 1 or 2, SCC-AS requests the MSRN from the CS domain. This setting can be done by requesting it from HSS over Sh interface, which in turn results in HSS requesting it from HLR over MAP. Or, it can be requested directly from HLR over the MAP SRI interface. This is the case when SCC-AS is deployed without an interface to HSS(IMS) as described in Section 2.1.4 SCC-AS without Interface to HSS(IMS), mtasSccHssDeploymentMode=1 (no HSS(IMS)) and a proper license is in place. In this case, the GMSC role with a MAP interface on the SS7 stack must also be configured as described in Section 3.2 T-ADS and GMSC Configuration.

When tone suppression in MSC is enabled for non-roaming users (mtasTadsSuppressCsTone=1), a +g.3gpp.ics feature tag is added to the outgoing INVITE in Feature-Caps header. CCM service is used to map Country Code (CC) from MSISDN, and either MSRN (for breakout with MSRN), or location information (for breakout with prefix) data, to unified Mobile Country Code (MCC). In the latter case, location information is requested from HSS on the arrival of INVITE. Roaming state is determined by comparing mapped unified MCCs from MSISDN and MSRN or location information.

If tone suppression is needed in IMS for roaming users, MMTel services can be configured accordingly (mtasRbtSuppressTone and mtasCatSuppressTone).

2.4.7   T-ADS Support for Wi-Fi Access for VoLTE Subscribers

T-ADS can deliver the call to EPC-integrated Wi-Fi, if VoLTE device is registered using the WLAN access type.

CM attribute mtasSubsDataMobileClassification must be configured with +g.3gpp.accesstype= "wlan" , +g.3gpp.accesstype= "cellular", and +g.3gpp.accesstype= "server" feature tags to identify the device as VoLTE device type.

Wi-Fi support requires the valid "Wi-Fi Calling" license configured and mtasTadsWifiAccessSupport is set to WIFI_ACCESS_SUPPORTED to activate the feature.

2.4.7.1   TADS Selects Wi-Fi Access and Retry with CS Breakout

When mtasTadsSelectionPolicy =3 or 5, SCC-AS tries to route INVITE to VoLTE device on Wi-Fi with accept-contact header containing "+g.3gpp.accesstype="wlan"" and 2 timers (mtasTadsWiFiNotReachableTimer and mtasTadsWiFiNoResponseTimer) are started.

In the following cases, a retry with CS breakout is performed:

• If the UE is not reached and does not respond with 183, and then mtasTadsWiFiNotReachableTimer times out.
• If the UE is reached and responds with 183, preconditions signaling continues end-to-end but media resources not properly reserved at B or QoS are not met, so that B is not alerted and 180 is not responded to SCC-AS, and mtasTadsWiFiNoResponseTimer times out.
• If the call is rejected with 4xx (except 486 User Busy), 5xx, 6xx, if the call is rejected with 4xx, 5xx or 6xx and the rejection code is within mtasTadsCsRetryPsSipErrorCodes, or if the 200 response times out.

2.4.8   Network Provided Location Information Retrieval

Network Provided Location Information (NPLI) for a mobile (2G/3G or VoLTE capable) can be retrieved in SCC-AS from HSS over Sh interface. The following options are available:

• Retrieve from LTE PS domain
• Retrieve from LTE and GPRS PS domain
• Retrieve from GPRS PS domain
• Retrieve from CS domain

For originating case, SCC-AS retrieves NPLI when there is no network-provided PANI in the INVITE or the CGI in PANI is not valid. For terminating case, SCC-AS retrieves NPLI when there is no network-provided PANI in the 18x/200 response or the CGI in PANI is not valid.

2.4.9   End Call

When a VoLTE session is terminated, the recent session data is updated with access domain and time for termination.

2.5   Interaction with Other Services

This section describes the ICS interaction with other services and support functions.

2.5.1   Charging

This section describes how the SCC-AS interacts with the Charging service.

2.5.1.1   General

Charging records generated by the SCC-AS can be used to correlate with charging records generated in the access nodes (P-CSCF, MSC), for determining access charge for the call. The combination of these charging records can be correlated with other IMS-based charging records for generating an overall charge for a call including access-related charge.

Note:  

Only offline charging is allowed in the charging profile for the SCC-AS.

For more information about the offline charging function of MTAS, refer to Diameter Offline Charging in MTAS.

2.5.1.2   Management

Charging in the SCC-AS uses the same principles for charging management as in the MMTel Telephony AS, that is, charging is controlled by the MTAS node level charging configuration and a charging profile dedicated for the SCC-AS sessions.

On node level the following charging parameters apply to the SCC-AS:

• Enable/disable offline charging for all originating sessions
• Enable/disable offline charging for all terminating session
• List of deactivated charging realms that are treated as unavailable for new charging sessions
• Default CDF address
• Number of ACR backup files

  The parameters on charging profile level, dedicated for the SCC-AS sessions, are as follows:

• Service context identity
• Continue free of charge or not (if fail to send ACR)
• Rf version
• Enable/disable generation of ACR events in case session setup fails
• List of ACR AVPs to be omitted from ACR messages

For details on the parameters, refer to Diameter Offline Charging in MTAS.

2.5.2   Flexible Communication Distribution

In FMC scenarios, the MMTel Flexible Communication Distribution (FCD) service can be used to distribute a call to ICS user's devices by adding the feature tag +sip.instance to the Accept-Contact header for each terminating call leg.

If additional mobility selectors are configured in MTAS (mtasFcdAdditionalTermSelectorMobile and mtasFcdAdditionalTermSelectorFixed), they are also inserted as Accept-Contact headers to INVITE requests towards fixed and mobile (VoLTE) devices, besides the sip.instance caller preferences.

A call destined to a fixed device, not targeted for T-ADS service, is passed on to the S-CSCF.

For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.

The SCC-AS can also be deployed in solutions with traditional CS only GSM/3G mobiles where no UE registration occurs.

In this case, when standalone (without MMTel Telephony AS), the SCC-AS can be deployed without an interface to the HSS. This option is achieved by setting the attribute mtasSubsDataRegistrationMode to the value of 2 (No Register Mode).

2.5.3   Subscriber Data

The SCC-AS depend on ICS user's registered contacts information to be able to distinguish the device identifier, type of device (VoLTE/Fixed), and from which domain it is registered (PS/CS)), and from access-type it is registered from (LTE, Wi-Fi).

This information is parsed from the registered contacts feature tags in the third-party registration and cached (Contact Data).

For this purpose, the iFC in HSS is configured to trigger initial registration, re-registration, and deregistration to the SCC-AS and to include the user REGISTER request and 200 OK response in the "message/sip" body of the third-party registration. The mtasSubsDataCacheContactData attribute must also be enabled.

For more information about the SCC-AS registration procedures, refer to MTAS External Network Configuration.

For more information about the Subscriber Data service, refer to MTAS Subscriber Data Management Guide.

3   ICS Services Configuration

The SCC ICS services, T-ADS and SDS, are controlled by the mtasScc, mtasTads, and mtasSds MO. An overview of the SCC MO structure is shown in Figure 4.

For configurable MOs and attributes related to the SCC service, refer to Managed Object Model (MOM).

3.1   SCC Configuration

The following sections describe the SCC configuration options.

3.1.1   SCC Administrative State

The SCC-AS is enabled by setting the mtasSccAdministrativeState attribute in the mtasScc MO to 1 (Unlocked). If the mtasSccAdministrativeState is set to 0 (Locked), no SCC service is provided by the MTAS.

3.1.2   Charging Profile

The charging profile for the SCC-AS is activated in the SCC service by setting the name of the charging profile to be used by SCC-AS.

For more information about the charging profile for the SCC-AS, refer to MTAS Charging Management Guide.

3.1.3   HSS Deployment Mode

The HSS deployment mode in SCC-AS is defined by setting mtasSccHssDeploymentMode. Setting it to 0 denotes normal deployment with interface to HSS(IMS). Setting to 1 denotes deployment without interface to HSS(IMS), which also requires a separate license "SCC-AS without interface to HSS(IMS)".

When configured without interface to HSS(IMS), a MAP interface to HLR is required for SCC-AS T-ADS/GMSC role to achieve the MSRN when call breakout to CS based on allocated MSRN occurs. The configuration of this MAP interface on SS7 is further described in Section 3.2.3 GMSC Role and MAP Configuration.

3.2   T-ADS and GMSC Configuration

This section describes the configuration activities for the T-ADS.

3.2.1   T-ADS Administrative State Configuration

The T-ADS service is enabled by setting the mtasTadsAdministrativeState attribute in the mtasTads MO to 1 (Unlocked). If the mtasTadsAdministrativeState is set to 0 (Locked), no T-ADS service is provided by the MTAS.

3.2.2   Activities for T-ADS Service Configuration

The configuration activities are listed in Table 1.

Table 1    More Configuration Activities for T-ADS

Activity	Attribute
Controls for how long the last terminated VoLTE session details can be used in the T-ADS procedure.	mtasTadsLastSessionValidTime
Attribute with the timer to be used in the HSS query for TADS information.	mtasTadsHssTimer
Defines the prefix to be added to called party in case of call breakout to CS.	mtasTadsCsrnPrefix
Defines the prefix to be added to calling party in case of call breakout to CS.	mtasTadsCallingPartyPrefix
Defines the routing number to be added to the Request-URI rn parameter when breaking out a call to CS.	mtasTadsRoutingNumber
Defines the list of SIP error codes or error code ranges, which cause T-ADS service to execute a CS breakout when call delivered to PS contact fails.	mtasTadsCsRetryPsSipErrorCodes
Defines the list of SIP error codes or error code ranges and optionally SIP cause codes, which cause T-ADS service to execute a CS breakout when call delivered to CS contact fails. When an entry contains both SIP error code and cause code, then it only matches if a SIP error with a given error code and cause code is received. When an entry only contains error code or error code range, without cause code, then it matches all SIP errors with the given error code, with or without any cause code.	mtasTadsCsRetryCsSipErrorCodes
Defines the selection policy to be used in TADS, to retry with CS breakout when call delivered to PS/CS contact fails or not.	mtasTadsSelectionPolicy
Defines the policy when breakout to CS is selected in TADS, CSRN based on prefix, or on the MSRN as obtained from HSS/HLR.	mtasTadsBreakoutPolicy
Defines if an indication to suppress tone generation is added in the INVITE to MSC when the served user is not roaming.	mtasTadsSuppressCsTone
The Wi-Fi Calling Support is enabled or disabled in T-ADS service.	mtasTadsWifiAccessSupport
Enables or disables support for Mobile Terminating Roaming Retry (MTRR), applicable only for non-HSS deployment.	mtasTadsMtrr
Defines the UE reachable timer to be used in T-ADS when PS contact is selected and T-ADS selection policy is configured to retry CS on PS contact failure or time-out. In this case, the timer is used when waiting for UE reached response (183) from VoLTE UE on PS. If the call setup is either rejected or the timer expires, a secondary call setup attempt is done by breaking out the call to CS.	mtasTadsNotReachableTimer
Defines the timer for UE resources reservation to be used in T-ADS when PS contact is selected and T-ADS selection policy is configured to retry CS on PS contact failure or time-out. In this case, the timer is used when waiting for 180 response from VoLTE UE on PS. If the call setup is either rejected or the timer expires, a secondary call setup attempt is done by breaking out the call to CS.	mtasTadsNoResponseTimer
Defines the UE reachable timer to be used in T-ADS when Wi-Fi contact is selected and T-ADS selection policy is configured to retry CS on PS contact failure or time-out. In this case, the timer is used when waiting for UE reached response (183) from VoLTE UE on Wi-Fi. If the call setup is either rejected (except 480 caller preferences, do not match) or the timer expires, a secondary call setup attempt is done by breaking out the call to CS.	mtasTadsWiFiNotReachableTimer
Defines the timer for UE resources reservation to be used in T-ADS when Wi-Fi contact is selected and T-ADS selection policy is configured to retry CS on PS contact failure or time-out. In this case, the timer is used when waiting for 180 response from VoLTE UE on Wi-Fi. If the call setup is either rejected (except 480 caller preferences, do not match) or the timer expires, a secondary call setup attempt is done by breaking out the call to CS.	mtasTadsWiFiNoResponseTimer

3.2.3   GMSC Role and MAP Configuration

This section describes the configuration of a GMSC role in SCC-AS and the associated ETSI MAP interface on SS7 towards HLR. It only applies to the case when SCC-AS is deployed without an interface to HSS (IMS) mtasSccHssDeploymentMode=1, and takes effect when mtasTadsBreakoutPolicy is set to use CS allocated MSRN, 1 or 2. Also, T-ADS service can be configured to support CAMEL users (mtasTadsMsrnCsi=1) and to support Mobile Terminating Roaming Retry (mtasTadsMtrr=1).

3.2.3.1   CSI Administrative State Configuration

The CSI subsystem and GMSC role is enabled by setting the mtasCsiAdministrativeState attribute in the MtasCsi MO to 1 (Unlocked).

If set to 0 (Locked), no GMSC role using MAP is possible in SCC-AS.

Note:  

The selected subsystem numbers must match with the subsystem numbers selected in the SS7 configuration.

3.2.3.2   Configuration Activities for GMSC Role

The configuration activities in CSI needed to define a GMSC role in SCC-AS are listed in Table 2.

Table 2    Configuration Activities in CSI for SCC-AS with GMSC Role

Activity	Attribute
Defines the subsystem number that SCC-AS uses in the SS7 network when SCC-AS has the role of a GMSC.	mtasCsiMapGmscSubsystemNumber
Defines the subsystem number that SCC-AS uses in the SS7 network when addressing HLR.	mtasCsiMapHlrSubsystemNumber
Defines the Global Title Indicator (GTI) that MTAS uses in the encoding of called party address and calling party address in MAP messages.	mtasCsiMapCdGti For called party.
	mtasCsiMapCgCsi For calling party.
Defines the Translation Type (TT) that MTAS uses in the encoding when the GTI (mtasCsiMapGti) is set to 2.	mtasCsiMapCdTt For called party.
	mtasCsiMapCgTt For calling party.
Defines the Nature of Address Indicator (NAI) that MTAS uses in the encoding when the GTI (mtasCsiMapGti) is set to 1 or 4.	mtasCsiMapCdNai For called party.
	mtasCsiMapCgNai For calling party.
Defines the Numbering Plan (NP) that MTAS uses in the encoding when the GTI (mtasCsiMapGti) is set to 3 or 4.	mtasCsiMapCdNp For called party.
	mtasCsiMapCgNp For calling party.
Defines the Encoding Scheme (ES) that MTAS uses in the encoding when the GTI (mtasCsiMapGti) is set to 3 or 4.	mtasCsiMapCdEs For called party.
	mtasCsiMapCgEs For calling party.
Defines the signaling network standard, ITU, or ANSI.	mtasCsiMapSccpStandard

Note:  

The parameters used for Global Title encoding must match with the SS7 configuration in Section 3.2.3.3 Configuring SS7 and MAP. For example, if mtasCsiMapGti is set to 2, then the Translation table for Translation Type as given by mtasCsiMapTt must also be configured in the SS7 stack.

3.2.3.3   Configuring SS7 and MAP

The configuration of the SS7 stack with ETSI MAP, and SCTP is described in MTAS SS7 Management Guide.

3.3   SDS and GSM Compatible SCF Configuration

This section describes the configuration activities for the SDS and GSM compatible SCF.

3.3.1   GSM Compatible SCF Configuration

This section describes the configuration of a GSM compatible SCF in SCC-AS and the associated CAP interface on SS7 towards a gsmSSF.

3.3.1.1   CSI Configuration

The GSM compatible SCF is enabled by setting the mtasCsiAdministrativeState attribute in the MtasCsi MO to 1 (Unlocked). The mtasCsiScfSubsystemNumber attribute defines the subsystem number that the MTAS uses in the SS7 network when the MTAS has the role of an SCF. The subsystem number can only be changed when the CSI subsystem is locked.

Note:  

The selected subsystem number for SCF (mtasCsiScfSubsystemNumber) must match with the subsystem number selected in the SS7 configuration in Section 3.3.1.2 SS7 Configuration.

3.3.1.2   SS7 Configuration

The configuration of the SS7 stack with CAP, and SCTP is described in MTAS SS7 Management Guide.

3.3.2   SDS Administrative State Configuration

The SDS service is enabled by setting the mtasSdsAdministrativeState attribute in the mtasSds MO to 1 (Unlocked). If the mtasSdsAdministrativeState is set to 0 (Locked), no SDS service is provided by the MTAS.

3.3.3   Configuration Activities for SDS Service

The configuration activities for the SDS service are listed in the following subsections.

3.3.3.1   General

The configuration activities general for the SDS service are listed in Table 3.

International access prefix and national trunk prefix attributes are mandatory and must be set here but are only used for conditional anchoring based on local Numbers, see Section 3.3.3.4 Conditional Anchoring Based on Local Numbers and Escape Code.

Table 3    General Configuration Activities for SDS

Activity	Attribute
MO defining an IMRN range.	mtasImrnRange
First number in an IMRN range.	mtasImrnRangeFirst
Last number in an IMRN range.	mtasImrnRangeLast
Attribute that defines the lifetime of an allocated IMRN.	mtasSdsImrnLifetime
Attribute that defines the IMRN prefix to be added to called party for T-SDS.	mtasSdsImrnPrefix
Defines the CAMEL SCF service keys supported by SCC-AS gsmSCF	mtasSdsSupportedServiceKeys
Defines the CAP error handling policy in SCC-AS gsmSCF, to return CAP Continue or CAP error.	mtasSdsCapErrorHandling
Defines the policy for selecting called party number in CAP InitialDP for originating service domain selection calledPartyNumber or calledPartyBCDNumber precedence.	mtasSdsCalledPartyNumberPreference
Attribute that defines the URI schema being used in O-SDS service for ICS MO calls.	mtasSdsUriSchema
MO defining served HPLMN, key=MCC.MNC(1)	mtasSdsServedHplmn
CC of served HPLMN.	mtasSdsServedHplmnCc
International access prefix at served HPLMN.	mtasSdsServedHplmnIntlAccessPrefix
National trunk prefix at served HPLMN.	mtasSdsServedHplmnNationalTrunkPrefix

(1)  This must be configured to handle MO cases where calling or called party number is not international.

3.3.3.2   Conditional Anchoring Based on Supported Media Call Types

The configuration activities for a conditional anchoring depending on supported media call types are listed in Table 4.

Table 4    Configuration Activities for Conditional Anchoring Based on Supported Media Call Types

Activity	Attribute
Enable the check for media call.	mtasSdsDynamicMediaCallType
List of media call types supported by SCC-AS gsmSCF.	mtasSdsSupportedMediaCallTypes
Default video type.	mtasSdsDefaultVideoType

3.3.3.3   Conditional Anchoring Based on Roaming Service Profiles

The configuration activities for a conditional anchoring depending on roaming service profiles are listed in Table 5.

Table 5    Configuration Activities for Conditional Anchoring on Service Profiles

Activity	Attribute
Enable the check for service profile.	mtasSdsDynamicServiceProfile
MCC.MNC for HPLMN served by SCC-AS.	MtasSdsServedHplmn
Mapping from SCF service key to Service profile.	mtasSdsServedHplmnServiceProfileMap
Service Profile defining if anchoring is allowed or not.	MtasSdsServiceProfile
Anchoring indication for a Service profile.	mtasSdsServiceProfileRoamingAnchoringIndication
Reference to a VPLMN whitelist for the Service profile.	mtasSdsServiceProfileWhiteListRef
Whitelist name.	MtasSdsWhiteList
Defines the VPLMNs from which IMS anchoring is allowed for this whitelist.	mtasSdsWhiteListVplmnList

3.3.3.4   Conditional Anchoring Based on Local Numbers and Escape Code

The configuration activities for a conditional anchoring depending on local numbers and escape code are listed in Table 6.

Table 6    Configuration Activities for Conditional Anchoring on Local Numbers and Escape Code

Activity	Attribute
Country Code (CC) of served HPLMN.	mtasSdsServedHplmnCc
International access prefix at served HPLMN.	mtasSdsServedHplmnIntlAccessPrefix
National trunk prefix at served HPLMN.	mtasSdsServedHplmnNationalTrunkPrefix
List of local numbers at served HPLMN. A range consists of all numbers starting with the configured prefix number, max 12 digits.	mtasSdsServedHplmnLocalNumbers
Escape code for the served HPLMN.	mtasSdsServedHplmnEscapeCode
Escape code allowed when at home.	mtasSdsServedHplmnEscapeCodeInHomeAllowed
MCC.MNC for a VPLMN.	MtasSdsVplmn
Country Code (CC) of a VPLMN.	mtasSdsVplmnCc
International access prefix at a VPLM.	mtasSdsVplmnIntlAccessPrefix
National trunk prefix at a VPLMN.	mtasSdsVplmnNationalTrunkPrefix
List of local numbers at a VPLMN. A range consists of all numbers starting with the configured prefix number, max 12 digits.	mtasSdsVplmnLocalNumbers

3.4   VoLTE Versus 2G/3G Configuration

This 2G/3G configuration is described in the following subsections.

3.4.1   Mix of VoLTE and 2G/3G

The VoLTE case name (mtasSubsDataVolteCaseName) is configured in SCC-AS to be used to distinguish a call to VoLTE subscriber from call to 2G/3G subscriber. See Section 2.4.5 Deployment Supporting Mix of 2G/3G and VoLTE Subscribers for a description of the feature.

This option is achieved by setting the attribute mtasSubsDataRegistrationMode in the MtasSubsData MO to the value of 2 (No Register Mode).

3.5   Network Provided Location Information Retrieval Configuration

The attribute mtasSccNpliOriginating defines the policy for originating NPLI retrieval in SCC-AS on incoming INVITE without valid CGI/ECGI in network PANI.

The attribute called mtasSccNpliTerminating defines the policy for terminating NPLI retrieval in SCC-AS on incoming 18x/200 response on (RE-) INVITE without valid CGI/ECGI in network PANI.

3.6   Caching of Registered Contacts Information Configuration

The attribute mtasSubsDataCacheContactData in the MtasSubsData MO defines whether to enable or disable caching contact data for device handling in MTAS. This attribute must be enabled for SCC-AS to be able to fetch the Contact Data from the third-party REGISTER request.

UE terminal type classification ("mobile" or "fixed") during third-party registration and processing of "reg" event notification for caching Contact Data purpose can be based on either registered contact's feature tags or P-Access-Network-Info (PANI) header. Feature tags, being the basis for device mobility classification as mobile (VoLTE), are configurable by mtasSubsDataMobileClassification attribute. If it contains at least one entry, the classification is based on feature tags listed in this CM attribute only, without taking P-Access-Network-Info header into account. Otherwise, that is, if this setting is empty (default value), a device is classified as "mobile" based on the P-Access-Network-Info header indicating 3GPP GERAN, 3GPP UTRAN, or 3GPP E-UTRAN access, and if P-Access-Network-Info header is absent - based on presence of +g.3gpp.ics="server", or +g.3gpp.accesstype="cellular", or +g.3gpp.accesstype="wlan" feature tag. If none of the above conditions is fulfilled, a device is classified as "fixed" by default.

4   Performance Management

For measurements related to the ICS functions for the SCC-AS, refer to Managed Object Model (MOM).

5   Fault Management

For alarms related to the ICS functions for the SCC-AS, refer to MTAS Alarm List.