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 Service Continuity As Base 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, T-ADS 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 T-ADS 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 is indicated as a local number the phone-context is set to the home Country Code of the calling subscriber (from IMSI). In solutions with SCC AS replacing BCS Mobility, there can be cases where the GW node for breakout from IMS does not support Tel URI, then O-SDS can be set to use SIP URI in Request URI and To header in orig call out of the blue (mtasSdsUriSchema=1). In a more specific case with multi-country support but same HPLMN can be mitigated by set O-SDS to use SIP URI without phone-context for local/national calls (mtasSdsUriSchema=2). In the latter case MMTel AS cannot be in the service chain.

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 a 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 T-ADS 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   T-ADS 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.
• If mtasTadsCsBreakoutControl is disabled, CS breakout and CS retry are executed independently of feature tags received from MMTel AS.
• If mtasTadsCsBreakoutControl is enabled, CS breakout and CS retry are executed when feature tags are received from MMTel AS.
• If mtasTadsSuppressCsRetryWhen5G is disabled, then CS breakout and CS retry are executed if a mobile call to user on 5G fails or times out. If mtasTadsSuppressCsRetryWhen5G is enabled, then CS breakout to a user on 5G is suppressed.

2.4.6.4   T-ADS 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.

When mtasTadsCsBreakoutControl is disabled, CS breakout and CS retry are executed independently of feature tags received from MMTel AS.

2.4.6.5   T-ADS 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 or mtasTadsRegionCsrnPrefix) 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).

When mtasTadsCsBreakoutControl is disabled, CS breakout and CS retry are executed independently of feature tags received from MMTel AS.

For 5G mobile terminating calls, CS retry is only available with mtasTadsSuppressCsRetryWhen5G=0 (disabled). When mtasTadsSuppressCsRetryWhen5G=1 (enabled), CS retry is suppressed when a mobile terminating call to 5G fails or times out, even if CS retry is enabled.

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   T-ADS 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.
• If mtasTadsCsBreakoutControl is disabled, CS breakout and CS retry are executed independently of feature tags received from MMTel AS.
• If mtasTadsCsBreakoutControl is enabled, CS breakout and CS retry are executed when feature tags are received from MMTel AS.

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, at session setup and/or session release. 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 180/200 response or the CGI in PANI is not valid.

When NPLI is enabled on session release, NPLI retrieval can be triggered on BYE or 200 OK for BYE coming from the served user, without network provided PANI or CGI 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 or disable offline charging for all originating sessions
• Enable or 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, reregistration, 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 it to 1 denotes deployment without interface to HSS (IMS), which also requires a Service Continuity As Base license.

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.

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.

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.

(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.

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.

Example:

Configuration of Service Profile to anchor calls according to whitelist with roaming partners (OP1,OP2)

Prerequisite to include supported ServiceKey's used in CAP IDP from OP1 (5001) and OP2 (5002) mtasSdsSupportedScfServiceKeys=5001,5002.

1. Configure the roaming partners VPLMN,

   MtasSdsVplmn="MCC.MNC[OP1]"

   MtasSdsVplmn="MCC.MNC[OP2]"

2. Whitelist with the allowed VPLMNs,

   MtasSdsWhiteList="OP1_and_OP2"

   mtasSdsWhiteListVplmnList="MCC.MNC[OP1]", "MCC.MNC[OP2]"

3. Service Profile with reference to the OP1/OP2 whitelist,

   MtasSdsServiceProfile = "SP_OP1_and_OP2"

   mtasSdsServiceProfileRoamingAnchoringIndication=2 (ACCORDING_TO_WHITELIST)

   mtasSdsServiceProfileWhiteListRef= "OP1_and_OP2"

4. Served HPLMN with mapping from service keys used in CAP IDP (5001 and 5002) from OP1 and OP2, to the service profile "SP_OP1_and_OP2"

   mtasSdsServedHplmnServiceProfileMap=(5001, "SP_OP1_and_OP2"), (5002, "SP_OP1_and_OP2")

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.

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. If the attribute mtasSccNpliOriginatingOnSessionRelease is set to 1 (enabled), the same policy applies for NPLI retrieval on session release.

The attribute mtasSccNpliTerminating defines the policy for terminating NPLI retrieval in SCC AS on incoming 180/200 response on INVITE, or re-INVITE, without valid CGI/ECGI in network PANI. If the attribute mtasSccNpliTerminatingOnSessionRelease is set to 1 (enabled), the same policy applies for NPLI retrieval on session release.

When NPLI retrieval is enabled on session release, SCC AS can trigger NPLI retrieval on BYE or 200 OK for BYE coming from the served user.

Note:  

It is recommended to set the attribute mtasChargingProfileReportAtDisconnection to 1 (TRIGGER_ON_BYE_OR_BYE_RESPONSE) in the SCC AS charging profile assigned to the subscribers.

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 are fulfilled, a device is classified as "fixed" by default.

3.7   Multiple Mobile Behavior Configuration

The Multiple Mobile behavior in SCC AS is decided by the CM attribute mtasSccMobileBehaviour. This attribute specifies the charging and call behavior for the mobile devices. If this attribute is set to MOBILE_ENHANCEMENT_ON, SCC AS sends mobile device information in Subscription-id AVP in charging and provides seamless call experience for all mobile devices for subscriber. If T-ADS is enabled, T-ADS delivers call to CS, PS, or CS with breakout access domain of mobile device identified based on the impi and cs subscription capability, present in the Accept-Contact header of incoming INVITE.

4   Performance Management

For measurements related to the ICS functions for the SCC AS, refer to MTAS Performance Measurements.

5   Fault Management

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