AR, VR – Real-time communication in 5G

GSMA Intelligence forecasts that the number of 5G connections globally will reach 1.3 billion by 2025, covering 40 percent of the world’s population or approximately 2.7 billion people. At that time, the Americas region is expected to account for over 260 million 5G connections or 20 percent of the global market.

The question everyone is asking in telco last couple of years is – do we really need 5G? Do we really need that throughput for our voice, video and messaging services? Can we significantly improve real-time communication services so that customers would be willing to pay for it? RCS aka Advanced Messaging is a great example of how difficult it can be to find the right business model for new technologies. EVS supported in 4G is more than what we need for voice calling. Although video calling is possible in 4G, not that many customers are using this option on their mobile devices. More popular than video is desktop-sharing, collaboration and communication in context. Well, lower latency and better throughput can be useful – but is it a reason strong enough to invest into the new 5G infrastructure, when collaboration applies mainly to fixed networks?

5G Drivers. Source GSMA

Still there are real-time communication applications which require low latency and huge amount of data so that 4G is not enough. Virtual Reality (VR) applications like 360-degree video will necessitate higher resolutions of 8K and above, and stereoscopic video (which separates left and right eye views in VR) also requires additional bandwidth. When most people hear about 3D video, holograms, Augmented Reality (AR) and Virtual Reality (VR), they mostly think about gaming. And yes, gaming can be a good example and people like to spend money for entertainment. But there are other examples, where AR and VR can make a difference.

VoLTE KPIs

I have never planned to talk about such an operator specific matter as KPIs. But since I posted NEWS: Telco Monitoring I’m receiving many questions related to this topic and I guess we can discuss at least the basic principles.

Inside AT&T’s Network Operations Center by PCWorldVideos

If you have read the VoLTE standards such as GSMA IR.92 or VoLTE Service Description and Implementation Guidelines, you probably noticed that performance monitoring is more or less ignored. And at the same time all operators are asking about it. What KPIs to watch, how, what are the guidelines?

Btw. I always enjoy being in NOC (Network Operation Centre) or war or crisis rooms. Especially during events like NYE. However mostly it is not allowed to take any photos there, so instead I’ve linked some youtube videos showing the scene. Respect to you bros working day and night to keep the network running!

OTT and VoLTE Calls

Over and over again I can hear:

Why we need VoLTE, when I can use Skype or Whatsapp (for free)?

Or also:

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 OTT we 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 Policy Control Summary

In IT and particularly in Telco we are obsessed with abbreviations. My wife always loughs and tries to mimic me when she listens to my calls. Today we should be very careful as many of them start on ‘P’ – PCC, PCRF, PCEF, P-CSCF, PGW, PDN, PDG, PDB, PHB. But no worries, there will be abbreviations starting on other letters as well 🙂

In the IMS we have separated signalling and media data. However a full independence of control and user plane is not desirable. We want to control when the media starts and stops, we want to be sure about media routing, we want to ensure Quality of Service (QoS). And, of course, we want to accordingly charge the users.

In order to achieve these requirements we use two techniques in the VoLTE architecture:

• Policy and Charging Control (PCC)
• Differentiated Services (DiffServ)

Policy and Charging Control

PCC functionality comprises of Policy Control (e.g. QoS, media gating, ..) and Flow Based Charging. The ETSI TS 29.212, 29.213, 29.214 and 29.203 define Policy and Charging Control Architecture. There are many PCC functions defined. For us the main 3 PCC elements are:

• Application Function (AF)
• Policy Charging and Rules Function (PCRF)
• Policy Control Enforcement Function (PCEF)

Policy and Charging Control (PCC) Architecture

Application Function

In VoLTE is the AF incorporated within the Proxy-CSCF. The P-CSCF provides the information related to the control plane signaling. The information is taken from SIP/SDP session setup and it is forwarded to the PCRF via the Rx reference point. Each new SIP message that includes an SDP payload or session events (e.g. session termination, modification) can trigger a new request sent towards the PCRF. This ensures that the PCRF gets the proper information in order to perform reliable PCC.

It is about quality!

One of the marketing reasons why one should prefer VoLTE instead of common VoIP is the Quality of Service. The framework for Policy and Charging Control is described in its own post. Here we’ll focus QoS support in SIP/SDP protocols. Note that this post goes in details and expects that you’re familiar with SIP/SDP session negotiation procedure. When we want to support QoS during the session negotiation we need to add so-called preconditions in the SIP INVITE:

Require: precondition

The details can be found in the RFC 4032 and RFC 3312. The preconditions can be of several types as  qos, connectivity or security. In order to support QoS there are dedicated fields in SDP:

 
      current-status     =  "a=curr:" precondition-type
                            SP status-type SP direction-tag
      desired-status     =  "a=des:" precondition-type
                            SP strength-tag SP status-type
                            SP direction-tag
      confirm-status     =  "a=conf:" precondition-type
                            SP status-type SP direction-tag
      precondition-type  =  "qos" | token
      strength-tag       =  ("mandatory" | "optional" | "none"
                         =  | "failure" | "unknown")
      status-type        =  ("e2e" | "local" | "remote")
      direction-tag      =  ("none" | "send" | "recv" | "sendrecv")

The logic is very simple. Each participant will define whether he/she has some desired status he/she wants to reach. Then during the SDP offer/answer negotiation they are simply checking if the current state >= desired state.