4 Real-time Media Communication Architecture

26.5063GPP5G Real-time Media Communication Architecture (Stage 2)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Overall architecture for Real-Time Media Communication (RTC)

Real-Time media Communication over 5G system (5G-RTC) in the context of this specification is defined as the delivery of delay-sensitive media from one peer to another with support of 5G network. AR conversational service described in TR 26.998 is a typical use cases for 5G-RTC, which enables end-users to directly communicate real-time media including AR/MR media contents as specified in TS 26.119 [x].As identified in clause 8.4 of TR 26.998, there may be different options to enable such AR conversational service, for example re-use of parts of MTSI such as the IMS data channel or 5G Media Streaming for managed services. In this specification, 5G-RTC architecture provides the core functions and entities to support WebRTC framework over 5G system. The WebRTC framework is a subset of WebRTC and is limited to a protocol stack and its implementation, excluding media codecs and other media processing functions defined in W3C and IETF.

Editor’s NOTE: Text above may need to be further elaborated.

The overall 5G-RTC architecture is shown in Figure 4.1-1 as below.

Figure 4.1-1: 5G-RTC General Architecture

Editor’s NOTE: Client architecture as well as the associated text in clause 4.2 should be updated based on the discussion during SA4#121

4.2 Functions and entities

4.2.1 General

This clause defines minimal and essential functions and extra functions and entities may appear in some cases. The definitions of extra functions and entities are specified in TS 26.113 [y] and TR 26.930 [z].

4.2.2 Provisioning function

The provisioning function may enable an application provider to perform provisioning of the following functionalities:

– QoS support provisioning for WebRTC sessions

– Charging provisioning for WebRTC sessions

– Collection of consumption and QoE metrics data provisioning related to WebRTC sessions

– Offering ICE functionality provisioning such as STUN and TURN servers

– Offering WebRTC signalling servers provisioning, potentially with interoperability to other signalling servers.

The provisioning function may not be relevant to all collaboration scenarios and some of the 5G support functionality may be offered without application provider provisioning.

NOTE: The integration/collocation of this 5G-RTC AF and WebRTC signalling server is possible. Co-located WebRTC signalling server is able to act as a 5G-RTC AF which is accessible to 5GC, and replace some of this 5G-RTC AF’s interfaces and APIs with WebRTC signalling. For example, interfaces and APIs between this 5G-RTC AF and UE will be replaced to avoid concurrent/redundant requests from UE.

4.2.3 Configuration function

The configuration function stores WebRTC-related configuration information and makes them accessible to the UE. It stores information and recommendations to operate network-assisted WebRTC sessions over 5G system.

The configuration information may consist of static information such as the following:

– Recommendations for media configurations

– Configurations of STUN and TURN server locations

– Configuration about consumption and QoE reporting

– Discovery information for WebRTC signalling and data channel servers and their capabilities in static and/or dynamic way.

4.2.4 Media Session Handler (MSH)

The MSH is an entity running on the UE, which assists with the 5G integration of the WebRTC application. It exchanges, on behalf of the application, information about the WebRTC sessions with the network.

The MSH receives information about a new WebRTC session from the application. It relays the information to the Network Support Function. It also receives events and other network information about the WebRTC session from the Network Support Function, which it may relay to the application.

In addition, one of subfunction in MSH is the metric collection and reporting. It executes the collection of QoS and QoE metrics measurements from the WebRTC Framework and the WebRTC application and sends metrics reports to the 5G-RTC AF for the purpose of metrics analysis or to enable potential transport optimizations by the network.

4.2.5 Network support function

The support functionality includes the following:

– Network Support Function receives information from the UE and/or other ASs about a WebRTC session and its state

– Network Support Function requests the network that QoS should be allocated (or satisfied) for a starting or modified session

– Network Support Function receives notification from the network about changes to the QoS allocation for the ongoing WebRTC session

– Network Support Function exchanges information about the WebRTC session with the trusted STUN/TURN/Signalling Server, e.g. to identify a WebRTC session and associate it with a QoS template.

4.2.6 Trusted ICE functions

The MNO may offer trusted ICE functions to the WebRTC application to be used during the WebRTC ICE gathering phase. These functions may be STUN and TURN servers that facilitate NAT and firewall traversal.

The MNO-operated trusted ICE functions may assist with the 5G integration of the WebRTC application. This could be done by triggering network assistance to starting or ongoing WebRTC sessions.

4.2.7 Trusted WebRTC signalling function

The trusted WebRTC signalling function is used to setup and manage MNO-operated WebRTC applications. They offer a standardized signalling protocol for the session setup to both parties of the WebRTC session. The WebRTC signalling function will handle the offer/answer exchange and will have access to the SDP in both directions.

The WebRTC signalling function may use that knowledge to offer network assistance and other 5G features to the endpoints of the WebRTC session.

The WebRTC signalling function manages media flow sessions in both uplink and downlink directions.

4.2.8 Trusted inter-working function

This function provides inter-working functionality to enable MNO-facilitated WebRTC sessions that involve endpoints across different MNOs. They may for example provide cross-network signalling functionality to allow WebRTC signalling server that are hosted in different networks to communicate, in order to establish and manage the WebRTC sessions.

4.2.9 Trusted transport gateway function

A transport gateway function may be offered by the MNO to support cross-operator WebRTC sessions. It may offer the border control function for user plane (e.g., topology hiding, IPv4-IPv6 translation) as a gateway, which is located at the network boundary where different operators or third-party network connects. It works under the control of the trusted inter-working function.

Note: Detailed functionality is specified in TR 26.930 [z].

4.2.10 Trusted media function

A media server may be offered by the MNO to support WebRTC sessions. It may offer a wide range of functionality such as:

– a content server that serves content to the WebRTC application, e.g. through a data channel

– media processing functionality: may be used by the WebRTC application as a relay that performs some media processing function such as transcoding, recording, 3D reconstruction, etc.

– scene composition functionality: the server may compose a 3D scene and distribute it to several point-to-point WebRTC sessions

– Multi-point Control Unit (MCU) functionality: the server may offer multi-party conferencing functionality to merge a number of point-to-point WebRTC sessions

– Selective Forwarding Unit (SFU) functionality: the server may offer the selection, copy, and forwarding functionality of IP steams produced by multiple WebRTC endpoints (i.e., participants).

– Maintain uplink and downlink flow context (QoS, remote control and etc.) by interacting with the WebRTC signalling function.

4.2.11 Trusted application supporting web function

A web server may be offered by the MNO to support applications by providing web service entry point, authorization/authentication, sharing files, or scheduling conferencing sessions.

4.3 Interfaces

Editor’s NOTE: All context here needs to be updated based on the future inputs/discussions

4.3.1 RTC-1: Provisioning interface

The RTC-1 interface allows the Application Provider to provision support for RTC sessions that are offered by it. The provisioning may cover the following aspects:

– QoS support for WebRTC sessions

– Charging provisioning for WebRTC sessions

– Collection of consumption and QoE metrics data related to WebRTC sessions

– Offering ICE functionality such as STUN and TURN servers

– Offering WebRTC signalling servers, potentially with interoperability to other signalling servers

The provisioning interface is not relevant to all collaboration scenarios and some of the 5G support functionality may be offered without application provider provisioning.

4.3.2 RTC-3: AS to AF interface

The 5G-RTC AS may exchange information regarding the RTC session with the 5G-RTC AF. This information may cover QoS flow information and QoS allocation as well as QoE and consumption reports. The 5G-RTC AF may subscribe to information about the status of the QoS flow, which it may share with the 5G-RTC AS, e.g. in form of bitrate recommendations.

4.3.3 RTC-4: Media-centric transport interface

This interface is used to exchange the WebRTC traffic with the other endpoint as well as to exchange signaling information related to the WebRTC session with the trusted application servers.

The traffic includes:

– Media streams sent over RTP

– Application data sent over data channel

– WebRTC Signaling data along with STUN and TURN servers

– Other application data

RTC-4 may further be grouped into two sub-interfaces as follows.

RTC-4s:

The RTC-4s interface is an interface between the WebRTC framework and the 5G-RTC AS such as WebRTC Signaling server. This interface is used for the exchange of signaling information related to the WebRTC session between two or more WebRTC endpoints using trusted application servers. In some cases where the signaling is not handled by WebRTC framework, the RTC-4s interface is an interface between the native WebRTC applications and the WebRTC Signaling server.

RTC-4m:

This interface is used for transmission of media and other related data between two or more WebRTC endpoints.

The traffic includes

Media data transmitted over RTP
Application data transmitted using Data channel
Media related meta-data transmitted using Data channel

NOTE 1: The Media Server should maintain the status for both uplink and downlink traffic and a separate interface for supporting downlink and uplink is expected to be defined in this specification.

NOTE 2: WebRTC-enabled UE should support streaming functions for uplink and downlink traffic. Therefore a new entity in UE may be defined.

4.3.4 RTC-5: Control transport interface

The RTC-5 interface is an interface between the Media Session Handler and the 5G-RTC AF. It is used to convey configuration information from the 5G-RTC AF to the MSH and to request support for a starting/ongoing WebRTC session. The configuration information may consist of static information such as the following:

– Recommendations for media configurations

– Configurations of STUN and TURN server locations

– Configuration about consumption and QoE reporting

– Discovery information for WebRTC signaling and data channel servers and their capabilities

The support functionality includes the following:

– MSH receives the configuration information

– MSH informs the 5G-RTC AF about a WebRTC session and its state

– MSH requests QoS allocation for a starting or modified session

– MSH receives notification about changes to the QoS allocation for the ongoing WebRTC session

– MSH receives the updated information about the WebRTC session with the 5G-RTC STUN/TURN/Signaling Server, e.g. to identify a WebRTC session and associate it with a QoS template

The 5G-RTC functionality that offer application functions to the WebRTC application may equally be provided by Application Servers (5G-RTC AS) instead of 5G-RTC AFs. These then use a dedicated interface RTC-3 to request configurations and network support for the ongoing WebRTC sessions from the 5G-RTC AF.

4.3.5 RTC-6: Client API

The MSH is a function in the UE that provides access to 5G-RTC support functions to the native WebRTC applications. These functions may be offered on request, i.e., through the RTC-6 interface, or transparently without direct involvement of the application. The MSH may assist indirectly in the ICE negotiation by providing a list of STUN and TURN server candidates that offer 5G-RTC functionality. The MSH also collects QoE metric reports and submits consumption reports. It may also offer media configuration recommendations to the application through RTC-6.

4.3.6 RTC-7: Client interface

This interface is similar in functionality to RTC-6. The difference lies in the face that this interface may not be exposed as an API to application developers but may be in form of a direct communication between the MSH and the WebRTC framework. The WebRTC framework hides away all details of the QoS allocation and network support from the application. It autonomously and transparently invokes the functions offered by the MSH to provide support for the RTC session.

4.3.7 RTC-8: Application interface

This is a proprietary interface between the application and the application provider, which may be used to exchange configuration information related to the RTC session or the application.

4.4 5G-RTC Architecture extension

4.4.1 Introduction

This clause defines an architecture that enables a 5G-RTC Application Provider to provision resources in the Edge Data Network (EDN) for an application through the M1 interface.

Media processing in the edge may be achieved in one of two different ways at the application layer:

1. Client-driven management. 5G-RTC Applications that are aware of the edge processing can directly request an edge resource and discover the Edge Application Server (EAS) that is best suited to serve the application.

2. Application Provider-driven management. The 5G-RTC AF automatically allocates edge resources for new streaming sessions on behalf of the application using information in the 5G-RTC provisioning session.

-An Edge-enabled 5G=RTC Client leverages the Edge Computing capabilities as defined in TS 23.558.

4.4.2 Extended 5G-RTC architecture for Edge Computing

The 5G-RTC architecture can be extended to add support for media processing in the edge. The extended architecture is an integration of the 5G-RTC architecture defined in TS 26.506 with the architecture for enabling Edge Applications defined in TS 23.558. The extended architecture is as shown in Figure 4.4.2-1.

Figure 4.4.2-1: Edge-enabled 5G-RTC architecture

4.4.2.1 Edge Application Server (EAS)

EAS is the application server resident in the EDN, performing edge-based processing for AR functionalities such as split rendering and spatial computing. The Application Client (AC) connects to the EAS in order to avail the services of the application with the benefits of Edge Computing.

It is possible that the server functions of an application are available only as an EAS.

However, it is also possible that certain server functions are available both at the edge and in the cloud as an EAS and an Application Server resident in the cloud.

The EAS can use the 3GPP Core Network capabilities in the following ways, all of which are optional to support:

a) invoking 3GPP Core Network capabilities via the edge enabler layer through the Edge Enabler Server (EES)

b) invoking 3GPP Core Network function (e.g., PCF) APIs directly, if it is an entity trusted by the 3GPP Core Network; and

c) invoking the 3GPP Core Network capabilities through the capability exposure functions, i.e., SCEF/NEF/SCEF+NEF.

The functions of Edge enabler Client (EEC), Edge Enabler Server (EES), Edge Configuration Server (ECS) are as defined in TS 23.558.

4.4.2.2 Edge Interfaces

Based on the extended architecture, the following interfaces are defined for performing edge-based processing for AR functionalities such as split rendering and spatial computing:

1. A 5G-RTC AF that is edge-enabled shall support EES functionality including:

– EDGE-1 API for supporting registration and provisioning of EEC functions, and discovery by them of EAS instances.

– EDGE-3 API towards the EAS function of 5G-RTC AS instances.

– EDGE-6 API for registering with an ECS function.

– EDGE-9 API for media session relocation.

2. A 5G-RTC AS that is edge-enabled shall support EAS functionality including the EDGE-3 API for registration with the EES.

3. A Media Session Handler that is edge-enabled should support EEC functionality including:

– Invoking the EES function using the EDGE‑1 API.

– Invoking the ECS function using the EDGE‑4 API.

– EDGE-5 API exposed to the Application Client.

4. A WebRTC Application that is edge-enabled shall support Application Client functionality and should invoke the ECS function using the EDGE‑5 API.