After years in fixed networks I had a chance to deliver a training related to mobile networks (operator in Portugal). It was a pleasure to touch IMS again. It was even better to hear questions like:
Karel, that realtimecommunication page – is it yours?
How many people are writing it? Only you?
It is one of my favorite webs about IMS and SIP. Can you write about … ?
Firstly obrigada, thank you. Then my apologies. Time to time I’m getting a request if I can write about some particular topic. My personal todo list is also quite long. However, it doesn’t go well with my current job. I’m simply busy and don’t have enough time or energy to write about VoLTE, 5G, V2X, .. would anyone know a way, how to change it, let me know. But till then, I’m afraid, I won’t update these pages too often.
Support and operation engineers don’t need to understand the majority of algorithms hidden in telecom software. But time to time it helps if you have an understanding of how some particular functionality is implemented.
The typical situation is Traffic Shaping or Overload Protection. Many operators want to understand and test, how their system behaves under a huge load of calls or messages. There are many ways how to implement these features, so let’s take a look at the most common ones.
The easiest way how to protect the system is to define some limit. For example, we can say that our SBC is able to handle only 1.2 mil. parallel calls. If we receive a new invitate which exceeds this threshold, we respond with system error.
Similarly, we can set a limit for CPU or memory consumption. Whenever we reach, let’s say 60 % of the CPU we raise an alarm and don’t allow any new call/registration. As soon as the resource utilization drops below the threshold again, we can resume the standard system behavior and accept new calls.
Sounds reasonable and simple, however, in case that the load is close to our limit – 60 % of CPU – it can lead to so called throttling causing system instability. The last thing which you desire for if you are facing high traffic.
Maybe you remember what I said about Group Messaging. That all the RCS deployments would be done faster without this feature. A similar thing we can say about VoLTE Conferencing. Ad-Hoc Multi Party Conference Call (CONF) is one of the basic requirements we have on VoLTE calling. Simply put each VoLTE network has to support conference calling. But to troubleshoot this great functionality can be a nightmare.
Ad-Hoc Multi Party Conference is one of the Supplementary Services supported by Telephony Application Server (TAS) (a dedicated Conference AS is an option too) and it is described in GSMA IR.92, which then refers to 3GPP TS 24.605 and 24.147. Today we’ll take a look at the conference call flow, along with the Mr’ interface between TAS and Media Resource Function (MRF).
Add participant button
Although we talk about conferencing, in fact it’s just a multi-party call. We don’t schedule any conference call for a given list of participants. We can only add additional numbers to an existing call. That’s why we describe the service as an ad-hoc conference. From the mobile operator point of view the conferencing service provides the means for a user to create, manage, terminate, join and leave conferences as well as the ability to update the involved parties. But most of the stuff is truly hidden to the end subscribers.
In general both voice and video conference can be supported, but only the support of audio media is required by VoLTE standard. The maximum number of participants differs network to network, usually it is between 6 and 10. Note, that the functionality is not limited to VoLTE users only, we can add to the call the CS users too.
Our current economy is digitized and generates an exponential growth of person-to-person (P2P) transactions. On the other hand we often face challenges around flexibility, trust, identity and authorization that existing financial instruments are sometimes struggling to address.
And that’s where blockchain comes into play. Blockchain is designed as a secure distributed system with high Byzantine fault tolerance. The most successful use cases for blockchain today are related to financial transactions and the management of financial assets. The most famous examples include Bitcoin, Ethereum, Ripple or Hyperledger.
GSMA has just recently published the final numbers for 2017. As expected the last year we’ve seen less 4G deployments than in 2016.
4G Deployments in 2017
The only exception was the RCS. (Btw. GSMA released its Universal Profile Version 2.0 for Advanced RCS Messaging.)
From the population coverage point of view the last year meant a great step forward. Although many developing countries have been still more focused on 3G (4G coverage is on average 35% there), the overall number of 4G coverage increased significantly.
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 IPnetwork 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.
The last time we discussed 5G and IMS. One of the main drivers for 5G is Machine-2-Machine (M2M) communication. But surely 5G is not the only technology which enables Internet of Things (IoT). Many operators already do support proprietary technologies such as SigFox or LoRaWAN. But there are also 3GPP standardized (Release 13) networks for IoT other than 5G. They are LTE-M and NB-IoT, and they both operate on licensed spectrum. These technologies came a bit later, however now it seems they are gaining momentum.
On GSMA pages you can now find an interactive map with the existing IoT deployments.