



moq                                                          Y. Yue, Ed.
Internet-Draft                                                F. Li, Ed.
Intended status: Standards Track                             W. Liu, Ed.
Expires: 4 January 2026                                     China Unicom
                                                            C. Yang, Ed.
                                                        A. Akhavain, Ed.
                                                           K. Zhang, Ed.
                                           Huawei Technologies Co., Ltd.
                                                             3 July 2025


      Challenges in Transporting Sensing Data with Media Over QUIC
               draft-yue-moq-transporting-sensing-data-02

Abstract

   This document proposes leveraging Media Over QUIC (MOQ) to address
   the challenges of transmitting large-scale, real-time sensing data in
   6G networks.  By building on QUIC's low-latency and multiplexing
   capabilities, MOQ offers a flexible and efficient transport mechanism
   tailored to the dynamic and high-throughput requirements of 6G
   environments.  The approach focuses on enabling protocol adaptability
   across diverse application scenarios such as autonomous driving,
   smart cities, and industrial IoT, while ensuring efficient data
   fragmentation, secure and anonymous transmission, and end-to-end QoS
   awareness.  Through information-aware endpoints and optimized data
   delivery mechanisms, this solution supports scalable, reliable, and
   intelligent sensing data distribution in next-generation wireless
   networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 4 January 2026.





Yue, et al.              Expires 4 January 2026                 [Page 1]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Autonomous Vehicles . . . . . . . . . . . . . . . . . . .   4
     3.2.  Smart Cities  . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Industrial IoT  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Multi-Scenario Applicability  . . . . . . . . . . . . . .   5
     4.2.  Efficient Data Transmission . . . . . . . . . . . . . . .   5
     4.3.  Anonymity . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Data Security . . . . . . . . . . . . . . . . . . . . . .   6
     4.5.  Traceability  . . . . . . . . . . . . . . . . . . . . . .   6
     4.6.  Information Awareness . . . . . . . . . . . . . . . . . .   6
   5.  MoQ Protocol Enhancements for Sensing Data Transport  . . . .   6
     5.1.  Conceptual Object Format with Metadata Extension  . . . .   6
     5.2.  Extended Metadata Fields  . . . . . . . . . . . . . . . .   7
       5.2.1.  Network Information . . . . . . . . . . . . . . . . .   8
       5.2.2.  Service and Task Context  . . . . . . . . . . . . . .   8
       5.2.3.  QoS Information . . . . . . . . . . . . . . . . . . .   9
     5.3.  Protocol Behavior Enhancements  . . . . . . . . . . . . .   9
       5.3.1.  Control-Plane Coordination  . . . . . . . . . . . . .   9
       5.3.2.  Failure Feedback Mechanisms . . . . . . . . . . . . .  10
   6.  Requirement . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Protocol Flexibility for Multi-Scenario Support . . . . .  10
     6.2.  Efficient Data Fragmentation and Multiplexing . . . . . .  10
     6.3.  Interoperability and Scalability (for QUIC) . . . . . . .  10
     6.4.  Network information awareness . . . . . . . . . . . . . .  10
     6.5.  QoS information awareness . . . . . . . . . . . . . . . .  10
     6.6.  Service information awareness . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10



Yue, et al.              Expires 4 January 2026                 [Page 2]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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

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








Yue, et al.              Expires 4 January 2026                 [Page 3]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

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

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

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









Yue, et al.              Expires 4 January 2026                 [Page 4]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


4.  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:

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

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

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











Yue, et al.              Expires 4 January 2026                 [Page 5]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

4.5.  Traceability

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

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

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

5.1.  Conceptual Object Format with Metadata Extension

   The following diagram illustrates a conceptual format for a MoQ
   object with enhanced metadata fields for sensing applications:






Yue, et al.              Expires 4 January 2026                 [Page 6]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


      +-------------------------------+
      |       MoQ Object Header       |
      +-------------------------------+
      |  - Object Name                |
      |  - Object Type                |
      |  - Duration (optional)        |
      |  - Group ID / Track ID        |
      +-------------------------------+
      |  Extended Metadata Header     |
      +-------------------------------+
      |  - Metadata Type (e.g., TLV)  |
      |  - Length                     |
      +-------------------------------+
      |           Data Info           |
      |  - Data Name                  |
      |  - Data Feature               |
      |  - Semantics Token            |
      |  - Data Representation        |
      |  - Data Hash                  |
      +-------------------------------+
      |         Network Info          |
      |  - Network ID (PLMN ID)       |
      |  - Cell ID                    |
      |  - Node ID                    |
      |  - Tracking Area Code         |
      |  - Sensing Region ID          |
      +-------------------------------+
      |        Service Info           |
      |  - XaaS Service ID            |
      |  - Task ID                    |
      |  - Mission ID                 |
      |  - SFC ID                     |
      +-------------------------------+
      |          QoS Info             |
      |  - QoS Identifier (QI)        |
      |  - Timestamp                  |
      +-------------------------------+
      |          Payload              |
      |      (Encrypted Data)         |
      +-------------------------------+

5.2.  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:



Yue, et al.              Expires 4 January 2026                 [Page 7]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

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

5.2.2.  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:





Yue, et al.              Expires 4 January 2026                 [Page 8]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

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

5.3.  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:

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








Yue, et al.              Expires 4 January 2026                 [Page 9]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

6.  Requirement

6.1.  Protocol Flexibility for Multi-Scenario Support

   TBD

6.2.  Efficient Data Fragmentation and Multiplexing

   TBD

6.3.  Interoperability and Scalability (for QUIC)

   TBD

6.4.  Network information awareness

   TBD

6.5.  QoS information awareness

   TBD

6.6.  Service information awareness

   TBD

7.  Security Considerations

   TBD

8.  IANA Considerations

   TBD

9.  References

9.1.  Normative References







Yue, et al.              Expires 4 January 2026                [Page 10]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


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

9.2.  Informative References

   [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-12, 23 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
              transport-12>.

   [I-D.lcurley-moq-use-cases]
              Curley, L., "Media over QUIC - Use Cases", Work in
              Progress, Internet-Draft, draft-lcurley-moq-use-cases-00,
              16 January 2025, <https://datatracker.ietf.org/doc/html/
              draft-lcurley-moq-use-cases-00>.

Authors' Addresses

   Yi Yue (editor)
   China Unicom
   Beijing
   China
   Email: yuey80@chinaunicom.cn


   Feile Li (editor)
   China Unicom
   Beijing
   China
   Email: lifl100@chinaunicom.cn


   Wei Liu (editor)
   China Unicom
   Beijing
   China
   Email: liuw550@chinaunicom.cn






Yue, et al.              Expires 4 January 2026                [Page 11]

Internet-Draft   Challenges in Transporting Sensing Data       July 2025


   Chenchen Yang (editor)
   Huawei Technologies Co., Ltd.
   Shanghai
   China
   Email: yangchenchen7@huawei.com


   Arashmid Akhavain (editor)
   Huawei Technologies Co., Ltd.
   Ottawa
   Canada
   Email: arashmid.akhavain@huawei.com


   Kuan Zhang (editor)
   Huawei Technologies Co., Ltd.
   Shanghai
   China
   Email: zhangkuan3@huawei.com
































Yue, et al.              Expires 4 January 2026                [Page 12]
