- What it is: an architecture for real-time media communication integrated into the 5G System, with its procedures, APIs and protocols.
- Based on 5GMS and on WebRTC: the control plane follows 5G Media Streaming; media is carried with a subset of the WebRTC protocol stack.
- Releases: created in Release 18; Release 19 adds PDU handling and marking enhancements, media capabilities and metadata.
Why it exists
For the moment the RTC work is focused on 5G-RTC, the architecture of TS 26.506 and the protocols of TS 26.113 (which share the provisioning and media session handling APIs of TS 26.510 with 5G Media Streaming), and, in parallel, on SWAP, the signalling protocol of TS 26.113 clause 13.2.4. There is no dedicated RTC Reference Tool yet.
In 5G Media Streaming, the separation of the data plane and the control plane, and the access it gives third-party services to 5G System functionality, was seen as a major benefit. 3GPP set out to extend these 5GMS principles to any type of service, including real-time communication and split rendering. The basic control plane is similar to 5GMS, while the media plane is generic, so that different operator and third-party services can be supported by the 5G System.
Beyond traditional 3GPP MTSI services, real-time transport of media over 5G systems is needed in new areas (WID SP-230977, clause 3). TS 26.506 defines Real-Time media Communication (RTC) over the 5G system as the delivery of delay-sensitive media from one peer to another with support of 5G network; an RTC endpoint incorporates an instance of the WebRTC Framework (TS 26.506 V20.0.0 clause 4.1.1).
The main functions
Click a figure to enlarge it. The RTC functions are shown in light blue.
- RTC AF: an Application Function, as defined in TS 26.501, dedicated to real-time media communication. Its Provisioning Function lets an RTC Application Provider provision QoS, charging, consumption and QoE reporting, ICE and the WebRTC Signalling Function. Its Configuration Function makes WebRTC-related configuration accessible to the UE. Its Network Support Function requests QoS from the network for a starting or modified session.
- RTC AS: an Application Server dedicated to real-time media communication. It may hold an ICE Function (STUN and TURN services for NAT and firewall traversal), a WebRTC Signalling Function that handles the offer/answer exchange, a Media Function that is itself an RTC endpoint, and functions for web support, cross-operator transport and interworking (TS 26.506 V20.0.0 clauses 4.1.1, 4.2.6 to 4.2.11).
- RTC Client: a UE function comprising an RTC Access Function, which sends and receives media and offers client APIs, and an RTC Media Session Handler, which assists with the integration of the RTC Application (TS 26.506 V20.0.0 clauses 3.1, 4.2.4, 4.2.12).
- RTC Application: a Native WebRTC App, which uses the RTC client APIs, or a Web App, which runs in a web browser and uses the W3C-defined WebRTC APIs (TS 26.506 V20.0.0 clause 4.1.1).
- RTC endpoint: an entity that participates in an RTC session by incorporating an instance of the WebRTC Framework, a defined subset of the WebRTC protocol stack. It is typically a UE, but an RTC AS may also play the role (TS 26.506 V20.0.0 clauses 3.1, 4.1.1).
Operator and third-party collaboration
TS 26.506 defines four collaboration scenarios, based on which functions are in the operator's trusted domain.
| Scenario | What the operator provides |
|---|---|
| 1. Over the top WebRTC | The session runs completely over the top. The operator may offer QoS allocation, bit rate recommendations and QoE report collection, on request by the UE (TS 26.506 V20.0.0 annex A.1). |
| 2. MNO-provided WebRTC functions | In addition, an ICE Function in the RTC AS (TS 26.506 V20.0.0 annex A.1). |
| 3. MNO-facilitated WebRTC services | The operator hosts and facilitates RTC sessions with a WebRTC Signalling Function, which may also offer 5G network assistance (TS 26.506 V20.0.0 annex A.1). |
| 4. Interoperable WebRTC services | Scenario 3 extended with functions for interoperability between operators. Some of its details are for future study (TS 26.506 V20.0.0 annex A.1 and its NOTE). |
Relation to 5G Media Streaming
TS 26.506 defines a generalised Media Delivery architecture, of which RTC is one possible realisation. The RTC AF is a realisation of the Media AF, the RTC AS of the Media AS, and the RTC Client is part of the Media Client. TS 26.501 defines the same generalised architecture for 5GMS, noting that the two may share many common functionalities for media session handling and media delivery. Full integration of 5GMS and RTC is not addressed.
The shared building blocks are specified once, in TS 26.510: provisioning sessions, certificates, edge resources, policy templates, dynamic policies, Network Assistance, QoE metrics reporting and consumption reporting. RTC adds its own provisioning of STUN, TURN and signalling services, delivered to the RTC Client in the service access information.
How it grew
- Release 18: the GA4RTAR work item creates the architecture (TS 26.506, approved June 2023). The iRTCW work item creates the procedures, APIs and protocols (TS 26.113, approved June 2024), with media session handling relying on the 5GMS_Pro_Ph2 work on TS 26.510. The 5G_RTP work item creates TS 26.522, the RTP header extensions and RTCP feedback that TS 26.113 uses for PDU Set marking in dynamic policies (TR 21.918 clauses 14.3 and 14.5). Later Release 18 changes add reference point RTC-11 in the UE, make RTC functions general Media Functions, and add PDU Set-based QoS handling.
- Release 19: 5G_RTP_Ph2 (TS 26.522, TS 26.510 and TS 26.113; TR 21.919 clause 11.7) adds PDU Set Importance for N6-unmarked PDUs, data burst size, time to next burst, expedited transfer and multiplexed media to dynamic policies. iRTCW adds media capability requirements for immersive real-time communication and timed metadata over the data channel. The generalised architecture gains reference point M13 (TS 26.113 V19.2.0 annex D (CR 0013 5G_RTP_Ph2; CR 0011 and 0012 iRTCW); TS 26.506 V20.0.0 annex C (CR 0009), clause 4.1.2.4).
Sources for this page
- Why it exists: WID SP-220672 (GA4RTAR), clause 3; WID SP-230977 (iRTCW), clause 3.
- The main functions: TS 26.506 V20.0.0, clauses 3.1, 4.1.1 and 4.2.2 to 4.2.12.
- Figures: redrawn from TS 26.506 V20.0.0, figures 4.1.1-1 and 4.1.1-2.
- Operator and third-party collaboration: TS 26.506 V20.0.0, annex A.1 and its NOTE.
- Relation to 5G Media Streaming: TS 26.506 V20.0.0, clause 4.1.2.1; TS 26.501 V20.0.0, clause 4.1.2.1 and NOTE; TS 26.510 V19.2.0, clause 5.1, table 5.1-1.
- How it grew: 3GPP work plan of 28 September 2026; WID SP-241961 (5G_RTP_Ph2), clause 4; TS 26.506 V20.0.0, annex C; TS 26.113 V19.2.0, annex D.