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 and standards.
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!
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).
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.
I’ve just recently changed my job and that reminded me, what it means to start from the beginning again. To help those of you who have just started with VoLTE/IMS I’ve created a short presentation.
Let me know if it works (and maybe one day I’ll find some to make a recording too 🙂 ). Good luck!
As a trainer and blogger I have a chance to talk to many engineers from various (telco) companies. And I can hear a lot of similar complains. “We’re just reinventing a wheel, over and over again.”, “I feel like an investigator – to find the right information/documentation is so painful.”, “R&D doesn’t want to share anything.”, “They are not answering to my questions, they’re just sending a lot of crap to keep me busy.”, etc. The common denominator is that companies don’t encourage engineers to work aloud and share their experience and knowledge. Why? So much effort and talent is wasted.. And by encouraging I mean also that they don’t provide the right tools (no, it’s not sharepoint) and managers don’t lead by their examples.
This can’t be fixed by any process or action points. It is about company/team culture. If managers treat engineers as “resources”, act as if they are more important, or if they say “we’re not at work to make friends” (and some are even so dump to share it on social networks), it is hard to imagine that others would willingly share their know-how. Yes, there can be some lessons-learn filled after project, some reports created – but honestly, what engineers read these documents??
Have you heard about the IMS Centralized Services (ICS)? The basic idea is fairly simple. We want to apply services for IMS subscribers, regardless what access network they use. We know that in IMS we can do it for all IP-based access domains. But if the subscriber is accessing through the legacy CS network (e.g. because of a low LTE coverage in her area), we are still triggering the services in the CS Core network … right, unless we have the ICS in place. So ICS enables the IMS services even when one is using CS access for the media bearer.
The ICS is specified in GSMA IR.64 and 3GPP TS 23.292, 23.237 and 23.216. The scope of the specification includes:
- Session establishment when using CS access for media transmission for an IMS service
- Support of Service Continuity
- Support of Single Radio Voice Call Continuity
- Access Domain Selection (ADS)
- IMS control of services where the media is transported via the CS network (e.g. managing of mid-call services)
- Service data management
The solution is applicable for UEs with or even without ICS functionality. As the first step all the sessions have to be anchored in the IMS. That is a job for Service Centralization and Continuity Application Server (SCC AS). The SCC AS is on the signalling path for both the originating and terminating services. Using the initial Filter Criteria (IFC), the SCC AS is triggered as the first AS for originating sessions and as the last for terminating sessions.
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.
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.
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.
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.
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.