What it does
Access transfer is a Rhino VoLTE TAS SCC service that is responsible for managing the handover of a call from a packet switched (PS) network to a circuit switched (CS) network when a subscriber moves out of PS network coverage. It works by replacing the existing access leg (that is, the SIP leg between the Rhino VoLTE TAS and the served user) with a new one.
Access transfer is initiated on receipt of a new initial INVITE request that has a Request-URI which aligns with either the configured ATU-STI or STN-SR. Initially this request is not directly associated with the call it applies to, and initially may not even be processed by the same Rhino VoLTE TAS node that is handling the original call. Information in the new INVITE request is used to correlate it with the original call so that it can be injected into that call, where it is used to establish the new access leg.
Supported cases
The Rhino VoLTE TAS supports Single Radio Voice Call Continuity (SRVCC) for PS to CS transfer of sessions in the following cases:
-
a single active session with media anchored in the Access Transfer Gateway (eSRVCC)
-
a single active session with media not anchored in the Access Transfer Gateway (standard SRVCC)
-
a single alerting session (aSRVCC)
-
a single originating session in the pre-alerting state (bSRVCC).
If a device initiates access transfer while it has multiple sessions in progress (for example, if the subscriber has someone on hold while talking on another call), only the most recently active session will be transferred. All other sessions are treated as superfluous and are ended as part of the transfer procedure.
Enabling access transfer
Access transfer is not enabled through configuration. Instead, it is enabled per-call if both of the following requirements are met:
-
The served subscriber’s registration data indicates that their device has
UE-SRVCC-Capability. -
The served subscriber has an assigned C-MSISDN in the HSS.
There are additional requirements for alerting and pre-alerting access transfer.
These take the form of media feature tags in the SIP Contact header from the subscriber.
For the calling subscriber this head will be checked on the initial INVITE request,
for the called subscriber the first SIP 18x response will be checked.
To enable alerting access transfer there must be a +g.3gpp.srvcc-alerting tag,
and for pre-alerting access transfer there must be a +g.3gpp.ps2cs-srvcc-orig-pre-alerting tag.
Note that pre-alerting access transfer is only applicable to the calling subscriber.
Access Transfer Control Function
Access Transfer Control Function (ATCF) is a signalling anchor that is used for eSRVCC procedures.
It is responsible for initiating access transfer procedures in the Rhino VoLTE TAS by sending a INVITE request using the ATU-STI as the Request-URI.
To determine where to send access transfer requests, the ATCF must know the ATU-STI to use for a given subscriber.
The Rhino VoLTE TAS is responsible for notifying the ATCF of the ATU-STI,
which it does by sending it in a SIP MESSAGE request when the subscriber registers with the network.
The maximum time that the Rhino VoLTE TAS should wait for a response to the MESSAGE request can be configured in the atcf-update-timeout-milliseconds field.
STN-SR and ATU-STI
The STN-SR (Session Transfer Number for SRVCC) and ATU-STI (Access Transfer Update - Session Transfer Identifier) serve the same purpose of identifying that an incoming request is for access transfer. The main difference between the two is that they are used to trigger different versions of the access transfer procedure.
The STN-SR is used for access transfer as defined in the Rel-8 3GPP specifications, where signalling is not anchored in the ATCF, therefore the Rhino VoLTE TAS receives the transfer request directly from the MSC (Mobile Switching Center, part of the CS core network).
It takes the form of a number prefix on the Request-URI of the incoming access transfer request.
The only requirement for picking an STN-SR is that it must cause messages to be delivered to the Rhino VoLTE TAS.
When a subscriber registers with the network, the Rhino VoLTE TAS will update their STN-SR in the HSS to match what is configured here.
The ATU-STI is used for access transfer, as defined in the Rel-10 3GPP specifications, where signalling is anchored in the ATCF, therefore the transfer request comes from the ATCF.
It is a fixed URI that is used as the Request-URI on access transfer requests.
As the Rhino VoLTE TAS tells the ATCF what ATU-STI to use for a subscriber, the only requirement for its value is that it resolves to the Rhino VoLTE TAS.
Configuration
The example for sentinel-volte-gsm-config.yaml and
example for sentinel-volte-cdma-config.yaml show example configuration
relevant to access transfer in the sentinel-volte/scc/service-continuity section.
What you need
-
❏ The STN-SR that will trigger Rel-8 access transfer.
-
❏ Optionally, a custom timeout period to wait for a response from the ATCF when updating the ATU-STI for a subscriber.
Setting up access transfer
I want to…
Set the STN-SR for triggering Rel-8 access transfer
In the service-continuity section,
set stn-sr with the desired number prefix:
stn-sr: "123456"Related section: STN-SR and ATU-STI
Change how long to wait for the ATCF to respond to a request to update a subscriber’s ATU-STI
In the service-continuity section,
set atcf-update-timeout-milliseconds with the desired time period, in milliseconds:
atcf-update-timeout-milliseconds: 5000Related section: Access Transfer Control Function
