IMS from 10.000 feet

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).

 

IMS for VoLTE

IMS for VoLTE

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

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
  • Provisioning
  • Charging
  • Roaming
  • 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.

Layers

The IMS has a layered structure

IMS Layered Architecture

IMS Network Architecture

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.

Protocols

The signaling protocols selected for IMS are the SIP and SDP (3GPP 24.229) over TCP/UDP/SCTP.

SIP INVITE Routing – Originating part

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).

There are plenty of other protocols which can be used such as various protocols on top of HTTP/WS – XCAP, XHR, SOAP, REST, JSON, SIMSERV, SPML, etc., then LDAP, DNS, DHCP, STUN, ..

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, ..).

IMS Network

IMS Network for T1 Operators

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:

 

 

13 thoughts on “IMS from 10.000 feet

  1. Pingback: Much Ado about Registration | Real Time Communication

  2. Pingback: WebRTC and IMS | Real Time Communication

  3. Pingback: VoLTE in IMS | Real Time Communication

  4. Pingback: SMS in 2G/3G | Real Time Communication

  5. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  6. Pingback: OTT and VoLTE Calls | Real Time Communication

  7. Pingback: Diameter Overview | Real Time Communication

  8. Pingback: SCTP Introduction | Real Time Communication

  9. Pingback: News: Finally 4G? | Real Time Communication

  10. Pingback: GSMA Advanced Messaging – RCS Universal Profile | Real Time Communication

  11. Pingback: SIP Illustrated 1: Basics | Real Time Communication

  12. Pingback: SIP Illustrated 2: SIP Message | Real Time Communication

  13. Pingback: SIP Illustrated 3: Routing and IMS Registration | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s