Challenges in Transporting Sensing Data with Media Over QUIC

Introduction With the advent of 6G networks, there is an exponential increase in the volume and diversity of data generated by connected devices, sensors, and applications. This data, known as "sensing data," encompasses a wide range of information, including environmental, contextual, and behavioral data that can be leveraged for various advanced applications like autonomous driving, smart cities, and industrial IoT. However, transmitting this sensing data efficiently in a 6G environment poses a significant challenge due to its large volume, distributed and massive number of sources , dynamic nature, and stringent real-time requirements. Media Over QUIC (MOQ) [I-D.ietf-moq-transport], a protocol designed to enable efficient media transport over QUIC, presents a promising solution for addressing these challenges. QUIC, being a modern transport protocol, provides low-latency, multiplexed connections with enhanced congestion control, making it well-suited for real-time communication in dynamic networks. MOQ builds on QUIC's capabilities to offer a robust and flexible framework for the high-throughput and low-latency transmission of multimedia data. This document explores how MOQ can be leveraged to efficiently transmit sensing data in 6G networks, focusing on its potential to handle the unique requirements of real-time, high-volume data streams while ensuring reliability, scalability, and low overhead. The use of MOQ for data transport in this context can significantly improve the user experience and enable innovative services in next-generation wireless communication networks.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Abbreviations and definitions used in this document: *MOQ: Media Over QUIC *V2V: Vehicle-to-Vehicle. *P2P: Point-to-Point

Use Cases [I-D.lcurley-moq-use-cases] defines several use cases for MOQ, while this document focuses on MOQ use cases in the context of sensing data transmission.

Autonomous Vehicles Autonomous vehicles rely on real-time sensing data from onboard sensors (e.g., LiDAR, cameras) and external sources (e.g., traffic signals, nearby vehicles). MOQ facilitates the efficient and reliable transmission of this data in the following ways: 1. Vehicle-to-Vehicle (V2V) Communication: MOQ over QUIC establishes low-latency, multiplexed streams between vehicles, enabling the exchange of situational data like location, speed, and hazards in real-time. 2. Data Prioritization: High-priority sensing data, such as collision warnings, is tagged for immediate transmission, while less critical data, like traffic updates, is sent with lower priority to optimize bandwidth.

Smart Cities Smart cities generate diverse types of sensing data from devices such as traffic cameras, pollution monitors, and utility sensors. MOQ enhances urban management through: 1. Adaptive Data Aggregation: Sensors stream data to edge servers via MOQ's multiplexed connections, which dynamically adapt to varying link conditions to prevent packet loss during congestion. 2. Real-Time Event Streaming: For critical events (e.g., emergencies or system failures), MOQ ensures prioritized and low-latency delivery of sensor data to central control systems or cloud platforms for immediate response.

Industrial IoT Factories equipped with IoT sensors require reliable, low-latency communication to monitor and optimize operations. MOQ supports industrial IoT through: 1. Real-Time Monitoring: MOQ streams sensor data such as vibration or temperature directly to monitoring systems, ensuring fast anomaly detection and response. 2. Redundant Transmission: For critical sensing data, MOQ can enable redundant streams over QUIC to ensure delivery even under adverse network conditions.

Problem Statement The application of Media Over QUIC (MOQ) for transmitting sensing data in 6G networks presents several key challenges that must be addressed to ensure its feasibility and effectiveness. These challenges are as follows:

Multi-Scenario Applicability Sensing data in 6G networks is generated in diverse scenarios, ranging from autonomous vehicles to smart cities and industrial IoT. Each scenario imposes unique requirements on the transport protocol, such as varying latency, throughput, and reliability demands. These use cases may involve real-time synchronous or asynchronous data transmission, as well as point to point (P2P) or multi-point communication modes. Ensuring that MOQ can adapt to these diverse requirements without compromising performance or introducing overhead remains a significant challenge , e.g., how to differentiate transmissions of sensing data flows with varying demands.

Efficient Data Transmission The sheer volume and velocity of sensing data in 6G networks necessitate highly efficient transport mechanisms. MOQ must address issues such as reducing overhead for small and frequent data packets, optimizing transmission for bursty data patterns, and ensuring low-latency delivery even under high traffic loads. Balancing efficient utilization of network resources while maintaining robust performance is critical. Avoid redundant data collection and transmission, e.g., to cache data on demand.

Anonymity In applications such as smart cities and industrial IoT, sensing data often includes sensitive or identifiable information. Ensuring anonymity during transmission is essential to protect user privacy and comply with regulatory requirements. MOQ must integrate mechanisms to obscure identifying information in data streams while maintaining the integrity and usability of the transmitted data. Data sources and data consumers are not aware of each other.

Data Security Sensing data in 6G networks is often critical to the operation of real-time systems, making it a prime target for cyber threats such as interception, tampering, and unauthorized access. MOQ must incorporate advanced security measures to guarantee the confidentiality, integrity, and authenticity of data in transit. Additionally, the protocol must address the challenge of securely transmitting data in dynamic and heterogeneous network environments, including cross-domain communication. Data payload is visible only to data sources and data consumers, and is invisible to intermediate nodes. The payload needs to be encrypted.

Traceability Sensing data logs can be recorded, and data collection and consumption history is traceable.

Information Awareness MOQ endpoints should be aware of key contextual information related to sensing data to enable efficient and intelligent data distribution. This includes: 1. Network Awareness: The MOQ endpoint should have knowledge of network-related sensing data, such as cell or sensing area information, to optimize data distribution decisions. 2. QoS Awareness: MOQ should ensure QoS guarantees for the collection and transmission of sensing data, adjusting delivery mechanisms accordingly. Service Awareness: The MOQ endpoint should identify the intended service or application utilizing the sensing data. This enables proper classification, retrieval, and provisioning of sensing data to authorized services.

Multi‑Source Federation & Scale Sensing in future networks is expected to involve a large number of distributed and heterogeneous sources, such as base stations, user devices, roadside units, and access points. Each source may produce sensing data of different types and at different temporal or spatial resolutions. When combined across diverse sensing tasks and use cases, the overall volume of generated data can become massive. Managing such a distributed and data-intensive environment raises challenges in terms of scalability, coordination, and resource efficiency. Multiple sensing entities may observe overlapping environments, leading to redundant or partially correlated information. Without mechanisms to coordinate data generation and dissemination, the resulting data traffic can impose significant load on transport infrastructure. Therefore, scalability in sensing networks is not only a matter of bandwidth or throughput but also of how effectively information from numerous and diverse sources can be collected, organized, and made available to the entities that need it. This requires careful consideration of data distribution principles that can operate efficiently under high source/destination density and dynamic network conditions.

Publish-subscribe mechanism for data distribution

Why Pub-Sub and MoQ for Data Distribution Large-scale sensing deployments, such as those envisioned for next-generation networks [3GPP.SA2.6G.SID], [3GPP.22.137], [3GPP.22.870], [ETSI.GRISC.001], can produce an immense and continuous flow of heterogeneous information ranging from assistance data, sensing measurements to sensing data, both attached with metadata, to sensing results that has contextual information attached. When multiple sensing use cases operate concurrently, for example, object tracking, localization, and environmental monitoring, the aggregate volume of information can become substantial. Using traditional web-based client-server application and point-to-point transport protocols to move such heterogeneous information across a mobile network, risks creating severe networking and processing bottlenecks. Furthermore, the heterogenous information comes with severely different quality of service (QoS) requirements when being exchanged between two endpoints in the mobile network, with those endpoints possible to change at any point in time due to the mobile nature of terminals. Existing protocols generally require dedicated sessions per source or per consumer, leading to duplicated transmissions, inefficient resource use, and reduced timeliness as the system scales and the same set of information from a single source is required at different destinations, e.g. allowing multiple instances at different parts of the mobile network to process information to identify the most reliable and accurate result. To address these scalability and dynamism challenges, a publish/subscribe information distribution model is more suitable. It decouples data producers and consumers, allowing information generated by many sensing entities to be distributed flexibly and efficiently to multiple analytics or network/application functions without maintaining direct session state between every pair. Such a model enables aggregation, filtering, and routing of sensing information according to spatial, temporal, or service-level needs, significantly improving scalability and resilience. Within the IETF, the Media over QUIC Transport (MOQT) protocol provides a foundation for realizing such an efficient, object-oriented, and real-time publish/subscribe distribution system. MOQT builds upon QUIC’s secure, congestion-controlled transport and introduces mechanisms for scalable dissemination of time-sensitive data. Its general design principles – publisher – subscriber decoupling, adaptive data delivery, and relay-based distribution, align well with the characteristics of sensing data and the need to serve multiple simultaneous use cases in a resource-efficient manner. In summary, adopting a publish/subscribe distribution approach, supported by technologies such as MOQ, offers a path to transport sensing information at scale while maintaining efficiency, flexibility, and timeliness across diverse sensing applications.

Benefits of Pub-Sub Mechanism for Data Distribution

Flexible and scalable: applicable to Point to point/Multi-points data distribution, real-time synchronous or asynchronous data transmission,
Efficient data distribution: any of the on-path Data Proxies can cache/store data, to avoid redundant data collection and transmission.
Data privacy and security: Data payload is visible only to data sources and data consumers, and is invisible to Data-Proxy.

Pub-Sub Flows for Data Distribution To support multi-scenario applicability of 6G system data (e.g., sensing data) distribution, aspects such as Network topology and transmission requirement should be taken into consideration: 1. Network topology: Providers and consumers of 6G system data (e.g., sensing data) are highly distributed in 6G network. P2P data distribution and point to multi-points (P2MP) data distribution are coexisted. 2. Transmission requirement: Different scenarios impose unique requirements in data sensing transmission, such as varying latency and throughput, real-time synchronous and asynchronous etc. Even the same data source might be consumed in different requirements by consumers. Due to these these aspects, a publish/subscribe information model is required. The publish/subscribe topology is illustrated in the figure below: | Data |----------------------+ | Data +-->--| proxy2|-->--+ Data | | session/ +-------+ \ session | | / | ^ \ | | Pub (2) Sub | | Sub (3) Pub | | / | | \ | | / | | \ | | / | | \ | | +-------+ | | +-------+ | +----| Data |<--------+ +------------| Data |<---+ +--------->| proxy1|--+ +---------------->| proxy3|---------------+ | +-------+ | | +---<---+-------+--->---+ | | | | | | | ^ | | | Pub (1) Sub | | Sub | Pub | | Sub | Pub | | | | | (4.1) | | (4.2) | | ^ | | | | | | | | Data| | | Data| | | Data | | | session| | | session| | | session| | | | | | | | | | | | | | | | | | | | | +------------+ | | +------------+ | | +------------+ | +---| Data |<---+ +--| Data |<--+ +--| Data |<-+ | provider 1 | | consumer 1 | | consumer 2 | | +------------+ +------------+ +------------+ ^ | | +------------+ | +----| Data |<-----+ Pub | provider 2 | Sub +------------+ ]]> In this figure, data proxies act as MoQ relays, data providers are original publishers of data (e.g., sensing data) and consumers are end subscribers requesting for data.

Data Publish Flows

Data providers (e.g., Data provide 1&2) publish metadata (e.g., sensing metadata) of 6G system data to upstream data proxies (e.g., Data-proxy 1) based on the MoQ publish mechanism and procedure. The data proxies can be new type of logical endpoints or other data providers or consumers. This metadata may include non-exhaustively: data information, network information, service information and QoS information (refer to descriptions in following sections).
The upstream data proxies active as publishers can continue publish metadata of 6G system data to their upstream endpoints (e.g., Data proxy 2). Considering that different endpoints may have different capabilities and network contextual status, the published information by upstream endpoints (e.g., Data proxy 2) might be different from the original data provider’s. Moreover, the upstream endpoints (e.g., Data-proxies) may perform some data processing actions (e.g., data cleaning, data filtering, data aggregation, data anonymization) before publish.
The metadata (e.g., sensing metadata) of 6G system data are published hop by hop to related upstream data proxies and/or data consumers, e.g., by specific policy.

Data Subscribe Flows After the publish process,

Data Consumer (e.g., sensing data consumer 1) active as Original Subscriber sends MoQ subscribe messages to its downstream endpoint (e.g., Data-proxy 3). The data consumer may select one of connected Data-proxies based on its specific demand on 6G system data (e.g., sensing data) and sends subscribe message.
Once the downstream endpoint (e.g., Data-proxy 3) receive the subscribe message, it will check whether there is available data (e.g., caching data), if there is, the downstream endpoint can send the available data to he Data Consumer; otherwise, the downstream endpoint will send MoQ subscribe messages to its downstream endpoints (e.g., Data-proxy 2) and so forth until the available data is found. For example, the available data is found from Data Provider 1.
A data session (consisting of MoQ session) can be established between the Data Provider 1 and the Data Consumer.
It is possible that more than one Data Consumers (e.g., Data Consumer 1 and 2 as in the figure) request the same data. The Data-proxy (e.g., Data-proxy 3) can collect data only once from Data Provider (e.g., data provider 1) and replicates the data to the Data consumers respectively. It can reduce redundancy of data collection and data delivery. Moreover, the Data Proxy can cache the collected data if necessary for further requests (e.g., other data consumers' requests for the same data).

MoQ Protocol Enhancements for Sensing Data Transport To support the efficient and intelligent transmission of sensing data in 6G environments, enhancements to the MoQ protocol are proposed. These enhancements aim to enrich MoQ metadata or header extensions to include key information required for intelligent routing, data classification, service mapping, and QoS-aware scheduling in sensing-centric applications.

Conceptual Object Format with Metadata Extension The following diagram illustrates a conceptual format for a MoQ object with enhanced metadata fields for sensing applications:

Extended Metadata Fields The following categories of metadata are recommended to be included in MoQ object headers or extension fields, either through expansion of the existing metadata field (e.g., the new information are some bits of the existing metadata fields) or through the definition of new metadata elements:

Data Information Metadata related to the content and identity of the sensing data: (1) data_keyword: Keywords or descriptors representing data semantics of content. (2) data_feature: Characteristics such as modality, format or other attributes. (3) data_representation: Encoding type (e.g., JSON, CBOR, binary). (4) data_name: Human-readable or system-assigned identifier. (5) semantics: Token-level annotations describing data meaning. (6) hash: Hash value of content, e.g., for indexing or integrity verification.

Network Information Network-related metadata used to describe the contextual origin or association of the data. One or more of the following fields may be included: (1) network_id (e.g., PLMN ID): Identifies the network to which the data belongs. This may refer to the network in which the data was collected or published, the network the data describes, or the network in which the sensing node resides. (2) cell_id: Identifies the cell associated with the data. This may refer to the cell where the data was collected or published, the cell the data is about, or the cell in which the sensing node resides. (3) node_id: Identifies the network node associated with the data. This may be the node that collected or published the data, or the node the data describes. (4) tracking_area_code (TAC): Identifies the tracking area to which the data belongs. This may refer to the area where the data was collected/published, the area the data is about, or the area in which the relevant node resides. (5) sensing_region_id: Identifies the sensing region associated with the data. This may refer to the region where the data was collected, the region being sensed, the region where the sensing node resides, or the region where the sensed object is located.

Service and Task Context Metadata describing the service or task context associated with the data. One or more of the following fields may be included: (1) service_id: Identifies the service to which the data is related. For example, it indicates that data can be used by an AI service, sensing service, XR service, etc. (2) task_id: Identifies a specific task that processes the data. A task may include AI model training, inference, data preprocessing, data analysis, privacy-preserving operations, or data distribution. (3) mission_id: Identifies a task group (or job), which consists of multiple tasks that are executed in a predefined sequence (e.g., sequential or parallel). The data is used as input for this mission. (4) sfc_id: Identifies a Service Function Chain (SFC). The data is used for processing through the corresponding service function chain.

QoS Information Metadata related to the quality of service requirements for the data. One or more of the following fields may be included: (1) QI (QoS Identifier): Represents a QoS class or profile, which may imply specific parameters such as maximum delay budget for processing, or end-to-end latency requirements (e.g., including both transmission and processing delays). (2) timestamp: Indicates the time at which the data was generated by the source or forwarded by an intermediate node. This can be used to calculate end-to-end latency or time spent in transit. The timestamp may be provided at different granularity levels, such as per object, group, or track. (3) data quality: identify quality metrics on data itself, e.g., accuracy, completeness, reliability, redundancy, bias, source reliability, and integrity. (4) data transmission QoS: Indicates QoS requirement (e.g., delay) on data transmission. (5) data processing QoS: Indicates QoS requirement (e.g., delay, accuracy) on data processing, e.g., data cleaning, data anonymization, data analysis, or data generation.

Protocol Behavior Enhancements In addition to metadata enrichment, certain behavioral extensions are necessary when applying MoQ to sensing applications, especially when operating at the user plane (UP) or data plane in 6G architectures:

Control Plane Coordination MoQ endpoints deployed in sensing environments may require dynamic interaction with the control plane to receive configuration parameters, access control policies, and data routing instructions. This includes the ability to register interests or capability to control plane, or notify the control plane upon data path failures or when requested publishers are not found.

Failure Feedback Mechanisms In cases where a MoQ subscriber is unable to locate a publisher (e.g., within limited time or hops) for the required sensing data, the protocol should support mechanisms to notify upstream orchestration entities or the control plane for further resolution or dynamic path redirection and publisher reselection.

Security Considerations TBD

IANA Considerations TBD

References

Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

Informative References

[3GPP.22.870] 3GPP TR22.870, "Study on 6G Use Cases and Service Requirements", https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4374.
[I-D.ietf-moq-transport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-14, 2 September 2025, https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-14.
[I-D.lcurley-moq-use-cases] Curley, L., "Media over QUIC - Use Cases", Work in Progress, Internet-Draft, draft-lcurley-moq-use-cases-01, 22 July 2025, https://datatracker.ietf.org/doc/html/draft-lcurley-moq-use-cases-01.
[3GPP.SA2.6G.SID] 3GPP SP-250806, "Study on Architecture for 6G System".
[3GPP.22.137] 3GPP TS22.137, "Service requirements for Integrated Sensing and Communication", https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=4198.
[ETSI.GRISC.001] ETSI ISAC ISG, "ISAC; Generic reference architecture for Integrated Sensing And Communications (ISAC)," ETSI GR ISC 001 - V1.1.1, 2025, https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/gr_isc001v010101p.pdf.