Content for  TR 26.928  Word version:  18.0.0

For the purpose of classifying use cases, this clause defines delivery categories for XR experiences. The following categories are defined:

• Download: An XR experience is downloaded and consumed offline without requiring a connection. All media and experience related traffic is downlink.
• (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.
• 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.
• Conversational: The experience is generated, shared and consumed in real-time from two or more participants with conversational latency requirements.
• 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.

A more detailed analysis of architectures in the context of 5G is provided in clause 6.

The integration of XR applications within the 5G System is approached following the model of 5G Media Streaming as defined in 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 TS 23.501. Three main functions are defined:

• 5G-XR AF: An Application Function similar as defined in clause 6.2.10 of TS 23.501,, dedicated to 5G-XR Services.
• 5G-XR AS: An Application Server dedicated to 5G-XR Services.
• 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 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.

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 Client contains two sub-functions
  • 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.
  • 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 TS 38.300. Sidelink is a mode of communication whereby UEs can communicate with each other directly as defined in TS 38.300.

Clause 5.7 of TS 23.501 explains the QoS model for 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 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; and
• 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 TS 23.501 and shown below in Table 4.3.3-1. 5QI values potentially relevant for XR applications in the context of this Technical Report are highlighted in italics.

The applicability of 5QI and potential gaps for XR Services over 5G are analysed further in this Technical Report.

In the context of this Technical Report and the delivery options identified in clause 4.3.3, the first three basic delivery types - download, passive streaming and interactive streaming - are most suitably mapped to 5G Media Streaming as defined in TS 26.501 and associated stage 3 specifications. The applicability of 5G Media Streaming for XR applications and potential necessary extensions are identified in clause 5, clause 6 and clause 7 of this Technical Report. Conversational services are most suitably mapped to the Multimedia Telephony Service for IMS (MTSI) as defined in 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 TS 26.114 may be suitably extended in order to support XR applications and services.

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.

In the context of Release-17, 3GPP work is ongoing in order to identify the integration of edge processing in 5G systems. TR 23.748 defines the necessary modifications to 5G system architecture to enhance Edge Computing. This work is currently in study phase, defining key issues and scope for Release-17. Specifically, this study is investigating mechanisms to discover connectivity to available Edge Computing resources (e.g. using DNS), mobility improvements for both UE consuming Edge Computing services and for Edge Application Servers, and for network capability exposure towards the Edge Application Server. In addition, in TR 23.758 and TS 23.558 a new set of application layer interfaces for Edge Computing are identified that may potentially be useful for integration of Edge Computing. Specifically, the interfaces will enable application-layer discovery of Edge Application Servers, capability exposure towards the Edge Application Server, and procedures for onboarding, registration, and lifecycle management of Edge Applications. The activities detailed in the present clause are intended to be application-neutral (i.e. to provide generic solutions for any use of Edge Computing platforms). The media aspects for using Edge Computing are not identified in these studies and information in the present Technical Report may be beneficial to contribute to Edge Computing for media processing. In particular, split Compute/Rendering architectures are not yet specified in the 5G System architecture beyond those being part of a 5G-XR aware application. Integration of computational resources into the 5G System as part of Edge Computing functionalities are currently under study in 3GPP. The present Technical Report serves to identify potentially relevant functions for XR applications when using Edge Computing and rendering.