Can VoNR+ reignite the allure of IMS?
I don’t think I’ve ever told anyone this, but I’m quite… fond, of the IP multimedia Subsystem. This admiration likely stems from the early part of the decade when my first marketing role had me peddling some of the earliest SIP application servers. Fast forward a decade and I was back to SIP cores. Metaswitch launch Project Clearwater, a unique open source IMS project that represented the very first virtualized network function within a newly defined ETSI network functions virtualization (NFV) initiative. It was this innovation that turned those with an innate aversion to IMS into cheerleaders of the technology.
IMS was the perfect case study for cloudification. It is a critical but complicated control plane component (1) within emerging voice infrastructures but remains a pure operational and capital cost-center with no attributable benefit to the top line. Removing the reliance on physical hardware and automating implementations helped move IMS from a much-maligned necessity to an adored adjunct. OK, adored might be a stretch but it is fair to say that people no longer had a negative visceral reaction any time IMS was uttered.
Since then, my interest has waned, somewhat. There was a little excitement at the prospect of new 5G service-based architecture (SBA) interfaces in support of voice over new radio (VoNR) (2), a few years back, and the fact that Clearwater’s call session control functions (CSCFs) extensively employed northbound HTTP API’s proved prescient. But, let’s be honest, that’s all inside-baseball stuff: Back-end improvements with zero service upside. Around the same time, however, there was an initiative brewing to breath new life into network voice, and IMS was at the heart of it.
Enter the IMS data channel
Emerging from the multiparty multimedia session control (MMUSIC) working group, early 2012 saw the introduction of an IETF draft outlining the definition and application of new WebRTC (Real-Time Communication) datagram connections. In this document, a connection was defined as secure and authenticated unreliable or reliable peer to peer relationship between two client endpoints that can be prioritized according to application. This is accomplished by employing the stream control transport protocol (SCTP) - per RFC 4960 - over datagram transport layer security encapsulation of SCTP packets (DTLS), as defined in RFC 8261.
These links can be instantiated with or without other concurrent media connections. While the last revision (v13) dropped in January 2015, it would be six years (January 2021) before the standard was ratified as RFC 8831 “WebRTC Data Channels.” Kicking off a year later, the in-band mechanism for establishing these data channels followed a similar trajectory, falling into an apparent void before reaching RFC status (RFC 8832) as the “WebRTC Data Channel Establishment Protocol.”
The reason for the 6-year IETF standardization sojourn revolved around the need to associate WebRTC data channels with actual applications. This required liaising with relevant GSMA working groups to ensure data channel support was included in the complete user equipment (UE) and core infrastructure specifications, such as 3GPP’s TS 26.114 (IMS; Multimedia Telephony; Media handling and interaction) and in reference documents like IR.92 (IMS Profile for Voice and SMS). Critically, RFC 8831 was architected to include the ability to employ not only in-band signaling (per RFC 8832) but also out-of-band (user and control plane separation) mechanisms favored in large communications networks. Consequently, the IETF commenced work on standardization of session description protocol (SDP)-based (SCTP over DTLS) data channel negotiation at around the same time - October 2013. (3)
It is the session description protocol that is transported within session initiation protocol (SIP) messages to negotiate and establish media connections for voice and video sessions. Consequently, the IETF working group created a new media-level attribute, "a=dcmap:" that defines the parameters for each data channel to be negotiated. As this work was directly related to the GSMA’s integration of WebRTC data channels onto their release 16 standardization work (circa 2020), revisions to that IETF draft continued through November 2019, before being frozen to changes. Coinciding with 3GPP release 17, RFC 8864 “Negotiation Data Channels Using the Session Description Protocol (SDP)” was ratified in January 2021, together with the other related standards (8831 and 8832).
3GPP technical specifications, such as TS 26.114, now put the data channel capability side by side with classic media connections, highlighting its increasingly important role within a multimedia telephony service for IMS (MTSI). Clients supporting data channel are referred to as (not surprisingly) DCMTSI’s. While the data channels operate independently from a call set-up and transport perspective, they allow for real-time interaction in parallel with the conversational media.
User and control plane protocol stack for a basic DCMTSI client
Identifying IMS data channel applications
It is Ericsson who should be credited with first embracing potential applications of an IMS data channel. In 2019, they partnered with British Telecom to demonstrate a mobile healthcare solution that paired video calling with haptics technology, adding the ability for a doctor to steer a paramedics hand during a sonogram procedure in a moving ambulance. (4) In the last 6 months, however, interest around possible applications of an IMS data channel has really accelerated.
On August 31st, 2021, a consortium of communications service providers and suppliers came together at the World 5G Conference to form the 5G VoNR+ (New Voice) working group. (5) This group operates under the auspices of the 5G Deterministic Network Industry Alliance (5GDNA), (6) itself, founded in only mid-2019. The 5GDNA was almost certainly formed as a response to supply chain disputes that continue to strain global standards initiatives, as evidenced by the almost exclusively Chinese membership roll. With the addition of Ericsson, though, much credit should be given to this community of interest for amplifying the IMS data channel opportunity. This started even before 2021, with a more limited collaboration that produced the first white paper on the topic of VoNR+ New Voice in December 2020. (7) ?
Liaising with the IETF, ETSI and the 3GPP, China Mobile and China Telecom have also initiated a new work item within study group 11 of the ITU. Building on 3GPP TS 26.114, IETF RFC 8831 and ITU-T Y.3104, Q.DC-SA “Signalling architecture of data channel enhanced IMS network” outlines the need for additional standard functional entities and reference interfaces it believes is required to support data channel enhanced IMS networks.
Early ITU Q.DC-SA reference model for a data channel enhanced IMS network. (8)
Seeing some of the new content coming out of this announcement made me reminisce about my early marketing achievements at Metaswitch. 10 years ago, we launched a mobile app called Thrutu with the promise of enhancing plain old circuit switched mobile voice calls. (9) Indeed, the screen overlays shown in business and consumer use case videos from Ericsson and ZTE (10) look almost identical, but advancements in handset compute capacity and network speeds now afford a far richer experience. This, together with the standardization of a peer-to-peer IMS data channel, affords the opportunity for these experiences to be native to the handset and ubiquitous across global service providers. This standardization work will eliminate the need for Thrutu-esq proprietary clients or custom centralized servers managing connections.
领英推荐
Real time video inferencing and live overlay IMS data channel use cases from Ericsson and ZTE (10)
As these videos demonstrate, IMS data channel proponents primarily envision business and consumer use cases combining real-time video inferencing on live chat sessions for augmented customer support. The extended list of possible scenarios, however, includes not only the type of healthcare solutions dreamed-up years earlier but also things like live AR/VR collaboration and control for remotely twinning service engineers with more skilled support professionals.
Reenergizing IMS and carrier calling services
While the lengthy nature of standardization work has likely served to downplay the significance of the IMS data channel, the formation of new (albeit heavily regionalized) industry working groups and the continued push to evolve global specifications is exciting. Certainly, since its inception in 1999, it’s hard to recall when multiple new IMS network functions and interfaces have been proposed, like this. And not since RCS has there been any standardization around enhanced calling services. Maybe I’ve jinxed it right there, but I believe that interest in VoNR+ will continue to grow, in the coming years, which will absolutely elevate the role of the IP multimedia subsystem in global operator networks. It could even mean a new-found respect for an infrastructure that, at best, has languished in obscurity or, at worst, been openly reviled. But whatever happens, IMS will always have a special place in my heart.
Disclaimer:
None of the ideas expressed in this blog post are shared, supported, or endorsed in any manner by my employer.?Or probably anyone else, for that matter.
Footnotes:
(1)???Meaning it is suitable for centralization within private datacenters or public cloud infrastructures because there is no need to handle data plane traffic and is far less sensitive to network and packet processing delays.
(3)???I should note that in the same timeframe (circa 2013) Rafael A. Gaviria of Verizon filed a patent for a WebRTC data channel facilitating IMS support of Rich Communications Services. This, however, simply defined a WebRTC-IMS gateway that extended RCS functionality to a browser interface.
(6)???5G确定性网络产业联盟 (5gdna.org)
(10)?5G interactive calling - YouTube and ZTE IMS data channel based interactive and immersive voice solution - YouTube
?
Sales Leader and Technologist in superposition
3 年Great article Simon... as usual!