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!
Over and over again I can hear:
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 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.
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
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.
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:
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
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. Continue reading