The role of IMS in Voice over 5G (VoNR)
The IMS specification started life, in 3GPP’s Release 5 specification, as part of the network evolution from a circuit to pure packet-switched core. That was 2003. No – that’s not a typo. In fact, I’m being generous because that is when the specification which specifically employed the term IP Multimedia Subsystem was introduced. The actual origins of IMS can be traced back to the “all-IP network option” which appeared in even earlier releases between 1999 and 2000. Now, just to be clear, I’m a massive IMS fan but after my last post on the topic, back in 2016, I swore to myself that if I ever had to write another, someone was going to pay. Having now remembered that someone is graciously paying for this, I decided to take a few minutes to explore the evolution of IMS in 5G.
While we indeed hailed the end of the circuit switched voice era back in the early part of the century, the fact is that even following a herculean effort between 2018 and 2019, the number of voice calls employing VoLTE in the UK is only around 60%. And that’s a developed nation (apparently) with a reasonably forgiving sociogeographical makeup. Admittedly, with that recent drive to deploy VoLTE, those 40% of have-nots may well be due to no fault of the service provider. As of 2019, for example, the European Union’s in-vehicle emergency call system (eCall), was based on 2G/3G technologies and people are not inclined to buy new vehicles for a clearer ambulatory experience. Although, having now written that, they probably should. Aside from that and the older handsets still employed by elderly users in rural locations [yes, dad, I’m talking about you] and there are also many other commercial and government systems that require those older radio technologies.
However, with VoLTE adoption still lagging, other countries and carriers might need further prompting to take the plunge. Respect to the 3GPP, they put a line in the sand with Release 15 (5Gv1) demanding the end of circuit switched voice. By Release 16 (5Gv2), though, the tide of reality had washed over it and an option to continue allowing Circuit Switched FallBack (CSFB) was included. Anyway, all that is just backstory because operators should be going all-out to support end-to-end packet voice on their shiny new 5G infrastructures and that requires a refresh of their existing IMS implementation. While that obviously means eradicating circuit switched voice through a legacy mobile switching center (MSC), two choices remain, depending on the appetite for evolution: Continue down the VoLTE path or jump headfirst into Vo5G.
The 3GPP have identified 172 Standalone (SA) and Non-Standalone (NSA) 4G/5G migration options. Alright – that’s a slight exaggeration. Back in June 2016, the RAN Service and Systems Aspect group proposed 8 deployment options, some with a couple of variants which the 3GPP then expanded on when adopting the proposal as part of Release 15. Granted, a couple of these were obvious, including Option 1 (stay all LTE) and Option 2 (deploy just 5G) and others (Option 6 and Option 8) were quickly written-off as unfeasible.
Many of the migration options maintain much of the Evolved Packet Core (EPC) infrastructure, allowing operators to preserve their existing IMS core and continue packet voice migration using VoLTE, if they so desire.
Legacy IMS systems could still support VoLTE during 4G/5G migration
Even our forward-looking interworking approach to 5G migration - which allows immediate turn-down of the EPC - has an option to keep the legacy IMS operational, with a skeleton number of SAE Gateways supporting it. While you might not have to upgrade those elements to support exponential traffic growth, with control/user plane separation (CUPS) for example, you still must maintain them. Seriously, why would you want to support that and a legacy IMS core? Unless you are lucky enough to have adopted a cloud native IMS - of which Clearwater Core from Metaswitch is still the one-and-only - in the last five years, you are (at best) dealing with components employing a monolithic codebase, shoehorned into a highly inefficient Virtual Machine. At worst, that monolithic codebase comes inside a proprietary hardware platform that arrives in a truck at your loading dock (typically in-bulk on the last day of your supplier’s financial quarter) every time you need to add a few more subscribers.
With a 4G/LTE interworking function in place or a standalone 5G implementation, you can forego or migrate from VoLTE in favor of Vo5G (aka Voice over New Radio/VoNR). That does not eliminate the need for an IP Multimedia Subsystem, but a 5G-ready IMS Core comes with some pretty cool enhancements. While optional before, a 5G IMS must be built cloud native using microservices methodologies, thereby affording the numerous benefits containerized OS virtualization has to offer over virtual machines. (Numerous enough, that is, to warrant a veritable deluge of posts on our blog). From an implementation standpoint, a cloud native IMS core affords the ability to participate in network slicing, an important technical and business goal of 5G. Instantiating highly granular and optimized IMS slices for specific applications and steering traffic via the 5G Network Slice Selection Function (NSSF) extends the critical concept of service isolation into the voice control plane.
Deploying Vo5G/VoNR, however, also requires updates to decades old IMS interfaces allowing the implementation of core components into the 5G Service Based Architecture (SBA). This is a large focus of the 3GPP’s, “Study on enhanced IP Multimedia Subsystem (IMS) to 5GC integration”, an exploratory technical report published as TR 23.794. And if you think I’m not totally stoked by the new eIMS acronym employed throughout that document, you obviously don’t know me very well. Slicing aside, TR 23.794 goes into great detail about augmenting and replacing Diameter interfaces with Service Based Interfaces (SBIs). This allows a 5G IMS core to support not only existing Producers (to use Service Oriented Architecture terminology) but newer, 5G-specific, network functions deployed within the SBA. As might be the case with our interworking approach, this could also include hybrid implementations, where a classic Home Subscriber Server (HSS) is located via the Network Function (NF) Repository Function (NRF) using an SBI Nnrf_NFDiscovery_Request message which then dips the current HSS database via a proxy.
Supporting Vo5G/VoNR with enhanced IMS within the Service Based Architecture
This would extend to each distinct cloud native IMS Core network function exposing a Cx or Dx interface to the HSS or a Subscription Locator Function (SLF), namely the consuming P/I/S-CSCFs. The ultimate goal is to facilitate a smooth migration to the SBA’s Unified Data Management (UDM) Service. Likewise, supporting network functions with a Diameter-based reference interface, such as applications servers (Sh) and Policy Control Functions (Rx) must move towards SBI’s, as those NFs evolve to embrace cloud native characteristics. The 3GPP study explores the mapping of Cx and Dx messages to existing SBI Nudm operations and replacing all diameter interfaces, currently defined within TS 29.228 and TS 29.229, with new IMS services with a Nhss_ims_ prefix.
So, four years after declaring that IMS had come of age, it has moved back home, and we are getting shouldered with college debt. Not being happy to sit in its bedroom with the curtains closed listening to Nirvana, however, it has a clear plan to build a life for itself. We should all support that for as much as IMS was our past, eIMS is our future.
Simon is the Director of Technical Marketing and a man of few words.