|
What are SCC-AS services?
The SCC-AS is a home network element that enables three main functions: |
Sentinel SCC is compliant with GSMA IR.64 (v12.0) IMS Service Centralization and Continuity Guidelines.
IMS Centralised Services (ICS) support
True ICS rely on either enhanced handsets (ICS UEs) or enhanced MSC Servers (e-MSS).
The ICS approach stated in GSMA IR.64 is based on the e-MSS, and therefore ICS UEs are not currently considered in Sentinel VoLTE. However this support can easily be added to the solution.
Sentinel VoLTE currently supports a non-ICS enhanced solution based on a combination of existing CS services within the MSC, and CAMEL based routing of CS-originated calls into IMS, as described in GSMA IR.64.
This is shown in the diagram below.
In this diagram:
-
The UE attempts a CS originated call.
-
The MSC VLR sends an InitialDP to the IN SCP function in Sentinel VOLTE, which then returns an IMS Routing Number (IMRN).
-
The CS network uses the IMRN to route towards the IMS.
-
The IMS network then routes the call based on the IMRN contained within the Request-URI of the SIP INVITE.
-
The SCC-AS correlates the SIP INVITE with the received InitialDP.
-
The SCC-AS generates an IMS session on behalf of the CS user.
This mechanism can be considered as “network-facilitated” ICS.
Terminating Access Domain Selection (T-ADS)
For sessions that terminate in the IMS domain, the SCC-AS is responsible for deciding whether to route the session to the CS network or the PS network — depending on registration, network characteristics, and subscriber preferences. This is called T-ADS.
Out of the box, Sentinel VoLTE supports a standard algorithm for T-ADS, which is fully extensible and customisable by a third party:
-
Sentinel VoLTE optionally performs a Diameter Sh lookup on the HSS to determine “IMS voice over PS Session Supported Indication”
-
The Circuit Switch Routing number is formed through either querying the HSS for the Correlation MSISDN (C-MSISDN), or the HLR for the Mobile Station Roaming Number (MSRN)
-
The third-party registration state is also examined, in order to determine subscriber state.
In addition to the standard T-ADS algorithm, Sentinel VoLTE supports different strategies for routing signaling towards PS or CS domains. These include:
-
Support for flexible sequential routing. Sentinel VoLTE can send INVITEs towards the PS or CS domains in either order (PS first, or CS first).
-
Support for routing towards a single domain only (either PS only, or CS only).
-
Support for parallel routing. Sentinel VoLTE initiates a Parallel Fork, sending INVITE messages towards the PS and CS domains simultaneously. The selected access network depends on received responses.
For further details refer to the Terminating Access Domain Selection Features section of the Administration Guide.
Computing the Circuit Switched Routing Number
The Circuit Switched Routing Number (CSRN) is generated by retrieving either the C-MSISDN from the HSS, or the MSRN from the HLR, and adding a routing prefix to it. When fetching the C-MSISDN from the HSS an “Sh-Pull” is used. Alternatively if requesting the MSRN from the HLR a “Send Routing Information” operation is used.
-
The SCC-AS optionally uses an “Sh-Pull” operation towards the HSS requesting the “IMS voice over PS Session Supported Indication”
-
The SCC-AS uses the retrieved information to determine where to route the call, depending on the algorithm described above. In case the session needs to be routed to CS, the SCC-AS re-targets the session to the CSRN — in other words, the Request-URI of the INVITE is now the CSRN.
The Circuit Switched Routing Number (CSRN) is used to force the S-CSCF to invoke the BGCF, which in turn directs the session towards an appropriate MSC-S/MGCF entry point to the CS network. When the SCC-AS changes the Request-URI to the CSRN, the S-CSCF will halt iFC processing and attempt to locate the new Request-URI target. Since the CSRN is not an IMS identity, the BGCF is used to route towards the CS domain.
Sentinel VoLTE contains configuration such that the MSRN and/or C-MSISDN for a subscriber is able to be fetched upon initial registration. It is then stored into Sentinel Registrar data storage.
During INVITE processing, Sentinel Registrar data storage is consulted. If it contains an MSRN, or C-MSISDN, the Registration time value is used. If there is no MSRN or C-MSISDN available in the Registration Data store, the HLR or HSS are consulted during INVITE processing prior to computation of the CSRN.
The OC-Terminating-Domain Header
The Sentinel VoLTE T-ADS implementation inserts a header in all provisional and success responses to an initial INVITE. This header provides information about the terminating access domain for the response. This allows systems "upstream" of the SCC-AS to alter their charging, if required.
OpenCloud’s MMTel-AS and IM-SSF include behaviour to alter charging if the terminating domain is PS=WLAN (WiFi access).
For further details of this header refer to the T-ADS section of the Sentinel VoLTE Administration Guide.
Extensibility
The Sentinel implementation of T-ADS is split into three features — a centralized decision, and two routing features. This approach coupled with the Sentinel feature-based implementation model allows operators to replace or augment default processing. In addition, the CSRN is calculated in a flexible way meaning that different "sources" for the CSRN can be used to compute the CSRN.
For example,
-
Route a terminating call to CS based on the decision taken for a previous call, in order to reduce HSS traffic.
-
Route a terminating call to CS if the subscriber is on PS but PS coverage in that location is deemed inadequate.
-
Route a terminating call to PS and CS simultaneously and select the network with best media offer.
Sentinel provides access to T-ADS context and TAS capabilities such as database queries, signalling queries, and cache access, enabling custom algorithms to be built easily.
Service Continuity and Access Transfer
Sentinel VoLTE supports enhanced Single Radio Voice Call Continuity (eSRVCC — from 3GPP Rel 10); providing bi-directional transfer of sessions between the IMS packet-switched and GSM circuit-switched networks. This mechanism relies on the presence of an ATCF (Access Transfer Control Function) in the operator’s network.
ATCF and ATGW were introduced as an enhancement to the base SRVCC specification as a means to localise media transfer. Previously, the new SDP offer from the MSC-S/MGCF had to be negotiated hop-by-hop to the remote UE, which incurred a delay. Using the ATCF, which architecturally sits in the Serving/Visited network — alongside the MSC-S/MGCF — normally entails a single hop of SDP Offer/Answer, which represents a significant optimisation of the session transfer.
-
The UE measurements indicate the LTE coverage is fading and CS coverage is becoming dominant. At this point the MME begins SRVCC procedures with the MSC-S.
-
The MSC-S/MGCF initiates a session towards IMS, using the Session Transfer Number for SRVCC (STN-SR), which resolves to the ATCF.
-
The ATCF uses the subscriber identity in the P-Asserted-ID header to identify the target session.
-
The ATCF informs the SCC-AS that a session transfer has occurred. The SCC-AS is addressed using an eSRVCC specific SIP URI known as an ATU.
-
If required, the remote end is updated.
Currently, Sentinel VoLTE supports PS to CS transfer of sessions in the following cases:
-
a single active session with media anchored in the ATGW
-
a single active session with media not anchored in the ATGW
-
a single alerting session
-
a single originating session in the pre-alerting state
Other sessions for a transferring device’s C-MSISDN are treated as superfluous sessions.
Service Continuity and Access Transfer in Sentinel VoLTE relies on both Session Tracking, and a Shared ATU-STI.
Features that implement Access Transfer are documented in the Packet Switched to Circuit Switched Access Transfer Features section of the administration guide.
