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
- 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.
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.
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.
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.
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 🙂
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.
Presence sharing is a very important functionality when it comes to Rich Communication. We know it from many communicators such as Skype, Google Hangout, Facebook, Jabber, etc. But maybe you noticed that each of these applications has a different set of statuses, allows to share a different type of hard-state data (e.g. avatar, idea of the the day, web link ..). Mobile operators require some more unified approach as a particular status should be interpreted in the same way in all the networks (‘busy’ should have the same meaning in T-Mobile, Vodafone, or any other network).
That’s why Open Mobile Alliance (OMA) standardized Presence sharing for RCS using SIMPLE – Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (see http://technical.openmobilealliance.org/Technical/technical-information/release-program/historic-releases/presence-simple-v2-0). But that can be quite confusing, as the presence system is not simple at all. It is very complex and sometimes a bit difficult to grasp.
Let’s start from the beginning – what is the presence?
What is Presence?