XR Delivery in 5G SystemTS 26.928

General Delivery Categories

The following delivery categories for XR experiences are defined:

1. Download: An XR experience is downloaded and consumed offline without requiring a connection. All media and experience related traffic is downlink.
2. (Passive) Streaming: The experience is consumed in real-time from a network server. The user does not interact with the XR experience, or if interacting with the XR experience, the interaction is not triggering any uplink traffic. All media related traffic is downlink.
3. Interactive (Streaming): The experience is consumed in real-time from a network server. The user (or the device automatically) interacts with the XR experience and the interaction changes the delivered content. The traffic is predominantly downlink, but certain traffic is uplink, e.g. XR Viewer Pose information. Different flavours of interaction exist, for example viewport adaptation, gaming events, etc. Interaction delay requirements may be different, ranging from immersive latency requirements to more static selection interactions.
4. Conversational: The experience is generated, shared and consumed in real-time from two or more participants with conversational latency requirements.
5. Split Compute/Rendering: Network functions run an XR engine to support processing and pre-rendering of immersive scenes and the delivery is split into more than one connection, e.g. Split rendering, Edge Computing, etc. The latency and interaction requirements again depend on the use case and the architecture implementation.

5G System and Radio Functionalities for XR

The integration of XR applications within the 5G System is approached following the model of 5G Media Streaming as defined in 3GPP TS 26.501. Assume a 5G-XR Application Provider being an XR Application provider that makes use of 5G System functionalities for its services. For this purpose, it provides a 5G-XR Aware Application on the UE to make use of a 5G-XR client and network functions using network interfaces and APIs, potentially defined in 5G-XR related specifications.

The architecture in Figure 4.3.2-1 represents potential 5G-XR functions within the 5G System (5GS) as defined in 3GPP TS 23.501. Three main functions are defined:

1. 5G-XR AF: An Application Function similar as defined in 3GPP TS 23.501, clause 6.2.10, dedicated to 5G-XR Services.
2. 5G-XR AS: An Application Server dedicated to 5G-XR Services.
3. 5G-XR Client: A UE internal function dedicated to 5G-XR Services.

In the context of this Technical Report, 5G-XR AF and 5G-XR AS are initially considered Data Network (DN) functions and communicate with the UE via N6, N3 and Uu as defined in 3GPP TS 23.501. Communication through sidelink PC5 may be an alternative to Uu based communication. Functions in trusted DNs are trusted by the operator’s network as illustrated. Therefore, AFs in trusted DNs may directly communicate with all 5G Core functions. Functions in external DNs may only communicate with 5G Core functions via the NEF using N33.

Note: The functions indicated by the yellow filled boxes are in potential scope of stage 3 specifications for 5GXR. The functions indicated by the grey boxes are defined in 5G System specifications. The functions indicated by the blue boxes are assigned to the applications.

The above architecture is used as a starting point. With XR related functions exclusively assigned to either DN or UE. However, architectural extensions may be identified for the 3GPP system that may benefit from XR applications. Examples include the use of network slicing, edge computing or usage of 5G quality of service.

A basic XR architecture integrated in 5G is shown in Figure 4.3.2-2. The following functions may be considered to be defined:

• 5G-XR Client on UE: Receiver of 5G-XR session data that may be accessed through well-defined interfaces/APIs by the 5G-XR Aware Application. The 5G-XR contains two sub-functions:
  1. XR Session Handler: A function of the UE that communicates with the 5G-XR AF in order to establish, control and support the delivery of an XR session. The XR Session Handler exposes APIs that can be used by the 5G-XR Aware Application.
  2. XR Engine: A function of the UE that communicates with the 5G-XR Application Server in order to get access to XR related data, includes XR relevant functionalities such as sensors and tracking, processes this data and communicates with the XR Session Handler for XR session control.
• 5G-XR Aware Application: The 5G-XR Client is typically controlled by an external XR aware application, e.g. an App, which implements the external application service provider specific logic and enables establishing an XR session. The 5G-XR Aware Application makes use of 5G-XR Client and network functions using interfaces and APIs.
• 5G-XR AS: An Application Server which hosts 5G-XR media and media functions.
• 5G-XR Application Provider: External XR application provider that makes use of 5G-XR client and network functionalities to provide an XR experience to the 5G-XR Aware applications.
• 5G-XR AF: provides various control functions to the XR Session Handler on the UE and/or to the 5G-XR Application Provider. It may relay or initiate a request for different Policy or Charging Function (PCF) treatment or interact with other network functions.

In the context of the above, 5G radio may also be differentiated between 5G Uu and 5G Sidelink/PC5. Uu is the interface between User Equipement (UE) and Radio Access Network (RAN) as defined in 3GPP TS 38.300. Sidelink is a mode of communication whereby UEs can communicate with each other directly as defined in 3GPP TS 38.300.

Quality-of-Service in 5G

The 5G QoS model is based on QoS Flows. The 5G QoS model supports both:

• QoS Flows that require guaranteed flow bit rate (GBR QoS Flows), and
• QoS Flows that do not require guaranteed flow bit rate (Non-GBR QoS Flows).

The 5G QoS model also supports Reflective QoS (see clause 5.7.5 of 3GPP TS 23.501).

A QoS Flow ID (QFI) is used to identify a QoS Flow in the 5G System. User Plane traffic assigned to the same QoS Flow within a Protocol Data Unit (PDU) Session receives the same traffic forwarding treatment (e.g. scheduling, admission threshold).

The QFI may be dynamically assigned or may be equal to the 5G QoS Identifier (5QI). A QoS Flow may either be 'GBR', 'Non-GBR' or “Delay Tolerant GBR” depending on its QoS profile and it contains QoS parameters as follows:

• For each QoS Flow, the QoS profile includes the QoS parameters:
  • 5G QoS Identifier (5QI); and
  • Allocation and Retention Priority (ARP).
• For each Non-GBR QoS Flow only, the QoS profile can also include the QoS parameter:
  • Reflective QoS Attribute (RQA).
• For each GBR QoS Flow only, the QoS profile also include the QoS parameters:
  • Guaranteed Flow Bit Rate (GFBR) - uplink (UL) and downlink (DL); and
  • Maximum Flow Bit Rate (MFBR) - UL and DL
• In the case of a GBR QoS Flow only, the QoS profile can also include one or more of the QoS parameters:
  • Notification control;
  • Maximum Packet Loss Rate - UL and DL

The one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in table 5.7.4-1 of 3GPP TS 23.501.

5G Media Delivery

Download, passive streaming and interactive streaming are most suitably mapped to 5G Media Streaming as defined in 3GPP TS 26.501.

Conversational services are most suitably mapped to the Multimedia Telephony Service for IMS (MTSI) as defined in 3GPP TS 22.173 with focus on XR media handling (e.g. signalling, transport, codecs, formates) when using 3GPP access, in particular 5G radio technologies. It is expected that the media handling of MTSI clients as defined in 3GPP TS 26.114 may be suitably extended in order to support XR applications and services.

Edge Computing

Beyond the use of Application Servers as defined in 5G Media Streaming today, the 5G-XR application may benefit from additional processing in the edge. In an example, as shown in Figure 4.3.5-1, an edge platform may be offered by the 5G network operator to support XR services served from the content provider or from the cloud.