]> InterDigital

Canada xavier.defoy@interdigital.com

United Kingdom renan.krishna@gmail.com

China Mobile

China tianjijiang2012@gmail.com

Transport MOQ This document specifies a mechanism for conveying media-frame metadata for low-latency, high-throughput traffic such as Extended Reality (XR). It enables the Media over QUIC (MoQ) protocol to carry frame-level information defined by 3GPP to support functions including energy efficiency and congestion management in wireless networks. Because MoQ traffic is end-to-end encrypted, MoQ relays are expected to extract the metadata needed to perform these functions.

Introduction Wireless networks can be a challenging environment for applications with high-throughput and low latency requirements, such as video conferencing and Extended Reality (XR, presented for example in ). Wireless networks implement techniques to improve network capacity and energy efficiency, as well as reduce the impact of packet losses on users' quality of experience (). An extension to the RTP protocol has been defined, which enables metadata associated with application data units to be identified at the ingress point of the wireless network (). To enable a similar operation with the MoQ protocol , this document describes how a MoQ relay can be used at the ingress point of the wireless network (). The rest of this document is structured as follows:

• describes XR metadata for MoQ.
• describes the behavior of the MoQ relay and of MOQ endpoints.
• describes IANA registrations.
• describes applicable security considerations.

Techniques used by Wireless Networks for XR Traffic Handling The network can handle groups of packets based on how critical they are to the user's experience. Some groups of data packets hold a unit of information generated at the application level, which we will designate as an application data unit, and which can be for example a video frame, or video slice. Application data units are typically handled (e.g., decoded) together by the application. 3GPP defines the term PDU set to identify these groups of data packets , which can correspond to the data packets of an application layer data unit. The handling of application data units by the application can depend on other application data units (e.g., in the case of decoding dependency). The wireless network performs differentiated handling of groups of data packets. For example, it prioritizes some groups over others in case of congestion. In congestion situations, the network can also selectively drop data packets that depend on already lost data packets. Furthermore, the network can limit the amount of time that the radio needs to stay awake to transmit and receive data. To achieve this this, the scheduler can use information on the size and periodicity of traffic, as well as delay budget and maximum tolerable jitter specific to the application.

XR Metadata in Encrypted Media Flows To perform differentiated handling of groups of data packets, a User Plane Function (UPF) at the ingress point of a wireless network receives, along with a media object, Media Related Information (MRI) including:

• PDU Set Information,
• End of Data Burst Indication,
• Expedited Transfer Indication,
• Data Burst Size,
• Time to Next Burst.

The UPF processes the MRI and provides it to the access node, which uses it to perform differentiated handling. The MRI encoding is described in section 22.2 of .

Identifying XR Metadata in MOQ flows For XR media traffic transported over the MOQ protocol, the UPF cannot access XR metadata unless it is exposed to the UPF in some fashion. This document describes how the UPF can act as, or communicate with, a MoQ relay to obtain XR metadata associated with media data. To enable this behavior, it is also necessary for the media sender to identify application data units that correspond to different desired traffic handling (e.g., different layers within a media frame), and provide associated metadata. describes a UPF with MoQ relay functionality, identifying XR metadata and transmitting it to an access nodes. For privacy and security, it is desirable that the MoQ relay, which can be operated by a network or service operator, does not have access to media data. For interoperability, it is also desirable for these mechanisms to not be codec specific.

XR Traffic Handling by Access Networks using a MoQ relay.

Terms and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Notational Conventions This document uses the conventions detailed in (, Section 1.3) when describing the binary encoding. See , section 1.3 for a non normative summary of the syntax.

XR MRI in MOQ Transport In MOQ Transport (MOQT), XR metadata is transmitted in object headers, using the extension header mechanism described in . This document describes a MOQT header extension in the MOQT protocol, corresponding to XR metadata identified in Release 19 of 3GPP.

Signalling of XR MRI Support This document registers with IANA a new MOQT Extension Header named XR_MRI_SUPPORT, which can optionally be exchanged by endpoints to indicate their support for specific types and versions of XR media related information.

XR_MRI_SUPPORT Header Extension

The MRI descriptor field is an integer formed by the concatenation of the MRI version field (in the most signicant bits) and MRI bitmask field of the Media Related Information data structure defined in section 22.2 of . An endpoint can include an XR_MRI_SUPPORT extension header in CLIENT_SETUP or SERVER_SETUP, to indicate that it supports processing, within objects it receives, the XR_MRI extension corresponding to the included MRI descriptor, i.e., same version and bitmask. An endpoint can include more than one XR_MRI_SUPPORT extension header, e.g., to indicate support for more than one version. The XR_MRI_SUPPORT extension header is advisory in nature. Alternatively, the endpoints may determine whether to communicate XR MRI, and which version, based on an out-of-band agreement.

Signalling of XR MRI in MOQT Objects This document registers with IANA a new MOQT Extension Header named XR_MRI, which is used to transmit MRI. When sending MOQ objects, an endpoint can include the XR_MRI header extension. When receiving MOQ objects, an endpoint can process or ignore the XR_MRI header extension.

XR_MRI Header Extension

The MRI field holds the media related information data structure defined in section 22.2 of . The MRI field is byte-aligned.

Endpoint Behavior for Communicating XR Metadata

Endpoint Behavior A MOQT endpoint may send one or more XR_MRI_SUPPORT header extension to indicate it can process certain versions of the MRI data in a XR_MRI header extension. A MOQT endpoint can send objects including an XR_MRI header extension. A MOQT endpoint can parse an XR_MRI header extension to obtain the MRI data associated with the object.

MoQ relay Behavior The extension header defined in this document can be added, removed and/or cached, but should not be modified by a MoQ relay.

IANA considerations This document registers an odd-numbered MOQT header extension, named XR media related information (XR_MRI) extension. This document registers an even-numbered MOQT header extension, named XR media related information support (XR_MRI_SUPPORT) extension.

Security Considerations To enable support for low-latency XR, the application exposes metadata to a MoQ relay under the control of a network or service operator. End-to-end encrypted media is not exposed to the MoQ relay, so this is not seen as a high-risk exposure.

Acknowledgments Thanks to Srinivas Gudumasu, who was a contributor to the first revision of this draft. Thanks to Jaya Rao, Ghyslain Pelletier, John Kaippallimalil, Sri Gundavelli, Hang Shi, Mike Starsinic and Hyunsik Yang for discussions and comments about this draft.

References Normative References Cisco Google Google Meta This document defines the core behavior for Media over QUIC Transport (MOQT), a media transport protocol designed to operate over QUIC and WebTransport, which have similar functionality. MOQT allows a producer of media to publish data and have it consumed via subscription by a multiplicity of endpoints. It supports intermediate content distribution networks and is designed for high scale and low latency distribution. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document explores the issues involved in the use of edge computing resources to operationalize a media use case that involves an Extended Reality (XR) application. In particular, this document discusses an XR application that can run on devices having different form factors (such as different physical sizes and shapes) and needs edge computing resources to mitigate the effect of problems such as the need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. This document also discusses the expected behavior of XR applications, which can be used to manage traffic, and the service requirements for XR applications to be able to run on the network. Network operators who are interested in providing edge computing resources to operationalize the requirements of such applications are the intended audience for this document. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. 3GPP 3GPP 3GPP

MRI Data Structure (informative) As a convenience to the reader, this section represents the version 1 of the Media Related Information data structure defined in section 22.2 of . It is based on the version 19.4.0 of . This appendix is informative and may be deleted from this draft prior to publication.

Media Related Information from 29.561 clause 22.2

Field Descriptions:

• Version (3 bits): Bits representing MRI version 1 (value is 0).
• Bitmask (13 bits): Bits representing the presence of optional fields, including PDU Set marking, PDU Set Size, Number of PDUs in the PDU Set, Burst Size, Time To Next Burst, Expedited Transfer Indication, and an extension bit.
• E (End PDU of the PDU Set) (1 bit): if PDU Set marking is included, this bit is encoded as End PDU of the PDU Set (E) field of the PDU Set marking.
• R (Reserved) (2 bits): if PDU Set marking is included, these bits are encoded as Reserved (R) field of the PDU Set marking.
• D (End of Data Burst) (1 bit): if PDU Set marking is included, this bit is encoded as End of Data Burst (D) field of the PDU Set marking.
• PSI (PDU Set Importance) (4 bits): if PDU Set marking is included, this bit is encoded as PDU Set Importance (PSI) field of the PDU Set marking.
• PSSN (PDU Set Sequence Number) (10 bits): if PDU Set marking is included, these bits are encoded as with PDU Set Sequence Number (PSSN) field of the PDU Set marking.
• PSN (PDU Sequence Number within the PDU Set) (6 bits): if PDU Set marking is included, these bits are encoded as PDU Sequence Number within the PDU Set (PSN) field of the PDU Set marking.
• PSSize (PDU Set Size) (24 bits): if PDU Set marking is included, these bits are encoded as PDU Set Size (PSSize) field of the PDU Set marking.
• NPDS (Number of PDUs in the PDU Set) (16 bits): if PDU Set marking is included, these bits are encoded as Number of PDUs in the PDU Set (NPDS) field of the PDU Set marking.
• BSize (Burst Size) (24 bits): if Burst Size is included, these bits are encoded as Burst Size (BSize) field of the Dynamically Changing Traffic Characteristics marking.
• TTNB (Time To Next Burst) (24 bits): if Time To Next Burst is included, these bits are encoded as Time To Next Burst (TTNB) field of the Dynamically Changing Traffic Characteristics marking.
• I (Expedited Transfer Indication) (1 bit): if Expedited Transfer Indication is included, this bit corresponds to Expedited Transfer Indication (I) field.
• Padding: zero-padding bits for byte-alignment.