]> 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 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, based on what is currently defined by 3GPP for RTP.
• describes the behavior of the MoQ relay and of MOQ endpoints.
• 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 application data units that are handled (e.g., decoded) together by the application. 3GPP defines the term "PDU set" to identify these groups of data packets carrying the payload of an application data unit , 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 an 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 (typically 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 .

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 a 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.

XR Metadata for 5G

XR Metadata for PDU Sets XR metadata applies to IP packets from the 5G system standpoint. Some metadata is the same for a group of IP packets (the PDU set), while some metadata varies per IP packet within the PDU set. Some metadata relates to a data burst, which may consist of one or more PDU sets sent together as one burst of data. 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, in normative stage based on the conclusion of )
  • The Burst Size (BSize) describes the size of a burst of traffic, which includes one or more PDU sets.
  • 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.

Applying XR Metadata to MOQT In MOQT, XR metadata is transmitted in object headers. This document describes XR metadata in the MOQT protocol, as needed for Release 18 and 19 of 3GPP. NOTE: a MOQT extension mechanism is currently being defined in https://github.com/moq-wg/moq-transport/pull/502/files. This document follows this mechanism and might need be updated to use the final mechanism, once published.

Signalling of XR Metadata Support This document will register with IANA an integer MoQ Extension Header type named "xr-metadata". The REQUESTED-EXTENSION parameter (key 0x02), if present in the CLIENT_SETUP and SERVER_SETUP message, will include the value corresponding to the "xr-metadata" MoQ extension header type, if the client and server intend to use the "xr-metadata" extension header. This document will register with IANA a new setup parameter XR-METADATA that is associated with the "xr-metadata" MoQ extension header type. The XR-METADATA parameter indicates the support for specific sets of XR metadata. The XR-METADATA parameter holds a value which is the concatenation of two varints: The first varint, named '3gpp-xr', identifies the supported set of XR metadata:

• 0x00: No XR metadata.
• 0x01: Release 18 XR metadata.
• 0x02: Release 19 XR metadata.

An endpoint may indicate support for both sets of metadata using a value of 0x03. The second varint, named '3gpp-xr-options', identifies optional metadata:

• 0x00: No optional metadata. This value must be used if the first varint indicates no XR metadata.
• 0x01: PSSize and NPDS metadata are included. This may be used with Release 18 or 19 XR metadata.

The client can include an XR-METADATA parameter in CLIENT_SETUP, to request the server to send XR metadata, and to indicate supported XR metadata sets and options. The server can include an XR-METADATA parameter in the SERVER_SETUP, to indicate its intent to send XR metadata, and to indicate the XR metadata set and option.

XR Metadata in MOQT Datagrams When sending MOQ objects in datagrams, the object XR header includes the following fields.

• When 3gpp-xr bit 0 or 1 is set, the following fields are present in every object.
  • E (1)
  • D (1)
  • PSI (4)
  • PSSN (10)
  • PSN (6)
• When 3gpp-xr bit 1 is set, the following fields are present in some objects.
  • BSize (size TBD)
  • TTNB (size TBD)
• When 3gpp-xr bit 0 or 1 is set, and 3gpp-xr-options bit 0 is set, the following fields are present in some objects.
  • PSSize (24)
  • NPDS (16)

XR Metadata in MOQT Streams When sending MOQ objects in streams, the object XR header includes the following fields.

• When 3gpp-xr bit 0 or 1 is set, the following fields are present in every object.
  • D (1)
  • PSI (4)
  • PSSN (10)
• When 3gpp-xr bit 1 is set, the following fields are present in some objects.
  • BSize (size TBD)
  • TTNB (size TBD)
• When 3gpp-xr bit 0 or 1 is set, and 3gpp-xr-options bit 0 is set, the following fields are present in every objects.
  • PSSize (24)
  • NPDS (16)

E and PSN are not included and can be derived from QUIC signalling.

Traffic Handling of High-Throughput Low-Latency Traffic

MoQ relay Behavior A MoQ relay at the ingress point of a wireless network extracts metadata associated with PDU sets. The relay obtains the PDU set XR metadata from the object XR header, and

• When objects are transported in MOQT streams, E is derived from the FIN flag of the QUIC stream
• When objects are transported in MOQT streams, PSN is generated based on the QUIC/UDP/IP packets received in order of STREAM frame offset. In case there are missing packets, the relay can use the STREAM frame offset and path MTU to determine the sequence number of a packet received after one or more missing packets.

The relay transmits the PDU set XR metadata along with each IP packet, to the radio access network, which uses them to apply XR traffic handling.

Endpoint Behavior To enable XR traffic handling, a MoQ client should set up a MOQT connection through a MoQ relay providing this functionality. Discovery of such relay is out of scope of this document. Both MoQ server and client exchange the setup parameter REQUESTED-EXTENSION including a varint indicating usage of the 'xr-metadata' MoQ extension header type, and the setup parameter XR-METADATA with a value indicating the content of the XR metadata extension (as described in ). Prior to transmitting an object, an endpoint determines the XR metadata applicable to the object, and, if applicable, adds a XR metadata extension header into the object header.

IANA considerations TBD: registrations of the xr-metadata header extension and XR-PARAMETER setup 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 and Hang Shi for discussions and comments about this draft.

Informative 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. Ericsson This document explores the issues involved in the use of Edge Computing resources to operationalize media use cases that involve Extended Reality (XR) applications. In particular, this document discusses those applications that run on devices having different form factors (such as different physical sizes and shapes) and need Edge computing resources to mitigate the effect of problems such as a need to support interactive communication requiring low latency, limited battery power, and heat dissipation from those devices. The intended audience for this document are network operators who are interested in providing edge computing resources to operationalize the requirements of such applications. This document discusses the expected behavior of XR applications which can be used to manage the traffic. In addition, the document discusses the service requirements of XR applications to be able to run on the network. 3GPP 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 PDU set metadata 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 Potential additional fields in the Release 19 of 3GPP include (text based on work in progress in ):

• 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.