| Internet-Draft | MOQ-EXT-NET-HANDLING | February 2026 |
| de Foy, et al. | Expires 20 August 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC9699]). 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 (Section 1.1). An extension to the RTP protocol [TS26.522] has been defined, which enables metadata associated with application data units to be identified at the ingress point of the wireless network (Section 1.2). To enable a similar operation with the MoQ protocol [I-D.draft-ietf-moq-transport], this document describes how a MoQ relay can be used at the ingress point of the wireless network (Section 1.3).¶
The rest of this document is structured as follows:¶
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 [TS23.501], 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.¶
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 [TS29.561].¶
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. Figure 1 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.¶
+---+ +-----------+ +-----------+ +---+
| A |<-|Access Node|------------| UPF |<--data+md--| B |
+---+ | |<-metadata--| MoQ relay | +---+
+-----------+ +-----------+
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the conventions detailed in ([RFC9000], Section 1.3) when describing the binary encoding. See [I-D.draft-ietf-moq-transport], section 1.3 for a non normative summary of the syntax.¶
In MOQ Transport (MOQT), XR metadata is transmitted in object headers, using the extension header mechanism described in [I-D.draft-ietf-moq-transport]. This document describes a MOQT header extension in the MOQT protocol, corresponding to XR metadata identified in Release 19 of 3GPP.¶
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 {
Parameter Type (i) = 0xTBD,
MRI descriptor (i),
}
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 [TS29.561].¶
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.¶
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 Type (i) = 0xTBD,
Header Length (i),
MRI (..)
}
The MRI field holds the media related information data structure defined in section 22.2 of [TS29.561]. The MRI field is byte-aligned.¶
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.¶
The extension header defined in this document can be added, removed and/or cached, but should not be modified by a MoQ relay.¶
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.¶
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.¶
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.¶
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 [TS29.561]. It is based on the version 19.4.0 of [TS29.561]. This appendix is informative and may be deleted from this draft prior to publication.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Bitmask |E| R |D| PSI | PSSN (hi) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PSN | PSSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NPDS | BSize (hi) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSize (lo) | TTNB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| Padding | +-+-+-+-+-+-+-+-+
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.¶