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.
IMS Centralized Services
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
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.
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.
Rich Communication Services (RCS) has been around for a couple of years without any major success (actually the number of RCS deployments has been declining). There were many reasons. From the technical point of view it was caused by very ambitious design at the times where there was a little experience with IP-based technologies in operators’ networks, along with the lack of good enough RCS clients. That has changed and in the November 2016 we got a new standard called RCS Universal Profile (RCS UP) created by GSMA.
It contains a set of Advanced Calling and Messaging features and agreed enablers – such as application to person messaging (chatbots) and conversational commerce (the seamless integration of transactions and messaging).
To date 46 Mobile Network Operators and 12 manufacturers, covering a subscriber base of 4.7 billion people globally, have committed to supporting a single, standard implementation of the Universal Profile. That means that the profile will be implemented by most smartphones makers (similarly as in the case of VoLTE/VoWifi). They are Alcatel, ASUS, General Mobile, HTC, Intex Technologies, Lava International Ltd., LG Electronics, Lenovo/Motorola, Samsung Electronics and ZTE,. Moreover the standard is supported by mobile OS providers Google and Microsoft. Therefore the devices will be equipped (as from Q2 2017) with a built-in Advanced Messaging app, so consumers will be able to text, chat and share media without the need to download any special application. (However a usage of app is also an option supported by RCS Universal Profile.)
Update: We have got the first smartphone with RCS UP support – more here.
It is worthwhile to mention that Google is playing an important role because it bought Jibe – one of a few useful RCS clients, and has developed a universal Android client based on the GSMA RCS UP. Google along with Sprint in US and Rogers in Canada announced that they’re rolling out with their RCS Messaging based on RCS UP at the end of the last year. Besides, as GSMA says, Google is offering a carrier hosted service for Operators to launch and manage Advanced Messaging services to their customers without deploying the RCS or even IMS infrastructure.
The year 2016 was in many ways the year of VoLTE and VoWifi. IP-based communication became an established standard and mobile operators are getting confident with the new technology. GSMA has just published the numbers for 2016.
IP deployments in 2016
One thing is the official announcement that an operator offers VoLTE/VoWifi, the other thing how much compliant it is and what services are really supported. We can see a big progress here as well. More and more operators are trying to interwork over IP, provide IP-based emergency services, IP voice and video mail, enhanced voice quality such as HD or EVS, support real multi-device feature or self-provisioning.
Operators are also trying to offer web-based access using WebRTC, which seems to be a must for enterprise integration and communication in context. RCS was not that popular in 2016, operators mostly use IPSMGW to provide SMS over IP. But seems it starts to change as can’t rely on SMS forever.
If the 2016 was about calling over IP, the 2017 can be about M2M (again). In the last 12 months we have seen many Sigfox and LoRaWAN deployments, and finally we got the log-awaited ‘so-called’ specification NB-IoT and we could see its first deployment. I planned to write a post about LPWANs, but then I read and article written by Nick Hunn, which is much better than anything I could put together: nb-iot is dead long live nb-iot.
Although we made a big step forward it doesn’t make our life any easier. In 2017 we can expect Artificial Intelligence everywhere, but I doubt it will allow us to relax either 🙂 Happy new year everyone!
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 🙂
I always enjoy to visit telcos’ monitoring centres. One feels like to be in NASA. It’s a pity that mostly it is not allowed to take any pictures.
It is interesting that rarely there is just one vendor of this monitoring. Usually it is a mix of various applications, which inform about the most important KPIs and events. Often we can see open applications to be used. If you are working in support you probably know at least some of them – cacti, zabbix, nagios, observium, MRTG, munin, zenoss, etc. One of them is grafana.
I’ve recently seen a T1-operator monitoring based on Grafana. The nice thing about it is that it allows to include various data sources, analytics where we can easily combine charts with related events and it supports multi-tenancy. Just before Christmas we have got a new version 4.1 with a new alerting feature. The alert rules are easy to configure using existing graph panels and threshold levels can be set simply by dragging handles. The rules will continually be evaluated by grafana-server and notifications will be sent out when the rule conditions are met. Besides the altering there are many other improvements and enhancements.
Anyway whatever tool you use, happy NYE monitoring!
Recently I have been asked for an advice regarding automated testing. I spent several years in R&D designing our test framework (for SMSC, MMSC, RCS, IPSMGW, ..), sometimes I felt like trying to break a wall, sometimes it was very rewarding (at least for me it is rewarding to find a bug 🙂 ). There are some lessons learnt I’ll remember for a long time. I’m afraid this post won’t be a short reading.