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) , 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 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 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.

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 or through the definition of new structured metadata elements: ### Data Information Metadata related to the content and identity of the sensing data: (1) data_keyword: Keywords or descriptors representing data semantics. (2) data_feature: Characteristics such as modality or format. (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 for 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) XaaS_service_id: Identifies the XaaS (Anything-as-a-Service) instance to which the data is related. For example, data may be used by an AI service, sensing service, AR 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 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 computation, or end-to-end latency requirements (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.

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 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 for the required sensing data stream, the protocol should support mechanisms to notify upstream orchestration entities or the control plane for further resolution or dynamic redirection.

Requirement

Protocol Flexibility for Multi-Scenario Support TBD

Efficient Data Fragmentation and Multiplexing TBD

Interoperability and Scalability (for QUIC) TBD

Network information awareness TBD

QoS information awareness TBD

Service information awareness TBD

Security Considerations TBD

IANA Considerations TBD