Media over QUIC transport signaling of media related information in a wireless communication system

Abstract

Various aspects of the present disclosure relate to an first network entity for wireless communication. The first network entity may be configured to, capable of, or operable to encapsulate a payload of media data into a media over QUIC transport, MoQT, object protocol data unit, PDU; determine a media related information, MRI, metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

Description

MEDIA OVER QUIC TRANSPORT SIGNALING OF MEDIA RELATED INFORMATION IN A WIRELESS COMMUNICATION SYSTEMTECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communication, including the media over QUIC transport signaling of media related information in a wireless communication system.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, which may be otherwise knowns as network equipment (NE) supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an examplestep that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] A first network entity for wireless communication is described. The first network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first network entity may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to encapsulate a payload of media data into a media over QUIC transport (MoQT) object protocol data unit (PDU); determine a media related information (MRI) metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0005] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to: encapsulate a payload of media data into an MoQT object PDU; obtain an MRI metadata for the MoQT object PDU; and output, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0006] A second network entity for wireless communication is described. The second network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the second network entity may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determine, from the at least one MoQT extension header, the MRI metadata.

[0007] A method performed or performable by the first network entity is described herein. The method may comprise: encapsulating a payload of media data into an MoQT object PDU; determining a MRI metadata for the MoQT object PDU; and transmitting, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0008] A method performed or performable by processor is described herein. The method may comprise: encapsulating a payload of media data into an MoQT object PDU; obtaining a MRI metadata for the MoQT object PDU; and outputting the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0009] A method performed or performable by a second network entity is described herein. The method may comprise: receiving, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determining, from the at least one MoQT extension header, the MRI metadata.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.

[0011] Figure 2 illustrates an example of a core network (CN) extended reality (XR) media (XRM) architecture for handling of MRI in accordance with aspects of the present disclosure.

[0012] Figure 3A illustrates an example of a serialization template for MoQT object extension headers in accordance with aspects of the present disclosure.

[0013] Figure 3B illustrates an example representation of a MoQT object header in accordance with aspects of the present disclosure.

[0014] Figure 4 illustrates an example of an MoQT protocol stack in accordance with aspects of the present disclosure.

[0015] Figure 5 illustrates an example of a process flow that marks MoQT objects with MoQT extension headers in accordance with aspects of the present disclosure.

[0016] Figure 6 illustrates an example of MRI marking of an MoQT object as a single MoQT extension header in accordance with aspects of the present disclosure.

[0017] Figure 7 illustrates an example of MRI marking of an MoQT object as a plurality of MoQT extension headers in accordance with aspects of the present disclosure.

[0018] Figure 8 illustrates an example of an MoQT extension header value in accordance with aspects of the present disclosure.

[0019] Figure 9 illustrates an example of a UE 900 in accordance with aspects of the present disclosure.

[0020] Figure 10 illustrates an example of a processor 1000 in accordance with aspects of the present disclosure.

[0021] Figure 11 illustrates an example of a NE 1100 in accordance with aspects of the present disclosure.

[0022] Figure 12 illustrates a flowchart of a method 1200 performed by a UE or NE in accordance with aspects of the present disclosure.

[0023] Figure 13 illustrates a flowchart of a method 1300 performed by a NE in accordance with aspects of the present disclosure.

[0024] Figure 14 illustrates a flowchart of a method 1400 performed by a processor in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0025] A wireless communication system, including one or more UEs and NEs may exchange media data of one or more applications. The media data may be exchanged between the one or more UEs and NEs as one or more PDUs of a PDU set. The one or more PDUs of the PDU set may be encapsulated as payloads according to a transport protocol. Accordingly, the media data itself may be kept secure during transport and visible only to the endpoints of the respective communication i.e., between the sender UE or NE ofthe media data and the intended recipient UE or NE for the media data. However, by keeping the media data secure from a network across which the media data is being routed, the network itself cannot tailor or optimize the routing based on attributes of the media data. Accordingly, it is desirable to be able to share MRI of the media data in-band with the media data itself, in order to enable a CN and radio access network (RAN) to optimise the radio resource allocation and the network transport.

[0026] Applications may generate media data with static or dynamic traffic characteristics. Applications with dynamic traffic characteristics include but are not limited to streaming or conversational services. Generally, MRI signaled in-band with media data according to canonical approaches has been limited to including PDU set information only, which does not fully capture the dynamic traffic characteristics of some media applications. Accordingly, the media data of applications with dynamic traffic characteristics has not been able to fully exploit the benefits of in-band signaling of MRI to optimise network routing. This is particularly the case for MoQT.

[0027] The disclosure herein tends to enable the signaling of a broader range of MRI in MoQT. Specifically, the disclosure herein utilises MoQT extension headers for the signaling of MRI for media data. This tends to allow for MRI associated with media data from applications with dynamic traffic characteristics, such as streaming or conversational services, to be made available to a CN and RAN for the purposes of optimising routing and transport. Even more specifically, where a UE or NE (such as a user plane function (UPF)) is acting as an MoQT relay, the MRI can be efficiently accessed and consumed, with minimal signaling overhead and without significant additional processing. Accordingly, the downstream delivery of media data can be optimised even for applications whose media exhibits dynamic traffic characteristics.

[0028] Aspects of the present disclosure are described in the context of a wireless communications system.

[0029] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a CN 106. The wireless communications system 100 may support various radio access technologies. In someimplementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0030] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a RAN, a NodeB, an eNodeB (eNB), a nextgeneration NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signalling, transmit signalling) over a Uu interface.

[0031] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN). In some implementations, different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0032] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as aremote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0033] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0034] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0035] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a UPF). In some implementations, the control plane entity maymanage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0036] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a PDU session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0037] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5 G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0038] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g., / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated witha third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0039] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0040] Additionally, or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l , / r=2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0041] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands,frequency channels, etc. By way of example, the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0042] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0043] The 3rdGeneration Partnership Project (3GPP) established in Release 19 the concept of MRI as metadata corresponding to media payloads which may be encrypted end to end (E2E). The MRI is information decorating in-band the media payloads and associated PDUs, thus signaling to CN and RAN dynamic traffic characteristics and media content awareness for optimized radio resource allocation and network transport (i.e., Quality of Service (QoS) flow setup and management).

[0044] The MRI may group media and describe application data units (ADUs) by means of PDU Set information or may signal dynamic traffic characteristics such as data burst size (BSize), time-to-next burst or expedited transfer indication (ETI). All these information may be transported via protocols ensuring security end-to-end, such as SRTP, Connect-UDP QUIC-encapsulated protocols (e.g., tunneling via Connect-UDP as described in the Internet Engineering Task Force (IETF) Standard RFC 9298 titled “Proxying UDP inHTTP”, forwarding via QUIC-aware proxy as described in the IETF draft-ietf-masque- quic-proxy-05 titled “QUIC- Aware Proxying Using HTTP”), UDP options or combinations thereof.

[0045] An alternative approach to carry MRI is to utilize the emerging media content distribution protocol atop of QUIC, i.e., MoQT, wherein part of MRI information may be available based on local configuration and identification of information elements based on MoQT metadata accessible to MoQT relays. The latter approach may appear appealing especially given the prospect of MoQT taking over existing hypertext transfer protocol (HTTP)-based streaming protocols, e.g., dynamic adaptive streaming over HTTP (DASH) or HTTP live streaming (HLS), as well as over real-time and interactive content distribution atop of WebRTC. However, currently 3 GPP does not specify any standard way to transport MRI atop of MoQT, leaving details of extracting MRI-like information from an MoQT configuration limited to canonical MoQT metadata. This approach neither scalable nor accurate as MoQT metadata information is not fully mappable to the MRI as it highly depends on the media configuration and mapping to the canonical MoQT transport elements, i.e., Objects, Subgroups, Groups, Tracks. It is therefore desirable and necessary to extend the existing MoQT metadata to further embed and include MRI.

[0046] XRM in the 5GS will now be described. XR is referred to hereafter as an umbrella term for different types of realities, according to the 3 GPP Technical Report TR 26.928 (vl7.0.0 - Apr 2022) titled “Extended Reality (XR) in 5G”. In particular, XR may include virtual reality (VR), augmented reality (AR) and mixed reality (MR).

[0047] VR is a rendered version of a delivered visual and audio scene. The rendering is in this case designed to mimic the visual and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Virtual reality usually, but not necessarily, requires a user to wear a head mounted display (HMD), to completely replace the user's field of view with a simulated visual component, and to wear headphones, to provide the user with the accompanying audio. Some form of head and motion tracking of the user in VR is usually also necessary to allow the simulated visual and audio components to be updated to ensure that, from the user's perspective, items and sound sources remain consistent with the user's movements. Insome implementations additional means to interact with the virtual reality simulation may be provided but are not strictly necessary.

[0048] AR is when a user is provided with additional information or artificially generated items, or content overlaid upon their current environment. Such additional information or content will usually be visual and / or audible and their observation of their current environment may be direct, with no intermediate sensing, processing, and rendering, or indirect, where their perception of their environment is relayed via sensors and may be enhanced or processed.

[0049] MR is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene.

[0050] XR refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as AR, MR and VR and the areas interpolated among them. The levels of virtuality range from partially sensory inputs to fully immersive VR. A key aspect of XR is the extension of human experiences especially relating to the senses of existence (represented by VR) and the acquisition of cognition (represented by AR).”

[0051] The MRI signaling and handling within CN and QoS flows will now be introduced, with reference in particular to XR media (XRM).

[0052] The XRM feature in 3 GPP Release 18 and Release 19 at the CN level introduced the concept of application awareness and exposure of application dynamic traffic characteristics to the CN and RAN. This was first implemented by means of PDU Set Information in Release 18 and further extended to MRI in Release 19. This MRI has been utilized to optimize in the CN and RAN the mapping, setup, and management of QoS flows for application data flows, as well as to optimize the radio resource allocation.

[0053] For example, a PDU Set may be used to handle QoS requirements of XRM applications and streams with a better granularity beyond that achievable of 5G Release 17 QoS flows. As such, according to the 3GPP Technical Report TR 23.700-60 (vl 8.0.0 - Dec 2022) titled “Study on XR (Extended Reality) and media services”, and the 3GPPTechnical Specification TS 23.501 (vl9.2.1 - Jan 2025) titled “System architecture for the 5G System (5GS)”, a PDU set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice for XRM Services). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts or all of the information unit, when some PDUs are missing.

[0054] In addition, the PDU set is associated with QoS requirements in terms of delay budget and error rate as outlined in the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025).

[0055] A PDU Set Delay Budget (PSDB) defines an upper bound for the time that a PDU-Set may be delayed between a UE and the N6 termination point at the UPF. PSDB applies to the downlink (DL) PDU-Set received by the UPF over the N6 interface, and to the uplink (UE) PDU-Set sent by the UE.

[0056] A PDU Set Error Rate (PSER) defines an upper bound for the rate of PDU-Sets (e.g., set of IP packets constituting a PDU-Set) that have been processed by the sender of a link layer protocol (e.g., radio link control (RLC) in RAN of a 3 GPP access) but where all of the PDUs in the PDU-Set are not successfully delivered by the corresponding receiver to the upper layer (e.g. packet data convergence protocol (PDCP) in RAN of a 3 GPP access). The PSER is used to determine an upper bound for a rate of non-congestion-related packet losses.

[0057] At protocol level, the PDU Set information as MRI comprises: PDU Set Sequence Number (PSSN); Indication of End PDU of the PDU Set (E); PDU Sequence Number within a PDU Set (PSN); PDU Set Size in bytes (PSSize); PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow (PSI).

[0058] Aside PDU Set information, other MRI may further comprise, according to the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025) dynamic traffic characteristics such as: End of Data Burst Indication (D), i.e., a bit flag indicating whetherthe current PDU is the last PDU in a data burst (i.e., one or more PDUs send by an application in a short period of time); EH, i.e., a bit flag indicating that the current PDU requires a data boost from the network and may be routed on a priority / elevated QoS flow associated with the application data flow; BSize, i.e., the size in bytes of the current data burst of PDUs; Time to Next Burst (TTNB), i.e., the time between the last PDU of the current data burst to the first PDU of the next data burst that the application will send, or alternatively, data burst periodicity, the expected time between data bursts, wherein the periodicity may change over time due to various encoding and application sender configuration changes or events.

[0059] The MRI may be signaled to the CN, i.e., the UPF, in-band within the user plane at reference point N6. The signaling is embedded within a communication protocol. Many protocols may be supported with different transport options for signaling the MRI in-band to the UPF at N6, as for example, according to the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025): secure (S) real time protocol (RTP) over user datagram protocol (UDP), wherein the MRI is transported over RTP Header Extensions marking PDUs with MRI originating at the application sender; Encapsulation protocols based on QUIC and CONNECT-UDP for E2E-encrypted media payloads and encrypted MRI, such as proxying-UDP-in-HTTP (as defined in IETF Standard RFC 9298, wherein the MRI is transported as a header in the HTTP Datagram preceding the associated UDP proxying payload (e.g., (S)RTP PDU, or alike media content delivery PDU)), or QUIC-Aware Proxy (as defined in IETF draft-ietf-masque-quic-proxy, wherein the MRI is transported as a header part of a packet transform for forward mode transport applicable optionally when UDP proxying payload is a QUIC PDU), or UDP-Options ( as defined in IETF draft-ietf- tsvwg-udp-options titled “Transport Options for UDP”, wherein the MRI is transported as an UDP Option field appended to the outer UDP PDU of the Connect-UDP tunnel used to establish the security context (i.e., secret key, security parameters etc.) of the MRI).

[0060] Figure 2 illustrates an example of a CN XRM architecture 200 for handling of MRI in accordance with aspects of the present disclosure. The CN XRM architecture 200 is presented as a protocol-independent overview.

[0061] Figure 2 shows an architecture 200 comprising an application service provider 210, a policy and control function (PCF) 215, a session management function (SMF) 220, an AMF 225, a RAN 230, a UE 235, a UPF 240. The application service provider 210 comprises a media AF 210a and a media application server 210b. The architecture 200 will now be described in respect of the processing steps for DL traffic.

[0062] At step 201a and 201b, the media AF 210a provides QoS requirements for packets of an application data flow (i.e., an IP flow and potentially including PDU Set requirements, i.e., PSDB and PSER) to the PCF 215. and information to identify the application (i.e. 5-tuple or application ID). Specifically at step 201a, the AF may determine if MRI is present and the PDU-set requirements and include corresponding MRI presence description and protocol description for the CN to identify packets comprising MRI and extract the MRI (e.g., PDU Set, EDB, ETI, BSize, TTNB, etc.). Specifically at step 201b the media AF 210a requests a QoS session with the MRI description and protocol description.

[0063] At step 202, the PCF 215 determines / derives QoS rules for the application data flow with MRI at N6 (i.e. uses a 5QI for XR media traffic), including specific QoS requirements for the PDU Set, if optionally requested, and configures the SMF 220 using QoS rules for a 5-tuple (including any available PDU-set related QoS requirements).

[0064] At step 203, the SMF 220 establishes a QoS flow according to the QoS rules received from the PCF 215 and configures the UPF 240 to route packets of the application data flow to a QoS flow, and, in addition, to enable MRI handling. The configuring of the UPF 240 is via N4 rules. The N4 rules container comprises additionally Packet Detection Rules (PDR) to inform the UPF of the protocol containing MRI at N6. The SMF 220 also provides the QoS profile containing PDU set QoS requirements to the RAN 230 via the AMF 225. The QoS profile may include PSDB, PSER and MRI detection information.

[0065] At step 204a the media application server 210b communicates with the UPF 240 at the N6 reference point using a protocol embedding MRI signaling in-band corresponding to PDR rules. At step 204b the UPF 240 inspects according to the configured PDR the packets at the N6 reference point and detects / determines MRI (e.g., based on extracting and inspecting the MRI container / field from the encapsulation protocol, or by additionalimplementation-specific means) based on AS-marked MRI over an encapsulation protocol (e.g., (S)RTP, Connect-UDP, UDP-Options etc) as per the 3 GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025). When the UPF 240 detects packets comprising MRI, the UPF 240 extracts the MRI, routes over GTP-U tunnel encapsulation the packets to the RAN 230 on the SMF 220 configured QoS flow and marks the corresponding packets to RAN 230 with MRI within their GTP-U headers. This is shown as “QoS flow 1” including the GTP-U header, itself including MRI such as PDU set, burst size, TTNB, ETI.

[0066] At step 205, the RAN 230 receives the packets and their corresponding MRI over GTP-U on the SMF 220 configured QoS flow (QoS flow 1). The RAN 230 identifies the MRI and handles the packets of the QoS flow according to the QoS requirements provided by the SMF 220. The RAN node 230 may use the MRI to optimize for the QoS requirements’ in associated radio bearer(s) handling to guarantee delivery of the packets according to the configured QoS and QoS profile, e.g., for radio resources / radio scheduling optimization, congestion handling, packet prioritization (e.g., based on MRI values, such as PSI, or ETI) to higher QoS requirement / radio bearer.

[0067] The RAN 230 may use priority levels as per the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025), Clause 5.7.3.3, which is incorporated by reference herein, across QoS Flows and PDU Set Importance within a QoS Flow for PDU Set level packet discarding in presence of congestion.

[0068] The MoQT protocol, as defined in the IETF draft-ietf-moq-transport titled “Media over QUIC Transport” is based on QUIC or can alternatively be layered on top of WebTransport. Although generic, MoQT has been initially designed for media delivery. MoQT is based on a publish-subscribe flow and allows a publisher to fan out and distribute media content to many subscribers with a focus on latency and scalability. Since QUIC and WebTransport are mainly used for Layer 4 transport channels between a client and a server, MoQT defines its own set of control messages and canonical object containers for media delivery to establish and operate a MoQT session.

[0069] An MoQT client endpoint can thus connect to an MoQT server using QUIC or WebTransport. Upon completing the QUIC connection handshake, the MoQT client initiates firstly a single QUIC bi-directional stream which serves as an in-band controlchannel between the MoQT client and MoQT server where MoQT control messages can be exchanged in either direction to configure and manage the media delivery among peers. For example, the first MoQT control messages exchanged are related to the MoQT client and MoQT server configuration and capability of MoQT protocol and these correspond to the CLIENT SETUP and SERVER SETUP MoQT control messages. Next, based on the content, either the MoQT client or the MoQT server may act as Publisher and / or Subscriber after the MoQT Transport Session has been established and MoQT protocol parameters have been exchanged and configured. To this end, MoQT control messages SUBSCRIBE and ANNOUNCE may be exchanged to setup the media subscription and delivery routing. For example, a Publisher may announce where a receiver may subscribe by means of MoQT ANNOUNCE control messages, whereas a Subscriber may subscribe via the MoQT SUBSCRIBE control messages to the desired media. The subscription in effect will cause the Publisher to send published MoQT Objects for the MoQT Track subscribed. MoQT Objects are thus transported between the Publisher and Subscriber based on the preferred and configured Object Forwarding Preference of an MoQT Track.

[0070] The canonical MoQT object data model for media delivery is structured hierarchically, in bottom-up fashion as will now be introduced. In particular, the terms ‘Object,’ ‘Subgroup,’ ‘Group’ and ‘Track’ will be defined.

[0071] An ‘Object’ is the basic data element of MoQT, that is an addressable PDU with a payload containing a sequence of bytes (e.g., encoded audio / video frame or part thereof, text messages, game data, game I / O etc). Although the Object may become unavailable its content is fixed and may not change across a Transport Session, or over time (i.e., MoQT relays are not allowed to change Object content even when caching such that the Original Publisher is solely responsible for the Object content). All objects belong to group and can be uniquely identified by Track (i.e., namespace and name, or alternatively, alias), group ID, subgroup ID and object ID.

[0072] A ‘Subgroup’ is a sequence of one or more objects from the same group in ascending order by Order ID, wherein Objects of a group have a dependency and priority relationship impinging sharing same QUIC stream (e.g., Objects comprising the content of a video frame, or alternatively Objects comprising the content of a Group of Picturessequence of video frames). Subgroups may be used only when Object Forwarding Preference of a Track is Subgroup, and their purpose is to ensure in-order reliable delivery with the ability of controlling sending, prioritization and data retransmission. Any object within a Group must belong to exactly one Subgroup and any two Subgroups must be transported over two different streams.

[0073] A ‘Group’ is a collection of objects as a sub-unit of a Track. A Group is meant to be independent of other Groups, meaning that objects often shall contain different media modality or media source than other Groups. For example, a Group may comprise a video stream and another Group may comprise an audio stream, or alternatively a Group may comprise a video stream from one logic capture device (i.e., left-eye camera) and another Group may comprise a video stream from another logic capture device (i.e., right-eye camera).

[0074] A ‘Track’ is a sequence of Groups and is an entity against which a subscriber can issue a subscription request.

[0075] In terms of protocol encapsulation, only the MoQT Objects are defined as basic data elements of the protocol, whereas the mapping of Objects to Subgroups, to Groups, and to Tracks is resolved based on the Streaming Format configured to the Tracks that can be subscribed to, and respectively, by the MoQT canonical Object metadata.

[0076] The MoQT Objects are published to a matching subscription on Data Streams. These data streams may be mapped to QUIC uni-directional streams or QUIC datagrams. QUIC uni-directional streams, as defined in the IETF Standard RFC 9000 titled “a UDP- based multiplexed and secure transport”, transport either Subgroups (started with a SUBGROUP HEADER of ID 0x4) or Objects (started with a FETCH HEADER) of a MoQT FETCH control message. The MoQT unidirectional streams usage associated with a subscription may thus be used only when the Track Object Forwarding Preference is set to Subgroup. The FETCH control message may be used by a Subscriber to request the Publisher to publish previously published data before a subscription SUBSCRIBE entry point, or standalone subset of Objects within a Track. QUIC datagrams, as defined in the IETF Standard RFC 9221 titled “An unreliable Datagram Extension to QUIC”, may be used to transport Objects datagrams, (i.e., OBJECT DATAGRAM andOBJECT DATAGRAM STATUS as per the IETF draft-ietf-moq-transport) without demanding requirements of reliable in-sequence transmission.

[0077] The canonical MoQT Object data model is encoded as an MoQT Object header (or alternatively MoQT metadata) and MoQT Object Payload. The MoQT metadata is therefore useful to uniquely identify objects in the context of a Track, Group, or Subgroup, and indicate priority / forwarding preference.

[0078] The MoQT Object header may be optionally extended as of version 9 of the IETF draft-ietf-moq-transport with MoQT Object extension headers specifically which may be visible to MoQT relays. Such MoQT Object extension headers may be defined in other specifications or be transport-specific, whereby MoQT only provides a serialization template (i.e., in the IETF Standard RFC 9000, Section 1.3 notational convention). Figure 3 A illustrates an example of a serialization template 310 for MoQT object extension headers in accordance with aspects of the present disclosure. In the template 310, the “Header Type” is an identifier of the extension header and its serialization encoding, with even types followed by a single Header Value, and odd types followed by variable number of Header Values.

[0079] Figure 3B illustrates an example representation of a MoQT object header 320 in accordance with aspects of the present disclosure. The representation 320 of the MoQT Object Header (including OBJECT DATAGRAM, OBJECT DATAGRAM STATUS, SUBGROUP HEADER and FETCH HEADER header types) includes its canonical headers conforming to the IETF draft-ietf-moq-transport as well as optional extension headers.

[0080] Figure 4 illustrates an example of an MoQT protocol stack 400 in accordance with aspects of the present disclosure. The MoQT protocol stack 400 includes an operating system (OS) kernel 410 and a OS user space 420. In the OS kernel 410 there is an IP 412 and UDP 414. In the user space 420, there is QUIC 422. The QUIC 422 may include a datagram extension. In the user space 420 there is HTTP / 3 424. The HTTP / 3 424 may include request prioritisation and HTTP datagram extensions. In the user space 420 there is WebTransport framework 426. In the user space 420 there is also MoQT 428. In the user space 420 there is also an MoQ media layer 429.

[0081] The QUIC substrate 422 is available in the OS user space 420 and is potentially accessible from a media application, relying on APIs (either OS-specific or standardized, e.g., WebTransport APIs), while the layers in the OS kernel space 410 are accessed via OS system calls (e.g., UDP 414 can typically only be accessed via an API provided by the OS- provided socket library). The IP 412, UDP 414, QUIC 422, HTTP / 3 424, MoQT layers 428 are protocol layers. The WebTransport framework 426 and MoQ media layer 429 are nonprotocol layers, such as client / server frameworks. The example 400 indicates APIs defined by a given block, with standardized APIs 440a, 440b, 440c, 440dand non-standardized implementation-specific APIs (e.g. library APIs) 430a, 430b, 430c, 43 Od, 43 Oe, 43 Of, 430g, 43 Oh. The WebTransport framework 426 initially uses HTTP / 3 424 for connection establishment and afterwards switches to interfacing with the QUIC layer 422 for data transfer. The MoQT layer 428 typically uses QUIC 422 directly, but can also be layered on top of WebTransport 426. The MoQ media layer 429 may use the MoQ Streaming Formats for configuration of policies and MoQT Subscriber / Publisher behaviour related to content discovery, subscription, and transport information on encoding, packaging, and mapping the media content to MoQ objects. Some examples of specific MoQ Streaming Formats may be WARP Streaming Format, as defined in the IETF draft-ietf-moq-warp titled “WARP Streaming Format” or MoQ, Media Interop, as defined in the IETF draft-cenzano- moq-media-interop titled “MoQ Media Interop”, based on the Low Overhead Media Container (LOC) as defined in the IETF draft-mzanaty-moq-loc titled “Low Overhead Media Container”.

[0082] MoQT may be used for MRI transport in the 3GPP CN as per 3GPP Release 19 of the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025) titled “System architecture for the 5G System (5GS)”. When MoQT is used at N6, the UPF is a MoQT server that acts as a MoQT relay to which a UE may subscribe or publish media content to. The UPF may then identify a limited subset of MRI, as per the 3GPP Technical Specification TS 23.501 (vl9.2.1 - Jan 2025) titled “System architecture for the 5G System (5GS)”, such as PDU Set Information and EDB. The UPF identification of PDU Set information and EDB is further limited to using local configuration and implementation specific means to map canonical MoQT Object headers metadata visible to MoQT relays to the information elements of PDU Set information and EDB. These limitations hinder MRIapplicability to MoQT, and, as such, require a solution to fully benefit of MRI handling at N6 over MoQT. The disclosure herein provides such a solution by introducing MRI MoQT Object Extensions, or alternatively, MRI MoQT extension headers to MoQT.

[0083] Examples of the disclosure herein use a generic container as a MoQT extension header to pass any MRI. This is not restricted only to PDU Set information as per previous art, but may include also other information, such as dynamic traffic characteristics, data burst metadata or ETI for instance.

[0084] Furthermore, the disclosure herein avoids high complexity at the UPF. Specifically, the examples described herein do not rely on the UPF doing heavy processing to determine the MRI (e.g., PDU Set information). Instead, such MRI is provided in-band as an extension header.

[0085] The disclosure herein is based on embedding MRI at the Transport Session layer of the MoQT protocol and making such data consumable by MoQT relays and endpoints as necessary for downstream optimized data delivery. To this end, in some examples the MRI may be embedded as an MoQT extension header by an MoQT Original Publisher (e.g., a Media Application Server, or alternatively, a peer UE). The MoQT Original Publisher may thus mark the MoQT Objects with MoQT extension headers and publish it to any subscribers.

[0086] In some examples, a UPF in a mobile CN acting as a MoQT relay that subscribes to the MRI-marked MoQT Objects may extract and process the MoQT extension header based on PDR rules configured by an SMF. The MRI may be encoded as a single MoQT extension header or as multiple MoQT extension headers for specific MRI fields (e.g., PDU Set information, Data Burst information, i.e., EDB and / or BSize, TTNB, ETI).

[0087] Once the UPF applies the PDR and identifies / detects the MRI of an MoQT Object as part of its MoQT extension headers, the UPF, as an MoQT relay that supports the MoQT extension headers, may cache the MRI for the PDUs corresponding to the MoQT Object; remove the MoQT extension headers from the MoQT Object for downstream MoQT content delivery to the End Subscriber (e.g., a UE).

[0088] The UPF may route the PDUs corresponding to the MoQT Object to a QoS flow according to the QoS rules and based on the extracted MRI (e.g., prioritize some MoQT Object to a QoS flow with higher QoS requirements, or alternatively, route MoQT Objects with PDU Set information to a QoS flow with PDU Set handling).

[0089] The UPF may signal the MRI, or a subset thereof, to the RAN in-band as part of the GTP-U tunnel GTP-U headers of PDUs corresponding to the MoQT Object.

[0090] Figure 5 illustrates an example of a process flow 500 that marks MoQT objects with MoQT extension headers in accordance with aspects of the present disclosure. The process flow 500 may implement or be implemented by aspects of the wireless communication system 100. For example, the process flow 500 may include a media application function 510, an PCF 520, an SMF 530, an AMF 540, a RAN 550, an UPF 560, a media application server 570, an UE 580, which may be one or more examples of devices described herein with reference to Figure 1. The media application server 570 may be referred to herein as a first network entity. The UPF 560 may be referred to herein as a second network entity. The UE 580 may be referred to herein as a third network entity.

[0091] The UPF 560 is shown as including PDR rules 562, an MoQT relay 564, an MoQT track 1 (videoO) 566 and an MoQT track 2 (audioO) 568.

[0092] The media application server 570 is shown as including an MoQT original publisher 572, an MoQT track 1 (videoO) 574 and an MoQT track 2 (audioO) 576.

[0093] The UE 580 is shown as including an APP 582, the APP 582 having an MoQT end subscriber 584, an MoQT track 1 (videoO) 586 and an MoQT track 2 (audioO) 588.

[0094] The process flow 500 may be referred to as a procedure, including one or more operations performed by one or more of the media application function 510, PCF 520, SMF 530, AMF 540, RAN 550, UPF 560, media application server 570, UE 580. In the process flow 500 the media application function 510 may provide QoS requirements for an IP flow (i.e., a 5-tuple) to the PCF 520. The QoS requirements may include MoQT protocol and track description. The PCF 520 may provide PCC rules to the SMF 530, including optionally PSDB and PSER requirements. The SMF 530 may provide a QoS profile to AMF 540, and / or N4 rules to the UPF 560. The AMF 540 may provide an N2 SM containerto the RAN 550 including the QoS profile and PSDB / PSER requirements. As shown in the process flow 500, the MoQT original publisher 572 of media application server 570 generates video frames (I-frames 592a, P-frames 592b, B-frames 592c) and audio frames 592d. The media application server 570 may explicitly include MRI in MoQT object extensions metadata. The MoQT original publisher 572 passes the video frames 592a, 592b, 592c to MoQT track 1 574, and the audio frames 592d to MoQT track 2 576. The video frames 592a, 592b, 592c and the audio frames 592d are encapsulated in an IP packet 594. Specifically, each IP packet 594 comprises an IP header 594a, a UDP header 594b, a QUIC header 594c and an MoQT object 594d. The MoQT object 594d includes a header 594dl, an extension header 594d2 and a payload 594d3 that is video frame 592a, 592b, 592c or audio frame 592d, dependent on the track 574, 576. In the downstream direction, the IP packets 594 are provided as QUIC frames between the media application server 570 and UPF 560. Specifically, the UPF 560 receives QUIC frames on MoQT track 1 566 from MoQT track 1 574 of media application server 570. The UPF 560 also receives QUIC frames on MoQT track 2 568 from MoQT track 2 576 of media application server 570. The UPF 560 may extract MRI from the MoQT extension headers 594d2 which may include PDU Set information, BSize, EH and / or TTNB. The UPF 560 may then establish a QoS flow 596 with RAN 550 to include audio and video with PSDB / PSER requirements. The UPF 560 may route the IP packets 594 without the extension headers 594d2 as IP packets 594* over the QoS flow 596 as QUIC frames towards UE 580. The respective QUIC frames for video and audio are received on MoQT track 1 586 and MoQT track 2 588 in APP 582 of UE 580 and to the MoQT end subscriber 584. Accordingly, media data is end to end encrypted as MoQT object pay loads between the MoQT original publisher 572 and MoQT end subscriber 584, but with MRI available to the UPF 560 via the MoQT extension headers 594d2.

[0095] Additional detail regarding the process flow 500 will now be provided. A content producer may control the media application function 510 to request on behalf of the media application server 570 (operating as MoQT Publisher 572) the QoS session with the QoS requirements. The Protocol Description, included in the request and referred to above as the MoQT protocol description, may indicate that the MoQT protocol is to be used. The Protocol Description may further comprise of a description of tracks as noted above. Thetrack description may include information elements comprising a track and its corresponding MoQT extension headers marking configuration as applied by the MoQT Original Publisher 572. The request for the QoS session is received by the PCF 520 and processed by the CN as described with reference to Figure 2, such that the UPF 560 can be configured by the SMF 530 with the N4 rules. The N4 rules may include PDR rules for detecting and identifying MoQT traffic and MoQT Object MoQT extension headers 594d2 for the downstream MoQT traffic from the MoQT Original Publisher 572. The MoQT Original Publisher 572 (the media application server 570) marks media content, i.e., the MoQT Objects 594d (e.g., at the origin MoQT server) with MoQT extension headers 594d2 (e.g., comprising PDU Set, data burst dynamic traffic characteristics, EH information). The downstream flow of MoQT Objects 594d towards a MoQT End Subscriber 584 (e.g., MoQT client at UE 580) is being relayed over a CN 550, 560 which is thus MoQT-aware. The MoQT-awareness is realized by the UPF 560 user plane gateway acting as MoQT relay 564 and being configured to apply PDR rules to downlink traffic for the IP flow(s) 594, 596 corresponding to the MoQT downstream traffic. The UPF 560 acting as the MoQT relay 564 applies the PDR and QoS rules configuration for the IP flow(s) 594 to detect, cache and extract MRI from the MoQT Objects 594d and MoQT extension header 594d2. Once this operation completes, the UPF 560 continues its operation in the CN by routing the PDUs corresponding to the MoQT Objects 594d to the RAN 550 by means of GTP-U encapsulation. Within GTP-U encapsulation, the UPF 560 may use GTP-U encapsulation headers (e.g., PDU Set information GTP-U header) to relay relevant MRI to the RAN 550 for optimized media handling according to the QoS flow 596 established by the SMF 530 configuration for the session.

[0096] In the description of the process flow 500, the operations or signalling performed between one or more of the media application function 510, PCF 520, SMF 530, AMF 540, RAN 550, UPF 560, media application server 570, UE 580 may be performed or signalled (e.g., transmitted, received) in a different order than the example order shown, or the operations or signalling performed by one or more of the media application function 510, PCF 520, SMF 530, AMF 540, RAN 550, UPF 560, media application server 570, UE 580 may be performed or signalled (e.g., transmitted, received) in different orders or at different times. Some operations or signalling may also be omitted from the process flow500. Additionally, although some operations or signalling may be shown to occur at separate times, these operations or signalling may occur at the same time or in overlapping time periods.

[0097] The marking of MRI in one or more MoQT extension headers by a first network entity (i.e., a media application server, a UE or more generally an MoQT original publisher) will now be described.

[0098] An MoQT Original Publisher (e.g., a peer UE publishing a live stream video, a peer UE publishing video / audio / chat text in a conversational / immersive service, a Media application server publishing a stream) referred to herein as a first network entity marks in some examples the media published as MoQT Objects with MRI as MoQT extension headers. The MRI may be comprised in a single common MoQT extension header associated with an MoQT Object, or alternatively, in multiple MoQT extension headers, each associated with the MoQT Object and corresponding to a particular type of MRI (e.g., PDU Set information, data burst information, ETI).

[0099] An MoQT Original Publisher that is itself a content producer, or alternatively, another MoQT relay acting as a downstream MoQT Publisher under the control of the content producer, generally referred herein as the MoQT Publisher or first network entity, may mark in some examples one or more MoQT Tracks associated with a media service with MRI as part of MoQT extension headers. For example, such an MoQT Track with MRI active marking may be a video media track, an audio media track, a chat media track, an Al media track (e.g., comprising multi-modal Al-processed media combining one or more of video, audio, video-embeddable objects, such as pictures, animations, decorations and 2D / 3D models).

[0100] In one example, the MoQT Publisher (first network entity) may mark the media payload, i.e., MoQT Object, inline with one single MRI MoQT extension header. The single MoQT extension header may identify its header type by a value (e.g., MRI header type = ‘65’) and encode an extensible length value. The header type value may be odd valued. The MoQT extension header payload, or alternatively, header value, may comprise of an extensible encoding of one or more MRI fields such as PDU Set information, data burst dynamic traffic characteristics (e.g., data burst size, end of data burst indication), ETI.The presence of individual MRI fields may be indicated by a pre-pended bitmask describing the contents of the encoding and its serialization order. In addition, the MoQT extension header value may comprise a first field as a ‘Version’ field indicating the MoQT extension header value encoding as a container. The container performing the serialization of the MoQT extension header may thus be future-compatible and extended to include other semantics for the bitmask bits or bitmask field, as well as its indicated fields encoding.

[0101] Figure 6 illustrates an example 600 of MRI marking of an MoQT object as a single MRI extended header in accordance with aspects of the present disclosure. The example 600 shows an MoQT object 610 including a MoQT header metadata (MD) 612, at least one MoQT extension header MD 614 and a payload 616.

[0102] The header MD 612 is shown as including a value indicating a Track Alias 612a, a Group ID 612b, an optional Subgroup ID 612c, an Object ID 612d, a value indicating a Publisher Priority (i.e., 8) 612e and an extension headers Length (i.e., a nonzero length) 612f.

[0103] The MoQT extension headers MD 614 are shown as including a value indicating a Header Type 614a (which may be an odd value), a value indicating a Header Length 614b, and a Header value 614c. The Header value 614c will be described in further detail.

[0104] The Header value 614c may be serialized for example according to a commonly defined 3 GPP data container that may be reused across other MRI transport options (e.g., Connect-UDP tunnel / forward mode, UDP-options). The MRI container, referred to as the Header value serialization 620, used as a value for a common MRI MoQT extension header 614 may variably comprise a number of fields field as follows.

[0105] A Ver field 621 may be included in the serialization 620 that may be2 bits and which identifies the different formats / syntax of the bitmask field 622.

[0106] A bitmask field 622 may be included in the serialization 620 that may be 14 bits. Bit 0 masks presence of the PDU Set marking field 623. Bit 1 may mask the presence of the PDU Set Size (PSSize) field 624 encoding only when Bit 0 is set to TRUE, otherwise is encoded as 0. Bit 2 may mask the presence of number of PDUs in the PDU Set field 625only when Bit 0 is set to TRUE, otherwise is encoded as 0. Bit 3 masks the presence of the BSize field 626. Bit 4 masks the presence of TTNB field 627. Bit 5 masks the presence of ETI field 628. Bit 6-12 are spared. Bit 13 may be optionally used to extend the bitmask by one octet if additional bits are needed to mask other MRI fields, and no bits are left available in the current bitmask to do so.

[0107] The PDU Set marking field 623 may be included in the serialization 620 and may be 6 bytes. It includes an ‘E’ field, an ‘R’ field, a ‘D’ field, a ‘PSI’ field and a ‘PSSN’ field.

[0108] The PDU Set Size field 624 may be included in the serialization 620 and may be3 bytes. This field may be OPTIONAL when PDU Set marking is present.

[0109] The Number of PDUs in the PDU Set 625 may be included in the serialization 620 and may be 2 bytes. This field 625 may be OPTIONAL when PDU Set marking is present.

[0110] The BSize field 626 may be included in the serialization 620 and may be 3 bytes.

[0111] The Time-to-next-burst field 627 may be included in the serialization 620 and may be 3 bytes.

[0112] An EH 628 may also be included in the serialization 620 and may be 1 bit. Additional bits may be appended to achieve a byte-aligned representation.

[0113] With reference to Figure 6, and a particular example wherein the MoQT Object Publisher (first network entity) may map each MoQT Object 610 to a PDU Set of lower layer protocols (e.g., IP PDU Set), the MoQT Object Publisher (first network entity) may mark the PDU Set marking field 623, and optionally the PDU Set Size 624 and number of PDUs in the PDU Set field 625 in a particular manner as follows.

[0114] For the PDU Set marking field 623 the ‘E’ being 1 bit set to a value ‘ 1’ since each MoQT Object is a PDU Set at lower layers of the protocol stack and hence each PDU Set has only one MoQT Object PDU at the MoQT layer. The R’ of the field 623 being 2 bits reserved for future use that may be set to ‘O’. The ‘D’ of the field 623being 1 bit set to‘0’ since the MoQT Object Publisher (first network entity) has no absolute control of the scheduling on the wire and data burst insights at the transport protocol level, i.e., IP / UDP, but relies on the QUIC substrate for segmentation and scheduling of MoQT Objects to lower layer PDUs. The ‘PSI’ of the field 623 being 4 bits set to the value of Publisher Priority MoQT header octet right shifted by 4 with or without a non-zero offset to linearly match the 0-255 encoding of the Publisher Priority MoQT canonical header field to the 0- 15 encoding space of the PSI available for lower layer PDUs. The ‘PSSN’ of the field 623 being 6 bits set to ‘0’ since each MoQT Object is a PDU Set at lower layers of the protocol stack and hence each PDU Set has only one MoQT Object PDU at MoQT layer.

[0115] For the PS Size 62424 bits may be set to the length of the MoQT pay load, as theUPF (second network entity) in the CN will have to cache and forward the MoQT Object downstream, including potentially other rules and operations (i.e., dropping the MRI Extended Headers in downlink over N3 to RAN), and so it may determine and signal the bit-exact lower layer PDU Set size given the lower layers encapsulation (i.e., IP / UDP / QUIC / MoQT).

[0116] For the NPDS 625, 16 bits may be skipped (i.e., not present) as the UPF (second network entity) in the CN will have to cache and forward the MoQT Object downstream, including potentially other rules and operations (i.e., dropping the MRI Extended Headers in downlink over N3 to RAN), and so it may determine the number of lower layer PDUs an MoQT Object is segmented to give a path’s MTU.

[0117] In another example, the MoQT Publisher (first network entity) may mark the media payload i.e., MoQT Object, inline with multiple MoQT extension headers each corresponding to one or more fields of MRI. This separation of MRI fields into two or more MoQT extension headers may allow the MoQT Publisher (first network entity) in some examples to dynamically extend and control MRI metadata at the level of MoQT protocol, by means of separate MoQT extension headers, rather than at the level of a single common MoQT extension header encoding. Despite multiple required IANA registrations, this approach may be more scalable at MoQT protocol level where the information is being signaled than signaling of MRI over a single common MoQT extension header with extensible value.

[0118] The one or more MoQT extension headers may identify their header types, format, and semantics by a value (e.g., MRI header type = value for PDU Set marking, MRI header type = value for data burst dynamic traffic characteristics, i.e., burst size and TTNB, MRI header type = value for ETI).

[0119] An MoQT extension header may encode a single value. In such an example, the MRI header type may be even numbered, e.g., MoQT extension header of type = ‘66’, whereas the value is byte-aligned encoded as a variable integer as per QUIC variable integer encoding of RFC 9000, Section 16. An example implementation of a single value MoQT extension header may comprise the ETI identified by an even Header Type (e.g., ‘66’) with its Boolean value encoded as one-byte variable integer as ObOOOOOOOO for FALSE and ObOOOOOOOl for TRUE as per RFC 9000, Section 16. Other examples may be MoQT extension Header for BSize, or TTNB serialized as single values for instance.

[0120] An MoQT extension header may comprise an encoded value that is serialized to a particular format and semantics that may exceed 8 bytes (i.e., the upper limit of variable integer encoding of RFC 9000 used in MoQT). The header type value may be odd valued, e.g., MRI header type = ‘65’ and identify the encoding serialization format of the MoQT extension header value. The MoQT extension header value may so comprise a value field serialized to comprise information of at least one of PDU Set information, data burst dynamic traffic characteristics (e.g., BSize, end of data burst indication).

[0121] Figure 7 illustrates an example 700 of MRI marking of an MoQT object as a plurality of MoQT extension headers in accordance with aspects of the present disclosure. The example 700 shows an MoQT object 710 as comprising a header (Hdr MD) 712, MoQT extension headers 714 and a payload 716.

[0122] The header 712 includes a Track Alias 712a, a Group ID 712b, an optional Subgroup ID 712c, and Object ID 712d, a Publisher Priority 712e (i.e., a value corresponding to an unsigned 8 bit encoding) and an extension headers Length 712f (i.e., a non-zero value).

[0123] The MoQT extension headers 714 include a PDU Set Information extension header 714a, a dynamic traffic characteristics extension header 714b, an expedited transfer information extension header 714c and any other MoQT object extension headers 714d.

[0124] The PDU set information extension header 714a includes a value for header type (that may be odd numbered), a value for header length, and a header value. The header value may be serialised. The serialisation 714al for the header value may be similar to the serialisation 620 restrained to field 623 and optionally 624, 625, in the example 600 of Figure 6.

[0125] The dynamic traffic characteristics extension header 714b includes a value for header type (that may be odd numbered), a value for header length and a header value. The header value may be serialised. The serialisation 714bl for the header value may comprise reserved bits, a BSize and a TTNB.

[0126] The expedited transfer information extension header 714c includes a value for header type (which may be even numbered to indicate a single following header value) and a header value (which may be a Boolean one byte encoding.

[0127] In the example 700, the three MoQT extension headers 714a, 714b, 714c are marked by the MoQT Publisher (the first network entity) and include the PDU Set information, the data burst dynamic traffic characteristics and the ETI. Each of the MoQT Object extension headers 714a, 714b, 714c for MRI are byte-aligned. They may be signaled by an MoQT Publisher (the first network entity) in a particular order or at random within the MoQT Object extension headers 714a, 714b, 714c depending on the implementation of the MoQT Publisher (the first network entity).

[0128] The MRI fields may be marked and scoped per track based on a content creator / content provider configuration. An MRI field may be configured to the MoQT Publisher (first network entity) for a track and the MoQT Publisher (first network entity) will publish the assigned MRI fields for each object of the track. A track’s catalog information and corresponding subscription information may be updated to include the MRI fields a Subscriber should expect for the track. Depending on configuration, an MoQT Publisher (first network entity) may choose to leave out some of the MRI fields. Forexample, a service level agreement between an operator and a content producer may be in place to constrain the MoQT Publisher (first network entity) to signal only the data bursts dynamic traffic characteristics and / or Expediated Transport Indication, while leaving out the PDU Set information to be parsed by an UPF (second network entity) based on local operator configuration and implementation. In such an example, the MoQT Publisher (first network entity) will set the PDU Set information bitmask bits of Figure 6 to 0 and only set to 1 the bitmask bits corresponding to BSize, TTNB and / or ETI fields. Similarly, with reference to Figure 7, the MoQT Publisher (first network entity) will only include MoQT extension headers of Data Burst dynamic traffic characteristics 714b and / or ETI 714c, and not the MoQT extension header for PDU set information 714a.

[0129] The MoQT extension header 714 may further comprise of information fields determining dynamically the UPF (second network entity) behaviour related to caching or forwarding the content associated with the MRI. In an implementation such information fields may represent a first caching rule and a second forwarding rule for the UPF (second network entity). The forwarding rule may be associated with the forwarding of the MRI metadata comprised in the MoQT extension header to the downstream MoQT subscriber. Figure 8 illustrates an example of an MoQT extension header value 800 in accordance with aspects of the present disclosure. The MoQT extension header value 800 includes a cache rule 810 and a forwarding rule 820. The cache rule 810 may comprise a variable integer indicating the desired time duration the MoQT Object content should be cached at the UPF (second network entity). The time duration may be expressed in seconds (e.g., CacheRule = 3600 seconds). The forwarding rule 820 may be represented as an octet and encode different forwarding behaviour of the MRI metadata fields. In an example the forwarding rule 820 may be reduced to a binary indication of whether the entire MoQT extension header should be forwarded downstream (e.g., through the RAN to a UE subscriber) or not. A 0 / FALSE may indicate no forwarding of the MoQT extension header, which will be dropped at the MoQT layer in the UPF (second network entity). A 1 / TRUE may indicate forwarding of the MoQT extension header downstream (e.g., to a UE MoQT subscriber / third network entity). Other forwarding rules may be implemented, where only sections of the MoQT extension header (e.g., ETI) are forwarded downstream. The UPF (second network entity) may apply the caching and forwarding rules as indicated, given anymobile network operator constraints (e.g., caching may be capped to a cache limit when the caching rule indication in MoQT exceeds a cache limit threshold configured by the UPF operator).

[0130] The MoQT extension header may comprise further, dynamically changing information, such as application layer forward error correction (AL-FEC) redundancy ratio, or alternatively, content ratio as an AL-FEC content value. The AL-FEC content value may provide an indication of how much of the MoQT Object content (i.e., payload) is data and how much is redundancy. The AL-FEC redundancy ratio may be utilized by a MoQT relay such as a UPF (second network entity), or other AL-FEC content value aware network node, as for example the RAN (based on UPF indication of AL-FEC content value as MRI in GTP-U headers), to determine whether the MoQT Object can be reconstructed, or not, at a receiver and avoid / cancel unnecessary (or obsolete) transmissions (in case of congestion) and / or retransmissions of any packets. The AL-FEC content value may assume that the AL- FEC code used is maximum distance separable (MDS) (such as Reed-Solomon, or within an approximation Raptor / RaptorQ) and hence has guarantees of recovery if at least a deterministic number of IP PDUs corresponding to the MoQT Object are received.

[0131] The second network entity as referred to herein will now be described in greater detail. Specifically, the second network entity may be a UPF. The UPF may be configured to act as an MoQT relay that subscribes to one or more tracks of a media service / application on behalf of one or more of its subscribers (i.e., UEs / third network entity) to an MoQT Publisher (the first network entity). The tracks may be marked at least in part with MoQT extension headers (e.g., at least one of the tracks is marked) by the MoQT Publisher (first network entity).

[0132] The implementation of the second network entity (i.e., the UPF) configuration may be indicated by an SMF via N4 rules. The configuration may comprise information elements related to setting up a QoS flow associated with the MoQT Publisher (first network entity) subscription and its downstream delivery to one or more UEs (third network entities). The configuration may comprise information elements relating to detecting downstream MoQT traffic from the MoQT Publisher (first network entity), and identifying and extracting MoQT extension headers of corresponding MoQT Objects of theMRI-marked tracks. The configuration may comprise information elements relating to routing an MoQT Object’s corresponding PDUs on the established QoS flow with the QoS requirements requested on behalf of the MoQT Publisher (the first network entity or by an AF within control of the media content creator / ASP) to the RAN, the PDUs signaled in- band with MRI-derived information (e.g., MRI elements, subsets thereof, or further processed MRI elements) over the GTP-U tunnel as GTP-U headers.

[0133] The UPF (second network entity) may be indicated the MRI-marked tracks by an SMF. The SMF may indicate in PDR rules the corresponding MoQT Protocol Description, including Track Description, namely that a track contains the MoQT extension headers for MoQT. This indication may contain a simple Boolean flag, or alternatively a list of MoQT extension headers included, e.g., by their header type, and the corresponding track ID and namespace, or alternatively, track alias.

[0134] The UPF (second network entity) may alternatively not be indicated of the MRI- marked tracks by the SMF. The SMF may indicate in the PDR rules only the MoQT Protocol Description without an information element regarding the track components. In such examples, the UPF (second network entity) may be additionally enabled by the SMF to perform MoQT extension header inspection. The MoQT extension header inspection may be limited by the SMF configuration for PDR rules to a particular set of MoQT extension header type (e.g., only PDU Set information MoQT extension header, only data burst dynamic traffic characteristics MoQT extension header etc.). The UPF (second network entity), as an MoQT relay, may apply the detection and identification routine of MoQT extension headers to all tracks of an associated MoQT subscription.

[0135] The UPF (second network entity) acting as a MoQT relay applies the PDR to identify and detect MRI based on the downstream MoQT traffic. The UPF (second network entity) may cache the MoQT extension headers and their values with the MoQT Objects. In downlink over the CN, one UPF (second network entity) implementation as an MoQT relay may remove the MoQT extension headers of an MoQT Object before routing its encapsulating PDUs (i.e., IP level PDUs) to the RAN over GTP-U tunnel user plane. The detected MoQT extension headers values (e.g., PDU Set information, BSize and TTNB) arethen transmitted over the GTP-U headers of the GTP-U encapsulation of corresponding PDUs.

[0136] The UPF (second network entity) may perform the MRI identification and detection directly from the MoQT extension headers only, as configured by the SMF N4 rules comprising the PDR. The UPF (second network entity) may perform the MRI identification and detection by a combination of an MoQT extension header (e.g., for data burst dynamic traffic characteristics, ETI), and a processing of canonical MoQT Object headers (e.g., for PDU Set information).

[0137] The processing of canonical MoQT Object headers and header fields, in particular Track Alias, Group ID, Object ID, Publisher Priority, and optionally Object Payload Length, Subgroup ID, Object Status, may be mapped to PDU Set information and used to determine the PDU Set information field.

[0138] For instance, an MoQT Object may be mapped directly 1 :1 to a PDU Set.

[0139] The PSSN may be determined based on Object ID and uniquely scoped globally to the flow by extending the Object ID optionally with one or more of Subgroup ID, Group ID, and Track Alias.

[0140] The PSN determined as above, may be determined based on the QUIC short header packet number available to the UPF (second network entity) as a QUIC peer to the MoQT Publisher (first network entity); the PSI may be mapped based on the Publisher Priority field. An example linear mapping would be a right bit shift by 4 bits of Publisher Priority, i.e., dividing the Publisher Priority value by 16 to achieve a PSI mapped between 0 and 15.

[0141] The End PDU of a PDU Set may be determined by the UPF (second network entity) acting as an MoQT relay, since the entire MoQT Object and all its corresponding PDUs need to be buffered and available at once, hence marking the last PDU is possible, wherein QUIC short header packet number may be used to exactly determine the last PDU of an MoQT Object.

[0142] The PSSize may be determined by the UPF (second network entity) acting as an MoQT relay, since the entire MoQT Object and all its corresponding PDUs need to be buffered and available at once.

[0143] The MoQT Objects payload may be fully encrypted end-to-end between the first network entity such as MoQT Original Publisher (i.e., content creator / provider, such as a media application server, a peer UE acting as a publisher etc.) and a third network entity such as an MoQT End Subscriber (i.e., a content consumer, such as a peer UE acting as a subscriber). Cryptographic measures may be applied to secure the MoQT Objects payload and may be use-case specific and / or dependent upon digital rights management (DRM) procedures.

[0144] Figure 9 illustrates an example of a UE 900 in accordance with aspects of the present disclosure. The UE 900 may include a processor 902, a memory 904, a controller 906, and a transceiver 908. The processor 902, the memory 904, the controller 906, or the transceiver 908, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0145] The processor 902, the memory 904, the controller 906, or the transceiver 908, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0146] The processor 902 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 902 may be configured to operate the memory 904. In some other implementations, the memory 904 may be integrated into the processor 902. The processor 902 may be configured to execute computer-readable instructions stored in the memory 904 to cause the UE 900 to perform various functions of the present disclosure.

[0147] The memory 904 may include volatile or non-volatile memory. The memory 904 may store computer-readable, computer-executable code including instructions when executed by the processor 902 cause the UE 900 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 904 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0148] In some implementations, the processor 902 and the memory 904 coupled with the processor 902 may be configured to cause the UE 900 to perform one or more of the functions described herein (e.g., executing, by the processor 902, instructions stored in the memory 904). For example, the processor 902 may support wireless communication at the UE 900 in accordance with examples as disclosed herein. The UE 900 may be configured to be, capable of, or operable to encapsulate a payload of media data into an MoQT object PDU; determine a MRI metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0149] The controller 906 may manage input and output signals for the UE 900. The controller 906 may also manage peripherals not integrated into the UE 900. In some implementations, the controller 906 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 906 may be implemented as part of the processor 902.

[0150] In some implementations, the UE 900 may include at least one transceiver 908. In some other implementations, the UE 900 may have more than one transceiver 908. The transceiver 908 may represent a wireless transceiver. The transceiver 908 may include one or more receiver chains 910, one or more transmitter chains 912, or a combination thereof.

[0151] A receiver chain 910 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 910 may include one or more antennas for receive the signal over the air or wireless medium.The receiver chain 910 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 910 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 910 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0152] A transmitter chain 912 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 912 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 912 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 912 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0153] Figure 10 illustrates an example of a processor 1000 in accordance with aspects of the present disclosure. The processor 1000 may be an example of a processor configured to perform various operations in accordance with examples as described herein. The processor 1000 may include a controller 1002 configured to perform various operations in accordance with examples as described herein. The processor 1000 may optionally include at least one memory 1004, which may be, for example, an L1 / L2 / L3 cache. Additionally, or alternatively, the processor 1000 may optionally include one or more arithmetic-logic units (ALUs) 1006. One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).

[0154] The processor 1000 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples asdescribed herein. The processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1000) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).

[0155] The controller 1002 may be configured to manage and coordinate various operations (e.g., signalling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1000 to cause the processor 1000 to support various operations in accordance with examples as described herein. For example, the controller 1002 may operate as a control unit of the processor 1000, generating control signals that manage the operation of various components of the processor 1000. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.

[0156] The controller 1002 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1004 and determine subsequent instruction(s) to be executed to cause the processor 1000 to support various operations in accordance with examples as described herein. The controller 1002 may be configured to track memory address of instructions associated with the memory 1004. The controller 1002 may be configured to decode instructions to determine the operation to be performed and the operands involved. For example, the controller 1002 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1000 to cause the processor 1000 to support various operations in accordance with examples as described herein. Additionally, or alternatively, the controller 1002 may be configured to manage flow of data within the processor 1000. The controller 1002 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1000.

[0157] The memory 1004 may include one or more caches (e.g., memory local to or included in the processor 1000 or other memory, such RAM, ROM, DRAM, SDRAM,SRAM, MRAM, flash memory, etc. In some implementations, the memory 1004 may reside within or on a processor chipset (e.g., local to the processor 1000). In some other implementations, the memory 1004 may reside external to the processor chipset (e.g., remote to the processor 1000).

[0158] The memory 1004 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1000, cause the processor 1000 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. The controller 1002 and / or the processor 1000 may be configured to execute computer-readable instructions stored in the memory 1004 to cause the processor 1000 to perform various functions. For example, the processor 1000 and / or the controller 1002 may be coupled with or to the memory 1004, the processor 1000, the controller 1002, and the memory 1004 may be configured to perform various functions described herein. In some examples, the processor 1000 may include multiple processors and the memory 1004 may include multiple memories. One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.

[0159] The one or more ALUs 1006 may be configured to support various operations in accordance with examples as described herein. In some implementations, the one or more ALUs 1006 may reside within or on a processor chipset (e.g., the processor 1000). In some other implementations, the one or more ALUs 1006 may reside external to the processor chipset (e.g., the processor 1000). One or more ALUs 1006 may perform one or more computations such as addition, subtraction, multiplication, and division on data. For example, one or more ALUs 1006 may receive input operands and an operation code, which determines an operation to be executed. One or more ALUs 1006 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1006 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not-AND (NAND), enabling the one or more ALUs 1006 to handle conditional operations, comparisons, and bitwise operations.

[0160] The processor 1000 may support wireless communication in accordance with examples as disclosed herein. The processor 1000 may be configured to support a means for a first network entity. Specifically the processor 1000 may be configured to, capable of, or operable to cause the first network entity to encapsulate a payload of media data into an MoQT object PDU; determine a MRI metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0161] Alternatively, the processor 1000 may be configured to, operable to, or capable to encapsulate a payload of media data into an MoQT object PDU; obtain an MRI metadata for the MoQT object PDU; and output, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0162] Alternatively, the processor 1000 may be configured to, operable to or capable to support a means for a second network entity. Specifically, the processor may be configured to, capable of, or operable to receive, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determine, from the at least one MoQT extension header, the MRI metadata.

[0163] Figure 11 illustrates an example of a NE 1100 in accordance with aspects of the present disclosure. The NE 1100 may include a processor 1102, a memory 1104, a controller 1106, and a transceiver 1108. The processor 1102, the memory 1104, the controller 1106, or the transceiver 1108, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0164] The processor 1102, the memory 1104, the controller 1106, or the transceiver 1108, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or anycombination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0165] The processor 1102 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1102 may be configured to operate the memory 1104. In some other implementations, the memory 1104 may be integrated into the processor 1102. The processor 1102 may be configured to execute computer-readable instructions stored in the memory 1104 to cause the NE 1100 to perform various functions of the present disclosure.

[0166] The memory 1104 may include volatile or non-volatile memory. The memory 1104 may store computer-readable, computer-executable code including instructions when executed by the processor 1102 cause the NE 1100 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 1104 or another type of memory. Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0167] In some implementations, the processor 1102 and the memory 1104 coupled with the processor 1102 may be configured to cause the NE 1100 to perform one or more of the functions described herein (e.g., executing, by the processor 1102, instructions stored in the memory 1104). For example, the processor 1102 may support wireless communication at the NE 1100 in accordance with examples as disclosed herein. The NE 1100 may be configured to support a means for a first network entity. Specifically the NE 1100 may be configured to, capable of, or operable to encapsulate a payload of media data into an MoQT object PDU; determine a MRI metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0168] Alternatively, the NE 1100 may be configured to or operable to support a means for a second network entity. Specifically, the NE 1100 may be configured to, capable of, oroperable to receive, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determine, from the at least one MoQT extension header, the MRI metadata.

[0169] The controller 1106 may manage input and output signals for the NE 1100. The controller 1106 may also manage peripherals not integrated into the NE 1100. In some implementations, the controller 1106 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 1106 may be implemented as part of the processor 1102.

[0170] In some implementations, the NE 1100 may include at least one transceiver 1108. In some other implementations, the NE 1100 may have more than one transceiver 1108. The transceiver 1108 may represent a wireless transceiver. The transceiver 1108 may include one or more receiver chains 1110, one or more transmitter chains 1112, or a combination thereof.

[0171] A receiver chain 1110 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 1110 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 1110 may include at least one amplifier (e.g., a low-noise amplifier (LNA)) configured to amplify the received signal. The receiver chain 1110 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 1110 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0172] A transmitter chain 1112 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 1112 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 1112 may also include at least one poweramplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 1112 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0173] Figure 12 illustrates a flowchart of a method 1200 in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE or UE as described herein. In some implementations, the NE or UE may execute a set of instructions to control the function elements of the NE or UE to perform the described functions.

[0174] At 1202, the method 1200 may include encapsulating a payload of media data into an MoQT object PDU. The operations of 1202 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1202 may be performed by a UE as described with reference to Figure 9 or an NE as described with reference to Figure 11.

[0175] At 1204, the method 1200 may include determining an MRI metadata for the MoQT object PDU. The operations of 1204 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1204 may be performed by a UE as described with reference to Figure 9 or an NE as described with reference to Figure 11.

[0176] At 1206, the method 1200 may include transmitting, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata. The operations of 1206 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1206 may be performed a UE as described with reference to Figure 9 or an NE as described with reference to Figure 11.

[0177] It should be noted that the method 1200 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0178] Figure 13 illustrates a flowchart of a method 1300 in accordance with aspects of the present disclosure. The operations of the method 1300 may be implemented by a NE asdescribed herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0179] At 1302, the method 1300 may include receiving, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU. The operations of 1302 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1302 may be performed by a NE as described with reference to Figure 11.

[0180] At 1304, the method 1300 may include determining, from the at least one MoQT extension header, the MRI metadata. The operations of 1304 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1304 may be performed by a NE as described with reference to Figure 11.

[0181] It should be noted that the method 1300 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0182] Figure 14 illustrates a flowchart of a method 1400 in accordance with aspects of the present disclosure. The operations of the method 1400 may be implemented by a processor as described herein. In some implementations, the processor may execute a set of instructions to control the function elements of the processor to perform the described functions.

[0183] At 1402, the method 1400 may include encapsulating a payload of media data into an MoQT object PDU. The operations of 1402 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1402 may be performed by a processor as described with reference to Figure 10.

[0184] At 1404, the method 1400 may include obtaining an MRI metadata for the MoQT object PDU. The operations of 1404 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1404 may be performed by a processor as described with reference to Figure 10.

[0185] At 1406, the method 1400 may include outputting the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata. The operations of 1406 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1406 may be performed a processor as described with reference to Figure 10.

[0186] It should be noted that the method 1400 described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0187] A first network entity for wireless communication is described. The first network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the first network entity may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to encapsulate a payload of media data into a MoQT object PDU; determine a MRI metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0188] The ability to share MRI in-band with the media data allows core and RANs to optimize radio resource allocation and network transport. However, for MoQT the functionality in 3GPP Release-19 is restricted to the sharing of PDU set information as MRI. This tends to be prohibitive to applications that have dynamic traffic characteristics such as streaming or conversational services. By providing MRI metadata in at least one MoQT extension header, the first network entity is enabled beyond the current scope of 3GPP Release 19, to share MRI beyond only PDU set information.

[0189] By using the MoQT extension header, valuable information for handling the payload can be made visible by the first network entity for other network entities whilst keeping the media data itself secure. Furthermore, by providing the MRI metadata in the MoQT extension header (i.e., in band) the MRI metadata is made available and consumable in an efficient manner, with minimal signaling overhead, for a downstream network node i.e., a UPF, receiving the MoQT object PDU and MoQT extension header. This is because the MRI metadata can be accessed without the UPF needing to perform significantadditional processing (i.e., decoding). Accordingly, downstream delivery of the media data can be optimized even for applications with dynamic traffic characteristics.

[0190] The media data may comprise video, audio, text, and / or a binary large object (blob). The media data may comprise artificial intelligence (Al) data, for instance a multimodal Al processed media data combining one or more of video, audio, video-embeddable objects (such as pictures, animations, decorations and 2D or 3D models).

[0191] The at least one processor may be configured to cause the first network entity to receive the media data from an application. The at least one processor may be configured to encode the media data into an object such as an MoQT object. The at least one processor may be configured to cause the first network entity to mark the at least one MoQT extension header with the MRI metadata.

[0192] The MoQT extension header may be comprised in an associated MoQT PDU header.

[0193] The MRI metadata may comprise one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises Internet protocol (IP), user datagram protocol (UDP), or QUIC protocol.

[0194] The first transport protocol may be a transport protocol for a lower transport layer. The one or more attributes may be dynamic transport attributes.

[0195] The one or more transport attributes comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an ETI field; an application-layer forward error correction (AE-FEC) characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

[0196] The PDU set information field may comprise at least one of: a PSSN field; a PSN within the PDU set field; an end of data burst indication; a PDU set end marker indication; a PSI field; a PSSize field; and / or a NPDS field.

[0197] The at least one processor may be further configured to cause the first network entity to set the PDU set information field to comprise at least one of: a cyclic value between 0 and 1024 for the PSSN field, wherein the cyclic value is based on at least one of: an identifier of the MoQT object; an identifier of an MoQT group, wherein the MoQT group comprises the MoQT object; an alias of an MoQT track, wherein the MoQT track comprises the MoQT group; and / or a packet sequence number of the PDU set; a value of 0 for the PSN field; a Boolean false representation for the end of data burst indication; a Boolean true representation for the PDU set end marker indication; a linear mapping of the PSI field to a publisher priority header field of the MoQT object; a value corresponding to an object length in bytes of the MoQT object; and / or an indication that the NPDS field is missing.

[0198] The dynamic data burst traffic characteristics field may comprise at least one of: a BSize field; an upcoming BSize field; a periodicity field; a TTNB field; and / or an end of data burst indication.

[0199] The AU-FEC characteristics field may comprise at least one of: an AU-FEC content value; an AL-FEC redundancy value; an AL-FEC identifier; and / or an indication that the MoQT object PDU comprises one of a source media pay load and a redundant media payload

[0200] The AL-FEC content value may be a value determining the ratio amount of the media data to AL-FEC redundancy added. Alternatively, the AL-FEC content value may be a value determining the ratio amount of media data to the total of the media data and AL- FEC redundancy added.

[0201] The AL-FEC redundancy value may be a value determining the ratio amount of AL-FEC redundancy added to the media data. Alternatively, the AL-FEC redundancy value may be a value determining the ratio amount of AL-FEC redundancy added to the total of the media data and AL-FEC redundancy added. The AL-FEC redundancy value may be utilized by an MoQT relay, such as a UPF, or other AL-FEC aware network node, such as a RAN, to determine whether the MoQT object can be reconstructed or not at a receiver. Accordingly, unnecessary or obsolete transmissions (i.e., in case of congestion) can be avoided or cancelled.

[0202] In some examples, it may be beneficial to expose the AL-FEC information in the MRI metadata to enable optimization of routing and scheduling in congestion conditions (e.g., dropping of obsolete or redundant PDUs of the MoQT object PDU). Accordingly, the AL-FEC characteristics field may comprise an AL-FEC identifier and / or an indication that the MoQT object PDU comprises one of a source media pay load and a redundant media payload.

[0203] The at least one MoQT extension header may be a single MoQT extension header for the MoQT object PDU, wherein the single MoQT extension header comprises an extensible encoding of the MRI metadata.

[0204] The extensible encoding of the MRI metadata may comprise an extensible encoding of one or more MRI-related fields, The at least one processor may be further configured to cause the first network entity to indicate the presence of the one or more MRI-related fields by prepending a bitmask to the extensible encoding of the MRI metadata.

[0205] The single MoQT extension header may comprise an indication that the single MoQT extension header is encoded as a container, wherein the container comprises a bitmask for indicating the presence of one or more MRI metadata fields.

[0206] By indicating that the MoQT extension header is encoded / is acting as a container, the extension header may become future compatible i.e., can be extended in the future to include other semantics.

[0207] The at least one MoQT extension header may comprise a plurality of MoQT extension headers for the MoQT object PDU, the plurality of MoQT extension headers comprising the MRI metadata.

[0208] By using a plurality of MoQT extension headers, different MRI can be separated across the extension headers. This tends to allow for dynamic extension / control of MRI metadata at the level of the MoQT protocol. Such an approach tends to be more scalable at the MoQT protocol level where the information is being signaled than signaling of MRI over a single common header extension with extensible value.

[0209] The first network entity may comprise: a UE; or an application server, optionally a media application server.

[0210] The first network entity may be referred to herein as an MoQT publisher, or alternatively, MoQT original publisher.

[0211] The second network entity may comprise a UPF.

[0212] A processor for wireless communication is described. The processor may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the processor may comprise at least one controller coupled with at least one memory and configured to cause the processor to: encapsulate a payload of media data into an MoQT object PDU; obtain an MRI metadata for the MoQT object PDU; and output, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0213] A second network entity for wireless communication is described. The second network entity may be configured to, capable of, or operable to perform one or more operations as described herein. For example, the second network entity may include at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determine, from the at least one MoQT extension header, the MRI metadata.

[0214] The at least one processor may be further configured to cause the second network entity to: apply a configuration for operating as an MoQT relay, wherein the configuration is for a QoS flow having one or more QoS requirements and one or more PDR; and route over the QoS flow to a third network entity, based on the configuration, the MoQT object PDU.

[0215] The at least one processor may be further configured to cause the second network entity to: route the MoQT object PDU using a GPRS tunnelling protocol user plane (GTP-U) encapsulation protocol; and indicate to the third network entity, in a GTP-U encapsulation header, the MRI metadata.

[0216] The MRI metadata may comprise one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises IP, UDP or QUIC protocol.

[0217] The first transport protocol may be a transport protocol for a lower transport layer. The one or more attributes may be dynamic transport attributes.

[0218] The one or more transport attributes may comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an ETI field; an AL- FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

[0219] The at least one processor may be further configured to cause the second network entity to cache the MoQT object PDU based on at least one of: the media cache duration indication; the configuration; and / or a mobile network operator policy.

[0220] The at least one processor may be further configured to cause the second network entity to: publish the MoQT object PDU to a subscribed MoQT peer over the QoS flow with the third network entity; and modify or discard the MRI metadata from the MoQT Object PDU published to the subscribed MoQT peer.

[0221] The QoS flow may comprise a network connection. The first network entity may comprise a UE or an application server, optionally a media application server. The second network entity may comprise a UPF. The third network entity may comprise a different UE, or application server.

[0222] The subscribed MoQT peer may comprise the third network entity. The subscribed MoQT peer may be a peer to an MoQT relay in the second network entity. This tends to be because the subscriptions in MoQT are per hop. Generally, for examples where the second network entity is a UPF, the UPF may have two functions. A first function is connectivity, which includes general routing and user plane data transfer inside a CN. A second function is MoQT relaying and specifically the publishing of MoQT object PDUs to subscribed MoQT peers.

[0223] A method performed or performable by the first network entity is described herein. The method may comprise: encapsulating a payload of media data into an MoQT object PDU; determining a MRI metadata for the MoQT object PDU; and transmitting, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0224] The MRI metadata may comprise one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises IP, UDP, or QUIC protocol.

[0225] The one or more transport attributes may comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an ETI field; an AL- FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

[0226] The PDU set information field may comprise at least one of: a PSSN field; a PSN within the PDU set field; an end of data burst indication; a PDU set end marker indication; a PSI field; a PSSize field; and / or a NPDS field.

[0227] The method may comprise setting the PDU set information field to comprise at least one of: a cyclic value between 0 and 1024 for the PSSN field, wherein the cyclic value is based on at least one of an identifier of the MoQT object, an identifier of an MoQT group, wherein the MoQT group comprises the MoQT object, an alias of an MoQT track, wherein the MoQT track comprises the MoQT group, and / or a packet sequence number of the PDU set; a value of 0 for the PSN field; a Boolean false representation for the end of data burst indication; a Boolean true representation for the PDU set end marker indication; a linear mapping of the PSI field to a publisher priority header field of the MoQT object; a value corresponding to an object length in bytes of the MoQT object; and / or an indication that the NPDS field is missing.

[0228] The dynamic data burst traffic characteristics field may comprise at least one of: a BSize field; an upcoming BSize field; a periodicity field; a TTNB field; and / or an end of data burst indication.

[0229] The AL-FEC characteristics field may comprise at least one of: an AL-FEC content value; an AL-FEC redundancy value, an AL-FEC identifier; and / or an indication that the MoQT object PDU comprises one of a source media pay load and a redundant media payload.

[0230] The at least one MoQT extension header may be a single MoQT extension header for the MoQT object PDU, wherein the single MoQT extension header comprises an extensible encoding of the MRI metadata.

[0231] The single MoQT extension header may comprise an indication that the single MoQT extension header is encoded as a container, wherein the container comprises a bitmask for indicating the presence of one or more MRI metadata fields.

[0232] The at least one MoQT extension header may comprise a plurality of MoQT extension headers for the MoQT object PDU.

[0233] The first network entity may comprise a UE; or an application server, optionally a media application server.

[0234] The second network entity may comprise a UPF.

[0235] A method performed or performable by processor is described herein. The method may comprise: encapsulating a payload of media data into an MoQT object PDU; obtaining a MRI metadata for the MoQT object PDU; and outputting the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

[0236] A method performed or performable by a second network entity is described herein. The method may comprise: receiving, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determining, from the at least one MoQT extension header, the MRI metadata.

[0237] The method may comprise applying a configuration for operating as an MoQT relay, wherein the configuration is for a QoS flow having one or more QoS requirementsand one or more PDR; and routing over the QoS flow to a third network entity, based on the configuration, the MoQT object PDU.

[0238] The method may comprise routing the MoQT object PDU using a GTP-U encapsulation protocol; and indicating to the third network entity, in a GTP-U encapsulation header, the MRI metadata.

[0239] The MRI metadata may comprise one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises IP, UDP or QUIC protocol.

[0240] The one or more transport attributes may comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an ETI field; an AL- FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

[0241] The method may comprise caching the MoQT object PDU based on at least one of: the media cache duration indication; the configuration; and / or a mobile network operator policy.

[0242] The method may comprise publishing the MoQT object PDU to a subscribed MoQT peer over the QoS flow with the third network entity; and modifying or discarding the MRI metadata from the MoQT Object PDU published to the subscribed MoQT peer.

[0243] The disclosure herein solves the problem of signaling MRI (i.e., PDU Set information, data burst dynamic traffic characteristics, ETI) over MoQT. In 3 GPP Rel-19, UPF MoQT relaying was added as UPF capability in the CN, but the transport of MRI has been limited to just PDU Set information based only on canonical information that has been available to MoQT relays. This limitation tends to be prohibitive to applications which may not require PDU Set QoS flow handling, but may present dynamic traffic characteristics (e.g., streaming, conversational services) and could benefit from optimized transport over the CN. The PDU Set identification restriction is based insofar on canonical MoQT headers only and adds complexity with respect to UPF implementation, going beyond MoQT relay functionality and requiring MoQT PDU inspection and processing besides caching and forwarding.

[0244] The disclosure herein takes advantage of the newly introduced IETF extension headers for MoQT. These extension headers apply to the atomic MoQT transport element, i.e., the MoQT Object and allow an MoQT publisher and MoQT relays to exchange valuable information about the handling of an MoQT Object pay load, all whilst keeping the media content opaque to any nodes except the original publisher and an end subscriber. The disclosure herein provides solutions to use the MoQT extension headers as containers for transporting any MRI thus removing the current 3 GPP Rel-19 limitation to MoQT handling only PDU Set information based on canonical MoQT Object headers inspection. The proposed MoQT extension headers may require IANA registration as part of the MoQT extension headers registry.

[0245] An alternative solution to that described herein is to obtain MoQT PDU Set information from MoQT Object headers. In 3GPP Rel-19, MoQT is however limited to PDU Set information only as MRI, thus not considering other MRI such as ETI, dynamic traffic characteristics, as well as any other MRI future extensions. The 3GPP Rel-19 approach is based on inspecting the MoQT metadata (i.e., MoQT canonical header information fields) and on mapping MoQT Objects to PDU Set information. Yet, it does not specify how the other possible MRI may be determined for MoQT. Furthermore, even if PDU Set information extraction may be possible for the UPF in case of MoQT as described in 3GPP Rel-19, this comes with additional complexity requiring cross-layers (QUIC and MoQT) processing to determine and map all necessary PDU Set information from the MoQT Object canonical header. In contrast, the disclosure herein benefits over 3GPP Rel-19 since it may provide all the MRI elements readily available to the UPF at the cost of tens of bytes extra signaling per MoQT Object (which are large payloads, e.g., thousands of bytes).

[0246] Another alternative solution to that described herein is to use other generic MRI transport options. MRI transport in 3GPP Rel-19 has been standardized over different encapsulation transport protocols. One such encapsulation protocol is Connect-UDP which may handle general UDP proxying, as well as QUIC-aware proxying. To this end, MRI for MoQT may be supported by encapsulation within Connect-UDP as either UDP proxying or QUIC-aware proxying between the UPF acting as MoQT relay and the MoQT publisher.However, given typical 1500 Ethernet maximum transmission unit (MTU), this tends to add a lot of overhead and complexity compared to the solution proposed herein which operates directly atop of MoQT.

[0247] In a first example disclosed herein, the behaviour of an MoQT publisher (e.g., a UE or media AS) is described. This example details how the MoQT publisher marks MoQT Objects with MoQT extension headers. It is further discussed how the signaling of MRI as extension headers can be either: i) a single common MoQT extension header to transport a 3GPP extensible encoding of MRI; or ii). multiple MoQT extension headers (e.g., one for PDU Set marking, one for data burst dynamic traffic characteristics, one for ETI) to transport individual MRI elements such as PDU Set information, data burst dynamic traffic characteristics and ETI.

[0248] In a further example disclosed herein, the behaviour of a UPF is described. This example details the UPF acting as an MoQT relay that subscribes to an MoQT publisher which marks MRI by means of MoQT extension headers. The UPF is configured (by N4 rules PDR from a SMF) to detect and extract MRI for an IP flow comprising MoQT traffic. As an MoQT relay the UPF will operate at the MoQT layer and will readily have the information in-band with the media, i.e., MoQT Objects. The UPF caches this information with MoQT Objects and routes it to the RAN via GTP-U encapsulation. The signaling of MRI to RAN is indicated in corresponding GTP-U headers of PDUs corresponding to the MoQT Objects marked with MRI. The UPF may optimize for bandwidth by removing MoQT extension headers from MoQT Objects before publishing to the UE.

[0249] There is provided a method at a first network node, the method comprising: encoding media of an application into an object; encapsulating the object as a pay load into a MoQT Object PDU; determining for the MoQT Object PDU a MRI metadata, the MRI metadata comprising dynamic transport attributes to a set of PDUs of a first lower layer transport, the PDU set of the first lower layer PDUs comprising the MoQT Object PDU; marking the MoQT Object PDU with the MRI metadata into a MoQT extension header, the MoQT extension header comprised in the associated MoQT Object PDU header; publishing the MoQT Object PDU with the MRI metadata MoQT extension header for transmission over a network to a second network node. The first network note may comprise a UEMoQT peer or a media application server acting as an MoQT publisher. The media of the application may comprise video, audio, haptics, text, blobs, for example. The second network node may comprise a UPF in a mobile network.

[0250] The first lower layer transport protocol may be one of an IP layer; an UDP layer; a QUIC protocol layer.

[0251] The dynamic transport attributes of the MRI metadata may comprise at least one of a PDU set information field; a dynamic data burst traffic characteristics field; an ETI field; an AL-FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for MRI metadata MoQT extension header.

[0252] The PDU Set information field may further comprise at least one of a PSSN field; a PSN within the PDU set field; an end of data burst indication; a PDU set end marker indication; a PSI field; a PSSize field; and / or a NPDS field.

[0253] The method may comprise the first network node setting the PDU set information field to at least one of a cyclic value between 0 and 1024 for the PSSN, the cyclic value derived based at least on an identifier of the MoQT Object, an identifier of a MoQT Group, an alias of an MoQT Track and a packet sequence number of the first lower layer PDUs, wherein the MoQT Track comprises the MoQT Group, the MoQT Group comprises the MoQT Object; a value of 0 for the PSN; a Boolean false representation for the end of data burst indication; a Boolean true representation for the PDU set end marker; a linear mapping of the PSI field to a Publisher Priority header field of the MoQT Object; a value corresponding to an object length in bytes of the MoQT Object; and / or a skipping of NPDS field.

[0254] The dynamic data burst traffic characteristics field may comprise at least one of a BSize field; an upcoming BSize field; a periodicity field; a TTNB field; and / or an end of data burst indication.

[0255] The AL-FEC characteristics field may comprise at least one of an AL-FEC content value; and an AL-FEC redundancy value. The AL-FEC content value may be the content value determining the ratio amount of object media content to AL-FEC redundancy added, or alternatively, the ratio amount of object media content to the total object mediacontent and AL-FEC redundancy added to the object. The AL-FEC redundancy value may be the redundancy value determining the ratio amount of AL-FEC redundancy added to the object media content, or alternatively, the ratio amount of AL-FEC redundancy added to the total object media content and AL-FEC redundancy added to the object.

[0256] There is further provided a method at a second network node, the method comprising: applying a configuration to establish a QoS flow with QoS requirements and PDR, and to activate a MoQT relay capability; receiving for the QoS flow from a first network node a MoQT Object PDU, the MoQT Object PDU comprising MRI metadata in a MoQT extension header of the MoQT Object PDU, wherein the MRI metadata comprises dynamic transport attributes to a set of PDUs of a first lower layer transport, the PDU set of the first lower layer PDUs comprising the MoQT Object PDU; detecting based on the PDR the MRI metadata from the MoQT extension header; routing based on the configuration the first lower layer PDUs comprising the MoQT Object PDU to a third network node over the QoS flow in a GTP-U encapsulation protocol; indicating in a GTP-U encapsulation header to the third network node the MRI metadata corresponding to the first lower layer PDUs. The second network node may be a UPF.

[0257] The method may further comprise the second network node publishing the MoQT Object PDU to a subscribed peer over a network connection with the third network node.

[0258] The dynamic transport attributes of the MRI metadata may comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an EH field; an AL-FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for MRI metadata MoQT extension header.

[0259] The method may further comprise at least one of: discarding the MRI metadata from the MoQT Object PDU published to the subscribed peer; and modifying at least in part MRI metadata in the MoQT extension header of the MoQT Object PDU published to the subscribed peer. The modifying may comprise removing or amending.

[0260] The method may further comprise caching the MoQT Object PDU based on at least one of the media cache duration indication; the configuration to establish the QoS flow with QoS requirements and PDR; and a mobile network operator policy.

[0261] The first lower layer transport protocol may comprise one of an IP layer; an UDP layer; a QUIC protocol layer.

[0262] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0263] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.

[0264] The following abbreviations are relevant in the field addressed by this document: 3GPP, 3rd generation partnership project; 5G, fifth generation; 5GS, 5G System; 5QI, 5G QoS Identifier; AF, application function; AMF, access and mobility function; AR, augmented reality; AS, application server; DL, downlink; NAL, network abstraction layer; PCF, policy control function; PDU, packet data unit; PPS, picture parameter set; QoE, quality of experience; QoS, quality of service; RAN, radio access network; RTCP, realtime control protocol; RTP, real-time protocol; SDAP, service data adaptation protocol; SMF, session management function; SRTCP, secure real-time control protocol; SRTP, secure real-time protocol; UE, user equipment; UL, uplink; UPF, user plane function; VCL, video coding layer; VMAF, video multi-method assessment function; VPS, video parameter set; VR , virtual reality; XR, extended reality; XR AS, XR application server; and XRM, XR media.

Claims

CLAIMSWhat is claimed is:

1. A first network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the first network entity to: encapsulate a payload of media data into a media over QUIC transport ‘MoQT’ object protocol data unit ‘PDU’; determine a media related information ‘MRI’ metadata for the MoQT object PDU; and transmit, to a second network entity, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

2. The first network entity of claim 1 , wherein the MRI metadata comprises one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises Internet protocol ‘IP’, user datagram protocol ‘UDP’, or QUIC protocol.

3. The first network entity of claim 2, wherein the one or more transport attributes comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an expedited transfer indication field; an application-layer forward error correction ‘AL-FEC’ characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

4. The first network entity of claim 3, wherein the PDU set information field comprises at least one of:a PDU set sequence number ‘PSSN’ field; a PDU sequence number ‘PSN’ within the PDU set field; an end of data burst indication; a PDU set end marker indication; a PDU set importance ‘PSI’ field; a PDU set size field; and / or a number of PDUs in the PDU set ‘NPDS’ field.

5. The first network entity of claim 4, wherein the at least one processor is further configured to cause the first network entity to set the PDU set information field to comprise at least one of: a cyclic value between 0 and 1024 for the PSSN field, wherein the cyclic value is based on at least one of: an identifier of the MoQT object; an identifier of an MoQT group, wherein the MoQT group comprises the MoQT object; an alias of an MoQT track, wherein the MoQT track comprises the MoQT group; and / or a packet sequence number of the PDU set; a value of 0 for the PSN field; a Boolean false representation for the end of data burst indication; a Boolean true representation for the PDU set end marker indication; a linear mapping of the PSI field to a publisher priority header field of the MoQT object; a value corresponding to an object length in bytes of the MoQT object; and / or an indication that the NPDS field is missing.

6. The first network entity of any one of claims 3-5, wherein the dynamic data burst traffic characteristics field comprises at least one of: a data burst size field; an upcoming data burst size field;a periodicity field; a time to next burst field; and / or an end of data burst indication.

7. The first network entity of any one of claims 3-6, wherein the AL-FEC characteristics field comprises at least one of: an AL-FEC content value; an AL-FEC redundancy value; an AL-FEC identifier; and / or an indication that the MoQT object PDU comprises one of a source media payload and a redundant media payload8. The first network entity of any one of the preceding claims, wherein the at least one MoQT extension header is a single MoQT extension header for the MoQT object PDU, wherein the single MoQT extension header comprises an extensible encoding of the MRI metadata.

9. The first network entity of claim 8, wherein the single MoQT extension header comprises an indication that the single MoQT extension header is encoded as a container, wherein the container comprises a bitmask for indicating the presence of one or more MRI metadata fields.

10. The first network entity of any one of claims 1 -7, wherein the at least one MoQT extension header comprises a plurality of MoQT extension headers for the MoQT object PDU, the plurality of MoQT extension headers comprising the MRI metadata.

11. The first network entity of any one of the preceding claims, wherein the first network entity comprises: a user equipment ‘UE’; or an application server, optionally a media application server.

12. The first network entity of any one of the preceding claims, wherein the second network entity comprises a user plane function ‘UPF’.

13. A processor for wireless communication, comprising: at least one controller coupled with at least one memory and configured to cause the processor to: encapsulate a pay load of media data into an MoQT object PDU; obtain an MRI metadata for the MoQT object PDU; and output, the MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises the MRI metadata.

14. A second network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the second network entity to: receive, from a first network entity, an MoQT object PDU with at least one MoQT extension header, wherein the at least one MoQT extension header comprises MRI metadata of the MoQT object PDU; and determine, from the at least one MoQT extension header, the MRI metadata.

15. The second network entity of claim 14, wherein the at least one processor is further configured to cause the second network entity to: apply a configuration for operating as an MoQT relay, wherein the configuration is for a quality of service ‘QoS’ flow having one or more QoS requirements and one or more packet detection rules ‘PDR’; and route over the QoS flow to a third network entity, based on the configuration, the MoQT object PDU.

16. The second network entity of claim 15, wherein the at least one processor is further configured to cause the second network entity to:route the MoQT object PDU using a GPRS tunnelling protocol user plane ‘GTP-U’ encapsulation protocol; and indicate to the third network entity, in a GTP-U encapsulation header, the MRI metadata.

17. The second network entity of any one of claims 14-16, wherein the MRI metadata comprises one or more transport attributes for a PDU set of a first transport protocol, wherein the PDU set comprises the MoQT object PDU, wherein the first transport protocol optionally comprises IP, UDP or QUIC protocol.

18. The second network entity of claim 17, wherein the one or more transport attributes comprise at least one of: a PDU set information field; a dynamic data burst traffic characteristics field; an expedited transfer indication field; an AU-FEC characteristics field; a media cache duration indication; and / or a set of forwarding rules for the at least one MoQT extension header.

19. The second network entity of claim 18, wherein the at least one processor is further configured to cause the second network entity to cache the MoQT object PDU based on at least one of: the media cache duration indication; the configuration; and / or a mobile network operator policy.

20. The second network entity of any one of claims 14-19, wherein the at least one processor is further configured to cause the second network entity to: publish the MoQT object PDU to a subscribed MoQT peer over the QoS flow with the third network entity; andmodify or discard the MRI metadata from the MoQT Object PDU published to the subscribed MoQT peer.

Images