



moq                                                          Y. Yue, Ed.
Internet-Draft                                                F. Li, Ed.
Intended status: Standards Track                             W. Liu, Ed.
Expires: 22 April 2026                                      China Unicom
                                                            C. Yang, Ed.
                                                        A. Akhavain, Ed.
                                                           K. Zhang, Ed.
                                           Huawei Technologies Co., Ltd.
                                                          M. Jadoon, Ed.
                                                       S. Robitzsch, Ed.
                                                InterDigital Europe Ltd.
                                                         19 October 2025


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

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.  It is also available to other types of 6G System Data
   [3GPP.22.870] besides sensing data, e.g., AI data, positioning data.

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



Yue, et al.               Expires 22 April 2026                 [Page 1]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   This Internet-Draft will expire on 22 April 2026.

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
     4.7.  Multi-Source Federation & Scale . . . . . . . . . . . . .   6
   5.  Publish-subscribe mechanism for data distribution . . . . . .   7
     5.1.  Why Pub-Sub and MoQ for Data Distribution . . . . . . . .   7
     5.2.  Benefits of Pub-Sub Mechanism for Data Distribution . . .   8
   6.  Pub-Sub Flows for Data Distribution . . . . . . . . . . . . .   8
     6.1.  Data Publish Flows  . . . . . . . . . . . . . . . . . . .   9
     6.2.  Data Subscribe Flows  . . . . . . . . . . . . . . . . . .  10
   7.  MoQ Protocol Enhancements for Sensing Data Transport  . . . .  11
     7.1.  Conceptual Object Format with Metadata Extension  . . . .  11
     7.2.  Extended Metadata Fields  . . . . . . . . . . . . . . . .  13
       7.2.1.  Data Information  . . . . . . . . . . . . . . . . . .  13
       7.2.2.  Network Information . . . . . . . . . . . . . . . . .  13
       7.2.3.  Service and Task Context  . . . . . . . . . . . . . .  14
       7.2.4.  QoS Information . . . . . . . . . . . . . . . . . . .  14
     7.3.  Protocol Behavior Enhancements  . . . . . . . . . . . . .  15
       7.3.1.  Control Plane Coordination  . . . . . . . . . . . . .  15
       7.3.2.  Failure Feedback Mechanisms . . . . . . . . . . . . .  15



Yue, et al.               Expires 22 April 2026                 [Page 2]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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 22 April 2026                 [Page 3]

Internet-Draft   Challenges in Transporting Sensing Data    October 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 22 April 2026                 [Page 4]

Internet-Draft   Challenges in Transporting Sensing Data    October 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 22 April 2026                 [Page 5]

Internet-Draft   Challenges in Transporting Sensing Data    October 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.

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



Yue, et al.               Expires 22 April 2026                 [Page 6]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   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.

5.  Publish-subscribe mechanism for data distribution

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



Yue, et al.               Expires 22 April 2026                 [Page 7]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   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.

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

6.  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:_





Yue, et al.               Expires 22 April 2026                 [Page 8]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


                                +-------+
           +------------------->| 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._

6.1.  Data Publish Flows

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






Yue, et al.               Expires 22 April 2026                 [Page 9]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


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

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

6.2.  Data Subscribe Flows

    After the publish process,

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

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

   3.  A data session (consisting of MoQ session) can be established
       between the Data Provider 1 and the Data Consumer.

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







Yue, et al.               Expires 22 April 2026                [Page 10]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


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

7.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 22 April 2026                [Page 11]

Internet-Draft   Challenges in Transporting Sensing Data    October 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           |
      |  - Service ID                 |
      |  - Task ID                    |
      |  - Mission ID                 |
      |  - SFC ID                     |
      +-------------------------------+
      |          QoS Info             |
      |  - QoS Identifier (QI)        |
      |  - Timestamp                  |
      |  - data quality               |
      |  - data transmission QoS      |
      |  - data processing QoS        |
      +-------------------------------+
      |          Payload              |
      |      (Encrypted Data)         |
      +-------------------------------+








Yue, et al.               Expires 22 April 2026                [Page 12]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


7.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 (e.g., the new information are some
   bits of the existing metadata fields) or through the definition of
   new metadata elements:

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

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






Yue, et al.               Expires 22 April 2026                [Page 13]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


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

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

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




Yue, et al.               Expires 22 April 2026                [Page 14]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


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

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

7.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 capability to
   control plane, or notify the control plane upon data path failures or
   when requested publishers are not found.

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

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD

10.  References

10.1.  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 (https://www.rfc-
      editor.org/info/rfc2119).





Yue, et al.               Expires 22 April 2026                [Page 15]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   *  [*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 (https://www.rfc-
      editor.org/info/rfc8174).

10.2.  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
      (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 (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
      (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
      (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
      (https://www.etsi.org/deliver/etsi_gr/ISC/001_099/001/01.01.01_60/
      gr_isc001v010101p.pdf).




Yue, et al.               Expires 22 April 2026                [Page 16]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


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


   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


   Muhammad Awais Jadoon (editor)
   InterDigital Europe Ltd.
   London
   United Kingdom



Yue, et al.               Expires 22 April 2026                [Page 17]

Internet-Draft   Challenges in Transporting Sensing Data    October 2025


   Email: Muhammad.AwaisJadoon@InterDigital.com


   Sebastian Robitzsch (editor)
   InterDigital Europe Ltd.
   London
   United Kingdom
   Email: Sebastian.Robitzsch@InterDigital.com











































Yue, et al.               Expires 22 April 2026                [Page 18]
