In the last post we have seen a basic SIP (VoLTE) session. This time we should analyze in more detail, what headers are used by network elements for their routing decisions and how they discover what port and IP to use. In practice that’s what people are not always sure about. They know the flow, order of signalling messages, but when something goes wrong, they are just guessing what could be the reason.
Let’s recap what we have learnt so far. We use loose routing. So if a SIP message contains a Route header, we will use the top most one for the routing. If there is no Route header the routing is done based on the Request-URI, which contains the address of the final recipient. Don’t forget, network elements are able to add and modify the headers. The way how we handle the messages and modify their content within the IMS is described in 3GPP standards.
To describe a single SIP Session in IMS is not that easy as it maybe sounds and in the beginning it requires a lot of simplification. The purpose of the signaling over SIP is to establish a multimedia session over RTP (or MSRP). That means that SIP helps to locate the recipient and to negotiate the parameters of the RTP session. To do that we need one more protocol, called Session Description Protocol (SDP) which SIP carries in its body. The procedures for IMS describing this mechanism can be found in 3GPP 24.229.
To set up a session the SIP protocol mandates the SIP INVITE request. It has to be answered by some final response – ideally with 200 OK. To confirm, that the client received the 200 OK message, it sends a special request SIP ACK. The SIP ACK is the only SIP request which doesn’t trigger any response on the server side. The procedure is also known as SIP 3-way handshake.
In this post we will go through a basic VoLTE flow from the SIP and SDP point of view.
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 🙂
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.
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.
Presence sharing is a very important functionality when it comes to Rich Communication. We know it from many communicators such as Skype, Google Hangout, Facebook, Jabber, etc. But maybe you noticed that each of these applications has a different set of statuses, allows to share a different type of hard-state data (e.g. avatar, idea of the the day, web link ..). Mobile operators require some more unified approach as a particular status should be interpreted in the same way in all the networks (‘busy’ should have the same meaning in T-Mobile, Vodafone, or any other network).
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 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.
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.
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)
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.
I remember when I started with artificial neural networks. I read two books describing the mathematical models. Theoretically I had all information I needed, still I had no clue how to make a program which would do something. It took me quite some time to understand how to implement such a thing in C. Those were the days before the Internet and Google 🙂 But even nowadays there is a long, long way from an IMS functional design to a real network deployment.
No, I’m not going to go through the virtualization and all the networking stuff. Instead we will look at one of the options for HSS implementation. Usually we understand the Home Subscriber Server (HSS) as a database which is providing a support and capabilities for User Identity Handling and User Security, Access Authorization, Mobile Management, Service Profile and Authorization. We can also use Subscriber Location Function (SLF) in order to map a particular subscriber to the right HSS or for loadsharing.
The definition above associates a big monolithic system, which often it is. However for some operators this can be impractical as they have to store a lot of information about their subscribers in several different databases, they have to introduce new provisioning procedures etc. Instead they could have just one ldap data-storage and the HSS would only work with the data from this database. And that’s exactly what is known as User Data Convergence (UDC) concept. In fact this is not limited only to the HSS, but the approach applies also to other systems as HLR, Provisioning Server, or ENUM. (Technicaly there can be also more than one LDAP database – e.g. we can have a dedicated cAAA LDAP database, etc.)
In this case we don’t talk about HSS, but about HSS Front End (HSS-FE) and User Data Repository (UDR). The interface between the HSS-FE and UDR is called Ud and you can find its description in the 3GPP TS29.335 and 3GPP TS23.335.