What is the IP Multimedia Subsystem (IMS)?

IMS is the core access-independent framework based on the Internet Protocol, which allows different types of multimedia services (e.g. Voice over IP / Voice over LTE, Video Conferencing, Cloud Gaming, Cloud and Edge Computing, Virtual Reality, Instant Messaging, Internet of Things etc.) and converges all types of both fixed and wireless access networks and devices. The IMS not only provides multimedia session control in the packet-switched (IP) domain but also allows integration of circuit-switched systems into the packet-switched core network. Figure 1 shows the coexistence of multiple networks and services within the IMS core.

IMS is based on a variety of protocols, most of which have been developed by the IETF (Internet Engineering Task Force) and 3GPP (The 3rd Generation Partnership Project). Two primary elements of the IMS are the SIP (Session Initiation Protocol) and the SDP (Session Description Protocol) protocols. Another major protocol used for subscriber profile-related data acquisition from the database is Diameter.

The IMS Architecture

The main requirements for the IMS Architecture are as follows:

• IP Multimedia Sessions and IP Connectivity
• Ensuring QoS (Quality of Service) for IP Multimedia Services
• IP Policy Control for Ensuring Correct Usage of Media Resources
• Charging Arrangements
• Secure Communication
• Support of Roaming and Interworking with Other Networks
• Layered Design and Access Independence.

These features are described in greater detail below.

A single IP Multimedia Session should provide voice, video, and instant text messaging sessions as well as allow IMS users to combine and map a variety of other IP-based services as they choose in a single communication session. To access these services, all user devices must have IP connectivity and their assigned IP address.
To ensure desired QoS, the UE (User Equipment) negotiates its QoS requirements and capabilities such as media type, data rate, packet size, etc. After negotiation of these parameters, UE will allocate sufficient resources from the RAN, packetize and encode media with the RTP (Real Time Protocol) and send it via SCTP (Stream Control Transmission Protocol), TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). If the resources cannot be reserved, the session will be dropped.
The IP Policy Control refers to the network’s ability to detect, control, and authorize media usage, meaning that the IMS network should be able to detect the usage of an application such as Skype or WhatsApp and block it or charge media usage differently. That being said, IMS must have the ability to provide different charging models based on used services, data usage, data rate, duration of the session and many others. IMS Core also enables secure communication based on authentication and authorization mechanisms such as AKA (Authentication and Key Agreement) and SIP Digest. In addition, IMS users should be able to access the IMS core independently of their geographical location and contact non-IMS users. The architectural setting of the IMS is built upon three planes: application, control, and user plane. The application plane provides services, the control plane manages the SIP session and signaling data, while the user plane handles media data.

Figure 2 depicts the nodes in the IMS Core network. As the figure 2 shows, the two main entities in the IMS are the CSCF (Call Session Control Function) and the HSS (Home Subscriber Server). CSCF consists of four main roles: P-CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), S-CSCF (Serving-CSCF) and E-CSCF (Emergency-CSCF), which is not shown in figure 2. The P-CSCF often serves as the A-SBC (Access-Session Border Controller) and is the first contact with the IMS core. P-CSCF is also responsible for SIP compression, security and authentication and interacts with both PDGW/PCEF (Packet Data Gateway/Policy and Charging Enforcement Function) and PCRF (Policy and Charging Rules Function). P-CSCF also finds suitable I-CSCF via DNS (Domain Name Server). The I-CSCF has the following tasks: finding and assigning the proper S-CSCF to handle the subscriber, based on the server capabilities obtained from the HSS via Diameter protocol. S-CSCF acts as a brain in the whole IMS core and is the stateful element which monitors the call session, downloads the subscriber profiles from the HSS during registration, handles deregistration, and is responsible for routing.

E-CSCF serves as a special function which handles emergency requests towards police, ambulance, fire brigade, and other rescue services. In addition, BGCF (Breakout Gateway Control Function) serves as a router for calls not intended for the subscribers of the home IMS network of the calling party. HSS serves as a frontend for the real-time and in-memory subscriber profiles database. The database stores subscriber profiles and other non-subscriber-related data. HSS interacts with other IMS entities via the Diameter protocol. However, when interacting with the DB (database), it uses the LDAP (Lightweight Directory Acquisition Protocol). In order to locate the subscriber, the HSS must interact with the MME (Mobility Management Entity), also via Diameter.

IMS in 5G Networks

Although the functionality of the IMS core within the 5G networks remains unchanged, the implementation of the IMS network somewhat changes. While the 4G IMS network elements are usually physical (bare metal) servers, administering only one network node that installs directly on top of the OS (Operation System) of the server, 5G IMS core is fully oriented on virtualization of network nodes and their deployment on top of cloud service. Figure 3 shows the building blocks of one network element in the 4G IMS core.

The 5G IMS core implements NFV (Network Function Virtualization), meaning that the network appliance hardware is replaced with VMs (Virtual Machines). A usual requirement for such a network is sufficient computing power, memory and storage. Therefore, a Cloud service in high availability mode should be deployed (e.g. TripleO distribution of OpenStack). Such a Cloud service consists of Undercloud and Overcloud. Undercloud is deployed on one hardware appliance and acts as a hypervisor for bare metal servers which run the Overcloud. On the other hand, Overcloud acts as a hypervisor for VMs which run the network function applications. More recently, the traditional VMs are now being replaced with containers. Figure 4 depicts building blocks of multiple VNFs (Virtual Network Function) in the 5G IMS core.