Maybe you have already heard about some features as Dynamical Network Slicing, CloudRAN, Network-as-a-Services, … Some basic 5G principals we’ll briefly discussed also in this post. However my question is: What will be the change from the real-time communication point of view? What will be the 5G calling look like? Is the IMS (IP Multimedia Services, don’t confuse with International Microwave Symposium) to stay in the operators’ networks?
5G Deployments Sep, 2019 by 5G Americas
Seems that at the first stage the change will be less dramatic than when we introduced 4G. 4G was in many ways a revolution, whereas 5G is “only” an evolution. In fact 4G and 5G, at least in the beginning, will coexist and complement one each other. Still 5G will have a big impact on our existing technologies and the way we work with telecommunication networks.
I like statistics. Sometimes it can be misleading or data can be hard to interpret. But it can help us when we struggle to see the forest for the trees.
The last two years the IP-based mobile technologies were booming. If you are working with 4G networks you know it well. This year however the number of new deployments decreased significantly (Sep 2017, source GSMA).
IP Deployments Sep-17
Well, there can be many reasons for that. Rather than guessing, let’s have a fun and take a look on how popular are some telco topics on Google in the last 3 years.
Why we need VoLTE, when I can use Skype or Whatsapp (for free)?
What is the difference between native (volte) and non-native client?
Of course, everyone likes applications for free. And it’s a great thing we can use our facebook, skype or google accounts practically on any device and from anywhere. Maybe it’s a bit annoying that in order to communicate using such an Over-The-Top (OTT) application, we have to install the same applications as all our buddies.
By OTTwe understand an application for a real-time communication using audio, video, and other media over the Internet without the involvement of a mobile operators’ IMS network. But when it comes to mobility we can’t get along without the operators’ infrastructure completely, we still need them to provide us with the internet connectivity.
OTT and LTE
Skype and other icons are used only for illustration.
There are many aspects and technical details which can’t be covered in this short article. Please, take this post as a brief introduction into the matter.
VoLTE is a communication standard defined by GSMA and 3GPP organizations. They created plenty of documents, but these documents are not good when one is a beginner. Still it’s no rocket science. Perhaps it is because the documents don’t contain more good pictures explaining the basic ideas. I believe if the standards would be written as comic books, they’d have much broader audience 🙂
What is VoLTE?
VoLTE stands for Voice over LTE. LTE is a new standard for wireless communication of high-speed data for mobile phones.
Sometimes we can see also ViLTE, which means Video over LTE.
In telco tracing has always been very important. It helps us to understand the flows, the content and – sure – to find bugs. SS7 used to be much more strict and we didn’t need to go in the detail traces that often. The flow and a few fields was usually enough. With SIP and SDP it is a different story. SIP is a very flexible protocol. That means powerful but also complex and sometimes quite confusing.
Let’s take a look on IMS Registration. I’m sure you remember the idea behind from a previous posts about Registration and 3rd party registration and at least the basic flow:
The registration flow is very important – in practice if something goes wrong, it is most probably registration. Once is a subscriber correctly registered, the other flows (call, sms, fileshare) usually works fine.
VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:
For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
Wow – this is very important! There is not only the SIP/RTP between UE and IMS network but there can be also http (xcap)! Unlike SIP, HTTP is designed as a general-purpose data transport protocol. The purpose of SIP is mainly to create, modify, or terminate multimedia sessions. But sometimes we want to work with other types of data (e.g. configuration data, presence data, ..) which could easily overwhelm intermediate SIP proxies. HTTP is a good choice how to solve this issue.
What is the network architecture then?
As we can see the http traffic does’t go through the SBC but either directly or through an Authentication Proxy (AP) instead. The interface uses in cellular access the HOS APN (Home Operator Services) as defined in GSMA PRD IR.88 (in Wi-Fi either the HOS APN or a different APN as defined in of GSMA PRD IR.51). The usage of AP depends on the HOS APN (Home Operator Services) value. The Network Identifier (NI) part of the APN is undefined and must be set by the operator. The operators can choose to reuse an APN for already deployed services (e.g. Internet access, MMS, etc.) or choose a new, specific APN for the APN for Home Operator Services.
As the HOS APN is often using the standard Internet access, we’ll take a look at the flows with AP. The main purpose of AP is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.
(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)
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).
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.