Multimedia in VoLTE

It’s very interesting (and well, a bit suspicious) that the main focus of most VoLTE textbooks and trainings is signalling. But from the user-point-of-view, it is the voice data, what matters. As an end-subscriber I don’t care about signalling. My only interest is the call quality. But times they are a changin and engineers are asking about how to improve the overall voice-call quality and user experience. Today we’ll go through the basics as jitter, mouth-to-ear delay, packet loss rate or MOS, needed for QoS analysis.

For real-time multimedia we used to have dedicated telephone/radio networks. That has changed and voice/video streams are transported over IP network now.

We should understand that these IP networks were originally designed for data transport. To transport data we prefer the best-effort service model, which allows an easy network scaling and simple routers’ logic. On the other hand we don’t care much if packets arrive in-order or what are the delays between particular packets. We simply wait until we receive a whole file. If any packet is lost, TCP will re-transmit it.

Packets in Data Networks

It’s a different story with the real-time communication services though. RTC applications are less sensitive to packet loss, but they are very sensitive to packet delay. Usage of IP data network as a carrier brings a lot of challenges which have to be addressed by media protocols and network elements.

News: Trends in Telco

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.

News: Finally 4G?

IMS was designed in a very a general way. As a service network which is access independent, supports multiple identities and it is very expensive to implement. Sometimes less is more – at least in the beginning. That’s also why we have the VoLTE – a minimum IMS profile which reduces the scope into something manageable and more practical.

As the VoLTE has been around for a couple of years already and works fine, the early adopters are looking for more – HD Voice, EVS, WebRTC and other technologies. Recently T-Mobile USA (DIGITS) and AT&T (NumberSync) announced their solutions for multi-device feature. Not all the features are always successful or truly practical – but this time I’d think more operators will follow. Btw. with IoT to come I wonder when exactly we will see a first virtual entity (agent) seamlessly moving from one devices to another 🙂

News: The World is to be All-IP

Based on the recent numbers from GSMA it seems that over 50 % of the world population is now in a reach of 4G services. The number of VoLTE deployments in 2016 (May) is already close to the number of all the deployments for the year 2015.

VoLTE Deployments

News: more than HD

T-Mobile USA is on the cutting edge. It was the the first operator who came with HD Voice back in 2013. This month they announced a new upgrade of their network – to Enhanced Voice Services (EVS). From the customer perspective it means a better audio quality – even better than HD. EVS does this with a broader audio frequency range, which translates to richer, more realistic-sounding voice audio. The EVS is supported for both VoLTE and VoWifi. Additionally for the LTE technology it also brings a higher reliability in areas of weaker signal.

T-Mobile has a pending patent for their solution where their customers with EVS compatible phones will benefit even if the B-party  doesn’t have an EVS-capable device. Currently the technology is available for LG G5,  Samsung Galaxy S7 and S7 edge. T-Mobile plans to support four more smartphones by the end of 2016. I wonder what will be the response of Alliance for Open Media for webRTC.

ePDG and IPSec

It seemed that once we have IMS in place we can add the VoWifi service for free. Of course, there is hardly ever anything for free. As we have is in the VoWifi Overview there are quite a few things we need to take into account. In IMS we have to be more sensitive when it comes to routing, forking, location services etc. In the access network we have to make sure that the communication is secure enough and that we can trigger an access transfer when needed. In this post we’ll go through the security part of it and describe the basic flows.

It is not that difficult to get lost among all the security frameworks, protocols and procedures we have implemented in ePDG. In order to establish an IPSec tunnel we have to use IKEv2 for encryption and then some form of EAP for authentication and then we can start with ESP encryption.

Security over SWu

So let’s start with a short dictionary:

VoWifi Overview

“Wi-Fi” is a trademark of the Wi-Fi Alliance and the brand name for products using WFA programs based on the IEEE 802.11 family of standards.

When I worked in R&D we used to say that patents are like hostages. The advantage is that we can create them ourselves.  In April 2009, 14 technology companies agreed to pay CSIRO (Commonwealth Scientific and Industrial Research Organization in Australia) $250 million for infringements on CSIRO Wi-Fi patents. Hence Australians labeled Wi-Fi as an Australian invention, though this has not been accepted by everyone without objections (especially in US). CSIRO won another $220 million settlement for Wi-Fi patent-infringements in 2012 with global companies in the US required to pay the CSIRO licensing rights estimated to be worth an additional $1 billion in royalties. Guglielmo Marconi or Joseph Fourier would be bambillionaires these days.

In our post the Wi-Fi refers to a WLAN access to ePC, both trusted over S2a interface or untrusted over S2b interface (3GPP TS 23.402). The VoWifi is then a voice and video over Wi-Fi IMS profile, defined in GSMA IR.51. If you are familiar with VoLTE (IR.92 and IR.94), the VoWiFi defines the same set of services, just over a different access network. The service network – the IMS – remains the same. Sure we need to be more sensitive when it comes to muli-device scenarios or access transfer.

VoWifi

This article is focused on the technical aspect of the VoWifi definition. Would you like to know a bit more about why to deploy the VoWifi, check out this post written by Alberto Diez.

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.

IMS from 10.000 feet

Over and over I need to go through the basics. One would think that everything was already said but sometimes a refresher is a good thing. Especially when we rely a bit on what we guess than on what we really know. I’m not any exception 🙂

There are many changes we can witness these days in operators’ networks.

The core network has become much more complex. We still have the 2G/3G mix in place, we added new LTE network, WiFi network, some operators are even introducing WebRTC GW. I’ll leave aside the IoT/M2M traffic – however very soon it will be the most important guy in town (now 2nd – 3rd biggest source of revenue for mobile operators).

Headers in User-centric networks

One of the key reasons why we need the IMS is the support of multiple devices for the same public identity. Simply put we don’t care what physical device our counterpart has, we just call and it is up to the network to select the particular device or more devices. For example my buddy can be connected via 3G or 4G and wifi from his smartphone, and he can be also connected from a web browser using the WebRTC (and well there are already some operators testing this).

As the logic says the key headers which are being used for routing will remain the same.

The examples here are taken from real networks (AS/CSCF). The exact ids and IPs were modified. You can enjoy the diversity of headers we can find all around the world. There could be much more of them, but I don’t want to have the post too long and boring.

 

Request-URI

INVITE sip:0123456789;
phone-context=ims.mnc000.mcc000.3gppnetwork.org@ims.mnc000.mcc000.3gppnetwork.org;
user=phone SIP/2.0

or

INVITE sip:+12345678912@ims.operator.com;
user=phone SIP/2.0

or just

INVITE sip:12345678912@server.networks.operator.com SIP/2.0

 

P-Prefered-Identity

P-Preferred-Identity: sip:+12345678912@ims.operator.com

P-Asserted-Identity

P-Asserted-Identity: sip:+12345678912@ims.operator.com

P-Served-User

P-Served-User: <sip:+12345678912@ims.operator.com>;
sescase=orig;regstate=reg