Intended audience

This document is intended for:

  • network architects and engineers selecting and deploying VoLTE infrastructures

  • solution architects defining solutions in the VoLTE space

  • software developers using the Sentinel VoLTE to deliver services and features.

Contents

Find out here about:

Overview

These sections provide an overview of Sentinel VoLTE and its architecture:

Product Overview

Sentinel VoLTE is based on Rhino Sentinel, OpenCloud’s next generation service layer solution that enables genuine service innovation for all types of telecom services.

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.

sentinel volte overview

MMTEL-AS and SCC-AS on the Rhino TAS

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:

  • Provides the essentials for VoLTE — The essential VoLTE services such as MMTel and SCC are available straight out-of-the-box.

  • NFV (virtualised model) — Rhino Sentinel can be virtualised and deployed in a private cloud model, providing more flexible and cost-effective deployment models.

  • Open platform and applications — Built on the Sentinel framework, VoLTE services can be extended and differentiated.

  • No vendor lock-in — You can choose to create new services or extend existing services yourself, with support from the OpenCloud developer ecosystem.

MMTel Services

Note
What does MMTel do?

MMTel (Multi-Media Telephony applications) delivers the core call-control services for voice and video communications, as well as the supplementary services for VoLTE.

Services General information

Rhino Sentinel VoLTE delivers these services in an LTE/IMS network, following the GSMA IR.92 (v9.0) and IR.94 (v10.0) standards.

  • With the exception of Message Waiting Indication (MWI), all IR.92 services are supported within Sentinel VoLTE. Using Sentinel Create, it is possible to extend the feature set to very easily include other services.

  • Anonymous Call Rejection (ACR) is also supported, even though it is not an IR.92 service.

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 of member identities bound to a single number, called the Pilot Number. When a call to the Pilot Number is identified, VoLTE will alert all the members of the group and the caller is bound to the first member of the group that answers the call.

3GPP defines Explicit Communication Transfer in TS 24.629. The service allows a member in a communication dialogue called the transferor to transfer their role in the dialogue to another user called the transfer-target. The member that remains in the dialogue during the transfer is called the transferee.

Is a service that allows an existing originating or terminating session to be transfered to another device. The target device is the one that pulls the session.

GSMA MMTel Supplementary Services

Rhino Sentinel VoLTE delivers these services in an LTE/IMS network, following the GSMA IR.92 (v9.0) and IR.94 (v10.0) standards.

  • With the exception of Message Waiting Indication (MWI), all IR.92 services are supported within Sentinel VoLTE. Using Sentinel Create, it is possible to extend the feature set to very easily include other services.

  • Anonymous Call Rejection (ACR) is also supported, even though it is not an IR.92 service.


Below are details of GSMA required MMTel supplementary services that Rhino Sentinel VoLTE supports.

Originating Identification Presentation/Restriction (OIP/OIR) (3GPP TS 24.607)

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:

Terminating Identification Presentation/Restriction (TIP/TIR) (3GPP TS 24.608)

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:

Communication Diversion (CDIV) (3GPP TS 24.604)

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:

CDIV condition Service behaviour

CFU (Unconditional)

Unconditionally divert communications to a different destination.

CFB (Busy)

Divert communications to a different destination on busy. User-determined busy (UDUB) is supported.

CFNR (No Reply)

Divert communications to a different destination upon no reply. A timer is provided for configuration.

CFNRc (Not Reachable)

Divert communications to a different destination if the original destination is unreachable.

CD (Call Deflection)

Enables subscriber to divert incoming communications to a different destination.

CFNL (Not Logged In/Not Registered)

Divert communications to a different destination if the original destination is unregistered.

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.

Communication Hold (HOLD) (3GPP TS 24.610)

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.

Communication Barring (CB) (3GPP 24.611)

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

Service Behaviour

Incoming Communication Barring (ICB)

Rejects incoming communications that fulfil certain conditions.

Outgoing Communication Barring (OCB)

Rejects outgoing communications that fulfil certain conditions.

Anonymous Communication Rejection (ACR)

Specific case of ICB service, that allows barring of incoming communications from an anonymous originator.

The following conditions are supported:

Condition Result

All incoming

Barring of all incoming communications.

All outgoing

Barring of all outgoing communications.

All incoming when roaming

Barring of all incoming communications when subscriber is roaming outside the home network.

Outgoing International

Barring of all outgoing communications to international destinations.

Outgoing International-exHC

Barring of all outgoing communications to international destinations, except calls to the home country.

Anonymous

Barring of incoming communications when the originator is anonymous.

Media

Barring of communication using specific media.

These services are implemented by the features:

Operator Determined Barring (ODB) (3GPP TS 24.315 and TS 24.041)

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:

Service Behaviour

Incoming Communication Barring (ICB)

Rejects incoming communications that fulfil certain conditions, as specified by the operator.

Outgoing Communication Barring (OCB)

Rejects outgoing communications that fulfil certain conditions, as specified by the operator.

Explicit call transfer (ECT)

Prevent the ECT service from running for the served user.

Condition Result

Barring of All outgoing

Barring of all outgoing communications.

Barring of Outgoing International

Barring of all outgoing communications to international destinations.

Barring of Outgoing International-exHC

Barring of all outgoing communications to international destinations excluding home network.

Barring of Outgoing International when roaming

Barring of all outgoing communications roaming outside the home PLMN country.

Barring of All incoming

Barring of all international

Barring of Incoming International when roaming

Barring of all incoming communications roaming outside the home PLMN country.

Barring of Outgoing Premium Rate Communications Information

Barring of all information communications for subscribers under this category. [Note 1]

Barring of Outgoing Premium Rate Communications Entertainment

Barring of all entertainment communications for subscribers under this category. [Note 1]

Barring of Outgoing Premium Rate Calls Information When Roaming Outside HPLMN Country

Barring of all information communications for subscribers under this category when roaming. [Note 1]

Barring of Outgoing Premium Rate Calls Entertainment When Roaming Outside HPLMN Country

Barring of all entertainment communications for subscribers under this category when roaming. [Note 1]

Barring of Invocation of Communication Transfer

Barring of invocation of explicit communication transfer

Barring of Invocation of Communication Transfer where at least one Leg is charged

Not supported

Barring of Invocation of Communication Transfer where at least one Leg is charged at International Rates

Not supported

Barring of Invocation of Chargeable Communication Transfer

Not supported

Barring of Multiple Invocation of Communication Transfer

Barring of multiple invocation of communication transfer

Barring of Operator Specific Barring Type1

Barring of all calls when the operator defined rules type 1 applies. See Operator Specific Barring Rules

Barring of Operator Specific Barring Type2

Barring of all calls when the operator defined rules type 2 applies. See Operator Specific Barring Rules

Barring of Operator Specific Barring Type3

Barring of all calls when the operator defined rules type 3 applies. See Operator Specific Barring Rules

Barring of Operator Specific Barring Type4

Barring of all calls when the operator defined rules type 4 applies. See Operator Specific Barring Rules

Barring of Roaming outside the HPLMN

Not applicable to the AS. The AS has no procedure to avoid a subscriber from Roaming.

Barring of Roaming outside the HPLMN country

Not applicable to the AS. The AS has no procedure to avoid a subscriber from Roaming.

Barring of Registration of any communication diverted-to address

Not supported on the XCAP server

Barring of Registration of any International communication diverted-to address

Not supported on the XCAP server

Barring of Registration of any International communication diverted-to address Ex-HPLMNC

Not supported on the XCAP server

Barring of Supplementary Services Management

Not supported on the XCAP server

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:

indication that this communication is a Premium Rate Communication: the Request-URI of the received INVITE request includes the " premium-rate" tel URI parameter set to either the value "information" or the value "entertainment".

For more information see Operator Determined Barring.

Explicit Communication Transfer (ECT) (3GPP TS24.629)

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.

Communication Waiting (CW) (3GPP TS24.615)

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.

Ad-hoc multi-party conference (CONF) (3GPP 24.605)

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

Supported Operations Notes

Conference Creation

By sending a SIP INVITE to the conference-factory URI, which is Sentinel VoLTE.

Invite users to the conference

Via a SIP REFER request.

Remove user from conference

Only the conference creator can remove participants from the call.

Terminate conference

The conference is terminated when the conference creator has left the call, or if the conference creator is the only party left in the conference.

Subscribe

Conference users can subscribe to the conference-event package for the information specified in IR.92.

This service is implemented by the features:

Anonymous Call Rejection (ACR) (3GPP TS24.611)

XCAP interface (Ut)

Sentinel VoLTE supports the XCAP interface over the Ut reference point between the UE and MMTEL-AS, as per 3GPP TS24.623.

For more information please refer to the XCAP Support section. For information on the Authorization Proxy please refer to Sentinel Authentication Gateway.

Explicit Communication Transfer

3GPP defines Explicit Communication Transfer in TS 24.629. The service allows a member in a communication dialogue called the transferor to transfer their role in the dialogue to another user called the transfer-target. The member that remains in the dialogue during the transfer is called the transferee.

Communication Transfer Modes

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

  • Consultative Transfer: The transferor has a consultation communication with the transfer target. This allows:

    • Classical charging models

    • Anonymization of the transfer target

  • Blind Transfer: The transferor has no consultative communication with the transfer target

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.

Example Explicit Communication Transfer Call Flows

Note Various IMS core elements and some SIP messages are omitted from the call flow diagrams for the sake of clarity.

Blind ECT

blind ect

Consultative ECT

consultive ect

Instance models inside VoLTE

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.

ect a transferor

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.

ect b transferor

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.

Charging

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.

Out of Scope

Consultative ECT and REFER out of dialog are not supported. To implement such support it is necessary to track all MMTel call sessions in progress along multiple nodes.

Flexible Alerting

What is Flexible Alerting

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 of member identities bound to a single number, called the Pilot Number. When a call to the Pilot Number is identified, VoLTE will alert all the members of the group and the caller is bound to the first member of the group that answers the call.

Group Members

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:

  • single-user

  • multiple-users

These groups have different rules for dealing with SIP responses.

For single-user

  • The Pilot Number is considered Busy when any of the members are busy and no 200 (OK) was received before.

  • The Pilot Number is considered in a state of Not Reachable when all group members are in a state of not reachable.

  • The Pilot Number is considered in a state of No Reply when all group members are in a state of no reply.

For multiple-users

  • The Pilot Number is considered Busy when all group members are busy.

  • The Pilot Number is considered Not Reachable when all group members are not reachable.

  • The Pilot Number is considered No Reply when all group members are in a state of no reply.

Alerting type

There are two alerting modes for FA. These are:

  • sequential

  • parallel

In the sequential alerting mode the group members are alerted in order, with each 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.

Flexible Alerting Features

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.

Flexible Alerting Mode Examples Call Flow

Note Various IMS core elements and some SIP messages are omitted from the call flow diagrams for the sake of clarity.

Parallel Alerting for group type of multiple-users

In the following Flexible Alerting call example there are two members in the FA group configured to receive the call in the HSS Service Data. The alerting mode is set to Parallel, so all members will be alerted at the same time. The Member B answers the call.

fa parallel mode multiple users

Parallel Alerting for group type of single-user

In the following Flexible Alerting call example there are two members in the FA group configured to receive the call in the HSS Service Data. The alerting mode is set to Parallel, so all members will be alerted at the same time. The Member B responds with 486 (Busy here) and the service cancel the ongoing alerting and finish the session.

fa parallel mode single user

Sequential Alerting for group of type multiple-users

In the following Flexible Alerting call example there are two members in the FA group configured to receive the call in the HSS Service Data. The alerting mode is set to Sequential, so all members will be alerted one after the other. The Member B answers the call.

fa sequential mode multiple users

Sequential Alerting for group type of single-user

In the following Flexible Alerting call example there are two members in the FA group configured to receive the call in the HSS Service Data. The alerting mode is set to Sequential, so all members will be alerted one after the other. The Member A is busy, causing the service to stop alerting the Member B and finish the session.

fa sequential mode single user

Session Transfer to Own Device

Is a service that allows an existing originating or terminating session to be transfered to another device. The target device is the one that pulls the session. The service is experimental and has some constraints (see Pre requisites).

Service description

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.

Pre requisites

Basic flow

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

simple stod

Features

The service is composed of several features:

The interactions among the features are show below:

stod simple process

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

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 it will set the proper procedures to cause the session to be tracked and the MMTelStodBind feature will bind the session to an ACI name. It also creates an external tracking key for the session and adds it to the set in session state.

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.

Charging

The Sentinel framework, which Sentinel VoLTE is based on, uses the Diameter Ro interface to the OCS to enable online charging. The charging over Diameter Rf is done via Rf Control Resource Adaptor.

For more details on this please see the Sentinel product documentation and Rf Control Resource Adaptor Architecture.

Highlighted below are the key pieces of charging functionality:

Multiple OCS support

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

  • During migration of an operator’s charging infrastructure, it is likely that more than one OCS will need to be supported.

  • The CSP may have different OCSs for prepaid and post-paid, and/or different OCSs for voice/SMS and data.

  • Multiple MVNOs may be hosted on an operator’s network, each with their own OCS.

scc services charging

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.

Re-authorization

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.

CDR generation

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.

Offline charging via Diameter Rf

VoLTE sends charging information to a configured Charging Data Function via Diameter Rf interface.

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.

Use of a Prepaid SCP via CAP

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.

SCC-AS Services

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

imrnaltcorrected

In this diagram:

  1. The UE attempts a CS originated call.

  2. The MSC VLR sends an InitialDP to the IN SCP function in Sentinel VOLTE, which then returns an IMS Routing Number (IMRN).

  3. The CS network uses the IMRN to route towards the IMS.

  4. The IMS network then routes the call based on the IMRN contained within the Request-URI of the SIP INVITE.

  5. The SCC-AS correlates the SIP INVITE with the received InitialDP.

  6. The SCC-AS generates an IMS session on behalf of the CS user.

    This mechanism can be considered as “network-facilitated” ICS.

In a CDMA network, the IN SCP role is supported with a dedicated service that receives an OriginationRequest or AnalyzedInformation trigger and returns an IMS Routing Number (IMRN).

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”

  • In GSM networks, 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)

  • In CDMA networks, the Circuit Switch Routing number is formed through querying the HLR for the Temporary Local Directory Number (TLDN)

  • The subscriber state is determined by examining third-party registration data.

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. In CDMA networks, the CSRN is based on the Temporary Local Directory Number (TLDN), which is fetched from the HLR.

  1. The SCC-AS optionally uses an “Sh-Pull” operation towards the HSS requesting the “IMS voice over PS Session Supported Indication”

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

esrvcccorrected
  1. 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.

  2. The MSC-S/MGCF initiates a session towards IMS, using the Session Transfer Number for SRVCC (STN-SR), which resolves to the ATCF.

  3. The ATCF uses the subscriber identity in the P-Asserted-ID header to identify the target session.

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

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

Architecture Overview

OpenCloud’s Rhino Sentinel VoLTE product implements the Service Centralisation and Continuity Application Server (SCC-AS) and Multimedia Telephony Application Server (MMTel-AS).

Tip

Sentinel VoLTE is based on OpenCloud’s Sentinel architecture and frameworks, and automatically gains from all benefits of Sentinel, including:

  • flexible online/offline/hybrid charging through configuration

  • remaining an open system…​ after it is deployed

  • feature-based extensibility.

Major components

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

sentinel volte overall arch

VoLTE includes the ‘session processing’ parts:

  • an extensible Third Party Registrar with support for either HSS or Cassandra as Storage system for Registrar Subscriber Data

  • an extensible IN SCP

  • an extensible SIP session processing framework.

It provides web-server based infrastructure for:

  • the administration web user interface (Rhino Element Manager)

  • RESTful Provisioning Services

  • an XCAP Server for UE self-provisioning

  • JSLEE services.

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.

JSLEE services

Sentinel VoLTE’s JSLEE services are based on OpenCloud’s Sentinel architecture and frameworks.

It includes four JSLEE services:

  • Sentinel-based SIP Third Party Registrar (for SCC and MMTEL)

  • Sentinel-based SIP based Service — hosting the ‘main session processing logic’ (for SCC and MMTEL)

  • Sentinel-based IN SCP Service (for SCC)

Sentinel VoLTE in an LTE network

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

sentinel volte architecture 1

B2BUA architecture

The B2BUA architecture includes:

iFC Triggering Chaining and the SCC and MMTEL

3GPP defines that the SCC-AS is the first TAS invoked in the Originating iFC treatment, and the last in the Terminating iFC treatment.

The following diagrams represent a session where the SCC-AS and the MMTEL-AS are the only two TAS invoked, and MMTEL is used for both Originating and Terminating treatment.

sentinel volte architecture 2

Note that for simplicity, both the Originating and Terminating Served-Users are in the same network, and happen to be assigned to the same Serving CSCF.

Sentinel VoLTE TAS implements both the SCC-AS and the MMTEL-AS. In this Session there are four Back-to-Back User Agent instances:

  • Mobile Originating SCC-AS

  • Mobile Originating MMTEL

  • Mobile Terminating MMTEL

  • Mobile Terminating SCC-AS.

Co-location using the Rhino SIS

OpenCloud supports co-location of the B2BUA instances in the same cluster, and even Unix process/JVM instance. The co-location and signalling interaction can be achieved using the Rhino SIS to orchestrate the session.

Therefore, the S-CSCF does not need to be configured for iFC trigger chaining as shown in the first case. This is an optional configuration and is represented below.

sentinel volte architecture 3

Subscriber Data Storage

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.

Supplementary services database

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.

Media resource function

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

Cloud and virtualisation

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

Cloud and Virtualisation

Sentinel VoLTE is based on Rhino Sentinel, which is not bound to a specific hardware architecture and supports the major virtualization technologies.

VMWare is certified as part of the latest release of the Rhino platform. Rhino applications have been deployed in a virtualised environment in a number of live deployments. A Rhino cluster can also be deployed using a mix of virtualised and non-virtualised instances.

The diagram below shows a cluster of virtualised Sentinel VoLTE (MMTel and SCC-AS) and other applications installed in a non-virtualised mode, all in a single deployment.

cloud and virtualisation
Tip We believe a cloud deployment model is well suited for VoLTE services, as it will help manage costs and service demand through hardware utilisation, increased flexibility, and elastic scalability.

Sentinel VoLTE can be easily scaled in a data centre or a private cloud environment.

The virtualised Sentinel VoLTE enables multiple independent configurations as well as strong isolation between independent services. This can be used to provide a controlled architecture where priority is given to one service over another.

XCAP Support

Sentinel VoLTE includes the following features to support XCAP.

Tip See also the XCAP Query Examples.

XCAP architecture within the IMS

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

ims xcap architecture
Tip XCAP’s use within IMS is described in 3GPP TS 33.222.

The Ut interface provides a user’s device with the ability to manipulate a configuration document. This document may contain user specific service settings such as privacy setting, communication barring and forwarding rules. TS 33.222 does not define how the MMTel-AS stores this document. However, 3GPP TS 29.364 defines a standardised XML schema for representing both the User and Operator settings for these services. TS 29.364 also defines the XML schema for transporting the user specific settings via the XCAP interface. This is called the "simservs" document. TS 29.364 also defines that an Application Server can store this service data on the HSS through the Sh interface as transparent data.

Sentinel VoLTE and XCAP

Sentinel VoLTE provides an XCAP server web application that implements the XCAP protocol towards the UE, and supports the XML schemas for user and operator data defined in TS 29.364, and stores and retrieves this information according to 29.364 in the HSS using Sh Transparent Data.

The diagram above shows several XCAP servers, as MMTEL-AS and Other-AS. Sentinel VoLTE provides the XCAP Server rather than the Authentication Proxy (AP) in the 3GPP architecture.

Sentinel VoLTE’s XCAP server application requires that the Ut/HTTP Requests have been Authenticated before reaching the XCAP application. Un-authenticated requests are rejected. Authentication may be achieved through use of the Sentinel Authentication Gateway product, or by using a separate Authentication Proxy.

The Sentinel Authentication Gateway is co-located with the XCAP server application rather than being a discrete AP. See Sentinel Authentication Gateway’s Architecture Overview for further information.

HTTP URIs and XCAP

If the XCAP host is running on xcap.server.net, the base XCAP URL for the XCAP Server application will be

https://xcap.server.net

The standard distribution of Sentinel VoLTE as an image contains nginx acting as a reverse proxy to support this base URL. If Sentinel VoLTE is installed in any other manner, the base XCAP URL for the XCAP Server application will be

https://xcap.server.net:8443/rem/sentinel/xcap

unless a similar reverse proxy is manually installed.

Active attributes inside the MMTel-Services document

There is a subtlety worth noting with respect to the per-service "active" attribute in the User portion of each MMTel Service.

The active attribute is specified as an optional boolean attribute in the XML schema for the simservs and MMTel-Services documents.

In an XML document, this means they can have three possible values:

  • does not exist (that is, attribute is not declared)

  • exists with the value true

  • exists with the value false.

The specifications assign special meaning to these ‘active’ attributes when the attribute in the document does not exist:

  1. during session processing - logic should treat a nonexistent attribute as though the value is true.

  2. XCAP requests from the user equipment are subject to special rules when the attribute does not exist:

    1. A request is not allowed to directly or indirectly create or otherwise modify a nonexistent active attribute

    2. A request is allowed to configure other portions of that service’s data.

Regardless of the active flag’s state (nonexistent, true, or false) a request can configure other portions of the service. For example, if Communication Diversion has no ‘active’ attribute, a request can configure communication diversion rules.

In summary, if an active flag is nonexistent this means that the user equipment cannot disable the feature. If the operator wants the user equipment to be able to enable or disable the feature, then the ‘active’ attribute should exist (and therefore be either true or false).

Other notable restrictions of XCAP

If a user’s MMTel-Services document does not contain a named service (for example, <communication-diversion>) the UE cannot indirectly or directly create this element. Child elements of a named service can be modified/created/removed, provided that the named service is present.

The IMS Operator Determined Barring service has both session processing and XCAP related behaviour. The XCAP related Operator Determined barring behaviour enables the operator to disallow a user’s capability to view and change their service settings.

Integration with Rhino Element Manager and Sentinel

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 the implementation 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:

volte web container

Integrated components

The diagram above includes these components:

  • The HTTP clients can be:

    • a web browser

    • a provisioning application

    • an XCAP client (such as XCAP-enabled user equipment connecting through an aggregation proxy).

  • The HTTP servlet container configuration is used to specify the IP interfaces and port numbers that the REM Web application is running on. Therefore, if the port that the REM application is running on is to be reconfigured, the HTTP servlet container needs restarting.

  • The REM web application is packaged as a web archive (WAR). It can be deployed into various HTTP servlet containers. OpenCloud tests the application in Apache Tomcat and Jetty HTTP servlet containers.

  • The three HTTP-triggered components (web user interface, REST Provisioning API, and XCAP server) are triggered from the same port. The HTTP Request URI is used to distinguish which component processes a certain request.

Note Each of the components has their own security configuration.

Sh Cache Microservice Client stacks and Rhino clusters

Each REM application includes one or more instances of the Sh Cache Microservice Client stack. Each instance is scoped to the Rhino cluster it is associated with. The Rhino cluster is selected when the REM user selects a “Rhino instance” to log into.

Each instance of the Sh Cache Microservice Client stack can select a different instance of the Sh Cache Microservice to connect to, each of which can be configured for a different Destination Realm. In other words, a single Diameter stack instance can be configured to connect to more than one distinct HSS.

Each instance of the Sh Cache Microservice Client stack is shared by both the XCAP server and parts of the web user interface.

Each Rhino cluster has connectivity to various systems. (That connectivity is not shown in the diagram above.)

XCAP Query Examples

Below are examples of XCAP queries with Sentinel VoLTE.

Note These examples assume that the XCAP Server is running on localhost with port 8090.

Get simservs document

Method

 GET

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net

Payload

N/A


          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx
Content-Type: application/vnd.etsi.simservs+xml

Payload

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:simservs xmlns:ns2="http://uri.etsi.org/ngn/params/xml/simservs/xcap">
<originating-identity-presentation active="true"/>
<originating-identity-presentation-restriction active="true">
<default-behaviour>presentation-not-restricted</default-behaviour>
</originating-identity-presentation-restriction>
</ns2:simservs>

Get active state of OIP supplementary service

Method

GET

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation/@active+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net

Payload

N/A


          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx
Content-Type: application/xcap-att+xml

Payload

true

Get default-behaviour of OIR supplementary service

Method

GET

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation-restriction/default-behaviour+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net

Payload

N/A

          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx
Content-Type: application/xcap-el+xml

Payload

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<default-behaviour>presentation-not-restricted</default-behaviour>

Enable OIP supplementary service

Method

PUT

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation/@active+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net
Content-Type: application/xcap-att+xml

Payload

true

          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx

Payload

N/A

Disable OIP supplementary service

Method

PUT

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation/@active+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net
Content-Type: application/xcap-att+xml

Payload

false

          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx

Payload

N/A

Set OIR default-behaviour to presentation-restricted

Method

PUT

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation-restriction/default-behaviour+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net
Content-Type: application/xcap-el+xml

Payload

<default-behaviour>presentation-restricted</default-behaviour>

          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx

Payload

N/A

Set OIR default-behaviour to presentation-not-restricted

Method

PUT

URL

+https://localhost/simservs.ngn.etsi.org/users/sip:user111000@home1.net/simservs/~~/originating-identity-presentation-restriction/default-behaviour+

Headers

X-3GPP-Asserted-Identity: sip:user111000@home1.net
Content-Type: application/xcap-el+xml

Payload

<default-behaviour>presentation-not-restricted</default-behaviour>

          

Response

HTTP/1.1 200 OK

Headers

ETag: xxxxxxxxx

Payload

N/A

Instance Architecture for Sentinel VoLTE

Features of the instance architecture of the Sentinel VoLTE include:

iFC triggering chaining and the SCC and MMTEL

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:

separate instances
Note For simplicity, both the originating and terminating served-users are in the same network, and happen to be assigned to the same serving CSCF.

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

  • mobile originating SCC

  • mobile originating MMTEL

  • mobile terminating MMTEL

  • mobile terminating SCC.

Note The phrase “back-to-back user agent” or B2BUA is used to describe each SIP Sentinel instance. This is often the case, as many SCC and MMTEL capabilities are able to be realised based on a routing back-to-back user agent. However it is not entirely accurate, as various capabilities, such as Access Transfer and MMTEL conferencing, require a much more sophisticated structure than a “Routing B2BUA”.

Co-location using the Rhino SIS

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:

co location using sis

Access to the HSS and HLR

The Sentinel VoLTE product is able to use both the HSS and optionally the HLR.

HSS access

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 Microservice component.

This includes:

  • Sentinel Registrar

  • Sentinel SIP Invite Session Processing (i.e. SCC and MMTEL)

  • the XCAP Server

  • the Transparent Data editing capability within Rhino Element Manager.

sh cache within volte

For more information on the Sh Cache Microservice see Sh Cache Microservice architecture.

HLR access

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

This includes:

  • Sentinel Registrar

  • Sentinel SIP Invite Session Processing (i.e. SCC and MMTEL)

cgin map within volte

Supplementary Service Data

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

Supplementary Service Data Access

All standardised Supplementary Service Data is located in either the HLR (for GSM networks) and/or the HSS (for IMS networks), and/or in a convergent HLR/HSS.

When accessing Supplementary Service Data from the HSS, the Diameter Sh interface is used. The Supplementary Service Data is stored according to standardized XML schemas within Transparent User Data.

When accessing Supplementary Service Data in the HLR, the GSM MAP protocol is used. Supplementary Service Data is stored according to standardized schemas (often ASN.1 defined).

Supplementary Service Data stored in the HSS

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

Component Name Purpose

Sentinel Registrar

Cache warming of the Served User’s Supplementary Service Data upon Initial Registration

Sentinel VoLTE MMTel Features

Supplementary Service Data is necessary for many features to operate

XCAP Server

The purpose of the XCAP server is to enable subscribers to query and modify their service settings

Transparent Data editing capability within the Rhino Element Manager

This capability enables an administrator to query and edit the Supplementary Service Data

For more information about the Sh Cache Microservice see Sh Cache Microservice architecture

Supplementary Service Data stored in the HLR

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:

  • Sentinel VoLTE MMTel features - Supplementary Service Data is necessary for many features to operate

Third Party Registrar Architecture

Sentinel VoLTE includes Sentinel’s Third Party Registrar with various features suitable for SCC and MMTel.

The Sentinel Registrar and SIP Session processing components share information through Registrar Data Storage.

When using HSS, both Sentinel Registrar and SIP Session processing share the following information via XML schemas for Transparent User Data storage:

  • the MMTel supplementary services standard schema

  • OpenCloud’s Third Party Registrar schema (used to store third-party registration information in the HSS for later use).

When using Cassandra, this information is shared via OpenCloud’s Third Party Registrar schema.

The Sentinel Registrar is for SIP REGISTER-triggered Session Plans, and Sentinel SIP is for INVITE-triggered Session Plans.

registrar invite hss atcf

The Third Party Registrar includes a feature that accesses the ATCF for 3GPP Release 10 Enhanced SR-VCC.

Both the Third Party Registrar and Sentinel SIP Features use the Sh Cache Microservice RA to access the HSS or Cassandra CQL RA to access the Cassandra database.

Charging Support

OpenCloud’s Sentinel framework enables online charging over Diameter Ro, Diameter Rf and CAP.

Online and Offline charging is a key part of Voice over LTE, and is particularly relevant for the MMTEL-AS.

Charging instance model

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

charging instance model

The diagram shows the three key concepts:

  1. There are Originating, Terminating, and Forwarding MMTEL instances.

  2. The S-CSCF “re-targets” a session if it is performing terminating processing, and the destination is altered. This means iFC is re-evaluated.

  3. The History-Info header communicates the fact that the Session has been forwarded. The MMTEL-AS inserts (if not present) or adds-to (if already present) the History-Info header, when it re-targets the INVITE to a changed destination.

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

charging instance model

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

Charging within the instance model

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

  • When you make a call, Online Charging is applied (to charge you for making the call).

  • When you receive a call, Online Charging is applied (to charge you to receive a call — this is typical when you roam to another country).

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:

  1. One Originating for A→B (charging the A party for a call to B)

  2. One Terminating for A→B (charging the B party for a call from A)

  3. One Originating_CDIV (or Forwarding) for B→C (charging the B party for a call to C)

  4. One Terminating for B→C (charging the C party for a call from B)

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-party’s Terminating Instance (for example, when not roaming), you can:

  • return the Online Charging System “credit control not applicable”, or

  • disable the Sentinel Session Plan Online Charging (in the terminating and not-roaming case) or

  • both of the above approaches.

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

SDP and charging

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.

  • If a change is deemed meaningful, then Sentinel will perform client initiated re-authorization towards the Online Charging System.

  • If a change is not meaningful, then the current credit reservation remains.

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

sdp codecs

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.

Tip For more about Sentinel and its various capabilities, including charging, see Sentinel Overview and Concepts.

Charging and Sessions Terminating in WiFi Networks

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.

Charging over Diameter Rf interface

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

Population of AVPs on the Diameter Ro interface

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

Using online and offline charging together

When configured for both online and offline charging, it may be desirable to allow sessions to proceed when there is a communications outage with the OCS.

This can be achieved using the procedure at Fault Tolerant Online Charging.

Note that when configured this way, conference calls will still fail when the OCS connection fails or times out mid-session, and there will be no CCR-T for calls that experience an outage.

Deployment Structure

Sentinel VoLTE has a variety of ways in which it can be deployed to fulfil different service requirements.

There are eight different deployment modules available:

  • volte-registrar-full-deploy

  • sentinel-volte-basic-dev-deploy

  • sentinel-volte-mmtel-deploy

  • sentinel-volte-mmtel-gsm-deploy

  • sentinel-volte-scc-cdma-deploy

  • sentinel-volte-scc-gsm-deploy

  • sentinel-volte-full-cdma-deploy

  • sentinel-volte-full-gsm-deploy

Each one will deploy the required services, resource adaptors, features, and config it requires to function.

Registrar

This deployment corresponds to the volte-registrar-full-deploy module.

This deployment gives you the Third Party Registrar as a standalone service.

This deployment is just the Third Party Registration features.

Basic Dev

This deployment corresponds to the sentinel-volte-basic-dev-deploy module.

This is intended to be a lightweight deploy that has only the core features required for basic call flows.

This deployment has the same content as Registrar with the addition of General features, SIP features, and General VoLTE features.

MMTel

This deployment corresponds to the sentinel-volte-mmtel-deploy module.

This deployment allows the MMTel Services to be run. It does not include any features that make use of CGIN.

This deployment has the same content as Basic Dev with the addition of MMTel features.

MMTel GSM

This deployment corresponds to the sentinel-volte-mmtel-gsm-deploy module.

This deployment has the same content as MMTel but includes features that make use of CGIN, and the IM-SSF.

SCC CDMA

This deployment corresponds to the sentinel-volte-scc-cdma-deploy module.

This deployment allows the SCC-AS Services to be run using CDMA for the MAP messages.

This deployment has the same content as Basic Dev with the addition of SCC features and the CDMA Reorigination Service, but excludes GSM features.

SCC GSM

This deployment corresponds to the sentinel-volte-scc-gsm-deploy module.

This deployment allows the SCC-AS Services to be run using GSM for the MAP messages.

This deployment has the same content as Basic Dev with the addition of SCC features, but excludes CDMA features and CDMAFetchTLDN.

Full CDMA

This deployment corresponds to the sentinel-volte-full-cdma-deploy module.

This deployment gives you a complete VoLTE that does both MMTel and SCC using CDMA. It has everything from the MMTel and SCC CDMA deployments.

Full GSM

This deployment corresponds to the sentinel-volte-full-gsm-deploy module.

This deployment gives you a complete VoLTE that does both MMTel and SCC using GSM. It has everything from the MMTel GSM and SCC GSM deployments.

CAMEL and SIP support for SCC

Sentinel VoLTE includes Sentinel’s IN Service and Sentinel’s SIP Service.

These both sit on top of OpenCloud’s Rhino SIS product.

scc camel and sip

These services each contain features for IMS Service Centralisation. Of note are the Reorigination features. One sits in the Sentinel IN service, and the other in the Sentinel SIP service. Reorigination data is stored in the Correlation RA.

More information on these features is described in the VoLTE Administration Guide, under the Service Centralisation Features.

CDMA and SIP support for SCC

Sentinel VoLTE includes Sentinel’s SIP Service, which sits on top of OpenCloud’s Rhino SIS product, and the CDMA Reorigination service.

scc cdma and sip

Supported Call Flows

IMS Service Centralisation

The Sentinel VoLTE product comes with a CDMA Reorigination Service and accompanying reorigination features which together support IMS Service Centralisation within CDMA networks, which store reorigination data in the Correlation RA. These components allow for both originating and terminating reorigination (retermination). A high-level overview of IMS Service Centralisation can be found in the IMS Centralised Services (ICS) support section, while call flows and more detailed information can also be found in the Sentinel VoLTE Administration Guide.

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 (in this case CDMA) network or the PS network. Sentinel VoLTE includes a feature for querying the HLR for the TLDN to use for CS routing. A high-level overview of T-ADS can be found in the Terminating Access Domain Selection (T-ADS) section.

SDP conflict management

Sentinel VoLTE may need to manipulate SDP (Session Description Protocol — RFC 4566) content in SIP message bodies to resolve conflicts. This section explains why SDP conflict management is required in some cases, and how it is implemented in Sentinel VoLTE.

SDP conflict management overview

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.

Permitted SDP modifications during a session

These are summarised from RFC 4566 and RFC 6337, for reference.

  • All SDP offers sent by a user agent in the same dialog must have the same session ID in the origin (o=) line.

  • An SDP offer that changes the session description must have a session version one greater than the previous SDP offer.

  • An SDP offer that does not change the session description must have the same session version as the previous SDP offer.

  • The order of media descriptions (m= lines) is significant, it is used by UEs when comparing with the previous SDP.

  • Media descriptions can be added and changed, but never removed. To "remove" a media description, leave it in place and set its port to zero.

  • A disabled media description’s position can be reused in a later offer, using a different port and codec etc.

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

  • The destination leg is the established leg between the SCC-AS and another entity, typically a UE. A previous SDP offer has been sent on this leg, so all subsequent offers must follow the same sequence of session ID and version, as well as matching the previous number of media streams.

  • The source leg is a new leg that the SCC-AS has received an offer on. This offer is intended to be sent out on the destination leg, after appropriate changes to the SDP.

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.

Access transfer example

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

Initial call setup

sdp manipulation example

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.

Access transfer request

sdp manipulation example 001

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

Remote update request

sdp manipulation example 002

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.

Remote update response

sdp manipulation example 003

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

SDP conflict types

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

Note The SDP content shown below is abbreviated to just show the relevant lines.

Session ID and version

In cases where the media was not anchored via an ATGW, the new source SDP offer will have a different session ID and version to the previous SDP offer sent on the destination leg. When the new offer is forwarded to the destination, the SCC-AS rewrites the origin (o=) line so that the session ID and version are consistent with the previous offer:

  • The session ID will be replaced with the previous offer’s session ID

  • The session version will be replaced with the previous offer’s version + 1

Previous SDP offer to destination New SDP offer from source Output SDP offer to destination
o=- 100000 100000 IN IP4 10.0.0.1
o=- 45678 45678 IN IP4 172.16.4.2
o=- 100000 100001 IN IP4 172.16.4.2

Use session ID and version + 1 from previous offer.

Subsequent offers arriving on the source leg get the same treatment, so the destination leg always sees the same session ID and monotonically increasing sequence of session versions.

In the reverse direction (destination → source), SDP offers and answers do not need their session IDs and versions rewritten; these are all generated by the destination UE which has not changed.

Media descriptions removed

This is when the new source SDP offer has fewer media descriptions than the previous offer sent to the destination.

Before the new offer is sent to the destination, the SCC-AS must zero the media lines that are no longer used.

Previous SDP offer to destination New SDP offer from source Output SDP offer to destination
m=audio 32500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 32600 RTP/AVP 98
a=rtpmap:98 H263/90000

Original media with audio & video.

m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1

New media after access transfer has audio only.

m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 0 RTP/AVP 98

Copy new audio description and disable previous video description.

When an SDP answer or subsequent offer forwarded in the reverse direction (destination → source), the disabled media descriptions are removed.

Original SDP offer from source SDP answer from destination Output SDP answer to source
m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1

New media from source leg was audio only.

m=audio 36900 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 0 RTP/AVP 98

Destination answers, accepting audio stream and leaving video disabled.

m=audio 36900 RTP/AVP 97
a=rtpmap:97 AMR/8000/1

Disabled video description removed in answer to source.

Media descriptions added

This is when the new source SDP offer has more media descriptions than the previous offer sent to the destination.

Before the new offer is sent to the destination, the SCC-AS must copy the new media descriptions into the next available positions in the output.

Previous SDP offer to destination New SDP offer from source Output SDP offer to destination
m=audio 32500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 40600 RTP/AVP 98
a=rtpmap:98 H263/90000

New source offer adds a video description.

m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 40600 RTP/AVP 98
a=rtpmap:98 H263/90000

Both media descriptions copied into offer sent to destination.

When an SDP answer or subsequent offer is forwarded in the reverse direction (destination → source), the new media descriptions are copied across.

Original SDP offer from source SDP answer from destination Output SDP answer to source
m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 40600 RTP/AVP 98
a=rtpmap:98 H263/90000
m=audio 56700 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 56800 RTP/AVP 98
a=rtpmap:98 H263/90000
m=audio 56700 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 56800 RTP/AVP 98
a=rtpmap:98 H263/90000

Both media descriptions copied into answer sent to source.

Reusing a media description that was previously set to zero

In the media descriptions removed case above, the SCC-AS adds a disabled media description to the output SDP. When the other party sends SDP in the other direction, this description would normally be removed. However, it’s possible that the other party reuses this disabled description’s position for a new media stream. In this case the SCC-AS has to copy the new media description rather than removing it.

Previous SDP offer to destination New SDP offer from destination Output SDP offer to source
m=audio 40500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 0 RTP/AVP 98

Video line was disabled by previous media descriptions removed interaction.

m=audio 56000 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 57000 RTP/AVP 100
a=rtpmap:100 H264/90000

New video media reuses same position as previously disabled stream.

m=audio 56000 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 57000 RTP/AVP 100
a=rtpmap:100 H264/90000

Existing and new media descriptions are copied to output.

From this point when SDP is forwarded in the reverse direction (source → destination), the new media descriptions are copied across.

Payload type conflicts

Payload type conflicts occur when a new media description in the same position tries to map the same dynamic RTP payload type number to a different codec. If the new media description was just copied across to the destination, the media stream would fail because the destination UE will already be using a different codec.

To resolve this conflict, the SCC-AS disables the original media description (sets its port to zero), and copies the new media description to the next available position in the output SDP.

Previous SDP offer to destination New SDP offer from source Output SDP offer to destination
m=audio 32500 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
m=video 32600 RTP/AVP 98
a=rtpmap:98 H263/90000

Previously the audio payload type 97 mapped to AMR/8000/1.

m=audio 40500 RTP/AVP 97 98
a=rtpmap:97 AMR-WB/16000/1
a=rtpmap:98 AMR/9000/1
m=video 40600 RTP/AVP 101
a=rtpmap:101 H263/90000

The new offer maps payload type 97 to AMR-WB/16000/1. This is a conflict.

m=audio 0 RTP/AVP 97
m=video 40600 RTP/AVP 101
a=rtpmap:101 H263/90000
m=audio 40500 RTP/AVP 97 98
a=rtpmap:97 AMR-WB/16000/1
a=rtpmap:98 AMR/9000/1

In the rewritten offer, zero the conflicting media description, add its replacement to the end.

When an SDP answer or subsequent offer is forwarded in the reverse direction (destination → source), the new media descriptions are copied back to their original positions, and the disabled media description is removed.

Original SDP offer from source SDP answer from destination Output SDP answer to source
m=audio 40500 RTP/AVP 97 98
a=rtpmap:97 AMR-WB/16000/1
a=rtpmap:98 AMR/9000/1
m=video 40600 RTP/AVP 101
a=rtpmap:101 H263/90000

Offer has audio in position 1, video in position 2.

m=audio 0 RTP/AVP 97
m=video 39700 RTP/AVP 101
a=rtpmap:101 H263/90000
m=audio 39800 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000/1

Due to payload type conflict above, answer has video in position 2, audio in position 3.

m=audio 39800 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000/1
m=video 39700 RTP/AVP 101
a=rtpmap:101 H263/90000

Transformed answer copies audio from position 3 to position 1; video from position 2 to position 2. Disabled audio in position 1 is removed.

Conflict types not supported

Currently the SDP conflict management system does not support changing IP versions, e.g. the connection address changing from an IPv6 address to an IPv4 address. This may be able to be resolved with a third-party media gateway.

Using SDP conflict management in a feature

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

import com.opencloud.sentinel.sdp.SdpRewriting;
...

SdpRewriting sdpRewriting = new SdpRewriting(tracer, sessionState);
sdpRewriting.startSdpRewritingForLegs(newAccessLegName, remoteLegName, newSourceSDP, previousDestSDP);

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.

SDP encoding issues and workarounds

Number of ports in media lines

The port field in a media (m=) line may include a "number of ports" suffix, if the media uses several ports. For example, RTP media with port 31700/2 means the media uses 2 ports.

Media that uses one port may be encoded as either 31700 or 31700/1, which are equivalent. The SDP implementation in Sentinel VoLTE (NIST SDP) uses the former, omitting the /1 suffix by default.

The formatting of SDP received from other systems will be preserved, so if the /1 suffix was present in an incoming SDP media field, it will not be removed. Conversely if the /1 suffix was absent, it will not be added.

SDP media fields created by Sentinel VoLTE features (using javax.sdp.SdpFactory) will not add the /1 suffix by default. If necessary this can be overridden, to always use /1, by setting the system property -Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false on the JVM command line.

In the Rhino SDK, add -Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false to the file $RHINO/config/jvm_args. In a production Rhino node, add the following to $RHINO/node-xxx/read-config-variables:

OPTIONS="$OPTIONS -Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false"

Session Tracking

Sentinel VoLTE includes a capability to store information related to ongoing SIP Sessions in Rhino’s Session Ownership Subsystem.

This enables global access from various Sentinel VoLTE cluster nodes to the same information.

Session Tracking is accessible to features through an API. It has two primary uses:

  1. SCC-AS to support implementation of various Access Transfer mechanisms

  2. steering requests for related dialogs to a node when replicating Sessions

Sessions are said to be Tracked Sessions if their existence and meta-data is stored in the Session Ownership Subsystem.

Use of Session Tracking by the SCC-AS

The SCC-AS tracks any originating or terminating session where the served user’s identity is registered by a UE that has a UE-SRVCC-Capability indicator. This occurs regardless of whether or not Session Replication is enabled.

In order to enable the Re-INVITE Based Three-party conference setup the SCC-AS will track the access leg for every originating or terminating session if the EnableSCCConfHandling attribute is set to true. For further information refer to SCC Conference Handling Configuration and Reuse of Access Transfer procedures for conferencing.

Use of Session Tracking for Session Replication

When Session Replication is enabled all SIP Dialogs in the replicated Session are tracked - not just the access leg.

When Sentinel VoLTE is configured to use CAP charging the IM-SSF service (which is not a Sentinel service) will also track the SIP dialogs on each side of its B2BUA.

Tracked Session Information

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

These are:

  • Half dialog - A SIP INVITE request has been sent, and no dialog-creating 1xx response has been received yet. This corresponds to the "Trying" and "Proceeding" states in RFC 4235.

  • Early - a SIP dialog is in the "early" state. This means that the INVITE request has received a dialog-creating 1xx response. Forks of this dialog may exist due to SIP forking.

  • Confirmed - a SIP dialog exists that has both local and remote tags, its INVITE request has been responded to with a 2xx, and the ACK for the 2xx has arrived at the TAS.

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.

State of Tracked Session Input to session tracking Session tracking behaviour

Does not exist

Initial INVITE request received and a feature enables half dialog session tracking

Session tracking creates appropriate rows in the Database. Each row is in the half dialog state.

Half dialog

A dialog creating 1xx response is received

Each half dialog row is removed from the database. A 'PRE_ALERTING' row is created if the Early Dialog was established with a 183. An 'ALERTING' row is created if the Early Dialog was established with a 180.

Early

A dialog creating 1xx response with a different remote-tag (a fork) is received

New rows representing the Early dialog for the fork are created in the database.

Early

An ACK to the 2xx-INVITE is received at the TAS

Any rows representing forked dialogs that did not receive the final response to the INVITE are removed from the database. The rows representing the established dialog are updated to be state 'ACTIVE' in the database.

Confirmed

A 2xx response to a hold request is received at the TAS

Any rows representing the confirmed dialog are updated to be state 'HELD' in the database.

Confirmed

A 2xx response to a resume request received at the TAS

Any rows representing the confirmed dialog are updated to be state 'ACTIVE' in the database.

Confirmed

A BYE request is sent/received on the Served User’s Dialog

Any rows representing the confirmed dialog are removed.

Session Tracking Capabilities

Session Tracking is implemented by the Access Leg Tracking and External Session Tracking features.

SIP stack level request proxying

When Session Replication is enabled, every replicated SIP dialog has an entry in a Session Ownership store. This per-dialog entry contains a SIP URI of the preferred node for processing that dialog.

When a mid-dialog request arrives at a node, the node checks a local memory cache for the existence of the dialog. If the dialog does not exist in cache, then the Session Ownership store is queried to fetch the entry for the dialog. If there is no entry for the dialog, then a 481 Call/Transaction Does Not Exist response is returned. Once the entry is returned, the URI is checked to see if the node exists in the cluster. If the node is a member of the cluster, then the request is proxied to that node. If the node is not a member of the cluster, then the entry for the dialog is updated in the Session Ownership subsystem pointing to the current node, and the request is processed locally.

This causes various Session States to be loaded by the Local Memory Database, and so the session has been adopted locally.

The Session Ownership store is a "key-value store" that supplies:

  • Compare and set operations (CAS)

  • a "consistent read" in cases where a failure did not occur when writing and replicating the write

Components running on the Rhino platform use the Session Ownership APIs in order to access the Session Ownership store. That is, the components are not tightly coupled with the particular implementation of the Session Ownership store. This means that it is possible to add support for additional Session Ownership Store implementation(s).

The Cassandra Database is supported in the initial Session Ownership Store implementation.

Failure detection

A dialog is intended for processing on one node at any point in time. This is maintained by the Session Ownership Subsystem.

If a request arrives at the "wrong" node, then it may consult the Session Ownership Subsystem in order to retrieve the current location of the Dialog. If the current location of the dialog is not available, then the dialog is processed locally. Essentially it is failed over when a request arrives, to the node receiving the request.

Rhino’s cluster membership subsystem delivers a voting result indicating that a node has failed. The SIS recognises and saves the current cluster membership for use when processing received requests, therefore it will not proxy requests to a failed node.

Session Tracking and Rhino’s Session Ownership Subsystem

Sentinel VoLTE version 2.6.0 introduced the concept of "Session Tracking". This concept is where certain SIP dialogs have meta-data about them written out to an external store. The meta-data includes a number of variables, including a URI for the home node of the dialog. Typically, Session Tracking is enabled in the SCC-AS for the purposes of Access Transfer. The Session Tracking features in 2.6.0 were implemented directly on top of the Cassandra Database. Further details can be found in the 2.6.0 Session Tracking description.

Sentinel VoLTE version 2.8.0 and later use a new Rhino capability called the "Session Ownership Subsystem". The Session Tracking features are now implemented on top of the Session Ownership Subsystem APIs. The SIS is also updated to use the Session Ownership APIs.

Area of difference Session Tracking prior to 2.8.0 Session Tracking in 2.8.0

Dialogs recorded into Database

SIP Access Leg/Dialog only

All SIP Dialogs in a replicated session. In a non-replicated session the only the SIP Access Leg is recorded.

Tracking key used

Application controlled key for Primary Key, application controlled keys for additional tracking keys

Platform controlled key for Primary Key, application controlled keys for additional tracking keys

Point in call where Dialog is recorded into Database

Application specific, typically used by the SCC-AS

Default is only Established Dialogs are recorded into Database, the SCC-AS will request recording of early and pre-early dialogs as necessary

Database schema

Very specific attributes are part of the schema, including major application uses as direct attributes

Schema is more general, application attributes are part of a "bucket" per row

Layer of software implemented on top of

Cassandra CQL API

Rhino’s Session Ownership RA Type

SLEE components that may access API

Sentinel features, SBBs, SBB parts

Sentinel features, SBBs, SBB parts, and Resource Adaptors

API abstraction between API user and Database

No

Yes

Implementation provided by

Sentinel Features

Rhino platform 2.6.1 and later, and Sentinel features

Capabilities required of a datastore

Rhino’s Session Ownership Subsystem provides an API to components. This API is intended to have a very thin implementation on top of any particular Key/Value store. The capabilities that the Key/Value store needs to provide are:

  • Compare and Set (CAS) operations for a single "row" or "value"

  • a "consistent read" in cases where a failure did not occur when writing and replicating the write

Use of Cassandra as the Session Ownership Database

Rhino’s Session Ownership Subsystem provides support for integration to various Key/Value "NoSQL" Databases. Out-of-the-box support for the Cassandra database is provided for Session Ownership 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.

Row Time-to-Live

Each row that is created in Cassandra has a "Time-to-Live" (TTL) set. When a row’s TTL expires, the row is no longer visible in the database and its disk storage is eventually removed. Row TTLs are used to ensure that in various failure cases (such as communication failure between the TAS and Cassandra, TAS failure, or Cassandra failure) that Cassandra does not "fill up" and then "overflow" its storage.

Tracked Sessions in different states have different TTL values set, as the expected frequency of signalling changes in different session phases.

State of tracked session Default row TTL Configuration location

Half dialog

60s

Not configurable

Early

60s

Not configurable

Confirmed

1.5 × session refresh period

As per SessionRefresh configuration

Consistency Level

Session Ownership uses a consistency level of LOCAL_QUORUM for reads and writes. This means that:

  • reads in a site will return the most recently written data in that site

  • to survive a single database failure, a minimum of three Cassandra database instances must be configured per site

  • database replication occurs synchronously within a site, and asynchronously between sites

  • there will be a replication lag between sites due to inter-site communication latency.

Cassandra Schema

The Rhino platform defines and manages the Cassandra database schema, including Keyspace and Table creation. Rhino provides a "Session Ownership Facility" API for Resource Adaptors to use, and a "Session Ownership Resource Adaptor Type" for SBBs and SBB-part components to use. The Session Ownership Subsystem implements these APIs on top of the Cassandra database.

Minimising the impact of Cassandra Database issues on Session processing

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:

  • Write-only statements for session tracking - session tracking only writes to the Cassandra Database. All data necessary to be written is held in local session state. Application features (such as SCC features) then add a read path as necessary. This enables global access to session tracking state.

  • Batch statements - any query that affects multiple rows is executed as a batch statement.

  • Asynchronous queries - threads used for processing signalling messages are not blocked waiting for a response from the database.

  • Signaling visibility after database transaction - signalling is only written "on the wire" after the database transaction has completed, or a guard timer has fired.

  • Per-query guard timeout - the TAS arms an internal timer for each Cassandra query, and if it fires before there is a response from Cassandra, signalling continues and the session is marked as "not tracked" so that further tracking of that session is disabled.

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:

  • no tracked session information - as rows may not have been created, or may have been removed due to TTL, or

  • out-of-date information - as there may have been successful queries prior to a query hitting its guard timer

Shared ATU-STI

The Access Transfer Update - Session Transfer Identifier (ATU-STI) is a SIP URI assigned during device registration, if 3GPP Rel10 (or later) enhanced Single Radio VCC (eSRVCC) is to be applied to that device’s sessions. In releases prior to Sentinel VoLTE 2.6.0 each TAS cluster member was required to have its own ATU-STI. As of release 2.6.0, TAS cluster members may share an ATU-STI, and indeed multiple TAS clusters may also share an ATU-STI.

The ATU-STI is used by the ATCF in order to route an INVITE due to ATU-STI to the SCC-AS as part of PS to CS SRVCC Access Transfer with ATCF enhancements. In the rest of this page, an INVITE due to ATU-STI, or an INVITE due to STN-SR that arrives at the SCC-AS is referred to as a "Handover INVITE".

Every TAS cluster member must be assigned a unique SCC-AS-URI that is routable between the TAS cluster. If multiple TAS clusters share an ATU-STI, then all TAS cluster members must be assigned a globally unique SCC-AS-URI, that must be routable from any node in any cluster, to any other node.

The ATU-STI must be routable between the ATCF (in the visited and home networks) and the SCC-AS (in the home network).

The capability of having a Shared ATU-STI is possible through the SCC-AS using the Session Tracking infrastructure.

Co-ordinating Access Transfer

A device may participate in several sessions at once. For example, it may have an ACTIVE session, and several HELD sessions; or it may have an ACTIVE session and an ALERTING session; and so-on. The SCC-AS signalling anchor instances for each of this device’s sessions may reside on different TAS cluster members, and possibly different TAS clusters. When multiple TAS nodes (regardless of which cluster) share an ATU-STI, a Handover INVITE may arrive at any of the nodes. Yet different nodes may be serving that device’s sessions. Therefore there is a need to co-ordinate Access Transfer between the nodes sharing the ATU-STI.

The following diagram shows a four node TAS cluster, where all nodes share a single ATU-STI. There are four sessions in progress. Three sessions share the same Correlation-MSISDN (C-MSISDN) (12345) and so are for the same device. Each session’s signalling anchor is located on different TAS cluster members. The Session Tracking Database (Cassandra) is storing the location and other meta-data (e.g. the SCC-AS-URI, and state fields) related to each of these sessions.

shared atu sti

The ATCF addresses the SCC-AS nodes via the ATU-STI. A common DNS configuration for the ATU-STI is to allow all cluster members to be resolved through the ATU-STI. So a single Handover INVITE with a Request-URI set to the ATU-STI will route to one of the four cluster members. A second Handover INVITE with the Request-URI set to the ATU-STI may route to the same, or another cluster member.

Handover INVITEs from the ATCF include the C-MSISDN in the P-Asserted-Identity header. The C-MSISDN is used by the SCC-AS in order to determine the Transferable Set. The Transferable Set includes any session to transfer, as well as any session that will not be transferred and is considered superfluous.

A simple co-ordination example

Assume that the system state is as described in the diagram above.

A Handover INVITE is sent from the ATCF with the Request URI set to the ATU-STI and a C-MSISDN equal to 45678. It is routed to the TAS cluster node SCC-AS-102. This node consults the Session Tracking Database, and observes that C-MSISDN 45678 has a single ACTIVE session, and that session resides on node SCC-AS-104. Therefore it proxies the INVITE request to the AS-URI SCC-AS-104. The TAS cluster node SCC-AS-104 then receives the proxied Handover INVITE and is able to perform SCC-AS procedures for transferring a single active session. In this case, the co-ordination is simply the proxying of an INVITE request.

A more complex co-ordination example

Assume that the system state is as described in the diagram above.

A Handover INVITE is sent from the ATCF with a Request URI set to the ATU-STI and a C-MSISDN equal to 12345. This Handover INVITE is routed to the TAS cluster node SCC-AS-104. The SCC-AS reads the Session Tracking Database and observes that C-MSISDN 12345 has three sessions. An ACTIVE session on node SCC-AS-101, a HELD session on node SCC-AS-102, and an ALERTING session on node SCC-AS-103. Now, the SCC-AS determines that the Transferable Set has a single ACTIVE session, and two superfluous sessions. Therefore the Handover INVITE is proxied to node SCC-AS-101.

Once the node SCC-AS-101 has performed the appropriate procedures to transfer the ACTIVE session, it then signals nodes SCC-AS-102 and SCC-AS-103 instructing them to clean up a superfluous session. It uses a SIP MESSAGE request, containing an OC-Access-Transfer-Procedure Header with an instruction to remove a superfluous session, and a Target-Dialog header indicating which session is superfluous.

The following call flow diagram illustrates this example.

access transfer coordination

Session Replication

As of version 2.8.0 of Sentinel VoLTE sticky session replication is supported.

Session Replication means that an existing session is available for processing despite the failure of the node it was originally running on. That is, the session is failed over to another node.

The phrase "sticky" refers to the fact that a session is processed on a node (say node 1), until such a time as the node fails. Once the session has failed over, it is then adopted to a new node (say node 2) and then sticks to the new node. Once the original node (node 1) recovers, the failed over session stays stuck to the new node (node 2).

There are several key concepts used to support Sticky Session Replication.

Outline of subsystems involved

rhino kv and session ownership

This diagram shows a cluster of two Rhino nodes. The cluster is not limited to two nodes. Each node runs in a single multi-threaded Process.

Applications and their components store Session State into the Local Session State Database. The SIS (a component providing the SIP interface) is configured to write state for established dialogs into the Local Session State Database. The Local Session State Database is configured to write data to a Key/Value Store

For further information related to Session State handling, refer to Storage of Session State.

When Session Replication is enabled, a record of which Rhino SLEE node is processing a particular protocol session (e.g. SIP Dialog) is stored by Session Tracking in the Session Ownership Subsystem.

DNS is used to route requests to a preferred node, with other cluster nodes acting as a backup. This mechanism scales horizontally as cluster size increases. For further information refer to DNS Redundancy and Record Route to enable fail-over of sticky sessions.

Storage of Session State

Session related information is stored in the Rhino platform’s Local Memory Database (MemDB local). This is resident in the JVM heap. Session related information contains variables such as:

  • SIP dialogs used in a B2BUA

    • dialog related information includes the Route set, CSeq and so-on

  • Feature state machine variables

  • Control variables for co-ordinating and controlling execution of sessions, and so-on

The Local Memory Database is the master for the data, and is configured to write data externally to a "key-value store" post transaction commit. In non-failure cases, the key-value store is only written to. Reads are served from the Local Memory Database.

In failure cases, a read-miss in the Local Memory Database causes a read to occur in the key-value store. Once the key and it’s value have been read they are then mastered in the Local Memory Database of the reading JVM process.

The "key-value store" is an external database. It is plugged into the data-storage layer of Rhino’s Memory Database (MemDB).

Rhino 2.6.1 and later includes out-of-the-box support for the Cassandra Database as the "key-value" store. For further information see Key/Value Stores.

In order to avoid inconsistency of the data, where multiple JVMs are accessing local data and not reading the "key-value store" a mechanism called Session Ownership is used.

The Local Memory Database delays local writes before pushing the modified data to the external key-value store. This is because Sessions typically undergo short periods of multiple signalling transactions, followed by relatively long idle periods.

Sequencing of a fail-over

Before failure
Figure 1. Before failure

Before failure shows a two node Rhino cluster, communicating with the CSCF via SIP, and with a Cassandra cluster shown as the "Cassandra State Store". The Rhino nodes contain all necessary components, including the Sentinel VoLTE application, SIS, and resource adaptors. Rhino is configured with a Session Ownership Store and Key Value store, both using the Cassandra cluster.

A call has begun, and is answered. The call is stick to Rhino node 1. As the call has been answered, it’s session state is marked for persistence - and so the session state is written out to the Key Value store ("Cassandra State store" in the diagram). A session ownership record for each SIP dialog related to the call is written into the Session Ownership store ("Cassandra State Store" in the diagram).

Node 1 fails
Figure 2. Node 1 fails

Node 1 fails shows that node 1 fails some time after the call is answered.

Session failover
Figure 3. Session failover

Session failover shows signalling after node 1 has failed. As an example a user places the call on hold. The CSCF uses DNS procedures as per RFC 3263 and the DNS Redundancy design. It finds that node 1 is not responsive and selects node 2, and sends the mid-dialog request to node 2. Node 2 consults the Session Ownership subsystem, and notices that node 1 (the owner of the SIP Dialog) is no-longer part of the cluster. Node 2 then takes over ownership of the SIP dialog and entire Session. It then retrieves session state from the "key-value" store.

Post failover
Figure 4. Post failover

Once all session failover handling has completed, the session is now stuck to node 2. This is shown in Post failover.

Before failure
Figure 5. Node 1 restarts

If a call lasts long enough it is possible that Node 1 restarts while the call is still open it is possible that Node 1 can receive SIP requests related to the call. This is due to the DNS Redundancy design. When this happens node 1 will recognise that it does not have state for the SIP dialog and proxy the request to node 2 through the use of the Session Ownership subsystem. This is shown in Node 1 restarts.

Limitations

The following are documented limitations with Session Replication:

  • Every Rhino/Savanna cluster that connects to a shared Cassandra cluster must have a unique Rhino Cluster ID. There is no checking or validation that the Rhino/Savanna cluster IDs are unique. Therefore either:

    • assign every Rhino cluster a unique cluster ID, or

    • provide each Rhino cluster with its own Cassandra cluster

  • Replicated Session data may only be used within a single cluster. This means that a session can fail-over from one cluster member to another, but not across clusters.

  • Replicated Session data is only used within a single Data centre. This means that session fail-over between sites is not supported.

  • Replicating Session data costs CPU cycles and memory, in both Rhino and the Cassandra Database. If a production installation is upgraded and wishes to make use of this capability, then capacity planning/hardware sizing should factored into the upgrade.

When Sentinel VoLTE is configured to use CAP charging, the IM-SSF service is used to do SIP to CAP translation. The IM-SSF service is more restrictive about how session replication and failover can be used:

  • Calls can only be fully replicated and failed over once they have entered the active state (i.e. an ACK for the initial INVITE has been received).

  • CAP dialogs are not replicated, so online charging capabilities for a call are lost after failover occurs.

Storage of Configuration

Each Rhino cluster stores it’s configuration in Profiles that are backed by a disk based SQL database, PostgreSQL. Each site runs one or more clusters. A cluster does not span sites.

No subscriber data is stored in the platform.

Companion Devices

Version 3.1.0 of Sentinel VoLTE includes support for companion devices using PS or CS networks.

Companion devices are VoLTE UEs that are linked to a primary device such as a smart phone. Smart watches are a common type of companion device.

Sentinel VoLTE’s companion device support enables primary and companion devices to share one phone number, that of the primary device:

  • A call to the shared number will alert both devices in parallel.

  • Calls from the companion device will appear to originate from the shared number.

This type of service is sometimes referred to as "One Number", "Multi-SIM" or "Multi-Device".

Overview of Operation

Companion device behaviour is enabled for a subscriber when the operator provisions companion device information in the subscriber’s Metaswitch-TAS-Services document in HSS transparent data. See Provisioning Companion Devices below.

The Metaswitch-TAS-Services document is read by the MMTel SubscriberDataLookupFromHSS feature. If companion device information is present, it is saved in session state for use by subsequent features.

If the subscriber does not have a Metaswitch-TAS-Services document, or the document’s companion device section is empty, then the call proceeds normally with no special companion device behaviour.

Note

By default Sentinel VoLTE does not query the HSS for the Metaswitch-TAS-Services document. This must be enabled as shown in Enable HSS Metaswitch-TAS-Services query.

Enabling this means that all MMTel calls will perform an extra Sh User-Data-Request query against the HSS.

An enable Companion Device section is located in Enable Companion Device page.

Shared and Undisclosed Identities

The terms "shared identity" and "undisclosed identity" are used when describing companion device features in Sentinel VoLTE:

  • The "shared identity" is the identity associated with the primary device — this is the IMS default public user identity configured in the HSS.

  • The "undisclosed identity" is the identity associated with a companion device. This identity is part of the same alias public identity set as the shared identity, but will not normally be shared with other parties on the network.

Undisclosed identities are not barred in the HSS — they are still allowed to make and receive calls in the VoLTE network. But by default, Sentinel VoLTE will try to ensure that other parties only see the shared identity, so that the primary and companion devices always appear to use the same identity.

Originating attempts

The originating MMTel-AS instance determines if the call is from a shared or undisclosed identity.

Originating call attempts from a companion device will typically use the shared identity already, as it should be the IMS default public identity (see Requirements of the Companion Device below).

However, if the originating MMTel-AS instance detects that a companion device is calling using an undisclosed identity, then it will change the calling party address to be the shared identity. The called party will then see that the call is from the shared identity. This behaviour is controlled by the Determine Shared And Undisclosed Identities feature.

The same behaviour applies when a companion device calling from the CS domain is re-originated in IMS using IMS Centralized Services. The original calling party address would be the MSISDN of the companion device (an undisclosed identity), but the originating MMTel-AS will update this to use the shared identity as well.

Terminating attempts

The terminating MMTel-AS instance determines whether the call is for the shared or undisclosed identity.

If the call is to an undisclosed identity, then the call can optionally be barred, to prevent the undisclosed identity from being used.

If the call proceeds, then the terminating MMTel-AS encodes companion device information in a SIP header on the INVITE request, which is forwarded downstream. This triggers additional behaviour in the terminating SCC-AS.

The terminating SCC-AS instance checks for the X-Msw-Companion-Device header, and if present, overrides the T-ADS routing mode to be "parallel". This means that all registered devices for the called party are alerted simultaneously, using SIP forking. Primary and companion devices using CS radio are alerted as well, if the SCC-AS can determine a CSRN for the devices.

The subscriber may answer the call using the primary or companion device, and the other forked legs are automatically cancelled.

Example Call Flows

Prerequisites

Requirements of the Companion Device

  • The companion device must be a 3G or 4G VoLTE/VoWifi-capable UE.

  • It will use the same IMS subscription and service profile as the primary device.

  • It may register its own IMS public identities.

  • The companion device public identities must belong to the same alias identity set as the primary device’s identities.

  • This means the default public identity for the companion device will be the same as the primary device.

Sentinel VoLTE Configuration

Companion Device Identity Model

It is expected that the shared and undisclosed public identities belong to the same IMS subscription, and are also part of the same alias public identity set (3GPP TS 23.008 §13.1.10). This means that all identities are in the same implicit registration set, and also share the same service profile and service data. This is illustrated in the diagram below:

companion identity model
Companion device IMS identity model

Provisioning Companion Devices

The relationship between a companion device and its primary device must be provisioned in two places — the IMS Subscription in the HSS, and in transparent data using the Metaswitch-TAS-Services service indication.

HSS IMS Subscription Provisioning

The subscriber’s IMS subscription in the HSS needs to be provisioned following the [companion-device-identity-model] above. This is not something that Sentinel VoLTE can do, this must be performed by the operator using the tools or APIs provided by the HSS vendor.

Transparent Data Provisioning

The subscriber’s transparent data in the HSS must also be provisioned with companion device information, so that Sentinel VoLTE can discover when a companion device user is making or receiving a call, and perform the necessary signalling.

Companion device information is provisioned in the Metaswitch-TAS-Services service indication, in the subscriber’s HSS transparent data. The provisioning of this information may be performed using either: the HSS vendor’s tools or APIs; the Sentinel VoLTE Provisioning REST API; or [manual-provisioning] as shown below.

The Metaswitch-TAS-Services document’s XML schema is shown in the MetaswitchServicesType API documentation.

Below is an example XML fragment showing that the user has a companion device that can use PS radio (VoLTE/VoWifi) and CS radio at the given MSISDN.

<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas">
  <complete-companion-device>
    <companion-device active="true"/>
    <operator-companion-device authorized="true">
      <shared-identity-sip>sip:+641234567@example.com</shared-identity-sip>
      <shared-identity-tel>tel:+641234567</shared-identity-tel>
      <hide-companion-identity>true</hide-companion-identity>
      <devices>
        <device active="true">
          <model>Acme Watch</model>
          <radio-access>
            <PS/>
            <CS msisdn="641234568"/>
          </radio-access>
        </device>
      </devices>
    </operator-companion-device>
  </complete-companion-device>
</metaswitch-services>
Manual Provisioning

This information can be provisioned manually using the REM HSS Transparent Data Editor.

Note
Automated Provisioning

It is expected that the network operator will integrate their backend systems with the HSS, so that when a subscriber’s companion device is activated, the necessary changes are automatically applied to the Metaswitch-TAS-Services service indication in HSS transparent data.

Charging

If the selected charging mode is Diameter Ro/Rf, there is no impact on charging when a companion device is in use. The calling and called party numbers are those of the primary device.

If CAMEL online charging is used via the IM-SSF service, and the SCC T-ADS forks an INVITE creating multiple outbound legs, then an IM-SSF service instance (and SCP dialog) is created for each outbound leg. Only one leg will be answered, and CAMEL charging will be performed as usual for that leg. The unused legs will terminate, and record zero-length calls on their SCP dialogs.

Note It is assumed that the SCP can handle multiple dialogs in this way.

MMTel Procedures

Originating

The originating MMTel instance’s SubscriberDataLookupFromHSS feature reads the calling parties' Metaswitch-TAS-Services document from HSS transparent data, and the Determine Shared And Undisclosed Identities feature uses this information to decide if the call is from a shared or undisclosed identity.

If the call was from an undisclosed identity, then the calling party address (in the From and P-Asserted-Identity headers) is rewritten to use the shared identity. This action is performed by the Hide Undisclosed Identity feature.

Terminating

The terminating MMTel instance’s SubscriberDataLookupFromHSS feature reads the calling parties' Metaswitch-TAS-Services document from HSS transparent data, and the Determine Shared And Undisclosed Identities feature uses this information to decide if the call is from a shared or undisclosed identity. If companion device information is found, this is added to session state.

If the called party is an undisclosed identity, then Determine Shared And Undisclosed Identities feature can optionally request that the MMTelICB feature bars the call, to prevent the undisclosed identity from being used.

If the call proceeds, then the terminating MMTel-AS encodes companion device information in the SIP header (X-Msw-Companion-Device) on the INVITE request, which is forwarded downstream. The header includes information about whether the device can be contacted using CS or PS. This triggers additional companion device behaviour in the terminating SCC-AS.

If the INVITE is retargeted by the MMTel-AS, then the X-Msw-Companion-Device header is automatically removed. This is because the terminating subscriber has changed, and the TAS does not know if the new subscriber has a companion device. The INVITE will return to the S-CSCF, which will trigger a new terminating MMTel instance if necessary. When the new terminating MMTel instance runs, SubscriberDataLookupFromHSS will read Metaswitch-TAS-Services for the new subscriber.

SCC T-ADS Procedures

Terminating

The terminating SCC instance’s SCCTADSDataLookup feature checks for the X-Msw-Companion-Device header. If found, then the T-ADS routing mode is set to "parallel", overriding the configured default routing mode. This means the SCCTADSParallelRouting feature will be used to send the INVITE to the called party, so that the primary and companion devices will be alerted simultaneously. This includes all devices whether they are currently attached to a PS or CS network.

If the companion device is registered then it will automatically be included in the determination of outbound routes. If a CSRN can be determined for the primary or the companion device, or both, then T-ADS will automatically fork to the CS network. This means that all devices will be alerted whether they are currently attached to CS or PS.

If T-ADS is configured with EnableSipInstanceRouting = true, then it will fork the INVITE towards the available PS contact addresses, including the companion device, if any.

If EnableSipInstanceRouting = false then T-ADS will create a single outbound PS leg, and let the S-CSCF perform the forking to all available PS contacts, which will include the companion device if it has registered with the S-CSCF.

If configured with EnableCompanionSipInstanceRouting = true, then T-ADS will automatically perform forking to all available PS contacts, if the call is to a subscriber with companion devices. This will override the EnableSipInstanceRouting value.

If configured with VoiceOverPSSupportRequired = true, then before determining the outbound PS routes, T-ADS will query the HSS T-ADS Information data reference to confirm that the subscriber is currently attached to the PS network.

More information about how outbound CS and PS routes are determined can be found in the SCCTADSDataLookup feature documentation.

Busy Behaviour

T-ADS can optionally terminate all forked legs when the first 486 (Busy Here) response arrives from any device. This means if multiple devices are alerting, and one device declines the call, then all devices will stop alerting as well. This behaviour is enabled by setting the ReleaseAllLegsOnBusy = true flag in the SCCTADSParallelRouting feature.

Stripping Preconditions

If a companion device is in use, then SIP forking is more likely to occur. SIP forking may cause issues with upstream devices that cannot properly handle preconditions negotiation on multiple early dialogs. If this is a problem, then this can be worked around by enabling the StripPreconditions feature.

When this feature is enabled, Sentinel VoLTE features that create parallel forks (currently SCCTADSParallelRouting and MMTelParallelFA) can request that preconditions are stripped from outbound INVITEs, so that the called party UE will not try to use preconditions.

Companion Device Call Flows

This page contains example call flows showing how calls to the primary device’s IMPU are forked to both primary and companion devices under various configurations.

Note

These call flows just show the path of the initial INVITE request up to when it is forked. From that point all scenarios would be identical to typical forking scenarios, so these parts have been omitted as they do not convey any new information.

Example with +sip.instance routing disabled

In this flow, T-ADS is configured with EnableSipInstanceRouting = false. This means that for the PS leg, T-ADS will forward the INVITE normally to the S-CSCF. The S-CSCF sees that there are multiple registrations for the user, so forks the INVITE to both devices.

CS and PS with +sip.instance routing disabled

companion cs and ps simple

Example with +sip.instance routing enabled

In this flow, T-ADS is configured with EnableSipInstanceRouting = true. This means that T-ADS will perform the forking itself, and create separate PS legs towards each registered device. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.

CS and PS with +sip.instance routing enabled

companion cs and ps enhanced

Example with +sip.instance routing enabled and Voice Over PS support required

In this flow, T-ADS is configured with EnableSipInstanceRouting = true and VoiceOverPSSupportRequired = true. This means that T-ADS will perform the forking itself, but will only create an outbound PS leg if the HSS can detect that the device is currently attached to the PS network. The Request-Disposition: no-fork header is added to the outbound INVITEs so that downstream nodes do not attempt to fork.

PS with +sip.instance routing enabled and Voice Over PS support required

companion ps enhanced vops

Example with primary and companion devices on CS

In this example, the called party (B) has a Metaswitch-TAS-Services document that indicates they have a companion device with CS support, by the presence of the device/radio-access/CS element as shown in the XML fragment below:

<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas">
  <complete-companion-device>
    <operator-companion-device authorized="true">
      <shared-identity-sip>sip:+641234567@example.com</shared-identity-sip>
      <shared-identity-tel>tel:+641234567</shared-identity-tel>
      <devices>
        <device active="true">
          <model>Acme Watch</model>
          <radio-access>
            <PS/>
            <CS msisdn="641234568"/>
          </radio-access>
        </device>
      </devices>
    </operator-companion-device>
  </complete-companion-device>
</metaswitch-services>

T-ADS is configured to query the HLR to determine CSRNs (UseHLRBasedCSRN = true). T-ADS sends a MAP SendRoutingInfo request to the HLR to determine the CSRNs for the primary and companion device.

Both devices on CS and PS with +sip.instance routing enabled

companion both ps cs

Example of hiding undisclosed identity

A companion device ("UE-X") is making a call, but is using its own undisclosed identity ("tel:+1234") as the calling party address. The originating MMTel instance retrieves the Metaswitch-TAS-Services document and sees that an undisclosed identity is being used. MMTel corrects the calling party address so that downstream devices see the shared identity ("tel:+5678")

Hiding an undisclosed identity

companion orig hide undisclosed

Example of barring call to undisclosed identity

In this example, the subscriber’s Metaswitch-TAS-Services document indicates that they have a companion device, and the shared identity is "sip:+2222@example.com"/"tel:+2222", which may be used to call the primary or companion device.

<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas">
  <complete-companion-device>
    <operator-companion-device authorized="true">
      <shared-identity-sip>sip:+2222@example.com</shared-identity-sip>
      <shared-identity-tel>tel:+2222</shared-identity-tel>
      <devices>
        <device active="true">
          <radio-access>
            <PS/>
          </radio-access>
        </device>
      </devices>
    </operator-companion-device>
  </complete-companion-device>
</metaswitch-services>

However, subscriber A attempts a call to the companion device’s undisclosed identity, "tel:+4444". This will be barred by the terminating MMTel instance.

Barring call to an undisclosed companion device identity

companion term undisclosed barred

Note When matching an identity with the shared identity in Metaswitch-TAS-Services, the identity is normalised using the Normalization Component.