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).
IMS Architecture for eSRVCC
Update: The information in this post became obsolete over the time. Recently we’ve got RCS Universal Profile standard, which defines Green Button Promise for Voice and Green Button Promise for IP Video Call Services and Enriched Voice Calling. I’m working on an updated material, which will compare RCS IP Calls and VoLTE/VoWifi calling and describe RCS Network Architecture.
It is similar with many OTT applications for calls and massaging. Which one is the right or at least decent one? The big advantage is that usually we can try it for free. Anyway what is the difference between a voice call performed as VoLTE (or VoWiFi) and voice call which is transmitted via RCS?
The 4G networks were originally designed for pure data traffic. But the voice service is a must have feature and right now it can’t be fully replaced by VoIP. The voice service has to be reliable and fully compatible with the service from 3G (Blacklisting, Call diverting, Lawful intercept, Emergency calls, DTFM, etc.) and has to allow seamless fallback in case the 4G coverage is lost (eSRVCC). This new service is called VoLTE.
Registration is something what was missing in the times of wires. Ok, not completely but it was done more or less once when an MSISDN was assigned to some line.
In contrast to the previous types of the networks the 4G network is ‘user-centric’. It means the user can use multiple devices and identities and we have to deal with it. The main purpose of the registration is to create a binding between user (her public identity) and IP address of the device, so we know where we can send the data to. That’s why there is a Contact header in the SIP REGISTER message. The Contact header contains an address which identifies the current location of the user (Point-of-Presence – e.g. IP/FQDN of a particular client). During the registration is the Contact Address is linked to a Public Identity (IMPU, AOR in SIP terminology). The IMPU is an equivalent to MSISDN in GSM and has to be present in the To header of the SIP REGISTER. One identity can by used by more terminals and as each terminal can have different capabilities this has to be also taken into account. This information is part of the Contact header.
As this is a blog, I’m not going to recap all the stuff you can find in wikipedia about RCS. Wikipedia is a great source of information but sometimes you can’t see the forest for the trees. The RCS is really a big theme so I guess it would be better to write several posts than to try put all the relevant information in one. I’ll probably use some simplifications, the details and exceptions will be described later.
So what is the RCS?
Update: For the information about RCS Universal profile read the post GSMA Advanced Messaging – RCS Universal Profile.
RCS is an attempt of mobile operators and their vendors to be more than just connectivity providers. With the 3rd generation of mobile networks many people started to believe that they’ll not need the operators soon – as long as they can connect to the Internet they have VoIP, Instant messaging, Emails, Facebook, etc (Over-the-top applications OTT). Why should anyone pay for roaming or use SMS anymore? But for the operators Voice services and SMS were/are the main sources of income. VoLTE and RCS should give their customers the user experience they know from Skype, Whatsapp, Viber or Line and enable them to stay relevant.