Over and over I need to go through the basics. One would think that everything was already said but sometimes a refresher is a good thing. Especially when we rely a bit on what we guess than on what we really know. I’m not any exception 🙂
There are many changes we can witness these days in operators’ networks.
The core network has become much more complex. We still have the 2G/3G mix in place, we added new LTE network, WiFi network, some operators are even introducing WebRTC GW. I’ll leave aside the IoT/M2M traffic – however very soon it will be the most important guy in town (now 2nd – 3rd biggest source of revenue for mobile operators).
Why we need the IMS? There is a big difference between the legacy core networks (let’s say UMTS) and the new Access Networks (LTE, Wifi, Internet).
Firstly in order to guarantee a seamless transition we need to support the same set of compatible services as in GSM/CDMA. That means the the users still have to be able to
- place/receive voice calls, regardless how they or their counterparts are connected to the network (CS break-out/break-in, Voice-Call-Continuity, MNP, roaming),
- manage supplementary services,
- communicate with voice mail and other systems
- hear usual tones and announcements
- send/receive SMS/MMS
- call emergency
From the operator’s point of view we need to support also
All this functionalities should be supported for any type of access (LTE, Wifi, Internet these days). And sure we want to support some new services as well
Another big difference is that in contrast to GSM/CDMA the network should be user-centric. Not device-centric any more. That means user can have more devices, devices can be connected at the same time from various access networks with different capabilities. With the WebRTC the device can be any HTML5 compatible web browser.
The Ip Multimedia Core Network Subsystem (IMS) was defined in 3GPP 23.228 as a user-centric network which is access independent and supports
- User identity
- User Authentication
- Session Routing
- Session Control
- QoS, ..
Simply it should support all what the legacy networks are capable of plus it has to be general enough for any new services in the future.
The IMS has a layered structure
In the first layer called Data/User/Transport the most important element is a Session Border Controller (SBC). On our simplified picture SBC groups Proxy-CSCF (P-CSCF) and IMS Application Level Gateway (IMS-ALG) and Access Gateway (AGW). It provides the connectivity (Access-SBC, Interconnecting-SBC), it is responsible for the security and encryption, it works with media and supports QoS. SBC is really a critical component and can become easily a bottle-neck for the IMS. As other IMS elements mostly don’t work directly with the raw data or media the SBC is applying all the data related policies.
Another important elements are Media Gateway Control Function (MGCF) and Media Gateway which are practically implemented as a part of MSC/MSS. That means they are physically in the legacy network and provide the interface for CS break-in/break out and for Access Transfer.
The second layer called Control/IMS is responsible for authentication, session routing and session control. The most important element is Serving-Call Session Control Function (S-CSCF). S-CSCF is an end-point for the user registration, it initiates 3rd party registration towards application servers, and provides session routing and control. In majority of deployments the S-CSCF is collocated with Interrogating-CSCF (I-CSCF) and Breakout Gateway Control Function (BGCF) in IMS Core also called CSCF.
The third layer is called Service/Application and it is responsible for application of service logic (routing based on presence, supplementary services, translations, triggering of tones and announcements played by MRF, presence, etc.). Application Servers sometimes also interwork with the legacy networks (IPSMGW, iSCP, ..).
We can say that most of the service logic (service as VoLTE, RCS) is implemented in the Application Servers (e.g. TAS/MMTel, SCC AS, RCS, PRS, ..). They make the decisions, they are the brains. IMS layer ‘only’ provides the routing – pumps the blood in the IMS veins and arteries. The SBC is then the one who really does the job, who is working with the real data and other network elements.
The logic of the IMS is driven by DNS and HSS databases. The DNS is responsible mainly for the routing on the network level. HSS contains all the information about subscribers and services. It is important for authentication, application level routing and service persistency.
For AAA (Authentication, Authorization, Accounting) we use the diameter protocol over SCTP/TCP. That means we use it for communication with HSS database (Cx, Sh, Zh interfaces), communication with access network (Rx interface) and for billing (Ro, Rf interfaces).
Sometimes we hear that the IMS is protocol independent. That is meant for media protocols. But in practice the media is sent over RTP. For RCS we use also MSRP. In case of WebRTC we can see SCTP or even WS for the data transmission.
Last but not least we use protocols for data encryption such as IPSec or TLS.
Services and complexity
IMS itself a bit too general for mobile operators. That’s why we have plenty of other standards (such as VoLTE, VoWifi, RCS, …) which specify how exactly we should use the IMS for our services. That is being done by GSMA (VoLTE, VoWifi, DNS, WebRTC integration ..) or OMA (RCS, CPM, REST API for WebRTC, ..).
Couldn’t we replace the IMS with something less complex, more compact? Of course, we could. That’s what the WhatsApp and others do. But than we will miss something what IMS brings – the common standard. This standard allows integration of products from various vendors and also integration of various networks. (That doesn’t mean that it couldn’t be done better. The number of standards is really a nightmare ).
Other related posts:
- VoLTE Illustrated: Beginners Guide
- VoLTE in IMS
- WebRTC and IMS
- VoWifi Overview
- SIP Illustrated: SIP by sip