Sentinel VoLTE Architecture

Transcription

1 Sentinel VoLTE Architecture TAS-022-Issue Release 1 May 2018

2 Notices Copyright 2017 Metaswitch Networks. All rights reserved. This manual is issued on a controlled basis to a specific person on the understanding that no part of the Metaswitch Networks product code or documentation (including this manual) will be copied or distributed without prior agreement in writing from Metaswitch Networks. Metaswitch Networks reserves the right to, without notice, modify or revise all or part of this document and/or change product features or specifications and shall not be responsible for any loss, cost, or damage, including consequential damage, caused by reliance on these materials. Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and products referenced herein are the trademarks or registered trademarks of their respective holders. 2

3 Contents 1 Sentinel VoLTE Architecture Intended audience Contents Overview Product Overview Open and fully-featured MMTEL-AS and SCC-AS on the Rhino TAS MMTel Services GSMA MMTel Supplementary Services Originating Identification Presentation/Restriction (OIP/OIR) (3GPP TS ) Terminating Identification Presentation/Restriction (TIP/TIR) (3GPP TS ) Communication Diversion (CDIV) (3GPP TS ) Communication Hold (HOLD) (3GPP TS ) Communication Barring (CB) (3GPP ) Operator Determined Barring (ODB) (3GPP TS and TS ) Explicit Communication Transfer (ECT) (3GPP TS24.629) Communication Waiting (CW) (3GPP TS24.615) Ad-hoc multi-party conference (CONF) (3GPP ) Anonymous Call Rejection (ACR) (3GPP TS24.611) XCAP interface (Ut) Explicit Communication Transfer Communication Transfer Modes Example Explicit Communication Transfer Call Flows Blind ECT Consultive ECT Instance models inside VoLTE Charging Out of Scope Flexible Alerting What is Flexible Alerting Group Members Alerting type

4 7.4 Flexible Alerting Features Flexible Alerting Mode Examples Call Flow Parallel Alerting for group type of multiple-users Parallel Alerting for group type of single-user Sequential Alerting for group of type multiple-users Sequential Alerting for group type of single-user Session Transfer to Own Device Service description Pre requisites Basic flow Features Charging Multiple OCS support Re-authorization CDR generation Offline charging via Diameter Rf Use of a Prepaid SCP via CAP SCC-AS Services IMS Centralised Services (ICS) support Terminating Access Domain Selection (T-ADS) Computing the Circuit Switched Routing Number The OC-Terminating-Domain Header Extensibility Service Continuity and Access Transfer Architecture Overview Major components JSLEE services Sentinel VoLTE in an LTE network B2BUA architecture ifc Triggering Chaining and the SCC and MMTEL Co-location using the Rhino SIS Subscriber Data Storage Supplementary services database Media resource function Cloud and virtualisation

5 12 Cloud and Virtualisation XCAP Support XCAP architecture within the IMS Sentinel VoLTE and XCAP HTTP URIs and XCAP Integration with Rhino Element Manager and Sentinel Integrated components Diameter Sh stacks and Rhino clusters XCAP Query Examples Get simservs document Get active state of OIP supplementary service Get default-behaviour of OIR supplementary service Enable OIP supplementary service Disable OIP supplementary service Set OIR default-behaviour to presentation-restricted Set OIR default-behaviour to presentation-not-restricted Instance Architecture for Sentinel VoLTE ifc triggering chaining and the SCC and MMTEL Co-location using the Rhino SIS Third Party Registrar Architecture Charging Support Charging instance model Charging within the instance model SDP and charging Charging and Sessions Terminating in WiFi Networks Charging over Diameter Rf interface Population of AVPs on the Diameter Ro interface CAMEL and SIP support for SCC Access to the HSS and HLR HSS access HLR access Supplementary Service Data Supplementary Service Data Access Supplementary Service Data stored in the HSS Supplementary Service Data stored in the HLR

6 21 SDP conflict management SDP conflict management overview Access transfer example SDP conflict types Session ID and version Media descriptions removed Media descriptions added Reusing a media description that was previously set to zero Payload type conflicts Conflict types not supported Using SDP conflict management in a feature SDP encoding issues and workarounds Number of ports in media lines Session Tracking Tracked Session Information Use of Cassandra Database Row Time-to-Live Consistency Level Cassandra Schema Minimising the impact of Database issues on Session processing Session Tracking Features Shared ATU-STI Co-ordinating Access Transfer A simple co-ordination example A more complex co-ordination example

7 1 Sentinel VoLTE Architecture 1.1 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. 1.2 Contents Find out here about: Sentinel VoLTE overview on page 8 an overview of the architecture and product XCAP support on page 48 support for XCAP, for user-equipment provisioning Instance architecture for Sentinel VoLTE on page 56 session processing and instances Access to the HSS and HLR on page 67 an overview of use of the HSS and HLR Third Party Registrar architecture on page 58 an overview of the Third Party Registrar. Charging support on page 60 how Sentinel VoLTE supports charging Sh Cache RA architecture SDP conflict management on page 70 how Sentinel VoLTE resolves SDP conflicts during access transfer CAMEL and SIP support for SCC on page 65 how Sentinel VoLTE interfaces to both the GSM and IMS core networks. 7

8 2 Overview These sections provide an overview of Sentinel VoLTE and its architecture: 8 Product Overview on page 9 Architecture Overview on page 42.

9 3 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. 3.1 Open and fully-featured 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. 3.2 MMTEL-AS and SCC-AS on the Rhino TAS The Sentinel VoLTE solution implements the Multimedia Telephony Application Server (MMTEL-AS) on page 11 and the Service Centralisation and Continuity Application Server (SCC-AS) on page 36 on the Rhino TAS. It includes built in support for multiple Charging on page 34 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. 9

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

11 4 MMTel Services 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 GSMA required Rhino Sentinel VoLTE delivers these services in an LTE/IMS network, Supplementary Services on following the GSMA IR.92 (v9.0) and IR.94 (v10.0) standards. page 12 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. Flexible Alerting on page 3GPP defines Flexible Alerting in TS and the flexible alerting 25 subscriber data schema is defined in TS and TS The service allows the creation of a group, composed by members, bounded by a single number, called Pilot Number. When a call to the Pilot Number is identified VoLTE will alert all the members of the group and the caller is bounded to the first member of the group that answers the call. Explicit Communication 3GPP defines Explicit Communication Transfer in TS The Transfer on page 19 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 transfeee. Session Transfer to Own Is a service that allows an existing originating or terminating session to Device on page 31 be transfered to another device. The target device is the one that pulls the session. 11

12 5 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. 5.1 Originating Identification Presentation/Restriction (OIP/OIR) (3GPP TS ) 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: MMTelOIP MMTelOIR 5.2 Terminating Identification Presentation/Restriction (TIP/TIR) (3GPP TS ) 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: 12 MMTelTIP MMTelTIR

13 5.3 Communication Diversion (CDIV) (3GPP TS ) 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 Divert communications to a different destination if the original destination is Reachable) unreachable. CD (Call Deflection) Enables subscriber to divert incoming communications to a different destination. CFNL (Not Logged In/ Divert communications to a different destination if the original destination is Not Registered) 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. 5.4 Communication Hold (HOLD) (3GPP TS ) 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. 5.5 Communication Barring (CB) (3GPP ) The Communication Barring (CB) service offers the following services: Service Behaviour Incoming Communication Barring (ICB) Rejects incoming communications that fulfil certain conditions. 13

14 Outgoing Communication Barring Rejects outgoing communications that fulfil certain (OCB) conditions. Anonymous Communication Rejection Specific case of ICB service, that allows barring of incoming (ACR) 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 Barring of all incoming communications when subscriber is roaming outside roaming the home network. Outgoing International Barring of all outgoing communications to international destinations. Outgoing International- Barring of all outgoing communications to international destinations, except exhc 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: MMTelICB MMTelOCB 5.6 Operator Determined Barring (ODB) (3GPP TS and TS ) 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 Rejects outgoing communications that fulfil certain (OCB) conditions, as specified by the operator. Explicit call transfer (ECT) Prevent the ECT service from running for the served user. 14

15 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 Barring of all outgoing communications roaming outside the roaming home PLMN country. Barring of All incoming Barring of all international Barring of Incoming International when Barring of all incoming communications roaming outside the roaming home PLMN country. Barring of Outgoing Premium Rate Barring of all information communications for subscribers Communications Information under this category. [Note 1] Barring of Outgoing Premium Rate Barring of all entertainment communications for subscribers Communications Entertainment under this category. [Note 1] Barring of Outgoing Premium Rate Barring of all information communications for subscribers Calls Information When Roaming under this category when roaming. [Note 1] Outside HPLMN Country Barring of Outgoing Premium Rate Barring of all entertainment communications for subscribers Calls Entertainment When Roaming under this category when roaming. [Note 1] Outside HPLMN Country Barring of Invocation of Communication Barring of invocation of explicit communication transfer Transfer Barring of Invocation of Communication Not supported Transfer where al least one Leg is charged Barring of Invocation of Communication Not supported Transfer where al least one Leg is charged at International Rates 15

16 Barring of Invocation of Chargeable Not supported Communication Transfer Barring of Multiple Invocation of Barring of multiple invocation of communication transfer Communication Transfer Barring of Operator Specific Barring Barring of all calls when the operator defined rules type 1 Type1 applies. See Operator Specific Barring Rules Barring of Operator Specific Barring Barring of all calls when the operator defined rules type 2 Type2 applies. See Operator Specific Barring Rules Barring of Operator Specific Barring Barring of all calls when the operator defined rules type 3 Type3 applies. See Operator Specific Barring Rules Barring of Operator Specific Barring Barring of all calls when the operator defined rules type 4 Type4 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 Not applicable to the AS. The AS has no procedure to avoid country a subscriber from Roaming. Barring of Registration of any Not supported on the XCAP server communication diverted-to address Barring of Registration of any Not supported on the XCAP server International communication diverted-to address Barring of Registration of any Not supported on the XCAP server International communication diverted-to address Ex-HPLMNC Barring of Supplementary Services Not supported on the XCAP server Management Note 1 : The indication of a "Premium Rate Communications Information or Entertainment" is defined on TS Release 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". 16

17 For more information see Operator Determined Barring. 5.7 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 on page 19 page. This service is implemented by the feature MMTelECT. 5.8 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. 5.9 Ad-hoc multi-party conference (CONF) (3GPP ) 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 Via a SIP REFER request. conference Remove user from Only the conference creator can remove participants from the call. conference 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: MMTel Conference MMTel Conference Subscription 17

18 5.10 Anonymous Call Rejection (ACR) (3GPP TS24.611) See Communication Barring on page XCAP interface (Ut) Sentinel VoLTE supports the XCAP interface over the Ut reference point between the UE and MMTELAS, as per 3GPP TS For more information please refer to the XCAP Support on page 48 section. For information on the Authorization Proxy please refer to Sentinel Authentication Gateway. 18

19 6 Explicit Communication Transfer 3GPP defines Explicit Communication Transfer in TS 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 transfeee. 6.1 Communication Transfer Modes There are two scenarios in which a transfer can be initiated: Consultive Transfer: The transferor has a consultation communication with the transfer target. This allows: Classical charging models Anonymization of the transfer target Blind Transfer: The transferee 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. 6.2 Example Explicit Communication Transfer Call Flows Various IMS core elements and some SIP messages are omitted from the call flow diagrams for the sake of clarity. 19

20 6.2.1 Blind ECT 20

21 6.2.2 Consultive ECT 6.3 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 21

22 the transferor, the transferee and the transfer target being served by the same node and some IMS core elements are not shown. The diagram below shows the MMTel instances when a communication transfer happens among A, B and C, where A is the transferor, B is the transferee and C is transfer target. When A initiates a dialog towards B, the INVITE request traverses the IMS network until it reaches the S-CSCF serving the user. The S-CSCF based on the registration data and the ifc in HSS forwards the messages to the VoLTE AS serving as MMTel AS. On receiving the INVITE request, the AS creates a session to process the call (A-orig) and apply the business rules including the MMTel services. After applying the business rules the AS forwards the INVITE request towards S-CSCF according to the B2BUA procedures. The S-CSCF identifies a terminating call for B and forwards the signalling to AS again after checking the registration records for B and determining the AS serves B. This time the AS will create another session to deal with the call (B-term). This session will apply the business rules for the terminating call for B. Now A and B are in communication. When A, acting as transferor, sends a SIP REFER message to B to refer to C, the ECT feature running in the A-orig instance changes the Refer-to-target header to a 22

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

24 For this scenario, when B sends a REFER to A to refer to C, the new ECT URI is generated on the Bterm 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. 6.4 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. 24

25 7 Flexible Alerting 7.1 What is Flexible Alerting 3GPP defines Flexible Alerting in TS and the flexible alerting subscriber data schema is defined in TS and TS The service allows the creation of a group, composed by members, bounded by a single number, called Pilot Number. When a call to the Pilot Number is identified VoLTE will alert all the members of the group and the caller is bounded to the first member of the group that answers the call. 7.2 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. 7.3 Alerting type There are two alerting modes for FA. These are: sequential 25

26 parallel In the sequential alerting mode the group members are alerted in order, with one member sending a final response or timing out before the next is alerted. In the parallel alerting mode all group members are alerted at once. Flexible Alerting allows the call to continue after final responses on one or more group members. 7.4 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. 7.5 Flexible Alerting Mode Examples Call Flow 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. 26

27 7.5.2 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. 27

28 7.5.3 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. 28

29 7.5.4 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. 29

30 30

31 8 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 on page 31 ). 8.1 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. 8.2 Pre requisites The subscriber has to have the STOD service enabled (see MMTelStodEnabled ) The special number has to be configured in the AS (see DetermineVoltePlanId ) The session tracking is enabled (see MMTelStodEnableSessionTracking ) The provisioning is done by feature profile see the DetermineVoltePlanId for the MmtelTransferNumber configuration see the MMTelStodEnabled for the subscriber provisioning 8.3 Basic flow The flow below shows a basic call flow with a simple transfer. 31

32 8.4 Features The service is composed of several features: 32

33 DetermineVoltePlanId MMTelStodEnableSessionTracking MMTelStodEnabled MMTelStodBind STODDetermineTargetSession MMTelStodTriggerAnchor MMTelStodProcessHandover The interactions among the features are show below: The DetermineVoltePlanId sets the session to mmtel and also checks if the request URI is for the STOD service. MMTelStodEnableSessionTracking creates an external tracking key for the session and adds it to the set in session state. The TrackSessionPreAnswer feature is used to process the session tracking information from session state. The MMTelStodEnabled checks its profile to assert that the user is allowed to trigger the service and if allowed the the MMTelStodEnableSessionTracking will set the proper procedures to make the session to be tracked and the MMTelStodBind feature will bind the session to an ACI name. This ACI name will be reconstructed by the MMTelStodDetermineTargetSession feature on receiving a transfer INVITE and the MMTelStodTriggerAnchor will route the transfer INVITE to the existing session. The MMTelStodProcessHandover intercepts the transfer INVITE and do the procedures to connect the existing called party to the new calling party. 33

34 9 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 on page 34 Re-authorization on page 35 CDR generation on page 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. 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. 34

35 9.2 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 on page 60 section. 9.3 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. 9.4 Offline charging via Diameter Rf VoLTE sends charging information to a configured Charging Data Function via Diameter Rf interface. The charging messages contain all information necessary to charge a session and VoLTE supports the Start, Interim and Stop messages as just and event message. The Rf Control Resource Adaptor receives request from VoLTE charging features and ensure the messages are persisted in the CDF or in a local disk buffer is case the CDF is not available. As soon as the CDF is available it will send the messages stored locally until the buffer is empty. For more information see Rf Control Resource Adaptor Architecture. 9.5 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. 35

36 10 SCC-AS Services What are SCC-AS services? The SCC-AS is a home network element that enables three main functions: IMS centralised services (ICS) on page 36 Terminating Access Domain Selection (T-ADS) on page 37 Service Continuity on page 39 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. 36

37 In this diagram: The UE attempts a CS originated call. The MSC VLR sends an InitialDP to the IN SCP function in Sentinel VOLTE, which then returns an IMS Routing Number (IMRN) The CS network uses the IMRN to route towards the IMS. The IMS network then routes the call based on the IMRN contained within the Request-URI of the SIP INVITE The SCC-AS correlates the SIP INVITE with the received InitialDP. The SCC-AS generates an IMS session on behalf of the CS user. This mechanism can be considered as network-facilitated ICS Terminating Access Domain Selection (T-ADS) For sessions that terminate in the IMS domain, the SCC-AS is responsible for deciding whether to route the session to the CS network or the PS network depending on registration, network characteristics, and subscriber preferences. This is called T-ADS. Out of the box, Sentinel VoLTE supports a standard algorithm for T-ADS, which is fully extensible and customisable by a third party: Sentinel VoLTE optionally performs a Diameter Sh lookup on the HSS to determine IMS voice over PS Session Supported Indication The Circuit Switch Routing number is formed through either querying the HSS for the Correlation MSISDN (C-MSISDN), or the HLR for the Mobile Station Roaming Number (MSRN) The third-party registration state is also examined, in order to determine subscriber state. In addition to the standard T-ADS algorithm, Sentinel VoLTE supports different strategies for routing signaling towards PS or CS domains. These include: Support for flexible sequential routing. Sentinel VoLTE can send INVITEs towards the PS or CS domains in either order (PS first, or CS first). Support for routing towards a single domain only (either PS only, or CS only). Support for parallel routing. Sentinel VoLTE initiates a Parallel Fork, sending INVITE messages towards the PS and CS domains simultaneously. The selected access network depends on received responses. For further details refer to the Terminating Access Domain Selection Features section of the Administration Guide. 37

38 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. 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 SCCAS 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, 38

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

40 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 on page 79, and a Shared ATU-STI on page

41 Features that implement Access Transfer are documented in the Packet Switched to Circuit Switched Access Transfer Features section of the administration guide. 41

42 11 Architecture Overview OpenCloud s Rhino Sentinel VoLTE product implements the Service Centralisation and Continuity Application Server (SCC-AS) on page 36 and Multimedia Telephony Application Server (MMTel-AS) on page 11. 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. VoLTE includes the session processing parts: an extensible Third Party Registrar on page 58 with support for either HSS or Cassandra as Storage system for Registrar Subscriber Data 42 an extensible IN SCP

43 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 on page 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) 11.2 Sentinel VoLTE in an LTE network The diagram below shows where Sentinel VoLTE fits into an LTE network. 43

44 11.3 B2BUA architecture The B2BUA architecture includes: ifc Triggering Chaining and the SCC and MMTEL on page 44 Co-location using the Rhino SIS on page 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. 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. 44

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

46 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 on page

47 12 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. 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. 47

48 13 XCAP Support Sentinel VoLTE includes the following features to support XCAP. See also the XCAP Query Examples on page XCAP architecture within the IMS The following diagram illustrates Sentinel VoLTE s XCAP architecture within the IMS: XCAP s use within IMS is described in 3GPP TS Sentinel VoLTE and XCAP Sentinel VoLTE supports the use of XCAP over HTTP. The diagram above shows this as MMTEL-AS and Other-AS not as an AP in the IMS architecture. Sentinel VoLTE s XCAP server support requires that the Ut/HTTP Requests have passed through a separate Authentication Proxy (not provided by the Sentinel VoLTE product) before reaching the XCAP server. OpenCloud provides an implementation of the Authentication Proxy (Ut interface) in the Sentinel Authentication Gateway product. 48

49 HTTP URIs and XCAP Rhino VoLTE s XCAP server runs alongside other HTTP servers. So it does not run on the root URI of a server; rather, it runs on a URI relative to the root URI. For example, if the XCAP Server is running on xcap.server.net with port 8080, the base XCAP URL will be The IMS XCAP standards place the XCAP URI at the root of the host. This means URI re-writing may be required before hitting Sentinel VoLTE s XCAP server. This could be done via the AP, or via an HTTP proxy or web-server (such as Apache Web Server) between the AP and Sentinel VoLTE s XCAP server 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 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: Integrated components The diagram above includes these components: The HTTP clients can be: 49

50 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. Each of the components has their own security configuration Diameter Sh stacks and Rhino clusters Each REM application includes one or more instances of the Diameter Sh 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 Diameter Sh stack has Diameter peer configuration including Realm tables for multiple Destination Realms. In other words, a single Diameter stack instance can be configured to connect to more than one distinct HSS. Each instance of the Diameter Sh 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.) 50

51 14 XCAP Query Examples Below are examples of XCAP queries with Sentinel VoLTE. These examples assume that the XCAP Server is running on localhost with port Get simservs document Method GET URL xcap/simservs.ngn.etsi.org/users/si Headers X-3GPP-Asserted-Identity: Payload N/A Response HTTP/ 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=" uri.etsi.org/ngn/params/xml/sims ervs/xcap"> <originating-ident ity-presentation active="true" /> <originating-identity-prese ntation-restriction active="tr ue"> <default-behaviour>presen tation-not-restricted</default -behaviour> </originating-iden tity-presentation-restriction> </ ns2:simservs> 51

52 14.2 Get active state of OIP supplementary service Method GET URL xcap/simservs.ngn.etsi.org/users/si active Headers X-3GPP-Asserted-Identity: Payload N/A Response HTTP/ OK Headers ETag: xxxxxxxxx Content-Type: application/xcap-att+xml Payload true 14.3 Get default-behaviour of OIR supplementary service Method GET URL xcap/simservs.ngn.etsi.org/users/si originating-identity-presentation-r estriction/default-behaviour Headers X-3GPP-Asserted-Identity: Payload N/A 52

53 Response HTTP/ OK Headers ETag: xxxxxxxxx Content-Type: application/xcap-el+xml Payload <?xml version="1.0" encoding=" UTF-8" standalone="yes"?> <defaultbehaviour>presentation-not-restrict ed</default-behaviour> 14.4 Enable OIP supplementary service Method PUT URL xcap/simservs.ngn.etsi.org/users/si active Headers X-3GPP-Asserted-Identity: ContentType: application/xcap-att+xml Payload true Response HTTP/ OK Headers ETag: xxxxxxxxx Payload N/A 14.5 Disable OIP supplementary service Method PUT URL xcap/simservs.ngn.etsi.org/users/si 53

54 active Headers X-3GPP-Asserted-Identity: ContentType: application/xcap-att+xml Payload false Response HTTP/ OK Headers ETag: xxxxxxxxx Payload N/A 14.6 Set OIR default-behaviour to presentation-restricted Method PUT URL xcap/simservs.ngn.etsi.org/users/si originating-identity-presentation-r estriction/default-behaviour Headers X-3GPP-Asserted-Identity: ContentType: application/xcap-el+xml Payload <default-behaviour>presentationrestricted</default-behaviour> Response HTTP/ OK Headers ETag: xxxxxxxxx Payload 54 N/A

55 14.7 Set OIR default-behaviour to presentation-not-restricted Method PUT URL xcap/simservs.ngn.etsi.org/users/si originating-identity-presentation-r estriction/default-behaviour Headers X-3GPP-Asserted-Identity: ContentType: application/xcap-el+xml Payload <default-behaviour>presentationnot-restricted</default-behaviour> Response HTTP/ OK Headers ETag: xxxxxxxxx Payload N/A 55

56 15 Instance Architecture for Sentinel VoLTE Features of the instance architecture of the Sentinel VoLTE include: ifc triggering chaining and the SCC and MMTEL on page 56 Co-location using the Rhino SIS on page 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 MMTELAS as the only two TAS invoked for a session, and using MMTEL for both originating and terminating treatment: 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. 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 56

57 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: 57

58 16 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 INVITEtriggered Session Plans. 58

59 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 RA to access the HSS or Cassandra CQL RA to access the Cassandra database. For more information, see Sentinel Registrar Overview and Concepts documentation. 59

60 17 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 MMTELAS Charging instance model The following image shows the three key types of charging instances. Each is a Sentinel VoLTE B2BUA. The diagram shows the three key concepts: There are Originating, Terminating, and Forwarding MMTEL instances. 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. 60

61 Forwarded Sessions may be forwarded, and then forwarded, and so on, infinitely. To stop infinite forwarding, the History-Info header is used. MMTEL s CDIV Service (a feature in Sentinel VoLTE) is responsible for stopping infinite forwarding 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: One Originating for A#B (charging the A party for a call to B) One Terminating for A#B (charging the B party for a call from A) One Originating_CDIV (or Forwarding) for B#C (charging the B party for a call to C) One Terminating for B#C (charging the C party for a call from B) 61

62 In the Terminating case typically if the B party is not roaming then the B party is often not charged. In order to disable Online Charging for the B-parties Terminating Instance (for example, when not roaming), you can: 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: 62

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

64 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 detailed records are sent via Diameter Rf interface to any CDF connected. The AVPs that are populated on the Diameter Rf interface are documented on the Rf Interface AVPs section of the Sentinel VoLTE Administration guide. For more information on Rf Control Resource Adaptor see Rf Control Resource Adaptor Architecture 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. 64

65 18 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. 65

66 These services each contain features for IMS Service Centralisation. Of note are the Re-origination features. One sits in the Sentinel IN service, and the other in the Sentinel SIP service. Re-origination data is stored in the Correlation RA. More information on these features is described in the VoLTE Administration Guide, under the Service Centralisation Features. 66

67 19 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 nontransparent data, access it through the Sh Cache 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. For more information on Sh Cache Resource Adaptor see Sh Cache RA architecture HLR access All components that need access to data from the HLR, access it through the CGIN MAP component. 67

68 This includes: Sentinel Registrar Sentinel SIP Invite Session Processing (i.e. SCC and MMTEL) 19.3 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 on page 69 68

69 20 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 Nontransparent data, access it through the Sh Cache 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 This capability enables an administrator to query Rhino Element Manager and edit the Supplementary Service Data For more information about the Sh Cache Resource Adaptor see Sh Cache RA architecture 20.2 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 69

70 21 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 on page 77 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. 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. 70

71 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 on page 73 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). 71

72 UE-A moves out of coverage range, triggering a PS-CS access transfer. The access transfer INVITE sent by the ATCF has different content to the previous SDP offer from A. This may be because the media was not anchored in the ATGW, so the ATCF must send a completely new SDP offer to the SCC-AS. The SCC-AS can see that the new offer is different to the previous one; the session IDs and versions differ, and also there is only one media description (no video). The SCC-AS must perform a remote update re-invite with UE-B, so that UE-B knows about the media change. If the SCC-AS just sent the new SDP offer to UE-B verbatim, UE-B would have to reject it, because the offer uses a different session ID ( 45678, not ), and the version is out of sequence. UE-B would expect the next offer to have session ID and version (incremented by one from the previous SDP offer 1). To resolve this conflict, the SCC-AS adjusts the SDP offer so that it uses the correct session ID and version, and also sets the video media description s port to zero so that UE-B knows it is no longer in use (media ( m= ) lines in SDP cannot be removed during a session, only changed or added). With the adjusted SDP offer 2a, UE-B can process it correctly, switching to the new audio stream and stopping the video stream. Conversely when the SDP answer 2a arrives at the SCC-AS, the disabled video media description must be removed. This is so that the number of media descriptions in the answer matches what was in the ATCF s original SDP offer 2. 72

73 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. 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 o= IN IP New SDP offer from source o= IN IP Output SDP offer to destination o= IN IP Use session ID and version + 1 from previous offer. 73

74 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 m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 New SDP offer from source m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 Output SDP offer to destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 New media after access transfer has audio only. Copy new audio description and disable previous video Original media with audio & description. video. 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 m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 SDP answer from destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 New media from source leg was audio only. Output SDP answer to source m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 Disabled video description Destination answers, accepting removed in answer to source. audio stream and leaving video disabled 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. 74

75 Previous SDP offer to destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 New SDP offer from source m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 Output SDP offer to destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 New source offer adds a video Both media descriptions copied description. 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 m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 SDP answer from destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 Output SDP answer to source m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video 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 on page 74 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 m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 Video line was disabled by New SDP offer from destination m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 100 a=rtpmap:100 H264/90000 Output SDP offer to source m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 100 a=rtpmap:100 H264/90000 previous media descriptions 75

76 removed on page 74 New video media reuses same Existing and new media interaction. position as previously disabled descriptions are copied to stream. 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 m=audio RTP/ AVP 97 a=rtpmap:97 AMR/8000/1 m=video RTP/AVP 98 a=rtpmap:98 H263/90000 Previously the audio payload type 97 mapped to AMR/8000/1. New SDP offer from source m=audio RTP/AVP a=rtpmap:97 AMRWB/16000/1 a=rtpmap:98 AMR/9000/1 m=video RTP/AVP 101 a=rtpmap:101 H263/90000 Output SDP offer to destination m=audio 0 RTP/AVP 97 m=video RTP/ AVP 101 a=rtpmap:101 H263/90000 m=audio RTP/AVP a=rtpmap:97 AMRWB/16000/1 a=rtpmap:98 AMR/9000/1 The new offer maps payload In the rewritten offer, zero the type 97 to AMR-WB/16000/1. conflicting media description, This is a conflict. 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 m=audio RTP/AVP a=rtpmap:97 AMRWB/16000/1 a=rtpmap:98 AMR/9000/1 m=video RTP/AVP 101 a=rtpmap:101 H263/ SDP answer from destination m=audio 0 RTP/AVP 97 m=video RTP/ AVP 101 a=rtpmap:101 H263/90000 m=audio RTP/AVP 97 a=rtpmap:97 AMRWB/16000/1 Output SDP answer to source m=audio RTP/ AVP 97 a=rtpmap:97 AMR-WB/16000/1 m=video RTP/ AVP 101 a=rtpmap:101 H263/90000

77 Offer has audio in position 1, Due to payload type conflict Transformed answer copies video in position 2. above, answer has video in audio from position 3 to position position 2, audio in position 3. 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 or 31700/1, which are equivalent. By default, the SDP implementation used in Sentinel VoLTE (NIST SDP) uses the latter form, adding /1 when one port is used. 77

78 SDP implementations on other devices may not expect the /1 suffix, despite this being valid SDP syntax. This can be worked around by setting a Java system property to disable adding the /1 suffix when the media uses one port. Simply add Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=true to the JVM command line. In the Rhino SDK, add Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=true to the file $RHINO/ config/jvm_args. In a production Rhino node, add the following to $RHINO/node-xxx/readconfig-variables : OPTIONS="$OPTIONS Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=true" 78

79 22 Session Tracking Sentinel VoLTE includes a capability to store information related to ongoing SIP Sessions in a Cassandra Database. This enables global access from various Sentinel VoLTE cluster nodes to the same information. Session Tracking is accessible to features through an API. It is primarily used by the SCC-AS supporting implementation of various Access Transfer mechanisms. Sessions are said to be Tracked Sessions if their existence and meta-data is stored in the Cassandra Database. Not all sessions are tracked. 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. In order to enable the Re-INVITE Based Three-party conference setup the SCC-AS will track 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 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 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. 79

80 State of Tracked Session Input to session tracking Session tracking behaviour Does not exist Initial INVITE request received and Session tracking creates appropriate a feature enables half dialog session rows in the Database. Each row is in tracking the half dialog state. A dialog creating 1xx response is Each half dialog row is removed from received the database. A 'PRE_ALERTING' Half dialog 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 Early A dialog creating 1xx response with a New rows representing the Early dialog different remote-tag (a fork) is received for the fork are created in the database. An ACK to the 2xx-INVITE is received Any rows representing forked dialogs at the TAS 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 Any rows representing the confirmed received at the TAS dialog are updated to be state 'HELD' in the database. Confirmed A 2xx response to a resume request Any rows representing the confirmed received at the TAS dialog are updated to be state 'ACTIVE' in the database. Confirmed A BYE request is sent/received on the Any rows representing the confirmed Served User s Dialog dialog are removed Use of Cassandra Database The Cassandra database is used by session tracking due to its high availability, and replication capabilities. Each site runs a TAS cluster, and a Cassandra cluster. The minimum number of nodes per-site for the Cassandra cluster is three, and for the TAS cluster is two. Each site should essentially repeat this structure. 80

81 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 Tracking 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 Session Tracking uses two tables to represent a Tracked Session. Each tracked session has one or more rows present in the Cassandra Database. These are the trackeddialog table, and the 81

82 trackeddialogkeys table. The trackeddialog table has the fully-formed Dialog ID of the SIP dialog as the primary key. The trackeddialogkeys table uses a Cassandra capability of a two part primary key, essentially to provide "Additional keys" to look up data, as Cassandra does not provide an optimal secondary key mechanism. The primary key for the trackeddialogkeys table is a composite of the trackingkey (text), and the fully-formed dialog ID. The schema itself can be viewed in External Session Tracking Cassandra Schema 22.3 Minimising the impact of 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 22.4 Session Tracking Features Session Tracking is implemented by the External Session Tracking Features in the Sentinel VoLTE Administration Guide. 82

83 23 Shared ATU-STI The Access Transfer Update - Session Transfer Identifier (ATU-STI) is a SIP URI assigned to a device during 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 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 on page 79 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 SCCAS-URI, and state fields) related to each of these sessions. 83

84 The ATCF addresses the SCC-AS nodes via the ATU-STI. A common DNS configuration for the ATUSTI 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 CMSISDN 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 on page. A Handover INVITE is sent from the ATCF with the Request URI set to the ATU-STI and a C-MSISDN equal to It is routed to the TAS cluster node SCC-AS-102. This node consults the Session Tracking Database, and observes that C-MSISDN has a single ACTIVE session, and that session 84