Category: IMS

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.

Like this:

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.

Like this:

Maybe you have already heard about some features as Dynamical Network Slicing, CloudRAN, Network-as-a-Services, … Some basic 5G principals we’ll briefly discussed also in this post. However my question is: What will be the change from the real-time communication point of view? What will be the 5G calling (VoNR) look like? Is the IMS (IP Multimedia Services, don’t confuse with International Microwave Symposium) to stay in the operators’ networks?

Seems that at the first stage the change will be less dramatic than when we introduced 4G. 4G was in many ways a revolution, whereas 5G is “only” an evolution. In fact 4G and 5G, at least in the beginning, will coexist and complement one each other. Still 5G will have a big impact on our existing technologies and the way we work with telecommunication networks.

Like this:

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.

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!

Like this:

Even in 2017 the telephone number remains the most universal identifier for real-time communication. And as the word is moving to be All-IP, we have to be able to translate the number into something more meaningful for routing in IP networks. The GSMA organization selected for this purpose the Electronic Number Mapping System (ENUM) and in 2007 released the first version of PRD IR.67.

ENUM based Routing

Moreover Mobile Operators in over 50 countries have to support Mobile Number Portability (MNP). Although for MNP is a great feature for end subscribers, it makes the signalling more complex and costly for the Operators. The MNP is not just a problem for signalling (routing) but also for billing and management of interconnect agreements. Last but not least it can be a significant issue for content and application providers who may not be aware of the change of the operator for a particular user.

Like this:

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.

SIP Message Routing

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.

Like this:

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.

SIP 3 Way Handshake

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.

Like this:

In the last post I promised that this time we will take a closer look on SIP headers which are related to routing. SIP routing is very flexible and most of the SIP textbooks are explaining it in a very general way. Here we focus only on routing in IMS context. We should also point out that there are two methods how to route SIP messages – so called strict routing and loose routing. As the strict rooting is obsolete since 2002 and 3GPP mandates only the loose routing for IMS, we will talk just about the loose routing.

The first and the most important header is the Request-Line, which contains the Request-URI. It allows us to route a SIP request directly to a Server. The response then follows the Via header. SIP Client and each proxy which wants to intercept the response adds itself into Via headers of the SIP request. During the processing of the response then each proxy removes its own Via record from the message. The Via header is also used to detect possible loops in signalling.

SIP Request – Response

In practice the UAs can’t see directly one each other and we have to use the IMS network to provide the routing. The first scenario we should go through is the IMS Registration. A VoLTE UE initiates a SIP REGISTER to the P-CSCF, using the P-CSCF IP that was made available during the LTE Attach. The Request-URI is set to the SIP-URI of the domain name of the home network.