There are two big enemies of mobile communication. Weak signal and battery drain. With the LTE technology in place we need to deal with the situation when our signal gets too weak. The higher frequencies have a problem to penetrate walls, currently the radio network is not covering whole country yet, etc..  these problems seems to be only temporary (as the LTE is moving forward) but at this point of time we can’t rely on the LTE network only. When we are out of 4G coverage while we are not calling we’ll simply fallback to CS network and VoLTE supports CS breakout or CS retry so our voice service is still working.

But what if it happens during an ongoing call? Can we handover and still maintain the session? It is possible but not easy as because of the battery drain we can access only one radio network at the time. What we are looking for is called enhanced Single Radio Voice Call Continuity (eSRVCC) and it is described in the GSMA IR.64 and ETSI TS 124 237. (SRVCC is applied during PS to CS access transfer in a single radio system from LTE to 3G/2G. For devices that support active WiFi, and 3G/2G and LTE dual radio, the enhanced Dual Radio Voice Call Continuity (eDRVCC) is applied.)

eSRVCC call flow is probably one of the most complex flows you can encounter in VoLTE. Read firstly about the basic flows VoLTE in IMS. In case of doubts or when more scenarios/details needed please refer to the spec.

To allow this functionality we need to add some more IMS elements in the network:

Access Transfer Control Function (ATCF)

ATCF acts as SIP signalling anchor and is located in the SIP signalling path between P-SCSF and S-CSCF. Very often it is part of the SBC. ATCF controls the ATGW, where the media plane is anchored. During the session transfer, the ATCF establishes a new session with the SCC AS. This new session substitutes the old session between the ATCF and the SCC AS.

Access Transfer Gateway (ATGW)

The ATGW anchors the media session.

Service Centralization and Continuity Application Server (SCC AS)

The SCC AS anchors originated and terminated sessions when using the PS or CS access. It is also responsible for the Terminating Access Domain Selection (T-ADS).

 

As the new elements ATCF and SCC are anchoring the session we have also to modify the basic VoLTE flows.

Firstly we need to modify the registration. We have to send the information about what ATCF is responsible for the user to enhanced MSC/MGCF. This information is called Session Transfer Number for SRVCC (STN-SR) and it is a TEL URI of ATCF. Another important information which we need to exchange is the MSISDN which is being used by the user in the CS network. We call it Correlation MSISDN (C-MSISDN). And last but not least ATCF has to be able to address the SCC AS. The address is referenced as Transfer Update – Session Transfer Identifier (ATU-STI) and it is a SIP URI of SCC AS.

The flows for eSRVCC in IMS are described in 3GPP 23.237 and ETSI TS 124 237.

eSRVCC Registration

According the ETSI TS 124 237  the UE doesn’t need to advertise its capability to do the eSRVCC (PS-CS).

ATCF decides, based on the operator’s policy and if the home network supports eSRVCC with ATCF to alocate an STN-SR.  The ATCF decides to include itself for sessions created using this registration and adds its record in the Path: ATCF URI for terminating requests followed by P-CSCF URI for terminating requests. ATCF URI for terminating requests uniquely identifies registration (or registration flow, if multiple registration mechanism is used).

It also adds a new header Feature-Caps: The header field contains

Feature-Caps: *;+g.3gpp.atcf=<tel:+123455555555>;
                +g.3gpp.atcf-mgmt-uri=<sip:abcdf@atcf.ims.mnc000.mcc000.3gppnetwork.org;abce>;
                +g.3gpp.atcf-path=<sip:abc@atcf.ims.mnc000.mcc000.3gppnetwork.org:5555;abcde;mtcall;lr>;
                +g.3gpp.mid-call;
                +g.3gpp.srvcc-alerting;
                +g.3gpp.ps2cs-srvcc-orig-pre-alerting

•  g.3gpp.atcf feature capability indicator indicating that the ATCF role is supported by this URI;
•  g.3gpp.atcf-mgmt-uri feature capability indicator indicating the management URI of the ATCF for receiving SIP MESSAGE requests containing SRVCC related information and the g.3gpp.atcf-path feature capability indicator. The value of the g.3gpp.atcf feature capability indicator contains the STN-SR allocated by ATCF. The value of the g.3gpp.atcf-mgmt-uri feature capability indicator contains the ATCF management URI. The value of the g.3gpp.atcf-path feature capability indicator is the ATCF URI for terminating requests;
• g.3gpp.mid-call indicating that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the MSC server assisted mid-call feature; and
• g.3gpp.srvcc-alerting indicating that all MSC servers, which can be involved in the SRVCC procedures and which are in the same network as the ATCF, support the SRVCC for calls in alerting phase.

Then the ATCF forwards the SIP REGISTER request to the I-CSCF.

SCC AS will receive the STN-SR (the TPR contains the original SIP REGISTER in the body) and will update the ePC HSS. Then it’ll send its own uri – ATU-STI along with the C-MSISDN to ATCF as an xml payload of a SIP MESSAGE:

<?xml version="1.0" encoding="UTF-8"?>
<SRVCC-infos>
  <SRVCC-info ATCF-Path-URI="sip:abcd@@atcf.ims.mnc000.mcc000.3gppnetwork.org:5555;abcde;mtcall;lr>;
    <ATU-STI>
      sip:sccas.ims.mnc000.mcc000.3gppnetwork.org
    </ATU-STI>
    <C-MSISDN>
      tel:+123456789012
    </C-MSISDN>
  </SRVCC-info>
</SRVCC-infos>

eSRVCC Call Flow

When a weak signal is detected the MME sends a handover request to CS network. Part of the request is the STN-SR and C-MSISDN. MSC/MGCF will create a new SIP INVITE and will send it to STN-SR e.g.

INVITE tel:+123455555555 SIP/2.0

ATCF finds the existing dialog for C-MSISDN (P-Asserted-Identity) and decides whether to anchor the media in the ATGW. Then sends a new SIP INVITE to SCC AS with the Target-Dialog which is to be transferred:

INVITE sip:sccas.ims.mnc000.mcc000.3gppnetwork.org SIP/2.0
From: "+123456789012" <tel:+123456789012>;tag=cCV3WU5ajDjUW1bX
Require: tdialog 
P-Asserted-Identity: tel:+123456789012
Request-Disposition: no-fork
Content-Disposition: session;handling=required 
Target-Dialog: 123-callid-56789;remote-tag=2926696543;local-tag=9074j32852k214956

If the call is anchored in the SBC (ATGW) then we don’t need to renegotiate the SDP again. The SBC will simply do the translation between the access leg (e.g. narrow band) and remote leg (e.g. wide band). In case that this is not possible the SCC AS will send SIP UPDATE with the new SDP. This is something we are trying to avoid as it noticeably increases the delay during the transfer.

Note that in the eSRVCC scenario an implicit deregistration from the IMS network is missing, instead we relay on T-ADS done by SCC AS.

Of course there is more then just eSRVCC.  3GPP in its releases gave us a nice set of various SRVCC scenarios.

• SRVCC – Access transfer without media anchoring – no ATCF/ATGW, SCC AS addressed by STN-SR (R9)
• Emergency SRVCC – Support of access transfer for Emergency Calls (R9)
• eSRVCC – Enhanced SRVCC – Media anchoring (+ mid-call feature support) (R10)
• aSRVCC – Alerting SRVCC – Support of SRVCC PS-CS transfer of a call in alerting (ringing) phase (R10)
• vSRVCC – Video Call support (R11)
• rSRVCC – Reverse SRVCC – Support of access transfer from GSM/UTMS to LTE (R11)
• bSRVCC – Before ringing SRVCC – Support of SRVCC PS-CS transfer of a call in pre-alerting phase (R12)

… and maybe some more.

aSRVCC/bSRVCC

During the SRVCC we can then transfer not just an ongoing session, but also a session during its setup phase.

The basic idea is quite straightforward. We simply use the SIP INFO method to carry XML document, which updates the relevant network elements on the session setup progress.

What type of SRVCC is supported by MSC is indicated in the incoming (transfer) INVITE in the Contact header e.g.:

Contact: <contact uri>; 
        +g.3gpp.srvcc-alerting;
        +g.3gpp.ps2cs-srvcc-orig-pre-alerting;
        +g.3gpp.path=<sip uri of msc for term>

However there can be many things which can happen during a session set up including the early media. Or call forking. Or we can also transfer one session which is ongoing and another which is just incoming or which is currently on hold. Or even a conference call. Good luck with the troubleshooting 🙂

Voice Continuity is just a first step towards Service Continuity and IMS Centralized Services (ICS) as defined in GSMA IR.64.