Sentinel VoLTE Architecture

This document is intended for:

Find out here about:

Rhino Sentinel delivers complete suites of fully-featured telecom applications for GSM (Sentinel Express) and VoLTE (Sentinel VoLTE) networks. And, unlike other solutions, Rhino Sentinel is completely open. It allows customers and their partners to extend and complement the application set using Sentinel Create, to go beyond the plain vanilla — quickly, cost-effectively, and safely.

The Sentinel VoLTE solution implements the Multimedia Telephony Application Server (MMTEL-AS) and the Service Centralisation and Continuity Application Server (SCC-AS) on the Rhino TAS. It includes built in support for multiple Charging systems.

The main benefits of the solution are:

The OIP service provides the terminating user with the possibility of receiving trusted (network-provided) identity information in order to identify the originating user.

The OIR service is a service offered to the originating user that restricts presentation of the originating user’s identity information to the terminating user. Both permanent and temporary modes are supported.

This service is implemented by the features:

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving trusted information in order to identify the terminating party.

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the terminating party to prevent presentation of the terminating identity information to the originating party. Both permanent and temporary modes are supported.

This service is implemented be the features:

The Communications Diversion (CDIV) service enables the diverting user to divert the communications addressed to the diverting user to another destination. This includes the following services:

The CDIV service also checks and adds to the SIP history-info header as required, for example to determine if the diversion limit has been exceeded.

This service is implemented by the feature MMTelCDIV.

The Communication Hold supplementary service enables a user to suspend the reception of media stream(s) of an established IP multimedia session, and resume the media stream(s) at a later time.

This service is implemented by the feature MMTelHold.

The Communication Barring (CB) service offers the following services:

The following conditions are supported:

These services are implemented by the features:

The Operator Determined Barring (ODB) is not part of GSMA IR.92, but we include it here because it is related to barring conditions. ODB conditions are evaluated by the following services:

Note 1: The indication of a "Premium Rate Communications Information or Entertainment" is defined on TS 24.315 Release 12.1.0 on Section 3.1:

For more information see Operator Determined Barring.

The Explicit Communication Transfer (ECT) service enables a transferor to transfer the call to a transfer target. The Explicit Call Transfer service uses 3PCC Call Transfer Procedures in case the transferee can not handle the transfer request. There is more discussion of this service in the Explicit Communication Transfer page.

This service is implemented by the feature MMTelECT.

The Communication Waiting (CW) service enables a terminating party to be informed at the time that a new communication is requested. The user then has the choice of accepting, rejecting, or ignoring the incoming communication.

This feature is implemented by the feature MMTelCW.

Sentinel VoLTE supports three party conferencing (3PTY) as part of this service. The following operations are supported:

This service is implemented by the features:

There are two scenarios in which a transfer can be initiated:

Consultative ECT using the 3pcc procedure does not support reusing the existing leg between the AS and the transfer-target, instead a new leg is created to link to the transferee.

Under certain circumstances the standard signalling flows may be interrupted and the feature will set up the new dialogue using Third Party Call Control (3pcc) procedures.

For feature details see MMTelECT.

VoLTE creates several instances according to which user the AS is serving. Those instances could also be spread across multiple nodes depending on the production environment. For simplicity we consider the transferor, the transferee and the transfer target being served by the same node and some IMS core elements are not shown.

The diagram below shows the MMTel instances when a communication transfer happens among A, B and C, where A is the transferor, B is the transferee and C is transfer target.

When A initiates a dialog towards B, the INVITE request traverses the IMS network until it reaches the S-CSCF serving the user. The S-CSCF based on the registration data and the iFC in HSS forwards the messages to the VoLTE AS serving as MMTel AS. On receiving the INVITE request, the AS creates a session to process the call (A-orig) and apply the business rules including the MMTel services. After applying the business rules the AS forwards the INVITE request towards S-CSCF according to the B2BUA procedures.

The S-CSCF identifies a terminating call for B and forwards the signalling to AS again after checking the registration records for B and determining the AS serves B. This time the AS will create another session to deal with the call (B-term). This session will apply the business rules for the terminating call for B.

Now A and B are in communication. When A, acting as transferor, sends a SIP REFER message to B to refer to C, the ECT feature running in the A-orig instance changes the Refer-to-target header to a generated URI (ECT URI) and stores the information in the database. This change occurs to maintain the AS in the signalling path. The REFER message traverses all the existing instances until it reaches the B party. When B receives the REFER message, it initiates a new dialog towards the generated ECT URI.

The INVITE request sent by B creates a new MMTel instance for B originating (B-orig), that will apply the proper business rules for this session. When the INVITE request reaches the AS again, a terminating instance is created (ect-term in the picture). This instance will change the ECT URI to the proper target destination stored in the database and send the INVITE request towards C. On receiving the INVITE request for C, the S-CSCF determines that C is served by the same AS and so forwards the INVITE request to the AS. When the AS receives the INVITE request to C, it creates a terminating instance for C (C-term). This instance will apply the business rules for this terminating call and forward the INVITE request to C. C accepts the call and eventually the call session between A and B will finish.

The diagram below is similar to the one above, but B is the transferor, A is the transferee and C is transfer target.

For this scenario, when B sends a REFER to A to refer to C, the new ECT URI is generated on the B-term instance. When A sends the INVITE to the ECT URI, a new instance is created for A (A-orig'). The signalling then proceeds identically to the previous example.

The indication that the Explicit Communication Transfer service was triggered is present on the charging procedures (Online charging and CDR generation). The MMTel-SService-Type AVP set to 20 indicates the ECT service was used. This information is set on the instances where possible to identify the ECT service: A-orig, ect-term and B-term when acting as transferor.

The MMTel-SService-Type AVP is present in MMTel-Information AVP. For more information see Populated AVPs in the MMTel-Information AVP.

3GPP defines Flexible Alerting in TS 24.239 and the flexible alerting subscriber data schema is defined in TS 24.239 and TS 29.364. The service allows the creation of a group, composed by members, bounded by a single number, called Pilot Number. When a call to the Pilot Number is identified VoLTE will alert all the members of the group and the caller is bounded to the first member of the group that answers the call.

The group of identities that may be contacted by the Flexible Alerting feature is called the FA Group.

There can be two types of FA Group:

These groups have different rules for dealing with SIP responses.

For single-user

For multiple-users

There are two alerting modes for FA. These are:

In the sequential alerting mode the group members are alerted in order, with one member sending a final response or timing out before the next is alerted. In the parallel alerting mode all group members are alerted at once.

Flexible Alerting allows the call to continue after final responses on one or more group members.

OpenCloud’s Flexible Alerting supports both Parallel or Sequential alerting mode by a configuration under MMTelDetermineFAConfigProfileTable. The configuration table can be accessed through REM and is specified using the MMTelDetermineFAConfigProfileTable profile table name. The feature profile is scoped by the sentinel key and the pilot number, meaning that each Pilot Number requires a profile, otherwise VoLTE will fallback to a default profile not scoped by the Pilot Number.

A subscriber with 2 registered devices (UE1 and UE2) under the same IMPU makes a call to another device B from UE1. Once the call between UE1 and B is established, the subscriber can use the registered UE2 to pull the call to that device. The user calls a special URI previously configured in the AS (see DetermineVoltePlanId). The AS will verify the called URI is a Session Transfer to Own Device URI service and pull the call to the UE2. The UE1 will be disconnected as soon as the session between UE2 and B is established.

The service also works for the terminating case, which means that the subscriber B receiving a call can also use another registered device (B') under the same IMPU to pull the call.

The flow below shows a basic call flow with a simple transfer.

The service is composed of several features:

The interactions among the features are show below:

The DetermineVoltePlanId sets the session to mmtel and also checks if the request URI is for the STOD service.

MMTelStodEnableSessionTracking creates an external tracking key for the session and adds it to the set in session state.

The TrackSessionPreAnswer feature is used to process the session tracking information from session state.

The MMTelStodEnabled checks its profile to assert that the user is allowed to trigger the service and if allowed the the MMTelStodEnableSessionTracking will set the proper procedures to make the session to be tracked and the MMTelStodBind feature will bind the session to an ACI name.

This ACI name will be reconstructed by the MMTelStodDetermineTargetSession feature on receiving a transfer INVITE and the MMTelStodTriggerAnchor will route the transfer INVITE to the existing session.

The MMTelStodProcessHandover intercepts the transfer INVITE and do the procedures to connect the existing called party to the new calling party.

Support of multiple OCSs is a key requirement for the session control element, for several reasons:

Sentinel is designed to provide session control on behalf of multiple OCSs. Sentinel determines which OCS to send the charging messages to in real time at session initiation. Different schemes may be utilised to determine the correct OCS. For example, it might be done by subscriber location, or attached network, or a real-time lookup to an external real-time database, or based on the APN used by the subscriber.

In the middle of a SIP session, media streams may be added and removed, as well as having their codecs changed. When codecs change, Sentinel VoLTE consults its SDP codec configuration to determine if the change was a “meaningful” change from a charging perspective (for example, if an audio call was changed to an audio and video call).

If a change is deemed meaningful, Sentinel performs client-initiated re-authorization towards the Online Charging System. If a change is not meaningful, the current credit reservation remains valid. This is explained in more detail in the Charging support section.

Rhino Sentinel writes a CDR for all charging session attempts, whether the session was successfully completed or could not be completed due to some error.

CDRs generated by Sentinel may also be used for offline charging situations.

The CDRs are written to a file in a configurable location and contain all the parameters that are available to the Rhino Sentinel. More detail on Sentinel VoLTE CDRs can be found in the Charging Information section of the Sentinel VoLTE Administration Guide.

VoLTE sends charging information to a configured Charging Data Function via Diameter Rf interface. The charging messages contain all information necessary to charge a session and VoLTE supports the Start, Interim and Stop messages as just and event message.

The Rf Control Resource Adaptor receives request from VoLTE charging features and ensure the messages are persisted in the CDF or in a local disk buffer is case the CDF is not available. As soon as the CDF is available it will send the messages stored locally until the buffer is empty.

For more information see Rf Control Resource Adaptor Architecture.

Sentinel VoLTE can be installed to use a Prepaid Service Control Point as the OCS, rather than communicating via Diameter Ro to the OCS. The use of Ro, CAP or neither for online charging is enabled through the Selection of charging mode. In all cases, Sentinel VoLTE will write a CDR for the session.

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:

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:

In addition to the standard T-ADS algorithm, Sentinel VoLTE supports different strategies for routing signaling towards PS or CS domains. These include:

For further details refer to the Terminating Access Domain Selection Features section of the Administration Guide.

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.

Currently, Sentinel VoLTE supports PS to CS transfer of sessions in the following cases:

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.

In the diagram below, the components OpenCloud provides are in green.

VoLTE includes the ‘session processing’ parts:

It provides web-server based infrastructure for:

It also provides Online Charging Support by either using the Ro interface or CAP interface with IM-SSF Protocol Translator and Offline Charging Support via Rf interface and CDRs. For more information see the Charging Support.

The diagram below shows where Sentinel VoLTE fits into an LTE network.

The B2BUA architecture includes:

VoLTE supports either HSS or HLR for storing Subscriber Data. The data from the HLR and HSS is normalized in VoLTE and used by MMTEL and SCC services. This means that the Operator can use either data source without changing the service logic.

The subscriber’s supplementary services data is stored in the HSS as transparent data. Sentinel VoLTE TAS queries the HSS via the Sh interface to read and store the data.

The data is stored in XML format and can have the standard service data and extensions or even proprietary data sets.

The Media Resource Function (MRF) is responsible for providing multimedia-related functions, such as mixing of streams of audio and audio/video conferences, controlling Interactive Voice Response (IVR) sessions, and playing back multimedia.

The MRF can be invoked by single-purpose protocols, such as NETANN, when the TAS does not need to have further control of the session. This is useful for actions such as post-call announcements where the TAS hands over the control of the session to the MRF. The single-purpose protocols can be used together with the VoiceXML protocol to specify the interaction script that the MRF executes for the call (TAS forwards the SIP INVITE message with the VoiceXML URI in a SIP URI parameter).

For more complex scenarios, the TAS uses other XML-based protocols to control the MRF, such as MSML. The TAS forwards the SIP INVITE with the SDP information to the MRF. The MRF establishes a RTP stream with the UE. After that, the TAS sends MSML documents inside SIP INFO messages with the actions that MRF should execute (for example, play announcement).

Sentinel VoLTE supports NETANN and the MSML interface. A H.248 interface is not supported, so the MRF is expected to provide both the MRFC and MRFP elements.

An MRF is not included within Sentinel VoLTE; however, Rhino TAS has been integrated multiple times with MRFs and media servers from all major vendors (including RadiSys, Dialogic, and Alcatel-Lucent).

Sentinel VoLTE is well-suited to cloud deployment. Find out more at the cloud and virtualisation page.

The following diagram illustrates Sentinel VoLTE’s XCAP architecture within the IMS:

Sentinel VoLTE supports the use of XCAP over HTTP. The diagram above shows this as MMTEL-AS and Other-AS — not as an AP in the IMS architecture.

Sentinel VoLTE’s XCAP server support requires that the Ut/HTTP Requests have passed through a separate Authentication Proxy (not provided by the Sentinel VoLTE product) before reaching the XCAP server. OpenCloud provides an implementation of the Authentication Proxy (Ut interface) in the Sentinel Authentication Gateway product.

The Sentinel XCAP server is a layer on top of the existing provisioning services and runs alongside the Sentinel REST machine API. XCAP is defined using REST principles and uses much of the same technology as the Sentinel REST API. It can be co-deployed with the Sentinel REST Provisioning API, and web human user interface, like this:

3GPP defines the SCC-AS as the first TAS invoked in the originating iFC treatment, and the last in the terminating iFC treatment. The following diagram illustrates having just the SCC-AS and the MMTEL-AS as the only two TAS invoked for a session, and using MMTEL for both originating and terminating treatment:

Rhino Sentinel VoLTE implements both the SCC-AS and the MMTEL-AS. The session includes four “back-to-back user agent” instances:

OpenCloud supports co-location of the Sentinel instances in the same cluster, and even Unix process/JVM instance. This means the S-CSCF does not need to be configured for iFC trigger chaining (as shown above). This is an optional configuration:

The following image shows the three key types of charging instances. Each is a Sentinel VoLTE B2BUA.

The diagram shows the three key concepts:

Forwarded Sessions may be forwarded, and then forwarded, and so on, infinitely. To stop infinite forwarding, the History-Info header is used.

MMTEL’s CDIV Service (a feature in Sentinel VoLTE) is responsible for stopping infinite forwarding.

Let us assume that Online Charging is used for every session:

Therefore, each Instance is creating Online Charging requests. So for a session that is forwarded once, and only once, and answered, the OCS will see four sessions:

In the Terminating case — typically if the B party is not roaming — then the B party is often not charged.

In order to disable Online Charging for the B-parties Terminating Instance (for example, when not roaming), you can:

All instances within a network can be tied to the same “real world session” through the IMS Charging Identifier (ICID).

Under the SIP protocol, media streams may be added and removed, as well as having their codecs changed.

When codecs change, Sentinel may consult its SDP codec configuration to determine if the change was a “meaningful” change from a charging perspective.

Below is a screen showing Sentinel VoLTE’s default codec configuration:

Codecs in the same equivalence class are treated as “equivalent” from a charging perspective; so changes between codecs in the same class do not cause client-initiated re-authorization.

The table in the image above can be found by navigating through REM to Management ▶ Profiles and scrolling to select “SdpMediaCodecProfileTable”. This table can be edited, and new codecs and equivalence classes introduced.

Sentinel VoLTE has support for allowing sessions to terminate in WiFi networks (Voice over WiFi). When a session is answered, the Terminating Access Domain Selection (T-ADS) Features on the SCC AS will analyse the response to determine the type of network that the call is terminating in. Once the network type has been determined, the T-ADS features will attach a proprietary header to the response before forwarding it upstream. This header is called the OC-Terminating-Domain Header, and when a session is answered over a WiFi network, the header will be given the value PS=WLAN.

When Sentinel VoLTE is configured to use online charging this header will be consumed at the MMTel AS serving the terminating user. A feature on the MMTel AS called MMTelWifiChargingFinalisation will read the header and, if the value matches PS=WLAN, the feature will issue an instruction to any active online charging instances to finalise charging for the terminating user, before stripping the header from the upstream forwarded response. When Sentinel VoLTE is not configured to use online charging, the header will not be stripped by the MMTel AS. This allows it to be read by upstream charging functions.

The IM-SSF contains support for the OC-Terminating-Domain header. It terminates the IN dialog towards the Prepaid SCP if it is processing a terminating session, and the terminating 2xx response to the INVITE contains the OC-Terminating-Domain header with value PS=WLAN. In this case it strips the header before forwarding the 2xx response upstream.

The Rf Control Resource Adaptor allows VoLTE to persist offline charging information in the Charging Data Function (CDF). The principle is the same as writing a CDR, but instead of storing the information in a local disk, the call detailed records are sent via Diameter Rf interface to any CDF connected.

The AVPs that are populated on the Diameter Rf interface are documented on the Rf Interface AVPs section of the Sentinel VoLTE Administration guide.

For more information on Rf Control Resource Adaptor see Rf Control Resource Adaptor Architecture.

The AVPs that are populated on the Diameter Ro interface are documented on the Ro Interface AVPs section of the Sentinel VoLTE Administration guide.

All components that need access to any data from the HSS, including both transparent data and non-transparent data, access it through the Sh Cache component.

This includes:

For more information on Sh Cache Resource Adaptor see Sh Cache RA architecture.

All components that need access to data from the HLR, access it through the CGIN MAP component.

This includes:

For information about the components that use the HSS and/or HLR for accessing supplementary Service Data refer to Supplementary Service Data Access

All components that need access to any data from the HSS, including both Transparent and Non-transparent data, access it through the Sh Cache component. Components that use Supplementary Service Data in the HSS include:

For more information about the Sh Cache Resource Adaptor see Sh Cache RA architecture

All components that need access to data from the HLR, access it through the CGIN MAP component. Components that use Supplementary Service Data in the HLR include:

The Sentinel VoLTE SCC-AS may detect SDP conflicts when forwarding SDP between a pair of legs on a session. This capability is currently only enabled in access transfer features. Other features may also access it through the sentinel-sip-spi API, see Using SDP conflict management in a feature below.

Conflicts arise when there is an existing media session established, and the SCC-AS receives an SDP offer from another source, that must replace the existing media. The new SDP offer must use the correct session ID and version, as well as having the same number of media (m=) lines that the previous offer had, otherwise the new offer will be rejected. If the new offer comes from a different entity to the previous offer, then there will almost certainly be a conflict. This situation occurs in many access transfer scenarios.

The conflict management system is defined in terms of source and destination legs:

When a feature detects that SDP conflict management is required, it sets up an SDP rewriting association between the source and destination legs. Classification of source and destination is up to the feature, but for access transfer cases, "source" means the new access leg, and "destination" means the remote leg.

When the SDP association is created, Sentinel VoLTE determines a set of transformations that apply the appropriate changes to the SDP, based on the previous and new SDP offers. The possible types of transformations are described in SDP conflict types below. From this point, for the remainder of the session, SDP rewriting is performed in both directions automatically, by the SDPRewriter system feature.

When performing access transfer, it is sometimes necessary for the SCC-AS to send a new SDP offer so that the remote party can handle the new media streams, enabling session continuity. The SCC-AS must ensure that any new SDP offer is compatible with previous SDP offers sent to the remote party. If not, the remote party UE will reject the new offer, and the access transfer will fail.

The figure below shows an example call between UEs A and B, with the call anchored in the originating SCC-AS. UE-A initially requests audio and video streams. For brevity assume both streams are accepted by UE-B (SDP answer not shown).

UE-A moves out of coverage range, triggering a PS-CS access transfer. The access transfer INVITE sent by the ATCF has different content to the previous SDP offer from A. This may be because the media was not anchored in the ATGW, so the ATCF must send a completely new SDP offer to the SCC-AS.

The SCC-AS can see that the new offer is different to the previous one; the session IDs and versions differ, and also there is only one media description (no video). The SCC-AS must perform a remote update re-INVITE with UE-B, so that UE-B knows about the media change.

If the SCC-AS just sent the new SDP offer to UE-B verbatim, UE-B would have to reject it, because the offer uses a different session ID (45678, not 12345), and the version is out of sequence. UE-B would expect the next offer to have session ID 12345 and version 12346 (incremented by one from the previous SDP offer 1).

To resolve this conflict, the SCC-AS adjusts the SDP offer so that it uses the correct session ID and version, and also sets the video media description’s port to zero so that UE-B knows it is no longer in use (media (m=) lines in SDP cannot be removed during a session, only changed or added).

With the adjusted SDP offer 2a, UE-B can process it correctly, switching to the new audio stream and stopping the video stream. Conversely when the SDP answer 2a arrives at the SCC-AS, the disabled video media description must be removed. This is so that the number of media descriptions in the answer matches what was in the ATCF’s original SDP offer 2.

The new media is now established between UE-A and UE-B, so the call can continue, with audio at least.

The Sentinel VoLTE SCC-AS handles most types of SDP conflicts that may occur when using access transfer, as described below.

A feature may enable SDP conflict management for a pair of legs using the SdpRewriting class from sentinel-sip-spi:

This sets up the SDP association between the legs named newAccessLegName and remoteLegName. This association is persisted in session state, and includes the set of transformations to correctly update the SDP in both directions.

The feature does not need to do any more work; the actual processing of the SDP is performed by the SDPRewriter system feature, after user features have run. Over the lifetime of the session, either party may change the set of media descriptions. The SDPRewriter system feature ensures that the SDP transformations are updated accordingly to account for new and updated media descriptions.

A Tracked Session is a session where Session Tracking is enabled. A session can have its tracking enabled at various "points".

These are:

In the case of the SCC-AS, session tracking is enabled for "Confirmed" if the UE is SR-VCC capable. Session tracking is enabled for "Early" and "Confirmed" if there is a terminating attempt and the UE indicates support for alerting access transfer. Session tracking is enabled for "Half dialog", "Early", and "Confirmed" if the SCC-AS is triggered for an originating session, and the UE indicates support for PS to CS SRVCC for originating calls in the pre-alerting state.

A tracked session writes information related to the SIP dialog(s) for the served user. In the case of an originating B2BUA, this is the dialog(s) towards the originating user. In the case of a terminating B2BUA this is the dialog(s) towards the terminating user.

The Cassandra database is used by session tracking due to its high availability, and replication capabilities.

Each site runs a TAS cluster, and a Cassandra cluster. The minimum number of nodes per-site for the Cassandra cluster is three, and for the TAS cluster is two. Each site should essentially repeat this structure.

As the SCC-AS is involved in potentially all originating IMS INVITE sessions, and all terminating IMS sessions, care is taken to reduce the impact of a database failure.

When tracking sessions the TAS uses the following strategies:

The effect of the guard timeout firing is that the user’s session setup can be successful, albeit with a small delay (the guard timer value). However if PS to CS SR-VCC is attempted, the access transfer may fail as when reading from the Cassandra Database the SCC-AS is likely to obtain either:

Session Tracking is implemented by the External Session Tracking Features in the Sentinel VoLTE Administration Guide.