Sentinel VoLTE 3.1.0 :: Sentinel VoLTE Architecture

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

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

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

A call to the shared number will alert both devices in parallel.
Calls from the companion device will appear to originate from the shared number.

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

Overview of Operation

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

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

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

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

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

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

Shared and Undisclosed Identities

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

The "shared identity" is the identity associated with the primary device — this is the IMS default public user identity configured in the HSS.
The "undisclosed identity" is the identity associated with a companion device. This identity is part of the same alias public identity set as the shared identity, but will not normally be shared with other parties on the network.
- Note that an alias public identity set is a special case of implicit registration set. See Companion Device Identity Model below.

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

See also Companion Device Identity Model below.

Originating attempts

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

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

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

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

Terminating attempts

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

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

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

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

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

Example Call Flows

See Companion Device Call Flows.

Prerequisites

Requirements of the Companion Device

The companion device must be a 3G or 4G VoLTE/VoWifi-capable UE.
It will use the same IMS subscription and service profile as the primary device.
It may register its own IMS public identities.
The companion device public identities must belong to the same alias identity set as the primary device’s identities.
- See Companion Device Identity Model below.
This means the default public identity for the companion device will be the same as the primary device.

Sentinel VoLTE Configuration

The SubscriberDataLookupFromHSS feature must be configured to retrieve the Metaswitch-TAS-Services document. See Enable HSS Metaswitch-TAS-Services query.
The StripPreconditions feature may need to be enabled in some configurations. See Stripping Preconditions below.

Companion Device Identity Model

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

Companion device IMS identity model

Provisioning Companion Devices

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

HSS IMS Subscription Provisioning

The subscriber’s IMS subscription in the HSS needs to be provisioned following the Companion Device Identity Model above. This is not something that Sentinel VoLTE can do, this must be performed by the operator using the tools or APIs provided by the HSS vendor.

Transparent Data Provisioning

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

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

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

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

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

Manual Provisioning

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

REM’s configuration must first be updated as described in Required configuration for Metaswitch TAS Services.
This can be automated with the sentinel-volte-mappings-config script as described in Populate XCAP server settings and MMTel service data.

Automated Provisioning

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

Charging

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

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

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

MMTel Procedures

Originating

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

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

Terminating

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

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

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

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

SCC T-ADS Procedures

Terminating

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

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

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

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

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

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

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

Busy Behaviour

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

Stripping Preconditions

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

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

Previous page Next page