By Dongwook Kim, 3GPP MCC

Imagine that you just found a mistake in your income declaration submission and you need to correct it immediately. What means of communication do you use to proceed? Most likely, it would be via a phone call to the tax office. Whilst many today use instant messaging services to make simple or informal communications, the traditional phone call and carrier messaging services are still widely used for formal and urgent situations. Considering that these services are also mandated by regulation, it is important for the networks to support these services. This document provides an overview of how such communication services are provided over mobile networks and the technologies behind the services in 4G and 5G networks.

Communication services

Communication services in this document are defined to be the basic carrier communication services primarily designed for communication between people. These include voice calls, video calls and messaging services.

Communication services are necessary because they provide a formal and official way of communicating. It is possible to subscribe to or cancel a subscription to a service via a phone call or short message services (SMS). Whilst it is true that many of these can be done via electronic methods today, the communication services still provide the most versatile form of interaction. For example, when all fails, a customer would call a call centre of the company.

It is also critical to provide communication services over mobile networks, because emergency communications require the basic communication service methods (especially voice calls) to function. It is very challenging to type a message or create multimedia during an emergency. Most of the time, the caller must attend to the emergency in the field and brief the dispatcher by voice simultaneously. This is why communication services provided by mobile networks are mandated to support emergency communications, and the reason why the services need to operate with high reliability.

How are communication services provided over mobile networks?

The communication services are supported in different ways depending on the generation of mobile networks. For 2G and 3G, the communication services are supported over the Circuit-Switched (CS) domain, where resources and the end-end path are reserved to establish communication which enabled the quality of the communication to be guaranteed. The downside, however, is that the resources can be underutilized and it is sometimes not possible to communicate to the parties whose call have been established (i.e., the line is busy).

On the other hand, for 4G and beyond, the communication services are supported over the Packet Switched (PS) domain. Packet-switched networks are what today's internet employs. Here, data is fragmented into various packets, where the packets can take different paths to reach the destination. Therefore, the packets may be received by the destination out of order, but all of the data ultimately reaches the destination. PS can use the resources of the network very efficiently, but is limited in guaranteeing the quality of service. 

These differences attribute to the evolution of the mobile generations. Initially, the mobile networks were created to provide communication services (specifically voice). It was only in the later stages of 2G that data communications were considered and the PS domain was introduced in parallel with the CS domain for this purpose. 3G supported both CS and PS domains by design. However, the 3G architecture did not differ significantly from that of the later 2G (GPRS, EDGE, etc.). It was in 4G, where only the PS domain remained, that the architecture shifted significantly and the support for communication services moved from CS domain to PS domain.

IP Multimedia Subsystem (IMS)

Recalling that PS domain came with the limitation that quality of service is more difficult to guarantee than CS domain, supporting voice services over PS domain of 4G (and beyond) networks required due consideration. This is where IP Multimedia Subsystem (IMS) comes in. IMS is defined to be (IMS textbook) "a global, access-independent and standard-based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols." and is able to provide carrier services over the PS domain data pipe.

In the context of communication services, IMS is the carrier's service platform which is access agnostic (i.e. is able to support multiple access types) and can coordinate with the access networks to provide carrier-grade quality calls or quality of service (QoS). This makes IMS an ideal candidate platform for telco communication services, because only one services platform (at least in theory) is required to provide communication services over multiple access networks that the carrier operates.

The two main protocols of IMS are Session Initiation Protocol (SIP) and Session Description Protocol (SDP). SIP is used to communicate call/session related signalling among the network nodes and the clients and SDP is used to describe the related media of that call/session (e.g. voice media details such as codec etc.). Whilst these protocols are also used by non-carrier Voice over IP (VoIP) services, IMS differs in that the platform interacts closely with the access networks in contrast to typical VoIP services that treat the underlying transport as mere data pipe without guaranteed quality.

VoLTE/VoNR and evolution

VoLTE and VoNR* refer to the communication services provided by IMS networks over 4G and 5G networks respectively. Both utilise IMS as the service platform to support communication services. Note that it is also possible to provide communication services over other accesses (e.g. WLAN) or to provide different types of multimedia services using IMS. However, this document focuses on the communication services over 4G/5G access (i.e. LTE and NR radio access networks (RANs)).

It should be highlighted that VoLTE and VoNR are not "technically correct" terms but terms to describe the services, and these are based on the respective GSMA profile of 3GPP specifications. For example, GSMA PRD IR.92 is the basis of VoLTE which defines "a profile for voice over IMS over LTE, and for SMS over IP and SMS over NAS, and lists “a number of Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolved Packet Core, IMS core, and UE features that are considered essential to launch interoperable services".  

The preliminary version of the VoLTE prototype was first developed by the One Voice Initiative, an alliance of vendors and carriers formed in 2009 that aimed to define the minimum mandatory set of functionality for interoperable IMS-based voice and SMS over LTE. Then, the GSMA announced that it adopted the work of the One Voice Initiative in February 2010 (https://www.3gpp.org/news-events/partner-news/industry-backs-volte-initiative) and published the version 1.0 of GSMA PRD IR.92 in March 2010.

The first VoLTE commercial service was in 2012, when MetroPCS from the United States of America launched its VoLTE service in August 2012. The world's first VoLTE interconnect was among the three operators in South Korea in June 2015, with all VoLTE enabled handset migration completed in November 2015. As of September 2020, there are 226 operators in 97 countries that have commercially launched VoLTE (https://www.gsma.com/futurenetworks/all-ip/statistics/).

The emergence of 5G resulted in both a new packet core network (the 5G Core) which replaced the 4G Evolved Packet Core  and a new radio access technology, namely 5G NR. However, IMS is not impacted by these developments as care was taken to support certain legacy interfaces to ensure that communication services can be supported over 4G or 5G without impacting the IMS.

* Technically correct term will be Vo5GS (Voice over 5G System), but this document will take the more popular terminology currently adopted in the market.

Benefits of VoLTE/VoNR

VoLTE/VoNR services provide a better user experience  compared to legacy CS services. Firstly, VoLTE/VoNR comes with better codecs such as the Adaptive Multi-Rate Wideband (AMR-WB) and Enhanced Voice Services (EVS), providing much clearer and more natural voice experience during calls. Secondly, the call setup times of VoLTE/VoNR are much faster than that of the legacy CS services. 2G/3G networks would take, on average, 5 seconds to establish a call and this can be reduced to 0.25 - 2.5 seconds for the case of VoLTE. Lastly, falling back to legacy CS services also degrades data experience while calling. There are many instances where the user needs to access data services (e.g., maps) while calling, but falling back to CS services will limit data to 2G/3G data connection. VoLTE/VoNR, on the other hand, allows the user to use 4G/5G data connection while calling, enhancing the user experience.

How does VoLTE/VoNR work? 

3GPP Specifications and Profiles

As described above, VoLTE/VoNR is based on GSMA profile(s) of 3GPP specifications. Depending on the local market, there can be further adaptations of the GSMA profile(s). For example, there is a TTA VoLTE standard (TTAK.KO-06.0357) that is based on GSMA PRD IR.92. Whilst there are a few deviations from the GSMA profile, the standard nevertheless follows IR.92 to great extent and sometimes further tightens the features to be used. The Figure below provides a graphical overview of the relationship among these documents.

3GPP specifications, GSMA profiles and (possible) local adaptations

3GPP specifications

In order to support VoLTE/VoNR, 3GPP has created a large number of technical specifications covering all aspects of the service and covering the access networks, the core network, the IMS platform and the terminal.  

Firstly, the 3GPP defines 4G and 5G access networks, which are responsible for the radio resource related aspects of the mobile network. 3GPP defines the radio bearers and the different radio protocols (e.g., Radio Link Control: RLC) such that they can be used for VoLTE/VoNR. Secondly, the 3GPP defines the 4G and 5G core networks, which are responsible for managing and operating the network overall (e.g., session management, mobility management, policy and charging, security, subscriber database, etc.). It is through the core networks that the IMS is able to enforce quality policies onto the access network. Thirdly, 3GPP defines the terminal related aspects, such as the smart card applications (i.e. IMS SIM modules) and the conformance specifications for the terminals and the IMS. Of course, the 3GPP also defines the IMS overall, ranging from architecture, the codecs to be used in VoLTE/VoNR, to the security mechanisms used by the IMS.

GSMA Profiles

There are many IMS related profiles developed and maintained by GSMA, but there are two major profiles with respect to communication services. The first is GSMA PRD IR.92, which defines the global mandatory minimum requirements for the User-Network Interface (UNI) of VoLTE. As described in the evolution of VoLTE/VoNR, this profile marked the beginning of VoLTE. The second profile is GSMA PRD NG.114, which is the equivalent document to IR.92 for VoNR. NG.114, however, is different from IR.92 in that IR.92 does not include video calls and carrier instant messaging service called Rich Communications Suite (RCS), while NG.114 includes video calls and RCS in addition to VoNR.  These differences between PRDs are essentially generational in that a 5G communication device (according to GSMA PRD NG.114) must support video and RCS messaging as well as voice, whereas the earlier IR.92 concentrated on voice and SMS services with other services being included in separate PRDs, for example, GSMA PRD IR.94 defines the profile for ViLTE (Conversational Video over LTE).

There are also profiles that are relevant to VoLTE/VoNR which cover roaming and interworking aspects such as GSMA PRD IR.65 (IMS Roaming, Interconnection and Interworking Guidelines), IR.88 (LTE Roaming Guidelines), IR.95 (SIP-SDP Inter-IMS NNI Profile) and NG.113 (5GS Roaming Guidelines). 

Service architecture and continuity

VoLTE/VoNR Architecture overview

VoLTE and VoNR are supported by the IMS networks over EPS and 5GS respectively. The Figure below shows a simplified architecture where standalone 4G and 5G networks are connected to IMS networks in order to provide VoLTE and VoNR services to a non-roaming user.

In the 4G network, eNB stands for eNode B and it is the radio access network node that connects with the UE. MME stands for Mobility Management Entity is the control plane entity that is in charge of NAS (Non-Access Stratum) signalling with UE (the NAS signalling terminates at the MME) . S-GW stands for Serving Gateway and it routes/forwards the user packets from the RAN and the P-GW. P-GW stands for PDN (Packet Data Network) Gateway and it is the entry and exit point of traffic between the UE and the external packet data network (e.g., internet). HSS stands for Home Subscriber Server and holds subscriber information. Finally, PCRF stands for Policy and Charging Rules Function and provides control for policy and charging.

For the 5G network, gNB stands for gNode B and it is the radio access network node that connects with the UE. Contrary to the 4G network, control plane and user plane of the core network are completely separated and control plane nodes include AMF (Access and Mobility Function), SMF (Session Management Function), PCF (Policy Control Function), and UDM (Unified Data Management), while user plane of the core network is served by UPF (User Plane Function). Whilst not the same, AMF is analogous to MME, SMF is analogous to the control plane functions of S-GW & P-GW, PCF is analogous to PCRF, and UDM is analogous to HSS of 4G networks.

In the IMS, P-CSCF stands for Proxy Call Session Control Function and is the first point of contact for the UE. I-CSCF stands for Interrogating CSCF and is responsible for identifying correct S-CSCF for a given user of the IMS. S-CSCF stands for Serving CSCF and is responsible for the IMS session control for a given user and invocation of the TAS dependent on the supplementary services applicable to the user. TAS stands for Telephony Application Server and it supports the various MMTEL (Multi-media Telephony) supplementary services such as call forwarding and call barring. The MRF (Media Resource Function) provides tones and announcements (usually related to supplementary service) in the media plane of the IMS. Finally, IBCF/TrGW stands for Interconnection Border Control Function / Transition Gateway, which provide control plane and user plane functionality for interconnection to other IMS networks.

Overall, one can observe that the IMS network provides communication services to the UE by interacting with the core network entities of 4G/5G network, which controls the radio access networks and underlying packet network to ensure the desired quality for communication services are achieved. Since there are many procedures that communication services require (e.g., registration, deregistration, call establishment/teardown, supplementary services such as call forwarding and call barring), readers are encouraged to refer to the following guidelines and specifications:

• VoLTE service description and implementation guidelines (GSMA N2020.1) for overview of end-to-end VoLTE architecture and service procedures
• 3GPP TS 23.228: for more detailed architecture and procedures specific to IMS, along with additional considerations for 4G/5G networks when accessing IMS

Interworking voice services

Communication services require carrier-grade performance, meaning that it must be reliable and should work independent of the underlying radio access technology. For example, the subscriber should be able to use communication services whether it is legacy circuit-switched or VoLTE or VoNR if at least one of them is supported in the area concerned. For this purpose, there are two types of solutions that the mobile network employs: Single Radio Voice Call Continuity (SRVCC) and Fallback to previous generation.

SRVCC, in high-level, is a solution where the voice calls made in a generation of non-circuit switched capable radio access technology is handed over to another circuit switched capable radio access technology when required, allowing continuity of voice calls when the original radio access technology performance/coverage  becomes limited (see Figure below). 3GPP SRVCC solution supports continuity between 4G (VoLTE) and legacy CS (2G/3G), and between 5G (VoNR) and legacy CS (2G/3G).

In addition to ensuring continuity of voice calls, it is also important to have access to a reliable communication service. Just as was the case for early (pre-VoLTE) 4G where the UE would fall back to 2G/3G networks when making/receiving voice calls (so-called CS Fallback), it is possible for 5G networks to fallback to 4G networks (i.e., VoLTE) when making/receiving voice calls when VoNR is not supported. The rationale behind this fallback is for users to enjoy the higher performance of 5G networks for services that does not require critical reliability, but still benefit from the already established reliable voice service (VoLTE) if they need to use voice services.

It is also possible to have fallback to 4G RAN from 5G RAN whilst maintaining connection to the 5G core network (5GC: 5G Core), where such fallback is called RAT fallback. Depending on the measurements of the two RANs, it is possible for the voice calls to be handed over from 5G RAN to 4G RAN while using VoNR. Of course, it is possible for devices to be handed over between EPS and 5GS depending on the coverage, just as it is possible for VoLTE devices to use legacy CS voices when 4G is not available but 2G/3G is. In this case, the choice of VoLTE and VoNR will depend on the available RATs and voice support on those RATs. The Figure below depicts EPS fallback (dark blue to grey arrow) and RAT fallback (dark blue to blue arrow) in high-level.

3GPP work on VoLTE/VoNR

As can be seen from the description on IMS and VoLTE, the VoLTE service has been deployed since 2012, and the related profiles were developed since 2010. Even further, 3GPP specifications for IMS were already being drafted as early as Release 5. This means that the work done on VoLTE (and latterly VoNR) are immense in volume and would be very challenging to fit in this overview document. Hence, this section will focus on the 3GPP work on VoLTE/VoNR since Release 15, the release that marks the beginning of 5G.

Release 15 functionalities

As the first release of 5G, Release 15 was where the work for VoNR started. After discussion on various options for supporting communication services of 5G system, 5GS_Ph1 work item decided that the communication services should still be provided by the IMS platform, and stage 3 started the 5GS_Ph1-IMSo5G work item to define the technical aspects required for the communication service, namely:

• 5G access network specific requirements
• Impacts on subscription data and interaction between the IMS and the HSS
• Impacts on policy and charging rules
• Impacts on numbering and addressing in IMS

Of course, it didn't mean that VoLTE was not impacted, as there were enhancements to IMS to take into account the latest advances in Internet Engineering Task Force (IETF) protocols under IMSProtoc9 work item. Furthermore, the IMSProtoc9 work item included the stage 3 work arising from evolution and enhancements in the requirements for IMS.

Release 16 functionalities

The 5G system differs from the previous generation in that it supports Service-based Architecture (SBA), where interfaces are not fixed to a network function to another network function but can be exposed by a network function to provide services to other network functions. It was in Release 16 where SBA features were defined in more detail, and the support of interaction between the 5G core and the IMS was defined in eIMS5G_SBA work item. For example, the policy control function services were updated such that IMS can access them as the application function of 5G core, and how discovery of P-CSCF and HSS should be in line with the discovery methods of network functions by Network Repository Function (NRF) in 5G.

In addition, 5G SRVCC to ensure continuity of voice calls in 5G was defined with 5G_SRVCC work item since there was no direct interworking between 5G and legacy CS networks (2G/3G) in Release 15 to enable the service continuity. In the 5G_SRVCC work item, there were work items to support 5G SRVCC in the 5G service-based interfaces and also legacy IMS interfaces, as it needs to interwork with the legacy CS networks.

The Release 16 IMSProtoc16 work item (i.e. the Release 16 equivalent of the IMSProtoc9 work item) provided enhancements to both VoLTE and VoNR in Release 16. Furthermore, there was eIMSVideo work item that allows video "ringtones" and "announcements" in IMS. Whereas in the previous releases of IMS supported only audio ringtones and announcements, the eIMSVideo work item enabled the provisioning of video ringtones and announcements by the IMS, potentially enriching the experience of both VoLTE and VoNR.

Release 17 functionalities

In Release 17, the 5G system charging systems were updated to support IMS charging functionalities using service-based interfaces in the 5GSIMSCH work item. In Release 15, this was limited to data connectivity and SMS, so this work updated charging support in the context of communication services. Since this is a Release 17 work item, it also supports the charging functionalities using service-based interface. Furthermore, to comply with the regulatory requirements of newly defined standalone non-public network (SNPN), the IMS was updated to support emergency calling in the context of SNPN with the IESNPN work item.

Optimization and enhancements were also made to IMS and 5GS, where signalling optimization to minimize the queries performed on HSS with the TEI17_IMSGID work item. In addition, the ING_5GS work item dealt with cases where 5G UE is not able to utilize EPS fallback because it disabled the 4G E-UTRA capability for some reason (causing disruptions to communication services). As previously , the IMSProtoc17 work item ensured that IMS specifications are aligned with the latest advances in IETF and also support evolution of IMS requirements in the same release.

Release 18 and looking ahead

In Release 18, the requirement on IMS to enable access to emergency services through SMS has been defined with the SMS2EC work item. In addition, the IMSProtoc18 work item is progressing to align IMS specifications with the latest advances in IETF and also support evolution of IMS requirements in the same release.

However, this is not the end of the work going on in Release 18. Whilst not within the scope of communication services defined in this document, the requirements and the solutions for next generation media leveraging IMS has been specified and are being specified in 3GPP. The requirements to support broadcast video service, remote control of video client, Augmented Reality / Virtual Reality (AR/VR) services were already specified in Release 16 with the enIMS work item.

In Release 18, the work is going on to define the support for AR/VR services and usage of data channel in conjunction with traditional IMS media (video/audio) and signalling to provide new services (e.g., sharing screens and gaming together during call). Furthermore, the eMMTEL work item defines the service requirements for enhanced IMS supplementary services. whilst the NG_RTC work item provides enhancements to IMS to support data channel services and the IBACS work item defines functionalities and enhancements to media aspects of IMS to support AR conversational service. The charging aspects of data channel is being considered in the IDC_CH work item and there is an additional discussion for Release 19, where the support of IMS data channel services in data off scenarios is being discussed with the IMSDCDataOff work item.

Concluding remarks

Communications services are still an important and vital aspect of today’s mobile networks today, also providing mission critical services such as emergency communications. The capability to support such mission critical services with high reliability is not easily achievable and requires careful design and work as described in this document.

Furthermore, the possibility to utilize the underlying technology of VoLTE/VoNR for leveraging next generation media for communications services makes VoLTE/VoNR not just socially desirable, but also economically attractive. The 3GPP will continue to enhance VoLTE/VoNR to provide both underlying infrastructure for social services and immersive experience with next generation media.

Acronyms:

References

3GPP Work Plan

See a listing of all work & study items here:  https://www.3gpp.org/ftp/Information/WORK_PLAN/ and search for ‘ACRONYM’ in the acronym field.

NOTE 1: Only parent work item listed above. Please ensure child work items are checked when identifying impacted CRs or new specifications.

NOTE 2: For simplicity, only work items of Release 15 or later have been identified and conformance aspects have been excluded. Please use "IMS", "VoLTE", "SRVCC", "IP Multimedia Subsystem" to search the work plan.

Working Groups

S1,2,3,4,5, C1,3,4,6, R2,3,5

3GPP Release:

Rel-9 onwards (VoLTE and VoNR)

Selected IMS Specifications:

[1] TS 22.228 on "Service requirements for the Internet Protocol (IP) multimedia core network subsystem (IMS); Stage 1" (from Rel-5)

[2] TS 23.216 on "Single Radio Voice Call Continuity (SRVCC); Stage 2" (from Rel-8)

[3] TS 23.228 on "IP Multimedia Subsystem (IMS); Stage 2" (from Rel-5)

[4] TS 24.229 on "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3" (from Rel-5)

[5]  TS 24.237 on "IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuity; Stage 3" (from Rel-8)

[6] TS 24.341 on "Support of SMS over IP networks; Stage 3" (from Rel-7)

[7]  TS 24.623 on "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary Services" (from Rel-8)

[8] TS 26.114 on "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction" (from Rel-7)

[9] TS 31.103 on "Characteristics of the IP Multimedia Services Identity Module (ISIM) application" (from Rel-5)

[10] TS 33.222 on "Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)" (from Rel-6)

NOTE: This is not an exhaustive list as there are more than 100 specifications related to VoLTE/VoNR. Therefore, readers are encouraged to refer to the GSMA Profiles to check referenced specifications and search through specifications in 3GU (https://portal.3gpp.org?sUrl=adc3de2e).

NOTE: For simplicity, only CRs corresponding to WIs described in 3GPP Work Plan section have been selected.

See also:

• Miikka Poikselka, Georg Mayer (2009). The IMS: IP Multimedia Concepts and Services (Third Edition), John Wiley & Sons Ltd.
• Miikka Poikselka, Harri Holma, Jukka Hongisto, Juha Kallio, Antti Toskala (2012). Voice over LTE: VoLTE, John Wiley & Sons Ltd.
• GSMA IR.92 IMS Profile for Voice and SMS
• GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
• GSMA IR.65 IMS Roaming and Interworking Guidelines
• GSMA IR.95 SIP-SDP Inter-IMS NNI Profile
• GSMA IR.94 IMS Profile for Conversational Video Service
• GSMA N2020.01 VoLTE service description and implementation guidelines

IMPORTANT NOTE: Please be aware that these pages are a snapshot of the work going on in 3GPP. The full picture of all work is contained in the Work Plan (https://www.3gpp.org/ftp/Information/WORK_PLAN/)  

Updated: 12/09/2023