Version 3.0.0 of Sentinel VoLTE adds experimental support for companion devices.

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.

Originating attempts

Originating call attempts from the companion device require no special treatment in Sentinel VoLTE. It is assumed the companion device uses the public identity of the primary device, as it is in the same implicit registration set (see Requirements of the Companion Device below).

Terminating attempts

If the terminating MMTel-AS instance finds companion device information in the called parties' Metaswitch-TAS-Services document, then it is encoded in a SIP header (X-Msw-Companion-Device) on the INVITE request, and 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. This also includes the primary device even if it is using 3G/CS radio.

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

  • These identities should be barred, but in the same implicit registration set as the primary device’s identities.

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

Restrictions

  • Only 4G (VoLTE/VoWifi) companion devices are supported in this release. Devices using 3G radio access will be supported in a future release.

Sentinel VoLTE Configuration

Provisioning Companion Devices

A subscriber’s companion device information must be provisioned in HSS transparent data, using the Metaswitch-TAS-Services service indication.

The 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 capable of PS radio (VoLTE/VoWifi), which is currently the only supported type of companion device.

<metaswitch-services xmlns="http://metaswitch.com/XMLSchema/tas">
  ...
  <complete-companion-device>
    <operator-companion-device authorized="true">
      <radio-access>
        <network>PS</network>
      </radio-access>
    </operator-companion-device>
  </complete-companion-device>
  ...
</metaswitch-services>

Manual Provisioning

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

Note

Automated Provisioning

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

Charging

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

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

MMTel Procedures

The terminating MMTel instance’s SubscriberDataLookupFromHSS feature reads the Metaswitch-TAS-Services document from HSS transparent data. If companion device information is found, this is added to session state. The SetCompanionDeviceHeaders feature adds the X-Msw-Companion-Device header to the outgoing INVITE. This header will be used in the terminating SCC-AS instance to trigger companion device behaviour.

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

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 the primary device whether it is attached to a CS or PS access network. Companion devices are currently only supported on PS access networks. Companion devices on CS networks will be supported in a future release.

If the companion device is registered then it will automatically be included in the determination of outbound routes. If a CSRN can be determined then T-ADS will automatically fork to the CS network. This means the primary device will be alerted if it is currently attached to CS.

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

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