]> InterDigital

Canada xavier.defoy@interdigital.com

United Kingdom renan.krishna@gmail.com

China Mobile

China tianjijiang@chinamobile.com

Transport MOQ This document describes a mechanism to convey information about media frames. The information is used for specific handling in functions such as error recovery and congestion handling. These functions can be critical to improve energy efficiency and network capacity in some (especially wireless) networks. Due to end-to-end encryption, MoQ relays are expected to extract the metadata required by these functions. This document aims to enable a level of wireless network support for MoQ that is equivalent to what is possible for RTP.

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.

Identifying XR Metadata in RTP Media Flows To perform differentiated handling of PDU sets, a network node (i.e., a User Plane Function, UPF) at the ingress point of a wireless network identifies PDU set metadata from a downlink media flow. 3GPP has developed an RTP header extension for XR traffic for this purpose (see Appendix A for details). When receiving a downlink packet, the UPF reads the XR metadata fields from the RTP header extension and transmits them to the RAN node in the GTP header that encapsulates the packet. The RAN node uses the XR metadata information to implement the differentiated handling described in . 3GPP defines metadata used for XR traffic handling when using RTP:

• In the 3GPP release 18 (RTP header extension for PDU set marking, )
  • The PDU Set Importance (PSI, 4 bits) is the importance of this PDU Set compared to other PDU Sets within the same Multimedia Session.
  • The end PDU of PDU set (E, 1 bit) indicates the last PDU of the PDU set.
  • The end of data burst (D, 1 bit) indicates the last PDU of a data burst.
  • The PDU set sequence number (PSSN, 10 bits) identifies the PDU set. The PSSN is incremented monotonically by 1 for each subsequent PDU set.
  • The PDU Sequence Number within a PDU Set (PSN, 6 bits) identifies a PDU with the PDU set, starting from 0 and incremented monotonically for every PDU in the PDU set in the order of transmission from the sender.
  • The PDU set size (PSSize, 24 bits) is an optional field which indicates the total size, in bytes, of all PDUs of the PDU Set (including IP header and IP payload).
  • The number of PDUs in the PDU Set (NPDS, 16 bits) is an optional field which indicates the number of PDUs in the same PDU set.
• In the 3GPP release 19 (work in progress, documented in )
  • The Expedited Transfer Indication (ETI) indicates whether this PDU should be forwarded with an expedited QoS level.
  • The Burst Size (BSize) describes the size of a burst of traffic, which includes one or more PDU sets. [23.501] defines a data burst as a set of multiple PDUs generated and sent by the application in a short period of time.
  • The Time to Next Burst (TTNB) describes the time between the end of the present burst and the beginning of the next burst.

The optional header extension fields are included subjects to an SDP signaling offer/answer negotiation.

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 access nodes, for example, for a media stream sent by B towards A and C. 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 Metadata in MOQ Transport In MOQ Transport (MOQT), XR metadata is transmitted in object headers, using the extension header mechanism described in . This document describes additional metadata in the MOQT protocol, corresponding to XR metadata identified in Release 18 and 19 of 3GPP.

Signalling of XR Metadata Support This document registers with IANA two new integer MoQ Extension Header types named Release 18 XR Metadata Extension, and Release 19 XR Metadata Extension. These MoQ Extension Header types are used to transmit XR metadata in object headers. This document registers with IANA a new MOQT setup parameter EXT-XR-METADATA. The EXT-XR-METADATA parameter can optionally be exchanged by endpoints to indicate their support for specific sets of XR metadata. Alternatively, the endpoints may determine whether to communicate XR metadata, and which metadata to communicate, based on an out-of-band agreement.

EXT-XR-METADATA MOQT setup parameter , Extension-List (i), } ]]>

Extension-List is a variable-length integer (as defined in ) containing a bit field, with zero or more bits being set to 1 among:

• 0x01, which indicates the Release 18 XR Metadata Extension,
• 0x02, which indicates the use of optional PSSize field in the Release 18 XR Metadata Extension,
• 0x04, which indicates the use of optional NPDS field in the Release 18 XR Metadata Extension,
• 0x08, which indicates the Release 19 XR Metadata Extension,
• 0x10, which indicates the use of optional Burst Size field in the Release 19 XR Metadata Extension,
• 0x20, which indicates the use of optional Time-to-Next-Burst field in the Release 19 XR Metadata Extension,

The client can include an EXT-XR-METADATA parameter in CLIENT_SETUP, to indicate that it supports receiving certain extensions and options. The server can include an EXT-XR-METADATA parameter in SERVER_SETUP, to indicate that it supports receiving certain extensions and options. The EXT-XR-METADATA parameter is advisory in nature, and its purpose is both to inform the media sender that including per-object XR metadata can be useful, and to enable the media sender to save processing time by only including the fields that are supported by the receiver. For example, a client may indicate that it supports receiving any metadata and optional metadata with an EXT-XR-METADATA Extension-List value of (0x3f), and the server may reply with a SERVER_SETUP that does not include EXT-XR-METADATA, to indicate that it does not intend to use any per-object XR metadata in objects it receives from the client (or, e.g., because the connection is intended for unidirectional streams from server to client only).

XR Metadata in MOQT Datagrams or Streams When sending MOQ objects, an endpoint can include one of the extension headers described in this section. When receiving MOQ objects, an endpoint can ignore any header extension or optional field that it does not support or does not wish to process. A media sender MAY include a Release 18 Metadata Extension Header in an object. If the sender includes the optional PSSize field, it MUST set PSSize_present to 1, else it sets PSSize_present to 0. If the sender includes the optional NPDS field, it MUST set NPDS_present to 1, else it sets NPDS_present to 0.

XR Metadata MOQT Extension Header

A media sender MAY include a Release 19 Metadata Extension Header in an object. If the sender includes the optional BSize field, it MUST set BSize_present to 1, else it sets BSize_present to 0. If the sender includes the optional TTNB field, it MUST set TTNB_present to 1, else it sets TTNB_present to 0.

XR Metadata MOQT Extension Header

Endpoint Behavior for Communicating XR Metadata

Endpoint Behavior The endpoints can either have an out-of-band or in-band agreement to use per-object XR metadata in some tracks in a MOQT connection. To establish an in-band agreement, the endpoint can exchange the setup parameter EXT-XR-METADATA including a value indicating the content of the XR metadata extensions and optional fields that the endpoint support receiving, as described in . An endpoint can send objects including XR metadata extension header(s) in the object header, which the receiver can parse to obtain XR metadata associated with the object, as described in .

MoQ relay Behavior To handle high-throughput low-latency traffic, a MoQ client (e.g., running on a mobile device) should set up a MOQT connection through a MoQ relay interworking with a wireless network and providing this functionality. Discovery of such relay is out of scope of this document. The MoQ relay establishes a connection with a MoQ server and may send the setup parameter EXT-XR-METADATA in CLIENT_SETUP, as described in . The MoQ relay, during the media delivery session, parses XR metadata associated with the downlink media objects, as described in . The MoQ relay transmits XR metadata along with IP packets containing the MOQT objects, to the radio access network, which uses the metadata to apply XR traffic handling to the IP packets, and conduct corresponding RAN resource scheduling and mobile device control.

IANA considerations This document will register 2 odd-numbered MOQT header extensions: a Release-18 XR Metadata Extension, and a Release-19 XR Metadata Extension. This document will register a MOQT setup parameter: EXT-XR-PARAMETER.

Security Considerations To enable support for the feature described in this document, 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 Discord Meta Cisco Google Google 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

XR RTP Header Extension for XR Traffic Handling in 5G Networks 3GPP defined an RTP header extensions for PDU set marking, in , which enables a media sender to indicate media related information in each RTP packet.

Release 18 XR Metadata The fields defined in the Release 18 of 3GPP are included in this appendix, for the reader's convenience (text copied from V18.1.0 with minor adaptations and omissions of some notes for readability):

• End PDU of the PDU Set [E] (1 bit): This field is a flag that shall be set to 1 for the last PDU of the PDU Set and set to 0 for all other PDUs of the PDU Set.
• End of Data Burst [D] (1 bit): This field is a flag that shall be set to 1 for the last PDU of a Data Burst. It shall be set to 0 for all other PDUs. A Data Burst may consist of one or more PDU Sets.
• PDU Set Importance [PSI] (4 bits): The PDU Set Importance field indicates the importance of this PDU Set compared to other PDU Sets within the same Multimedia Session. This information may help RAN to discard PDUs, when needed. Lower values shall indicate a higher importance PDU Set, with the highest importance PDU Set indicated by 1 and the lowest importance PDU Set indicated by 15. When the RTP sender cannot define an importance, it shall set the value to 0.
• PDU Set Sequence Number [PSSN] (10 bits): The sequence number of the PDU Set to which the current PDU belongs, acting as a 10-bit numerical identifier for the PDU Set. The PSSN shall be incremented monotonically by 1 for each subsequent PDU Set.

NOTE: This value wraps around at 1023, however, using the 16-bit RTP packet sequence number and PSSN pair, a receiver may uniquely distinguish between any PDU Sets.

• PDU Sequence Number within a PDU Set [PSN] (6 bits): The sequence number of the current PDU within the PDU Set. The PSN shall be set to 0 for the first PDU in the PDU Set and incremented monotonically for every PDU in the PDU Set in the order of transmission from the sender.

NOTE: A receiver may use the RTP packet sequence number together with the PSN to distinguish between PDUs within a PDU Set that contains more than 64 PDUs.

• PDU Set Size [PSSize] (24 bits): The PDU Set Size indicates the total size of all PDUs of the PDU Set to which this PDU belongs. This field is optional and subject to an SDP signaling offer/answer negotiation, where the RTP sender shall indicate whether it will provide the size of the PDU Set for that RTP stream. If not enabled, the field shall not be present within the RTP HE. If enabled, but the RTP sender is not able to determine the PDU Set Size for a particular PDU Set, it shall set the value to 0 in all PDUs of that PDU Set. The PSSize shall indicate the size of a PDU Set including RTP/UDP/IP header encapsulation overhead of its corresponding PDUs. The PSSize shall be expressed in bytes. It is recommended to add the PDU Set Size field when the Number of PDUs in the PDU Set field is present.

NOTE: This field may be optionally present given the signaling of the "pdu-set-size" extension attribute in the SDP offer/answer negotiation.

• Number of PDUs in the PDU Set [NPDS] (16 bits): The number of PDUs within the PDU Set indicates the total number of PDUs belonging to the same PDU Set. This field is optional and subject to an SDP signaling offer/answer negotiation, where the RTP sender may indicate whether it will provide the number of PDUs within the PDU Set for that RTP stream. If enabled, but the RTP sender is not able to determine the Number of PDUs in the PDU Set, it shall set the value to 0 in all PDUs of that PDU Set. It is recommended to add the Number of PDUs in the PDU Set field when the PDU Set Size field is present.

NOTE: This field may be optionally present given the signaling of the "num-pdus-in-pdu-set" extension attribute in the SDP offer/answer negotiation.

Release 19 XR Metadata Additional fields are added to media related information in the Release 19 of 3GPP (text based on ):

• Expedited Transfer Indication [ETI]: this field indicates whether this object should be forwarded with an expedited QoS level.
• Burst size [BSize]: this field describes the size of a burst of traffic, which includes one or more PDU sets.
• Time-to-next-burst [TTNB]: this field describes the time between the end of the present burst and the beginning of the next burst.