Mind the coverage hole!

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

SRVCC

eSRVCC

 

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.

Registration

srvcc register

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>
IMS Registration for eSRVCC

IMS Registration for eSRVCC

Access Transfer PS to CS

Access Transfer PS to CS

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.

SRVCC signalling and media path

SRVCC signalling and media path

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 PS to CS transfer. There is also CS to PS and PS to PS transfer. In general Voice Call Continuity is just a first step towards Service Continuity and IMS Centralized Services (ICS) as defined in GSMA IR.64.

Advertisements

12 thoughts on “Mind the coverage hole!

  1. Pingback: A magic box called SBC | Real Time Communication

  2. Pingback: VoLTE in IMS | Real Time Communication

  3. Pingback: VoLTE flows – close encounters | Real Time Communication

  4. Pingback: This is an emergency! | Real Time Communication

  5. Pingback: Messaging in RCS | Real Time Communication

  6. Pingback: VoLTE or RCS Voice Call? | Real Time Communication

  7. Pingback: Roaming in IMS | Real Time Communication

  8. Pingback: An Éminence Grise – the DNS | Real Time Communication

  9. Pingback: IMS from 10.000 feet | Real Time Communication

  10. Pingback: How to read tcpdump – Registration | Real Time Communication

  11. Pingback: OTT and VoLTE Calls | Real Time Communication

  12. Pingback: IMS Centralized Services – Overview | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s