Apparatuses and wireless communication methods for data plane service

Abstract

A wireless communication method for data plane service, performed by a network node, includes receiving, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service request comprises one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS, verifying the DPSS based on the data plane service request, and transmitting a data pipeline service subscribe request to one or more functional entities, wherein the data pipeline service subscribe request comprises data plane service parameters corresponding to each respective functional entity.

Description

APPARATUSES AND WIRELESS COMMUNICATION METHODS FOR DATA PLANE SERVICECROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63 / 674,2426, entitled “LEVERAGING DATA PIPELINE APPROACH FOR DATA COLLECTION TO SUPPORT INTRA AND INTER DOMAINS DATA PLANE SERVICES”, filed on July 22, 2024, which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates to the field of communication systems, and more particularly, to apparatuses and wireless communication methods for data plane service.BACKGROUND

[0003] Conventional wireless communication networks are designed to support data transmission between user equipment and core network components, focusing on throughput, latency, and connectivity. However, they are not equipped to meet the emerging demands of autonomous intelligent systems, which require real-time ingestion and processing of metadata from diverse and distributed data pipelines. These systems, such as artificial intelligence / machine learning (AI / ML)-based inference engines, sensing platforms, and digital twin models, depend on synchronized, high-fidelity, and context-aware data to operate effectively. The lack of native support for data-driven service orchestration in existing networks presents a limitation for enabling such advanced functionalities.SUMMARY

[0004] An object of the present disclosure is to propose apparatuses and wireless communication methods for data plane service, which can solve these issues in the prior art and other issues, enable efficient, scalable, and context-aware data integration across distributed system domains, and / or empower autonomous intelligent systems with timely and reliable metadata for enhanced artificial intelligence / machine learning (AI / ML), sensing, and digital twin operations.

[0005] In a first aspect of the present disclosure, a wireless communication method for data plane service, performed by a network node, includes: receiving, from a data plane servicesupplicant (DPSS), a data plane service request, wherein the data plane service request includes one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; verifying the DPSS based on the data plane service request; and transmitting a data pipeline service subscribe request to one or more functional entities, wherein the data pipeline service subscribe request includes data plane service parameters corresponding to each respective functional entity.

[0006] In a second aspect of the present disclosure, a network node, includes a transmitter configured to receive, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service request includes one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; and a verifier configured to verify the DPSS based on the data plane service request; wherein the transceiver is further configured to transmit a data pipeline service subscribe request to one or more functional entities, and the data pipeline service subscribe request includes data plane service parameters corresponding to each respective functional entity.

[0007] In a third aspect of the present disclosure, a network device includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The network device is configured to perform the above method.

[0008] In a fourth aspect of the present disclosure, a non-transitory machine-readable storage medium has stored thereon instructions that, when executed by a computer, cause the computer to perform the above method.

[0009] In a fifth aspect of the present disclosure, a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the above method.

[0010] In a sixth aspect of the present disclosure, a computer readable storage medium, in which a computer program is stored, causes a computer to execute the above method.

[0011] In a seventh aspect of the present disclosure, a computer program product includes a computer program, and the computer program causes a computer to execute the above method.

[0012] In an eighth aspect of the present disclosure, a computer program causes a computer to execute the above method.BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to illustrate the embodiments of the present disclosure or related art more clearly, the following figures will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present disclosure, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.

[0014] FIG. l is a block diagram of a network node according to an embodiment of the present disclosure.

[0015] FIG. 2 is a flowchart illustrating a wireless communication method for data plane service by a network node according to an embodiment of the present disclosure.

[0016] FIG. 3 is a block diagram of a network node according to an embodiment of the present disclosure.

[0017] FIG. 4 is a schematic diagram illustrating a reference architecture for a data plane in a next generation mobile system according to an embodiment of the present disclosure.

[0018] FIG. 5 is a schematic diagram illustrating a data pipeline architecture concept supported by data plane in a next generation mobile system according to an embodiment of the present disclosure.

[0019] FIG. 6 is a schematic diagram illustrating data pipeline contributor functionalities and their respective data flows according to an embodiment of the present disclosure.

[0020] FIG. 7 is a schematic diagram illustrating a use case for cross domains single data pipeline operation according to an embodiment of the present disclosure.

[0021] FIG. 8 is a schematic diagram illustrating protocol stacks for HTTP / 2 and HTTP / 3 according to an embodiment of the present disclosure.

[0022] FIG. 9 is a schematic diagram illustrating protocol stacks for data plane network data service control and orchestration communication between a UE and a core network according to an embodiment of the present disclosure.

[0023] FIG. 10 is a schematic diagram illustrating protocol stacks for data plane network data service control and orchestration communication between a UE and a RAN without HTTP transport, and between the RAN and a core network according to an embodiment of the present disclosure.

[0024] FIG. 11 is a schematic diagram illustrating protocol stacks for data plane network data service control and orchestration communication between a UE and a RAN using HTTPtransport, and between the RAN and a core network according to an embodiment of the present disclosure.

[0025] FIG. 12 is a schematic diagram illustrating high-level descriptions of QUIC packet format according to an embodiment of the present disclosure.

[0026] FIG. 13 is a schematic diagram illustrating concepts for QUIC stream ID partitioning to support DP stream ID and DP pipeline ID assignments according to an embodiment of the present disclosure.

[0027] FIG. 14 is a schematic diagram illustrating protocol stacks for data plane data transmission support for data pipeline operation according to an embodiment of the present disclosure.

[0028] FIG. 15 is a schematic diagram illustrating data pipeline ID life cycle according to an embodiment of the present disclosure.

[0029] FIG. 16 is a flowchart illustrating data plane service request procedures to initiate and to trigger local domains data pipeline operation configured to implement some embodiments presented herein.

[0030] FIG. 17 is a flowchart illustrating data plane service request procedures to initiate and to trigger cross domains data pipeline operation configured to implement some embodiments presented herein.

[0031] FIG. 18 is a flowchart illustrating procedures for data pipeline ID negotiation and allocation configured to implement some embodiments presented herein.

[0032] FIG. 19 is a block diagram of an example of a computing device according to an embodiment of the present disclosure.

[0033] FIG. 20 is a block diagram of a communication system according to an embodiment of the present disclosure.DETAILED DESCRIPTION OF EMBODIMENTS

[0034] Embodiments of the present disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present disclosure are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.

[0035] As 3rd generation partnership project (3GPP) system moves toward international mobile telecommunications 2030 (IMT-2030) and the next generation sixth generation (6G), the vision is to enable data-driven network services that support native artificial intelligence (Al), integrated sensing and communication (ISAC), and digital twin technologies. However, thecurrent fifth generation (5G) architecture lacks two critical capabilities: (1) a flexible architecture to facilitate data collaboration among various network entities acting as data sources, and (2) efficient and reliable network operations for data processing and management.

[0036] One proposed approach to evolving 5G to better support data services is by extending the user plane function (UPF) architecture. However, the existing user plane framework transmits user traffic in a closed, point-to-point session between the user equipment (UE) and the UPF. This rigid structure does not support any-to-any communication among network entities over arbitrary topologies, which is essential for metadata collection, inter-entity data exchange, and real-time processing or pre-processing required for native Al, sensing, and digital twin operations.

[0037] Moreover, the UPF does not offer mechanisms for enforcing data privacy protections that comply with regional regulations or operator policies. It is primarily designed to manage data forwarding between a data source and a data destination external to the mobile network. As such, it is not equipped to control data handled by internal network entities or to facilitate intermediate processing or pre-processing of data between them. This architectural limitation underscores the need for a more dynamic and privacy-aware framework to meet the demands of 6G-era services.

[0038] When considering the extension of the existing 3GPP TS 23.288 functions — namely, network data analytics function (NWDAF), data collection coordination function (DCCF), and messaging framework adaptor function (MFAF) — as well as enhancements to 3GPP TS 28.104, TS 28.537, and TS 28.622, which define data service capabilities and the management data analytics framework (including the management data analytics management function, or MDAMF), it becomes evident that these functionalities are primarily designed to collect data and generate analytics reports for consumers with a focus on management-level data analysis.

[0039] However, these existing features are not intended to harness the extensive computing resources available across network entities and devices, nor do they consider diverse application scenarios that require orchestrating various functional chains. As a result, they fall short in supporting collaborative data collection and advanced operations such as artificial intelligence and machine learning (AI / ML), integrated sensing, or digital twin implementations.

[0040] To enable data-driven network services, the industry is witnessing a clear paradigm shift — from the traditional model of session-based information transmission toward a platform- oriented approach for data management and orchestration. In this context, it is necessary to introduce a new data service framework in 6G. This framework must support collaborative datacollection and enable dynamic data pipeline operations to realize next-generation services such as AI / ML, sensing, and digital twin technologies.

[0041] Some embodiments of the present disclosure are to define how the data plane architecture is designed to enable data pipeline operations in support of data-driven network services. By leveraging a data pipeline approach for data collection, the architecture facilitates both intra-domain and inter-domain data plane services. This approach allows for seamless coordination among various network entities, enabling efficient, scalable, and flexible handling of data to support advanced use cases such as AI / ML, integrated sensing, and digital twin applications.

[0042] FIG. 1 illustrates an example of a network node 100 according to an embodiment of the present disclosure. The network node 100 is configured to implement some embodiments of the disclosure. Some embodiments of the disclosure may be implemented into the network node 100 using any suitably configured hardware and / or software. The network node 100 may include a memory 101, a transceiver 102, and a processor 103 coupled to the memory 101 and the transceiver 102. The processor 103 may be configured to implement proposed functions, procedures and / or methods described in this description. Layers of radio interface protocol may be implemented in the processor 103. The memory 101 is operatively coupled with the processor 103 and stores a variety of information to operate the processor 103. The transceiver 102 is operatively coupled with the processor 103, and the transceiver 102 transmits and / or receives a radio signal. The processor 103 may include application-specific integrated circuit (ASIC), other chipset, logic circuit and / or data processing device. The memory 101 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium and / or other storage device. The transceiver 102 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the memory 101 and executed by the processor 103. The memory 101 can be implemented within the processor 103 or external to the processor 103 in which case those can be communicatively coupled to the processor 103 via various means as is known in the art.

[0043] In some embodiments, the memory 101 stores executable instructions that when executed by the processor 103 cause the processor 103 to effectuate operations including: receiving, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service request includes one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; verifying the DPSS based on the data plane service request; andtransmitting a data pipeline service subscribe request to one or more functional entities, wherein the data pipeline service subscribe request includes data plane service parameters corresponding to each respective functional entity. This can solve these issues in the prior art and other issues, enable efficient, scalable, and context-aware data integration across distributed system domains, and / or empower autonomous intelligent systems with timely and reliable metadata for enhanced AI / ML, sensing, and digital twin operations.

[0044] FIG. 2 illustrates a wireless communication method for data plane service by a network node according to an embodiment of the present disclosure. FIG. 2 is an example of a communication method 200 for data plane service according to an embodiment of the present disclosure. The communication method 200 for data plane service is configured to implement some embodiments of the disclosure. Some embodiments of the disclosure may be implemented into the communication method 200 for data plane service using any suitably configured hardware and / or software. In some embodiments, the communication method 200 for data plane service includes: an operation 202, receiving, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service request includes one or more of the following: a data plane network data service descriptor identifier indicating a type of a data- driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; an operation 204, verifying the DPSS based on the data plane service request; and an operation 206, transmitting a data pipeline service subscribe request to one or more functional entities, wherein the data pipeline service subscribe request includes data plane service parameters corresponding to each respective functional entity. This can solve these issues in the prior art and other issues, enable efficient, scalable, and context-aware data integration across distributed system domains, and / or empower autonomous intelligent systems with timely and reliable metadata for enhanced AI / ML, sensing, and digital twin operations.

[0045] In some embodiments, the network node includes a data plane access controller (DP AC). In some embodiments, the DPSS includes a user equipment (UE), a radio access network (RAN) function node, a core network function (core NF) node, an operation, administration and maintenance (0AM) function node, or an application function (AF) node. In some embodiments, if the DPSS is verified, validating data plane network data service descriptors based on capabilities, policies, and / or applicable data protection regulations of a serving mobile network operator corresponding to a location or an environment of the DPSS. In some embodiments, the method further includes upon successful validation, obtaining a data pipeline identifier; selecting one or more local functional entities that support a data plane service operation; and transmitting data plane service parameters to the selected functional entities. In some embodiments, the method further includes transmitting a data pipeline servicesubscribe request to the selected functional entities, wherein at least one functional entity operates as a data sink and others operate as metadata sources for the data plane service operation.

[0046] In some embodiments, the method further includes receiving a pipeline service subscribe response from each of the selected functional entities, the pipeline service subscribe response indicating confirmation of participation in a data pipeline operation. In some embodiments, the method further includes transmitting, to the DPSS, a service notification including an operation status indicating initiation of the data plane service. In some embodiments, the method further includes receiving, from a data consumer functional entity, a metadata transaction subscribe request including one or more metadata profiles required to support the data plane service operation. In some embodiments, the method further includes initiating one or more metadata subscribe requests to metadata source functional entities based on the one or more metadata profiles; and receiving metadata from the metadata source functional entities. In some embodiments, the method further includes aggregating the metadata; transmitting an aggregated metadata to the data consumer functional entity; and receiving, from the data consumer functional entity, a completion notification or analytic result to finalize the data plane service operation. In some embodiments, the method further includes initiating a cross-domain data pipeline operation by involving a data pipeline orchestration controller (DPOCa) to communicate with one or more remote domain orchestration controllers (DPOCbs) for functional entity selection and coordination.

[0047] In some embodiments, the data plane service request is exchanged between the DPOCa and the DPOCb. In some embodiments, upon confirmation of readiness from selected functional entities acting as data pipeline contributors, the network node notifies the DPSS of successful initiation or completion of the data plane service operation. In some embodiments, the network node obtains a data pipeline identifier from a data pipeline identifier pool based on whether the data plane service operation involves a cross-domain pipeline. In some embodiments, for a crossdomain operation, the network node coordinates with a DPOCa to negotiate the data pipeline identifier with a remote domain through an iterative exchange of pipeline identifier requests and responses until a mutually agreed identifier is selected. In some embodiments, upon completion of the data plane service operation, the network node releases the data pipeline identifier to the data pipeline identifier pool and notifies the DPSS of an operation status.

[0048] FIG. 3 illustrates a communication device according to an embodiment of the present disclosure. FIG. 3 illustrates that, in some embodiments, a network node 300 includes a transmitter 301 and a verifier 302. The transmitter 301 is configured to receive, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service requestincludes one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS. The verifier 302 is configured to verify the DPSS based on the data plane service request. The transceiver 301 is further configured to transmit a data pipeline service subscribe request to one or more functional entities, and the data pipeline service subscribe request includes data plane service parameters corresponding to each respective functional entity. This can solve these issues in the prior art and other issues, enable efficient, scalable, and context-aware data integration across distributed system domains, and / or empower autonomous intelligent systems with timely and reliable metadata for enhanced AI / ML, sensing, and digital twin operations.

[0049] In some embodiments, the network node 300 includes a data plane access controller (DP AC). In some embodiments, the DPSS includes a user equipment (UE), a radio access network (RAN) function node, a core network function (core NF) node, an operation, administration and maintenance (0AM) function node, or an application function (AF) node. In some embodiments, if the DPSS is verified, validating data plane network data service descriptors based on capabilities, policies, and / or applicable data protection regulations of a serving mobile network operator corresponding to a location or an environment of the DPSS. In some embodiments, upon successful validation, the transceiver is configured to obtain a data pipeline identifier; the verifier is configured to select one or more local functional entities that support a data plane service operation; and the transceiver is configured to transmit data plane service parameters to the selected functional entities. In some embodiments, the transceiver 301 is configured to transmit a data pipeline service subscribe request to the selected functional entities, and at least one functional entity operates as a data sink and others operate as metadata sources for the data plane service operation. In some embodiments, the transceiver 301 is configured to receive a pipeline service subscribe response from each of the selected functional entities, and the pipeline service subscribe response indicates confirmation of participation in a data pipeline operation.

[0050] In some embodiments, the transceiver 301 is configured to transmit, to the DPSS, a service notification including an operation status indicating initiation of the data plane service. In some embodiments, the transceiver 301 is configured to receive, from a data consumer functional entity, a metadata transaction subscribe request including one or more metadata profiles required to support the data plane service operation. In some embodiments, the verifier 302 is configured to initiate one or more metadata subscribe requests to metadata source functional entities based on the one or more metadata profiles; and the transceiver 301 isconfigured to receive metadata from the metadata source functional entities. In some embodiments, the verifier 302 is configured to aggregate the metadata; the transceiver 301 is configured to transmit an aggregated metadata to the data consumer functional entity; and the transceiver 301 is configured to receive, from the data consumer functional entity, a completion notification or analytic result to finalize the data plane service operation. In some embodiments, the verifier 302 is configured to initiate a cross-domain data pipeline operation by involving a data pipeline orchestration controller (DPOCa) to communicate with one or more remote domain orchestration controllers (DPOCbs) for functional entity selection and coordination. In some embodiments, the data plane service request is exchanged between the DPOCa and the DPOCb.

[0051] In some embodiments, upon confirmation of readiness from selected functional entities acting as data pipeline contributors, the transceiver 301 notifies the DPSS of successful initiation or completion of the data plane service operation. In some embodiments, the transceiver 301 obtains a data pipeline identifier from a data pipeline identifier pool based on whether the data plane service operation involves a cross-domain pipeline. In some embodiments, for a crossdomain operation, the verifier 302 is configured to coordinate with a DPOCa to negotiate the data pipeline identifier with a remote domain through an iterative exchange of pipeline identifier requests and responses until a mutually agreed identifier is selected. In some embodiments, upon completion of the data plane service operation, the verifier 302 releases the data pipeline identifier to the data pipeline identifier pool, and the transceiver notifies the DPSS of an operation status.

[0052] FIG. 4 illustrates a reference architecture for a data plane in a next generation mobile system according to an embodiment of the present disclosure. FIG. 4 illustrates two options for a high-level mobile system reference architecture designed to support the new data plane functionalities referenced in this invention for enabling the data pipeline. Some embodiments address two primary aspects of data plane functionality: (a) data plane service control and orchestration, and (b) data plane data transmission support.

[0053] For data plane transmission support, the data plane is responsible for the transport and routing of data flows that carry raw or processed data originating from one or more data sources (e.g., user data, network data, application data, subscription data, etc.). These flows are delivered to authorized internal or external network components over arbitrary topologies, supporting flexible, reliable, and secure data services, along with on-path data processing to improve efficiency.

[0054] For data plane service control and orchestration, along the data pipeline carrying the data flows, several data processing functions — such as data collection, pre-processing, and analytics — are executed at various network entities. These functions are orchestrated and iocoordinated by the data plane access controller to collaboratively process, transform, and analyze the data outputs required by various data plane services.

[0055] In addition to data transport, routing, and in-network processing, the data plane also provides storage management services for both collected and processed data. These storage services support immediate and / or future use and enable data tracking and auditing to comply with data trustworthiness and explainable Al requirements.

[0056] To enable data plane support at the user equipment (UE) level, two options for mobile system architecture are proposed:

[0057] Option 1 : Evolving N1 to leverage the “Distributed NAS” approach.

[0058] In this option, each mobile network-related function within the UE communicates directly with the 5G Core network functions without routing through the access and mobility management function (AMF), differing from the current 5G architecture.

[0059] Option 2: Evolving N1 to leverage the service-based architecture (SB A) approach.

[0060] In this approach, each mobile network-related function within the UE communicates with the 5G Core network functions through direct IP -based connections using the HTTP / 2 service-based interface (SBI) protocol, again bypassing the AMF as opposed to today's 5G system.

[0061] It should be noted that the detailed designs of option 1 and option 2 may be beyond the scope of this disclosure. However, the design of the data plane protocols, taking into consideration these two options, is further discussed. The mobile network architecture options illustrated in FIG. 4 serve as the reference architecture for describing the data pipeline design proposed in some embodiments of this disclosure.

[0062] The data plane includes four major functional components: Data plane orchestration coordinator (DPOC), data plane access controller (DP AC), data plane repository (DPR), and data pipeline contributor (DPC).

[0063] Among these, the DP AC plays a central role and is responsible for several critical tasks. These include data acquisition, validation of the identities of both data sources and data consumers, and execution of data processing functions. The DP AC also manages data exposure and facilitates data distribution or sharing across network entities.

[0064] Additionally, the DP AC interacts with the data plane repository function (DPRF) for data storage management and other related data services. It supports mechanisms for data auditing and traceability, ensuring compliance with data governance and security requirements. Furthermore, the DP AC is responsible for tracking and maintaining the membership of dataproducers and consumers, as well as managing the domains associated with their respective metadata profiles.

[0065] Similar to an AMF set in current 5G systems, DPACs form a DP AC set to ensure reliable access to data plane services. DPACs from different domains collaborate with each other, with the assistance of the DPOC, to support inter-domain data plane functionalities.

[0066] The DPOC is a distributed logical function responsible for coordinating all crossdomain data plane communications. This includes managing cross-domain security, enforcing access control policies, and providing topology hiding between domains — similar in concept to the signaling communication proxy (SCP) in today’s 5G architecture. The DPOC may be colocated with a DP AC and coordinates with other distributed DPOC functions from different domains to ensure seamless data plane orchestration.

[0067] Within each functional domain of a mobile system, multiple DPCs — which are typically network entities — may be selected to participate in a data pipeline operation, depending on the specific service requirements.

[0068] The DPR provides persistent and large-scale data storage, which is necessary for storing log data, datasets used in Al model training, and snapshots of intermediate steps during Al model optimization, among other use cases. Furthermore, to comply with data privacy regulations and meet the reliability requirements of Al-driven network operations, data stored in the DPR can be immutable and traceable. While the DPR plays a critical role in the overall data plane architecture, its detailed design may be considered beyond the scope of this disclosure.

[0069] The data pipeline is defined as a composite chain of activities that may span across different mobile network functional domains. It is used to manipulate metadata collected from one or more data sources in order to support a specific data plane service. Within this framework, the DPC is the component of the data pipeline embedded within a network entity that performs data plane-specific functionalities — such as data collection, pre-processing, labeling, and more. Along the data pipeline, the output of data processing from one network entity serves as the input to the next, enabling a smooth and automated flow of data from the source to the destination.

[0070] A data pipeline begins with one or more pipeline data sources and terminates at one or more pipeline data sinks, which receive the final processed data. Data Pipeline Contributors are designed to automate key data operations including extraction, transformation, combination, validation, and loading of data. The pipeline is capable of handling various types of data, such as continuous streams, intermittent bursts, or batch data.

[0071] Each data pipeline contributor is part of the data plane functionality that resides within a network entity — such as UE, a radio access network (RAN) function, a core network function, operations, administration and maintenance (0AM) function, or an application function. When the data plane initiates a data pipeline operation to support a specific service, the network entities that provide the required DPC functionalities are selected to participate in the pipeline. These entities support one or more of the following operations: data collection, data processing, preprocessing, data labeling, analytics, and data routing or forwarding.

[0072] FIG. 5 illustrates a data pipeline architecture concept supported by data plane in a next generation mobile system according to an embodiment of the present disclosure. FIG. 5 illustrates a high-level data pipeline architecture concept, which forms part of the data plane functionalities designed to support various data plane services. A data pipeline contributor can also serve as a pipeline data source or a pipeline data sink, depending on its role within the pipeline. The pipeline data source represents the starting point of a data pipeline, where metadata begins its journey. A data pipeline can include multiple pipeline data sources, such as applications, cloud storage, streaming data from sensors or loT devices, and APIs from external services. These sources ingest raw data and inject it into the pipeline for further processing. The pipeline data sink is the endpoint of the data pipeline, where clean, processed, and integrated data becomes available for downstream actions — such as data analysis, machine learning model training, or real-time decision-making. For example, in a vehicle-to-everything (V2X) scenario, the processed data may be used for machine learning operations to support autonomous driving. Each data pipeline is dedicated to a specific data service operation, which may be initiated by an entity that is either part of or external to the pipeline components. In some cases, the data service request may originate from an authorized external entity outside the mobile system, indicating the flexibility and extensibility of the data plane architecture. In order to transport metadata — which may be high in volume — between data pipeline contributors for processing in an efficient, effective, reliable, and secure manner, a dedicated transmission protocol is required. This protocol must be specifically designed to meet the needs of data pipeline operations and differs fundamentally from the user plane design currently defined in 3GPP 5G systems. The new protocol should be capable of supporting dynamic data flows, ensuring data integrity, and accommodating the orchestration demands of data-driven services.

[0073] FIG. 6 illustrates data pipeline contributor functionalities and their respective data flows according to an embodiment of the present disclosure. FIG. 6 illustrates an example of data flows within a data pipeline operation designed to support AI / ML model training. This figure demonstrates how data pipeline contributor function in various roles, such as pipeline data source, data controller, or other contributor components within the pipeline. In the role of apipeline data source, data, whether structured or unstructured, can be introduced into the pipeline in batch, intermittent, or continuous modes. The data may be pushed to the DP AC, which acts as a data collector, or pulled by the DP AC from the source. Export of data can occur through realtime events, batch records, or a combination of both. Once collected, the data is exposed to the DP AC, which may have subscribed to a corresponding metadata profile, thereby enabling authorized data consumers to access and utilize it.

[0074] Raw data can be processed before use. This involves converting the data into a standardized format defined by the metadata profile to ensure compatibility with downstream functions. Prior to participating in pipeline operations, network entities are authenticated and authorized to guarantee secure and policy-compliant access. Only verified contributors are permitted to interact with the pipeline, maintaining system integrity.

[0075] As part of data acquisition and processing, information is ingested from various sources and stored in a Data Repository for future use. The ingested data is logged and archived, potentially in compressed formats that can later be retrieved and uncompressed. Handling varies by data type: real-time streaming data is processed sequentially, while continuous data is validated immediately. The processing stage may include aggregation, parsing, and transformation to convert raw inputs into structured or semi -structured formats suitable for analytics and model training.

[0076] The system also features robust data pipeline monitoring, which includes three types. Pipeline Performance Monitoring tracks metrics such as data availability and latency. Data Profile Monitoring ensures data conforms to expected metadata profiles. Condition Monitoring detects anomalies or faults, triggers event logging or alarms, and supports diagnostic and mitigation processes, thereby enhancing traceability and explainability.

[0077] To support ongoing data operations, the pipeline provides permanent, reliable, and immutable storage for raw, processed, and pre-processed data. This ensures long-term data availability for auditing, reuse, or additional analysis. After storage, data can be exposed again, as the DP AC enables registered and subscribed consumers to retrieve archived data according to their access configurations — whether via instant notifications, periodic access, or on-demand downloads.

[0078] As pipelines are constructed, the DP AC uses pre-configured Data Plane Network Data Service Descriptors to identify and select appropriate Data Pipeline Contributors and determine routing paths. Upon establishing the pipeline, a unique Data Pipeline ID is assigned to track data flows and contributor associations.

[0079] The DP AC also orchestrates the data pipeline service by identifying participating network entities, assigning their processing roles, and determining the execution order necessary to support the intended data service operation. This orchestration ensures that the entire pipeline operates in a coordinated and efficient manner.

[0080] To improve data quality and ML performance, data pre-processing is performed before the data reaches the target ML models. This step includes data cleaning, normalization, labelling, quality assessment, imputation, encoding, and sampling. The pre-processed output is then fed into the AI / ML model for training, retraining, testing, and validation.

[0081] Throughout the operation, data pipeline contributors can communicate with one another, subject to operator-defined policies and mutual authorization. The pipeline is continuously monitored, enabling proactive issue detection, event logging, and alarm generation, as well as execution of mitigation actions when needed. At any stage, contributors may store processed outputs in the data repository for reuse by other applications or for future data services, supporting long-term auditing and data traceability.

[0082] As illustrated in FIG. 6, when a data pipeline contributor operates as a pipeline data source, it performs several key functions that initiate and enable the flow of data through the pipeline. First, it handles data collection, where structured or unstructured data may be introduced into the data pipeline in batch, intermittent, or continuous modes. This data can be either pushed from the source to the DP AC, acting as a data collector, or pulled by the DP AC from the respective data sources. Data export may occur through real-time events, batch records, or a combination of both.

[0083] Once collected, the data undergoes data exposure, where it is made available to the DP AC. The DP AC may have subscribed to a specific metadata profile associated with the data source, enabling selective and authorized access to the data. Following this, the data processing step involves converting the raw data into a predefined format based on the metadata profile. This ensures the data is compatible with downstream processing components and systems.

[0084] When a data pipeline contributor functions as a pipeline data sink, it receives processed and integrated data and uses it to support the target data service operation, such as data analytics or AI / ML model training. For instance, in V2X machine learning scenarios, the data sink may utilize the incoming data to train models that enhance autonomous driving capabilities.

[0085] In some cases, before the pipeline data sink can begin its designated operation, it may require assistance from other data pipeline contributors to conduct preliminary steps such as data pre-processing. This process optimizes the data for use in machine learning algorithms and may include data quality assessment, imputation, encoding, sampling, and labeling. The output frompre-processing is then forwarded to the Pipeline Data Sink, which hosts the target service (e.g., model training, retraining, testing, or validation) and utilizes the refined data accordingly.

[0086] To orchestrate, organize, and direct data flows and processing tasks across the various contributors in support of a specific data service operation, the DPOC and the DPACs within the involved domains work collaboratively. Their actions are guided by the data plane network data service descriptors, which define the necessary processing logic and control policies.

[0087] Among the core responsibilities of the DPOC and DP AC is data pipeline access authentication and authorization, which ensures that each participating network entity is properly validated and permitted to interact with the pipeline. This enforces secure, policy-compliant access across the system.

[0088] The data acquisition and processing function involves collecting data from various sources and ingesting it into a data repository for long-term use. All ingested data is logged and archived, potentially in a compressed format, and can be retrieved and uncompressed later as needed. Different data types are processed in distinct ways — for example, real-time streaming data is handled sequentially, while continuous data is validated immediately. Processing steps may include aggregation, parsing, and transformation, converting raw inputs into structured or semi -structured formats suitable for statistical analysis and machine learning applications.

[0089] Throughout the pipeline, monitoring is carried out across dimensions: Pipeline performance monitoring, which tracks metrics like data availability and latency; pipeline QoS monitoring, which verifies that data quality meets the requirements defined in the descriptors; and pipeline condition monitoring, which detects faults, triggers logs and alarms, and facilitates traceability and explainability in case of data-related issues. The system also provides robust data storage capabilities, ensuring permanent, reliable, and immutable storage for raw, processed, and pre-processed data. This stored data can be revisited for future auditing, analysis, or data exposure. Regarding data exposure, the DP AC enables authorized and registered consumers to retrieve archived data using metadata profiles. Consumers may access this data via on-demand queries, periodic updates, or event-driven notifications, depending on their subscription configurations. In terms of contributor selection, the DP AC uses the Data Plane Network Data Service Descriptors to determine the appropriate Data Pipeline Contributors for a given operation. Once the participants are identified, the system assigns a unique Data Pipeline Identifier (DP ID) to facilitate flow classification and association of contributors within that specific pipeline. Finally, the DP AC oversees data pipeline service orchestration. It determines the list of required network entities, their roles, responsibilities, and the execution sequence needed to fulfill the service operation. In cross-domain scenarios, the DP AC that receives theData Plane Service Request (from the supplicant) assumes responsibility for orchestrating the entire cross-domain data pipeline, ensuring cohesive operation across different system domains.

[0090] The data plane network data service descriptors define the characteristics of the data workflow within the data pipeline for a specific type of network data service (e.g., Autonomous Driving, Smart Metering, Network Congestion Control, etc.). These descriptors are detailed in Table 1 below.

[0091] Tablet : Data plane network data service descriptors.

[0092] FIG. 7 illustrates a use case for a cross-domain single data pipeline operation, in accordance with an embodiment of the present disclosure. This example demonstrates how a single data pipeline can support operations across multiple domains. Use Case: ML data collection is requested by the V2X application server (V2X-AS) to enable AI / ML-assisted sensing operations for estimating vehicle location, which contributes to building an autonomous driving map. In this scenario, the RAN and the Core Network are configured as separate domains. The DPOC works in coordination with the DPACs to determine which network entities from each domain are required to act as Data Pipeline Contributors in order to support the requested operation. Once the contributors are selected based on the Data Plane Network Data Service Descriptors, the DPOC assigns a unique Data Pipeline Identifier (DPID) to the established pipeline. This identifier enables tracking and orchestration of the pipeline throughout its lifecycle.

[0093] FIG. 7 presents an example of a cross-domain, single-pipeline operation within a mobile system, illustrating how a data plane service request is handled for a specific network data service operation. In this use case, network entities from multiple domains collaborate to support the data pipeline operation. Specifically, a V2X Application Server (V2X-AS) requests the mobile system to provide AI / ML assistance for a V2X sensing operation aimed at estimating vehicle locations to help construct an autonomous driving map.

[0094] The V2X-AS sends an ML data collection data plane service request, referencing a set of predefined data plane network data descriptors that correspond to this specific operation, to its registered serving DP AC. Based on these descriptors, the DP AC determines that the service request targets a specific network environment — such as a defined geographic location, a set of UEs, relevant datasets, and an Al model — and requires the collaboration of multiple network entities across domains (e.g., UE, RAN functions, and core network functions) to execute the operation.

[0095] After validating the V2X-AS’s eligibility to initiate this service request, the DP AC notifies the DPOC to coordinate with DPOCs in other domains to establish the necessary datapipeline, based on the specifications of the data plane network data descriptors. Within each domain, the DP AC is responsible for verifying the feasibility of the request based on current network resources and conditions. It then selects suitable network entities that meet the operational requirements to act as data pipeline contributors. Once these network entities confirm their ability to participate, the DP AC provisions them with the required data plane service parameters.

[0096] Following provisioning, the DPOCs in each domain coordinate with the serving DP AC of the V2X-AS to confirm the readiness of the data pipeline operation. The requested ML Data Collection Data Plane Service is triggered once the necessary network conditions and environmental factors are satisfied. The above descriptions primarily address the data plane control and orchestration aspects of the architecture. The relevant protocol stacks for these operations are disclosed. During the data plane network data service operation, the data pipeline contributors across domains coordinate to transport metadata and pre-processed data using the data pipeline data transmission protocol, such as quick UDP internet connection (QUIC).

[0097] Table 2 below lists the data plane service request parameters that may be included in a service request initiated by a service request supplicant (e.g., UE, RAN functions, core network functions, 0AM, AF, etc.), or in a data pipeline service request used to trigger a data pipeline operation.

[0098] Table 2: Data plane service parameter descriptions.

[0099] FIG. 8 is a schematic diagram illustrating protocol stacks for HTTP / 2 and HTTP / 3 according to an embodiment of the present disclosure. FIG. 8 illustrates that, in some embodiments, the data plane design proposed in this invention comprises two main aspects. The first aspect focuses on data plane control and orchestration support. For this purpose, two control signaling options are considered:

[0100] A. The Uu and N1 interfaces are extended at the Access Network (AN) layer to provide NAS-like signaling support for managing UE-specific Data Plane functionalities. However, instead of anchoring this signaling to the existing Access and Mobility Management Function (AMF), it is redirected to a new N1 proxy function. This change is intended to optimize any-to- any communication between the UE and Core Network components without overloading the AMF.

[0101] B. The Uu interface is extended at both the AN layer and the Network layer to support Service-Based Interface (SBI)-based signaling between the UE and any mobile network functions located in the RAN or Core Network.

[0102] For both signaling options, it is assumed that the current NGAP -based N2 interface between the RAN and core network may evolve to support SBI-based N2 signaling. It should also be noted that service-based architecture (SB A) support in current 5G systems utilizes the HTTP / 2 protocol. In the context of evolving the mobile system to support enhanced data plane operations, this invention assumes that SBA support could be implemented using either HTTP / 2 or the more advanced HTTP / 3 protocol.

[0103] FIG. 9 is a schematic diagram illustrating protocol stacks for data plane network data service control and orchestration communication between a UE and a core network according to an embodiment of the present disclosure. FIG. 9 outlines the protocol stacks corresponding to options A and B for enabling data plane control and orchestration support.

[0104] A. In option A, both the Uu and N1 interfaces are extended at the access network (AN) layer, and N1 is further extended at the network layer to provide NAS-like signaling support for UE-specific data plane management functionality.

[0105] A.1 : For data plane communications between the UE and the core network, as illustrated in FIG. 9, both the Uu and N1 interfaces, at both the AN and network layers, may be enhanced to support data plane signaling control. A new N1 proxy anchor is introduced to perform protocol stack transcoding, thereby enabling seamless communication between the UE and the core network.

[0106] Assuming that the RAN evolves to support service-based architecture (SBA) using either HTTP / 2 or HTTP / 3 as the transport protocol, this invention envisions that the N1 Proxy Anchor will leverage these transport protocols to facilitate new service-based interface (SBI) services. These services are important to enable robust and flexible data plane communications between the UE and the core network.

[0107] FIG. 10 is a schematic diagram illustrating protocol stacks for data plane network data service control and orchestration communication between a UE and a RAN without HTTP transport, and between the RAN and a core network according to an embodiment of the present disclosure.

[0108] A.2: UE data plane communications with the RAN and RAN communications with the core network:

[0109] FIG.10 illustrates the protocol stacks for data plane network data service control and orchestration communication between a UE and a radio access network (RAN) — without the use of HTTP transport — and between the RAN and a core Network, according to an embodiment of the present disclosure. In addition to supporting data plane signaling control between the UE and the core network, similar support is also required between the UE and the RAN, as well asbetween the RAN and the core network. FIG. 10 depicts two separate peer-to-peer data plane signaling communications. For communication between the UE and the RAN, the existing Uu interface must be extended to support the new data plane signaling mechanisms. For communication between the RAN and the core network, the existing N2 interface is expected to evolve into a service-based interface (SBI). This evolution includes the integration of new data plane services, enabling enhanced and flexible data plane communications between the RAN and the core network.

[0110] B. Extending Uu to provide SBI-based signaling support for UE data plane management functionality:[oni] FIG. 11 illustrates protocol stacks for data plane network data service control and orchestration communication between a UE and a RAN using HTTP transport, and between the RAN and a core network according to an embodiment of the present disclosure. To enable any- to-any service communication between the UE and various mobile network functions in both the RAN and Core Network, the Uu interface and the AN layer are extended. This extension allows the AN protocol layer to support SBI-based service communication between the UE and the RAN. FIG. 11 illustrates the protocol stacks for data plane network data service control and orchestration communication between the UE and the RAN using HTTP transport, as well as between the RAN and the core network. For the peer-to-peer data plane service control and orchestration communication between the RAN and the core network, it is expected that the existing N2 interface will evolve into a service-based interface (SBI-N2). The added new data plane services will operate over this SBI-N2 interface to support robust and scalable data plane communications between the RAN and the core network.

[0112] Protocol stack for data plane data transmission support: The data plane is designed to support data collection and processing tasks, particularly for sensing and Al-related operations. Given the diverse characteristics and potentially high volume of metadata involved, the existing 3GPP user plane transport mechanisms are not sufficient to handle such requirements efficiently. Therefore, careful consideration must be given to the selection of the transmission protocol used for transporting metadata across the data pipeline between Data Pipeline Contributors. The following outlines the key requirements for such a protocol:

[0113] a. Reliability: Due to the potentially high volume of metadata transmission, the chosen transmission protocol must ensure reliable delivery of data across the pipeline.

[0114] b. No Head-of-Line (HOL) Blocking: While TCP offers reliable transport, its design introduces head-of-line blocking, which can significantly degrade data transmission performance. Therefore, the target protocol should be resistant to HOL blocking.

[0115] c. Multi-Streaming Multiplexing / Demultiplexing Support: A single data source may generate multiple streams of metadata relevant to a given Data Plane Network Data Service operation. The transmission protocol should be capable of efficiently multiplexing and demultiplexing multiple streams to optimize throughput and resource utilization.

[0116] d. Security: Metadata often contains sensitive information. The protocol must ensure data privacy, integrity, and protection from exposure or compromise during transmission.

[0117] e. Minimal Signaling Overhead: To establish secure transmission sessions and ensure data integrity, many protocols require multiple rounds of signaling handshakes. The target protocol should minimize signaling exchanges and protocol overhead while still ensuring secure and reliable metadata transmission.

[0118] f. Support for Data and Operation Correlation Among Data Pipeline Contributors: Each instance of a collaborative data pipeline operation is identified by a Pipeline ID. Contributors must be able to correlate incoming metadata to the correct operation. Given that a network entity may participate in multiple concurrent data pipelines, the transmission protocol must support accurate correlation of data and operational context.

[0119] Considering all these requirements, QUIC emerges as a strong candidate protocol to support metadata transmission in the data plane. Figure 8 presents the high-level format of a QUIC packet. For further technical details regarding the QUIC protocol, reference should be made to RFC 9000.

[0120] FIG. 12 illustrates high-level descriptions of QUIC packet format according to an embodiment of the present disclosure. The following summarizes the structure of a QUIC packet as illustrated in FIG. 12. A UDP datagram contains a header specifying the source and destination ports, along with length and checksum data. It carries one or more QUIC packets and serves as the unit of information transmitted from the client to the server across the network.Each QUIC packet includes one QUIC header and one or more QUIC frames. The QUIC header provides metadata about the packet and comes in two forms: the long header, which is used during the connection establishment phase, and the short header, which is used once the connection has been established. The short header contains fields such as the connection ID, packet number, and key phase. The key phase is used to identify which encryption keys were applied to the packet, supporting key rotation. Packet numbers are unique and increment for each packet within a given connection and key phase. Each QUIC frame contains a type identifier, stream ID, offset, and stream data. Although stream data may span multiple frames, it can be reassembled using the connection ID, stream ID, and offset to ensure that data chunks are presented in the correct order. A stream represents a unidirectional or bidirectional flow of datawithin a single QUIC connection. QUIC supports multiple independent streams per connection, each identified by a unique stream ID. Notably, if a packet carrying some streams is lost, the other streams within the same connection remain unaffected. This capability is essential in avoiding the head-of-line (HOL) blocking issues observed in protocols such as HTTP / 2. Additionally, streams can be initiated by either endpoint and can operate bidirectionally. QUIC Frame Information includes several components essential for data transport and stream management. The Frame Type indicates the specific QUIC protocol frame type, such as PADDING, PING, ACK, etc. The Stream ID identifies the data stream carried by the QUIC frame; each stream functions similarly to a TCP connection, ensuring ordered byte-stream delivery. The Offset is analogous to the TCP sequence number and is used for data frame ordering, loss detection, and retransmission to ensure reliable delivery. Each data frame is uniquely identified by a combination of the Stream ID and frame offset. Data Length specifies the total size of the Stream Data, while the Stream Data itself is the actual payload of the frame. These components together enable efficient and reliable transport of data over QUIC connections.

[0121] FIG. 12 illustrates the structure of a QUIC packet encapsulated within a UDP packet. At the lowest level, the UDP packet header contains fields such as the source port, destination port, and a checksum plus length field. The UDP payload carries the QUIC packet, which begins with the QUIC packet header. This header includes flags, a connection ID, and a packet number, all of which are encrypted to enhance security. Following the header is the QUIC payload, which may consist of various types of frames, including an ACK frame, a flow control frame, and a stream frame. The stream frame itself is composed of a stream frame header and the actual stream frame payload, which in this case carries the HTTP data. Importantly, the HTTP data, along with the QUIC packet header and all QUIC payloads, is fully encrypted. At the end of the packet, a QUIC MAC (Message Authentication Code) ensures data integrity and authenticity. This layered and encrypted design of QUIC over UDP enables both performance and security improvements compared to traditional TCP -based transport protocols.

[0122] According to RFC 9000, the Variable-Length Integer Encoding technique is commonly used for encoding QUIC packet information, including the stream ID, in order to optimize storage and memory usage. The concept of Variable-Length Integer Encoding is detailed in RFC 9000. This encoding method is designed for non-negative integer values and ensures that smaller integers require fewer bytes to encode. Specifically, the two most significant bits (2MSB) of the first byte indicate the base-2 logarithm of the total encoding length in bytes. The remaining bits are used to encode the actual integer value in network byte order. As a result, integers can be encoded in 1, 2, 4, or 8 bytes, corresponding to 6-bit values, 14-bit values, 30-bit values, or 62-bit values, respectively. Table 3 summarizes the encoding properties: 2MSB: 00 - Length: 1 byte, Usable Bits: 6, Range: 0-63. 2MSB: 01 - Length: 2 bytes, Usable Bits: 14, Range: 0- 16,383. 2MSB: 10 - Length: 4 bytes, Usable Bits: 30, Range: 0-1,073,741,823. 2MSB: 11 - Length: 8 bytes, Usable Bits: 62, Range: 0-4,611,686,018,427,387,903. An example of a decoding algorithm and sample encodings is provided in Appendix A. l of RFC 9000. It is important to note that values are not required to be encoded using the minimum number of bytes necessary, except for the Frame Type field. However, certain values, such as versions, packet numbers in headers, and connection ID lengths in long header packets, are represented as integers but do not use this variable-length encoding method.

[0123] Table 3: Summary of Integer Encodings.

[0124] In the case where the QUIC protocol is used for data transmission within the data pipeline, the metadata may be encapsulated within the stream frame payload as stream data, as illustrated in FIG. 12. To coordinate the data plane network data service operation among the selected data pipeline contributors for a specific pipeline, some embodiments of this disclosure propose to reserve part of the stream ID field to represent the pipeline ID. Before discussing the proposed partitioning of the stream ID, it is important to review RFC 9000, which defines how the two least significant bits (LSBs) of the stream ID are reserved for identifying the stream Type. Streams in QUIC can be either unidirectional or bidirectional. Unidirectional streams carry data from the initiator to its peer, while bidirectional streams support two-way data exchange. Each stream is uniquely identified within a connection by a numeric stream ID, which is a 62-bit integer ranging from 0 to 262-l. Stream IDs are encoded as variable-length integers, as defined in RFC 9000. A QUIC endpoint does not reuse a stream ID within the same connection. The least significant bit (0x01) of the stream ID indicates the initiator of the stream: Client-initiated streams have even-numbered stream IDs (bit set to 0), server-initiated streams have odd- numbered stream IDs (bit set to 1). The second least significant bit (0x02) specifies the directionality of the stream: Bidirectional streams have the bit set to 0, unidirectional streams have the bit set to 1.

[0125] Together, these two least significant bits define the stream type, as summarized in Table 4:

[0126] Table 4: Stream ID Types.

[0127] The stream ID space for each type begins at its respective minimum value (0x00 through 0x03), and subsequent streams of that type are created with incrementally increasing stream IDs. If a stream ID is used out of order, it results in all lower-numbered streams of that type being considered open as well. With this understanding of stream ID structure, in some embodiments, the proposed use of additional bits within the stream ID to represent the pipeline ID aims to support robust correlation and coordination of data flows across the data pipeline contributors involved in a particular data plane service.

[0128] FIG. 13 illustrates concepts for QUIC stream ID partitioning to support DP stream ID and DP pipeline ID assignments according to an embodiment of the present disclosure. In some embodiments of this disclosure, it is proposed to partition the maximum 8-byte QUIC Stream ID into two segments: the pipeline ID and the data plane stream ID. Specifically, the two least significant bytes (i.e., allowing for up to 16,383 Pipeline IDs) are reserved for the data plane pipeline ID assignment. The data plane stream ID assignment then begins from the third least significant byte and extends up to the eighth byte (i.e., the most significant byte of the QUIC Stream ID). If the allocation of 16,383 pipeline IDs proves insufficient, the reservation for the pipeline ID can be extended to include up to the four least significant bytes, thereby supporting as many as 1,073,741,823 unique pipeline IDs. FIG. 13 illustrates the concept of QUIC stream ID partitioning, showing how the stream ID field can be split to accommodate both the data plane pipeline ID and the data plane stream ID, enabling efficient coordination and identification of metadata streams within the data pipeline architecture.

[0129] FIG. 14 illustrates protocol stacks for data plane data transmission support for data pipeline operation according to an embodiment of the present disclosure. After applying the proposed modifications to the QUIC Stream ID to support both the Data Plane Stream ID and the Pipeline ID, the QUIC protocol can now serve as an effective transport protocol for metadata transmission within the data pipeline operation. This enhancement enables QUIC to support high-efficiency, low-latency, and reliable data exchange across the distributed architecture of the mobile system. FIG. 14 presents examples of protocol stacks that leverage QUIC as the transport protocol for supporting metadata transmissions within the mobile system as part of the data pipeline operation. If QUIC is adopted as the new native transport layer for metadata exchange between different network elements — such as between the UE and RAN, UE and Core, and RAN and Core — new interfaces may need to be introduced to support these transmissions. Specifically, interfaces such as NDPTUU, NDPTI, and NDPT2 may be defined to represent Data Plane Transport / Transmission links between these entities, respectively. These new interfaces would enable consistent and optimized QUIC -based communication across the end-to-end mobile network data pipeline.

[0130] FIG. 15 illustrates data pipeline ID life cycle according to an embodiment of the present disclosure. As described in previous embodiments, the QUIC Stream ID is partitioned to include the Data Pipeline ID, which is assigned by the DP AC. FIG. 15 illustrates the lifecycle of the Data Pipeline ID, which includes three phases: preparation, operation, and closing.

[0131] (1) Preparation Phase: Once the DP AC verifies the authenticity and authorization of a DP AC Service Request from the supplicant, and before initiating theDPAC DataPipelineServiceSubscribe Request to the candidate Data Pipeline Contributors, it retrieves an unused Data Pipeline ID from the Data Pipeline ID Pool. This pool is maintained either by the Unified Data Management (UDM) function or by another equivalent system-wide entity. The value of the Data Pipeline ID ranges from 1 to 16383. The DP AC includes this ID in the DPAC DataPipelineServiceSubscribe Request, along with relevant Network Data Service Descriptor information (e.g., roles of data contributors, next hop, previous hop, etc.), and sends it to the selected Data Pipeline Contributors. Once a contributor confirms its participation in the pipeline operation, it binds the Data Pipeline ID to its local resources and configuration.

[0132] (2) Operation Phase: During the data pipeline operation, whenever a Data Pipeline Contributor inserts metadata — whether raw or pre-processed — into a QUIC stream, the data source generates a QUIC Stream ID. This is done by placing the Data Pipeline ID (provided by the DP AC) into the two least significant bytes, while the locally assigned Data Plane Stream ID occupies the higher-order bytes, starting from the third least significant byte. The encoding of the QUIC Stream ID must conform to the rules specified in RFC 9000. Any downstream DataPipeline Contributor that receives the QUIC stream can identify the associated pipeline by examining the two least significant bytes of the Stream ID and process the metadata accordingly.

[0133] (3) Closing Phase: Once the data pipeline operation is completed, each participating Data Pipeline Contributor will remove the binding between the Data Pipeline ID and its local resources and configurations. The DP AC will then release the Data Pipeline ID back to the ID Pool, making it available for future operations.

[0134] Note: If the allocation of 16383 Data Pipeline IDs is not sufficient, the partitioning of the QUIC Stream ID can be extended to reserve the four least significant bytes, thereby supporting up to 1073741823 unique Data Pipeline IDs.

[0135] Some embodiments provide further detailed illustrations of how the Data Plane supports Data Pipeline Service operations in both intra-domain and inter-domain scenarios. It explains the mechanisms and procedures involved in enabling seamless metadata transmission, coordination, and processing among Data Pipeline Contributors, whether they reside within a single domain or span across multiple functional domains. These illustrations help clarify the orchestration and transport functions of the Data Plane, ensuring effective support for data-driven network services in diverse deployment environments.

[0136] FIG. 16 illustrates data plane service request procedures to initiate and to trigger local domains data pipeline operation configured to implement some embodiments presented herein. FIG. 16 illustrates that, in some embodiments, data plane service request procedures may include at least one of following operations.

[0137] Operation 1 : The Data Plane Service Supplicant (e.g., UE, RAN function, Core Network Function (NF), 0AM function, Application Function (AF), etc.) initiates a Data Plane Service Request to the Data Plane Access Controller (DPACa) in order to collect the necessary metadata to support a specific type of data-driven network operation (e.g., Al-assisted integrated sensing model training). The supplicant sends the request using the message DPAC_Service_Request(DataPlaneNetworkDataServiceDescriptorsID, DPSShcorrlD, DPSSID, DP SSDigi tai Signature, DPSSPublicKey). This message includes one or more of the following: The Data Plane Network Data Service Descriptors Identifier, which indicates the specific data- driven network operation; the Data Plane Service Supplicant Correlation Identifier, used to correlate the request between the supplicant and the DPACa; the supplicant’s Identifier, the digital signature, or the public key of the supplicant, enabling the DPACa to verify the supplicant’s identity. Note: It is expected that the supplicant has already been registered with the DP AC and that mutual authentication has been successfully completed.

[0138] Operation 2: The DPACa first verifies the identity of the Data Plane Service Supplicant (DPSS). If the verification is successful, DPACa proceeds to validate the Data Plane Network Data Service Descriptors requested by the DPSS. This validation is performed against the capabilities and policies of the serving Mobile Network Operator (MNO), as well as any applicable local or regional data protection regulations, taking into account the DPSS’s location and operational environment. If the request passes all validation checks, DPACa obtains a unique Data Pipeline Identifier from the Data Pipeline ID pool in preparation for establishing a data pipeline to support the requested data plane service operation. Further details regarding the retrieval of the Data Pipeline Identifier can be found in some embodiments. Based on the contents of the requested Data Plane Network Data Service Descriptors, DPACa identifies that the requested data plane service operation requires support from specific functional entities within the local domain. Accordingly, DPACa selects the necessary entities that are capable of hosting the Data Pipeline function, as determined by the criteria outlined in the descriptors. Once all required functional entities have been identified and selected to support the Data Pipeline operation, the DPACa or the Data Plane Orchestration Coordinator (DPOCa) sends the appropriate Data Plane Service Parameters — as defined in some embodiments — to the respective functional entities for execution.

[0139] Operation 3 : The DPACa sends the Data Pipeline Service Subscribe Request to the selected functional entities — Entity-X, Entity-Y, and Entity -Z — to notify them of their respective Data Plane Service Request parameters. This is done using the message DPAC_DataPipelineServiceSubscribe_Request(DataPipelineIdentifier, DPACalD, DP ACaDigital Signature, DPACaPublicKey, DataPlaneServiceParametersTuple), as specified in some embodiments. In this example, Functional Entity-X acts as the data sink, which requires metadata to be collected from Functional Entity-Y and Functional Entity-Z. Entity-X uses this metadata to perform data analytics and generate aggregated analytic outputs, which are necessary to support the Data Plane Service operation initially requested by the Data Plane Service Supplicant.

[0140] Operations 4a, 4b, and 4c: The message DPAC_DataPipelineServiceSubscribe_Response(DataPipelineIdentifier, Operationstatus) is sent by Functional Entity-X, Entity-Y, and Entity-Z to the DPACa to indicate their confirmation and readiness to participate in the Data Pipeline operation. This response confirms that each entity has successfully received and processed the subscription request and is prepared to execute its respective role in supporting the requested Data Plane Service.

[0141] Operation 5: The DPACa notifies the Data Plane Service Supplicant by sending the message DPAC_Service_Notify(DPSShconTD, Operationstatus) to indicate that the operationfor the requested Data Plane Service has been successfully initiated. This notification confirms that all necessary functional entities have subscribed to the data pipeline and that the system is ready to proceed with the service execution.

[0142] Operation 6: The Data Pipeline Contributor within Function Entity-X, acting as the data consumer, initiates a solicited metadata transaction request to the DP AC for Metadata Profiles M and N. This is done by sending the message DPAC_MetaTrans_Subscribe_Request(DataConsumereDPID, DataConsumerhconTD, DataConsumerlD, DataConsumerDigital Signature, DataConsumerPublicKey, Metadata Profile {M, N}). The request includes two metadata profiles — M and N — specifying the types of metadata that the data consumer requires for processing.

[0143] Operations 7a and 7b: The DPACa initiates a Solicited Metadata Subscribe Request to Functional Entity-Y and Functional Entity -Z on behalf of Function Entity-X, in order to collect metadata corresponding to Profile-M and Profile-N. Upon receiving the request, both Entity-Y and Entity-Z evaluate the request and respond to DPACa with a Metadata Subscribe Response, thereby authorizing the requested metadata collection by Entity-X. This exchange ensures that metadata sharing is controlled, secure, and aligned with the specified profiles.

[0144] Operations 8 and 9: The DP AC consolidates and processes all the collected metadata responses from steps 7a and 7b. After aggregating the requested data sets, it sends a response to Function Entity-X using the message DPAC_MetaTrans_Subscribe_Response(DataConsumerhcorrID, Metadata, Transactionstatus). This response includes the aggregated metadata corresponding to the requested profiles, along with the transaction status, thereby completing the solicited metadata transaction process initiated by the data consumer.

[0145] Operation 10: Function Entity-X receives the metadata collected from Entity-Y and Entity-Z, and performs further data pre-processing before initiating data analytics on the aggregated metadata. After completing the analysis, Entity-X initiates an unsolicited Metadata Transaction Request to DPACa to store the resulting analytic data. It then notifies DPACa of the completion of the Data Plane Service Request, signaling that the data processing and service execution have been successfully finalized.

[0146] Operation 11 : Function Entity-X initiates a DPAC_MetaTrans_Create / Update_Request(DataSourceDPID, DataSourcehcorrlD, DataSourcelD, DataSourceDigital Signature, DataSourcePublicKey, MetadataProfile, DPACpubkey(Metadata)) message to DPACa in order to store the analytic output in the designated storage. This request includes the necessary identifiers, digital credentials, theassociated metadata profile, and the encrypted analytic data using DP AC's public key, ensuring both secure transmission and proper attribution of the data source.

[0147] Operation 12: DPACa informs the Data Plane Service Supplicant of the completion status of the Data Service Request by sending the message DPAC_Service_Notify(DPSShcorrID, OperationStatus). This notification indicates whether the operation was successful or failed, allowing the supplicant to take appropriate action based on the final outcome of the requested data plane service.

[0148] FIG. 17 illustrates data plane service request procedures to initiate and to trigger cross domains data pipeline operation configured to implement some embodiments presented herein. FIG. 17 illustrates that, in some embodiments, data plane service request procedures may include at least one of following operations.

[0149] Operation 1 : The Data Plane Service Supplicant (e.g., UE, RAN function, Core Network Function (NF), 0AM function, Application Function (AF), etc.) initiates a Data Plane Service Request to the Data Plane Access Controller (DPACa) to collect the necessary metadata required to support a specific type of data-driven network operation, such as Al-assisted integrated sensing model training. The supplicant sends this request in the form of DPAC_Service_Request(DataPlaneNetworkDataServiceDescriptorsID, DPSShcorrlD, DPSSID, DP SSDigi tai Signature, DPSSPublicKey). This message includes one or more of the following: the Data Plane Network Data Service Descriptors Identifier, which specifies the intended data- driven operation, the Data Plane Service Supplicant (DPSS) Correlation Identifier, used to correlate the service request between the supplicant and the DPACa, the supplicant’s identifier, the digital signature, or the public key, which together enable the DPACa to authenticate the identity of the supplicant. Note: It is assumed that the supplicant has already been registered with the DP AC and that mutual authentication has been successfully completed prior to initiating this request.

[0150] Operation 2: The DPACa first verifies the identity of the Data Plane Service Supplicant (DPSS). Upon successful verification, DPACa validates the Data Plane Network Data Service Descriptors requested by the DPSS against the serving Mobile Network Operator’s (MNO's) network capabilities and policies, as well as applicable local or regional data protection regulations, taking into consideration the DPSS’s location and operational environment. If the request passes all validation checks, DPACa obtains a unique Data Pipeline Identifier from the Data Pipeline ID Pool in preparation for establishing a data pipeline to support the requested data plane service operation. Further details on the allocation of the Data Pipeline ID can be found in some embodiments. Based on the content of the requested Data Plane Network Data Service Descriptors, DPACa may determine that the operation requires support from functional entitieslocated in another domain, such as Domain-b. In this case, DPACa involves the Data Plane Orchestration Coordinator (DPOCa) to communicate with the DPOC(s) of the other domain(s), in order to select and coordinate the required functional entities needed to fulfill the data plane service request.

[0151] Operation 3 : The DPOCa relays the requested Data Plane Service Request to Domain-b in order to initiate collaboration for the data pipeline operation that supports the requested data plane service. This is accomplished by sending a DPOC_Service_Request(DataPlaneNetworkDataServiceDescriptorsID, DPOCahcorrlD, DPOCalD, DPOCaDigital Signature, DPOCaPublicKey, DataPipelineldentifier) message. The request includes one or more of the following: : the Data Plane Network Data Service Descriptors Identifier, which specifies the target data-driven network operation; the DPOCa-specified correlation identifier (DPOCahcorrlD) to track and correlate the service request between the two DPOCs; DPOCa’ s identifier, digital signature, or public key, allowing DPOCb to verify DPOCa’ s identity; and the Data Pipeline Identifier, which is used to coordinate the data pipeline operation across domains. Note: It is assumed that DPOCa and DPOCb have already mutually authenticated each other prior to this exchange.

[0152] Operation 4: The DPOCb receives the Data Plane Service Request from DPOCa, along with the accompanying Network Data Service Descriptors information. DPOCb then coordinates with DPACb to agree on a unique Data Pipeline Identifier, and to identify and select the necessary functional entity that supports the Data Pipeline Contributor function and meets the functional and performance criteria specified in the target Data Plane Network Service Descriptors. Once the unique Data Pipeline Identifier is agreed upon and the participation of the selected Data Pipeline Contribute^ s) is confirmed, the information of the selected functional entity(ies) hosting the Data Pipeline Contributor(s) is provided back to DPOCa. Note 1 : For detailed procedures on obtaining and agreeing upon a unique Data Pipeline Identifier for crossdomain data pipeline operations, refer to some embodiments. Operations 3 to 5 in this embodiment are partially superseded by the procedures outlined in some embodiments regarding the negotiation and retrieval of the Data Pipeline ID. Note 2: The specific details regarding how DP AC verifies the resource requirements of the Data Pipeline Contributor to support the target Data Plane Service Request are outside the scope of this disclosure.

[0153] Operations 5a and 5b: The DPOCb responds to DPOCa with information about the selected functional entity(ies) that will provide Data Pipeline Contributor support for the requested Data Plane Service Request. This response is sent using the message DPOC_Service_Response(DPOCahconTD, DataPipelineContributorInfo(FunctionEntityTuple(FunctionalType, Identifier)), which includesone or more functional entities that have been selected to participate in the data pipeline operation. Note: If DPOCb or DPACb fails to identify any appropriate functional entity to support the requested Data Plane Service, the returned list will be empty. In such a case, DPACa will notify the Data Plane Service Supplicant of the operation failure via the message DPAC_Service_Notify(DPSShcorrID, OperationStatus) and skip the subsequent procedures related to pipeline setup and execution.

[0154] Operation 6: While the DPOCa coordinates with other DPOC(s) to support the requested Data Plane Service Request, the DPACs proceed to select the required functional entity(ies) that host the necessary Data Pipeline Contributor functions. This selection is based on the criteria specified in the Data Plane Network Data Service Descriptors. Once all the functional entities needed to support the Data Pipeline operation for the requested Data Plane Service are identified, the DPACs or DPOCa send the corresponding Data Plane Service Parameters, as defined in some embodiments, to the respective functional entities. Note: The specific procedures by which the DP AC verifies whether a Data Pipeline Contributor meets the resource requirements for supporting the target Data Plane Service Request are outside the scope of this disclosure.

[0155] Operation 7a: DPACa sends the Data Pipeline Service Subscribe Request, i.e., DPAC_DataPipelineServiceSubscribe_Request(DataPipelineIdentifier, DPACalD, DP ACaDigital Signature, DPACaPublicKey, DataPlaneServiceParametersTuple (see some embodiments)), separately to each of the selected functional entities within its local domain that will act as Data Pipeline Contributors. Each request contains the respective Data Plane Service Parameters as specified in some embodiments. Upon receiving the request, each Data Pipeline Contributor proceeds with local resource provisioning and configuration to support the Data Pipeline operation based on the parameters provided. This includes binding its local resources and configurations to the assigned Data Pipeline Identifier received from DPACa. For further details on the local binding of the Data Pipeline Identifier, refer to some embodiments. Once the configuration is complete, each Data Pipeline Contributor sends a Subscribe Response back to DPACa, confirming its readiness to participate in the Data Pipeline operation.

[0156] Operation 7b- 1 : DPOCa sends DPOCb an individual Data Pipeline Service Subscribe Request for each selected functional entity in Domain-b. The request is sent using the message DPOC_DataPipelineServiceSubscribe_Request(DataPipelineIdentifier, DPOCalD, DPOCaDigital Signature, DPOCaPublicKey, FunctionalEntity Identifier, DataPlaneServiceParametersTuple (see some embodiments)). This message instructs DPOCb to relay the request to the already selected functional entity, which serves as a Data Pipeline Contributor in Domain-b. The request includes the respective Data Plane Service Parameters, asspecified in some embodiments, enabling the selected functional entity to prepare for its role in the Data Pipeline operation.

[0157] Operations 7b-2 and 7b-3: DPACb transposes the Data Pipeline Service Subscribe Request received from DPOCb into a local data pipeline service subscribe request directed to the target functional entity. This is done using the message DPAC_DataPipelineServiceSubscribe_Request(DataPipelineIdentifier, DPACblD, DP ACbDigi tai Signature, DPACbPublicKey, FunctionalEntity Identifier, DataPlaneServiceParametersTuple (see some embodiments)). Upon receiving the request, each Data Pipeline Contributor proceeds with local resource provisioning and configuration to support the Data Pipeline operation in accordance with the parameters received. This includes binding its local resources and configurations to the assigned Data Pipeline Identifier provided by DPACb. For further details on the local binding process, refer to some embodiments. After completing the provisioning, each Data Pipeline Contributor sends a Subscribe Response to DPACb, confirming its readiness to participate in the Data Pipeline operation.

[0158] Operation 8: Once DPACa receives confirmation from all selected Data Pipeline Contributors indicating their readiness to proceed with the data pipeline operation, DPACa notifies the Data Plane Service Supplicant that the requested Data Plane Service has been successfully initiated. This notification is sent using the message DPAC_Service_Notify(DPSShconTD, OperationStatus), confirming that the setup phase has been completed and the service is ready to operate as requested.

[0159] Operation 9: At this point, all Data Pipeline Contributors of the selected functional entities have been provided with their respective Data Plane Service Parameter information. Each Data Pipeline Contributor proceeds with its operational procedures in accordance with the specific Data Plane Network Data Service Descriptors. These procedures may include subscribing to the designated pipeline data source for data collection and subsequently exposing the raw or processed data to the next functional entity in the pipeline. A Data Pipeline Contributor may also perform further pre-processing and / or data labeling to prepare the data for potential downstream tasks such as data analysis, storage, model training, or inference operations. As each functional entity receives information about other relevant functional entities as part of the Data Plane Service Parameters, the Data Pipeline Contributor within a given functional entity is able to recognize its subsequent counterpart(s). This enables it to advance to the next step, such as forwarding processed output to the next entity for further or final operations in the pipeline. The initial DP AC, referred to as DPACa, is responsible for initiating the Data Pipeline Operation Monitoring both within its own domain and across domains. Monitoring status is maintained in the respective local domain, and any abnormal behaviordetected during the operation will be reported to DPACa for logging. The specific details of the monitoring process are outside the scope of this disclosure. In any event — whether the data pipeline operation fails, is interrupted, or completes — the corresponding local serving DP AC may be notified of the operation status. In cross-domain scenarios, the local DP AC may in turn notify the DPOC, which will relay the operation status back to the initial DPACa.

[0160] Operations 10 and 11 : Function Entity-X from the local domain and Function Entity-Y from the partner domain notify DPACa / DPOCa of the completion of their respective data pipeline operations related to the Data Service Request. This notification indicates that both entities have successfully executed their assigned roles within the data pipeline and have fulfilled the requirements specified for the requested Data Plane Service.

[0161] Operation 12: Once DPACa is informed of the completion of the data pipeline service operation, it will notify the Data Plane Service Supplicant of the final status by sending the message DPAC_Service_Notify(DPSShconTD, OperationStatus). This message confirms whether the requested Data Plane Service was successfully completed or encountered any issues during execution.

[0162] FIG. 18 illustrates procedures for data pipeline ID negotiation and allocation configured to implement some embodiments presented herein. FIG. 18 illustrates that, in some embodiments, procedures for data pipeline ID negotiation and allocation may include at least one of following operations.

[0163] Operation 1 : The Data Plane Supplicant initiates a Data Plane Network Data Service Request to its serving DPAC-A by sending the message DPAC_Service_Request(DataPlaneNetworkDataServiceDescriptorID, DPSShcorrlD, DPSSID, DP SSDigi tai Signature, DPSSPublicKey). This request includes one or more of the following: the Data Plane Network Data Service Descriptor ID, a correlation ID (DPSShcorrlD) to track the request, the supplicant’s identifier (DPSSID), the digital signature, or public key of the supplicant to enable DPAC-A to verify its identity.

[0164] Operation 2: Once DPAC-A validates the identity of the supplicant and confirms the legitimacy of the request, and if the system resource estimation is sufficient, it proceeds to request the allocation of a unique Data Pipeline ID in preparation for the Data Pipeline operation. Based on the Data Plane Network Data Service Descriptor, the DP AC service request may require a cross-domain data pipeline operation. In such cases, DPAC-A will request a list of available Data Pipeline IDs from the Data Pipeline ID Pool to coordinate across domains. Otherwise, it will request a single ID for intra-domain operation.

[0165] Operation 3 : DPAC-A sends a request to Data Pipeline ID Pool -A using the message DP_PipelineIDPool_Subscribe_Request(DPACaID, DP ACaDigi tai Signature, DPACaPublicKey, DPACaCorrlD, [ID-List]). This request includes one or more of the following: DPAC-A’ s identifier, digital signature, public key, the correlation ID for the request, or, optionally, a list of requested IDs. Note: It is assumed that DPAC-A has already discovered its serving Data Pipeline ID Pool-A prior to initiating this request.

[0166] Operation 4: Data Pipeline ID Pool-A receives the request from DPAC-A and proceeds to allocate one or more unused Data Pipeline IDs. If only a single ID is allocated, the Data Pipeline ID Pool will mark that ID as “unavailable”, indicating that it is reserved and cannot be assigned to any other request until released.

[0167] Operation 5 : Data Pipeline ID Pool-A responds to DPAC-A's request for Data Pipeline ID allocation by sending the message DP_PipelineIDPool_Subscribe_Response(DPACaCorrID, DataPipelinelD(s)). This response includes the correlation ID provided by DPAC-A and the allocated Data Pipeline ID(s), confirming the successful reservation of the ID(s) for the upcoming Data Pipeline operation.

[0168] Operation 6: DPAC-A determines whether the Data Plane Network Data Service Request requires cross-domain support. If so, it relays the Data Pipeline Service Request to its corresponding DPOC-A, which then extends the service request to other relevant DPOCs. If cross-domain support is not required, DPAC-A proceeds directly to operation 16.

[0169] Operation 7: DPOC-A initiates a DPOC Service Request to DPOC-B by sending the message DPOC_Service_Request(DataPlaneNetworkDataServiceDescriptorID, DPOCahcorrlD, DPOCalD, DPOCaDigital Signature, DPOCaPublicKey, List of Data Pipeline IDs). This message includes one or more of the following: the Data Plane Network Data Service Descriptor ID, a correlation ID for tracking the request, DPOC-A’ s identifier, its digital signature, or public key for authentication, as well as the list of allocated Data Pipeline IDs intended for coordination across domains.

[0170] Operation 8: DPOC-B verifies the identity of DPOC-A and then relays the request to DPAC-B. Upon receiving the request, DPAC-B contacts Data Pipeline ID Pool-B to determine whether any of the Data Pipeline IDs in the provided list are usable within its local domain to support the requested Data Pipeline operation. This step ensures ID consistency and operational compatibility across domains.

[0171] Operation 9: DPAC-B sends a DP_PipelineIDPool_Subscribe_Request(DPACbID, DP ACbDigi tai Signature, DPACbPublicKey, DPACaCorrlD, List of Data Pipeline IDs) to Data Pipeline ID Pool-B in order to identify a usable Data Pipeline ID from the provided list. Thisrequest includes one or more of the following: DP AC -B’s identifier, digital signature, public key for authentication, the correlation ID from DPAC-A, or the list of candidate Data Pipeline IDs to be evaluated for compatibility within the local domain.

[0172] Operation 10: If none of the Data Pipeline IDs from the provided list is usable within the DPAC-B domain, Data Pipeline ID Pool-B suggests a list of alternative IDs to DPAC-B.Otherwise, Data Pipeline ID Pool-B selects one valid ID from the list to be used within its local domain for the requested Data Plane Network Data Service Request. This ensures proper coordination and compatibility for the Data Pipeline operation across domains.

[0173] Operation 11 : DPAC-B sends a DP_PipelineIDPool_Subscribe_Response(DPOCbID, DPOCbDigi tai Signature, DPOCbPublicKey, DPOCaCorrlD, one or more IDs) message. This response includes one or more of the following: DPOC-B’s identifier, digital signature, public key, the correlation ID provided by DPOC-A, or one or more Data Pipeline IDs that have been confirmed as usable for the requested Data Pipeline operation within the local domain.

[0174] Operation 12: DPAC-B relays the response to DPOC-B, which then sends the message DPOC_Service_Response(DPOCahconTD, one or more IDs) to DPOC-A. This response includes the correlation ID originally provided by DPOC-A and the one or more Data Pipeline IDs that have been confirmed for use in the cross-domain Data Pipeline operation.

[0175] Operation 13 : If more than one ID is returned in the response to DPOC-A, this implies that an additional round of Data Pipeline ID negotiation is required. A new request must be initiated to determine a mutually acceptable and usable ID for the Data Pipeline operation across the involved domains.

[0176] Operation 14: DPAC-A sends an additional inquiry to Data Pipeline ID Pool-A regarding the list of IDs that were rejected and suggested by the other domain. This is done by sending the message DP_PipelineID_Pool_Subscribe_Verify_Request(DPACaID,DP ACaDigital Signature, DPACaPublicKey, DPACaCorrlD, list of rejected IDs, list of suggested IDs). The request includes one or more of the following: DPAC-A’ s identifier, digital signature, public key, the correlation ID, the relevant lists of rejected, or suggested Data Pipeline IDs for verification and reconciliation.

[0177] Operation 15: The Data Pipeline ID Pool releases any rejected IDs that had been previously reserved for DPAC-A. It then evaluates the suggested IDs to determine if any are usable. If one or more usable IDs are identified, the pool selects one and marks it as "unavailable" before responding to DPAC-A. If none of the suggested IDs are suitable, the pool instead provides a new list of alternative IDs to DPAC-A for further consideration.

[0178] Operation 16: The Data Pipeline ID Pool sends a DP_PipelineID_Pool_Subscribe_Verify_Response(DPACaCorrID, one or more IDs) message to DPAC-A. Operations 7 to 16 are then repeated as necessary until a unique Data Pipeline ID is agreed upon by all domains involved in the specific Data Pipeline operation. Note 1 : The crossdomain Data Pipeline ID negotiation process is conducted with one external domain at a time to maintain better control and coordination. Note 2: Once a common Data Pipeline ID is agreed upon among the domains, each domain will proceed with the standard procedures outlined in operations 17 to 21 below.

[0179] Operation 17: Once the Data Pipeline ID is successfully identified, DPAC-A sends a DPAC_DataPipelineServiceSubscribe_Request(DataPipelineIdentifier, DPACalD,DP ACaDigital Signature, DPACaPublicKey, DataPlaneServiceParametersTuple (see Clause 1.4)) message to the selected candidate Data Pipeline Contributor-X. This request includes the newly allocated Data Pipeline ID and serves as a formal invitation for Contributor-X to participate in the specified Data Pipeline operation. The message also contains all relevant Data Plane Service Parameters necessary for Contributor-X to provision its resources and configure its role within the pipeline.

[0180] Operation 18: If Data Pipeline Contributor-X determines that it is feasible to participate in the requested Data Pipeline operation, it proceeds with the binding of the Data Pipeline ID to its local resources and configurations in preparation for the operation. Once the necessary provisioning is completed, Contributor-X responds to DPAC-A with a confirmation of its participation in the Data Pipeline operation.

[0181] Operation 19: Data Pipeline Contributor-X confirms its participation in the Data Pipeline operation by sending a DPAC_DataPipelineServiceSubscribe_Response(DataPipelineIdentifier, DPACalD) message to DPAC-A. This response indicates that Contributor-X has successfully completed the necessary preparations and is ready to support the specified Data Pipeline operation.

[0182] Operation 20: Once the Data Pipeline operation is completed, Data Pipeline Contributor- X will release its local resources and configurations and unbind them from the associated Data Pipeline ID. Following this, DPAC-A will return the Data Pipeline ID to the ID pool, making it available for future Data Pipeline operations.

[0183] Operation 21 : DPAC-A sends a DP_PipelineID_Pool_Subscribe_Notify(DPACaID, DP ACaDigital Signature, DPACaPublicKey, DPACaCorrlD, DataPipelinelD) message to the Data Pipeline ID Pool to formally release the Data Pipeline ID. This message includes one or more of the following: DPAC-A’ s identifier, digital signature, public key, the correlation ID, orthe specific Data Pipeline ID being released, allowing the pool to mark it as available for future use.

[0184] Operation 22: DPAC-A informs the Data Plane Service Supplicant of the completion status of the Data Service Request by sending the message DPAC_Service_Notify(DPSShcorrID, OperationStatus). This notification indicates whether the requested Data Plane Service operation was successfully completed or encountered a failure, allowing the supplicant to take appropriate follow-up actions.

[0185] In summary, some embodiments of this disclosure are to describe how to design the 6G system to establish a data pipeline capable of delivering data-driven services that support emerging AI / ML training and inference, sensing, and digital twin operations. These operations rely on metadata collected from multiple pipeline data sources to enable autonomous intelligent system behavior, where the contributing system entities may be distributed across one or more system domains (i.e., operator-configured administrative domains) and interconnected over arbitrary network topologies. Without the proposed solution, the network would be unable to provide the necessary data-driven services to support AI / ML, sensing, and digital twin functionalities. Consequently, it would not be possible to enable autonomous intelligent system operations that depend on the ingestion and coordination of metadata from diverse and distributed data sources.

[0186] Commercial interests for some embodiments are as follows. 1. Solve issues in the prior art and other issues. 2. Enable efficient, scalable, and context-aware data integration across distributed system domains. 3. empower autonomous intelligent systems with timely and reliable metadata for enhanced AI / ML, sensing, and digital twin operations. Some embodiments of the present disclosure can be used in many applications. Some embodiments of the present disclosure are used by chipset vendors, video system development vendors, automakers including cars, trains, trucks, buses, bicycles, moto-bikes, helmets, and etc., drones (unmanned aerial vehicles), smartphone makers, communication devices for public safety use, AR / VR / MR device maker for example gaming, conference / seminar, education purposes. Some embodiments of the present disclosure are a combination of “techniques / processes” that can be adopted in video standards to create an end product. Some embodiments of the present disclosure propose technical mechanisms. The at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure may be used for current and / or new / future standards regarding communication systems such as a UE, a base station, a network device, and / or a communication system. Compatible products follow at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure. The proposed solution, method, system, and apparatus are widely used in a UE, a base station, a network device, and / ora communication system. With the implementation of the at least one proposed solution, method, system, and apparatus of some embodiments of the present disclosure, at least one modification / improvement to methods and apparatus for data plane service are considered for standardizing.

[0187] In some embodiments of the present disclosure, a network device is provided. The network device includes a memory, a transceiver, and a processor coupled to the memory and the transceiver. The network device is configured to perform the above-described method. In some embodiments, the network device may be implemented as or within a computing device, such as computing device 1100 illustrated in FIG. 19. As shown, computing device 1100 may include a processor 1112 communicatively coupled to a memory 1114 and configured to execute computer-executable program code stored therein to perform the disclosed operations. The processor may include a microprocessor, an application-specific integrated circuit (ASIC), or other suitable processing units.

[0188] In some embodiments of the present disclosure, a non-transitory machine-readable storage medium is provided. The storage medium has stored thereon instructions that, when executed by a computer (e.g., the computing device 1100 of FIG. 19), cause the computer to perform the method described above. In some embodiments of the present disclosure, a chip is provided. The chip includes a processor configured to call and run a computer program stored in a memory, such that the device in which the chip is installed (e.g., as part of computing device 1100 or communication system 1200 of FIG. 20) performs the method described above. In some embodiments of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program that causes a computer (e.g., processor 1112 in FIG. 19 or components in FIG. 20 such as baseband circuitry 1220 or application circuitry 1230) to execute the method described above. In some embodiments of the present disclosure, a computer program product is provided. The computer program product includes a computer program that, when executed by a computer, causes the computer to perform the method described above. In some embodiments of the present disclosure, a computer program is provided that causes a computer to perform the method described above. The computing environment may include components such as RF circuitry 1210, application circuitry 1230, and memory / storage 1240 as depicted in FIG. 20, which collectively support the execution and operation of the data-driven method described herein.

[0189] FIG. 19 is an example of a computing device 1100 according to an embodiment of the present disclosure. Any suitable computing device can be used for performing the operations described herein. For example, FIG. 19 illustrates an example of the computing device 1100 that can implement apparatuses and / or methods illustrated in FIG. 2 to FIG. 18 using any suitablyconfigured hardware and / or software. In some embodiments, the computing device 1100 can include a processor 1112 that is communicatively coupled to a memory 1114 and that executes computer-executable program code and / or accesses information stored in the memory 1114. The processor 1112 may include a microprocessor, an application-specific integrated circuit (“ASIC”), a state machine, or other processing device. The processor 1112 can include any of a number of processing devices, including one. Such a processor can include or may be in communication with a computer-readable medium storing instructions that, when executed by the processor 1112, cause the processor to perform the operations described herein.

[0190] The memory 1114 can include any suitable non-transitory computer-readable medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, a memory chip, a read-only memory (ROM), a random access memory (RAM), an application specific integrated circuit (ASIC), a configured processor, optical storage, magnetic tape or other magnetic storage, or any other medium from which a computer processor can read instructions. The instructions may include processor-specific instructions generated by a compiler and / or an interpreter from code written in any suitable computer-programming language, including, for example, C, C++, C#, visual basic, java, python, perl, javascript, and actionscript.

[0191] The computing device 1100 can also include a bus 1116. The bus 1116 can communicatively couple one or more components of the computing device 1100. The computing device 1100 can also include a number of external or internal devices such as input or output devices. For example, the computing device 1100 is illustrated with an input / output (“I / O”) interface 1118 that can receive input from one or more input devices 1120 or provide output to one or more output devices 1122. The one or more input devices 1120 and one or more output devices 1122 can be communicatively coupled to the I / O interface 1118. The communicative coupling can be implemented via any suitable manner (e.g., a connection via a printed circuit board, connection via a cable, communication via wireless transmissions, etc.). Non-limiting examples of input devices 1120 include a touch screen (e g., one or more cameras for imaging a touch area or pressure sensors for detecting pressure changes caused by a touch), a mouse, a keyboard, or any other device that can be used to generate input events in response to physical actions by a user of a computing device. Non-limiting examples of output devices 1122 include a liquid crystal display (LCD) screen, an external monitor, a speaker, or any other device that can be used to display or otherwise present outputs generated by a computing device.

[0192] The computing device 1100 can execute program code that configures the processor 1112 to perform one or more of the operations described above with respect to someembodiments illustrated in FIG. 2 to FIG. 18. The program code may be resident in the memory 1114 or any suitable computer-readable medium and may be executed by the processor 1112 or any other suitable processor.

[0193] The computing device 1100 can also include at least one network interface device 1124. The network interface device 1124 can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks 1128. Non limiting examples of the network interface device 1124 include an Ethernet network adapter, a modem, and / or the like. The computing device 1100 can transmit messages as electronic or optical signals via the network interface device 1124.

[0194] FIG. 20 is a block diagram of an example of a communication system 1200 according to an embodiment of the present disclosure. Embodiments described herein may be implemented into the communication system 1200 using any suitably configured hardware and / or software. FIG. 20 illustrates the communication system 1200 including a radio frequency (RF) circuitry 1210, a baseband circuitry 1220, an application circuitry 1230, a memory / storage 1240, a display 1250, a camera 1260, a sensor 1270, and an input / output (VO) interface 1280, coupled with each other at least as illustrated.

[0195] The application circuitry 1230 may include a circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include any combination of general -purpose processors and dedicated processors, such as graphics processors, application processors. The processors may be coupled with the memory / storage and configured to execute instructions stored in the memory / storage to enable various applications and / or operating systems running on the system. The communication system 1200 can execute program code that configures the application circuitry 1230 to perform one or more of the operations described above with respect to FIG. 2 to FIG. 18. The program code may be resident in the application circuitry 1230 or any suitable computer-readable medium and may be executed by the application circuitry 1230 or any other suitable processor.

[0196] The baseband circuitry 1220 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processors may include a baseband processor. The baseband circuitry may handle various radio control functions that may enable communication with one or more radio networks via the RF circuitry. The radio control functions may include, but are not limited to, signal modulation, encoding, decoding, radio frequency shifting, etc. In some embodiments, the baseband circuitry may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry may support communication with an evolved universal terrestrial radio access network (EUTRAN) and / or other wireless metropolitan area networks(WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0197] In various embodiments, the baseband circuitry 1220 may include circuitry to operate with signals that are not strictly considered as being in a baseband frequency. For example, in some embodiments, baseband circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency. The RF circuitry 1210 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. In various embodiments, the RF circuitry 1210 may include circuitry to operate with signals that are not strictly considered as being in a radio frequency. For example, in some embodiments, RF circuitry may include circuitry to operate with signals having an intermediate frequency, which is between a baseband frequency and a radio frequency.

[0198] In various embodiments, the transmitter circuitry, control circuitry, or receiver circuitry discussed above with respect to apparatuses and / or methods illustrated in FIG. 2 to FIG. 18 may be embodied in whole or in part in one or more of the RF circuitry, the baseband circuitry, and / or the application circuitry. As used herein, “circuitry” may refer to, be part of, or include an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and / or a memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable hardware components that provide the described functionality. In some embodiments, the electronic device circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, some or all of the constituent components of the baseband circuitry, the application circuitry, and / or the memory / storage may be implemented together on a system on a chip (SOC). The memory / storage 1240 may be used to load and store data and / or instructions, for example, for system. The memory / storage for one embodiment may include any combination of suitable volatile memory, such as dynamic random access memory (DRAM)), and / or non-volatile memory, such as flash memory.

[0199] In various embodiments, the I / O interface 1280 may include one or more user interfaces designed to enable user interaction with the system and / or peripheral component interfaces designed to enable peripheral component interaction with the system. User interfaces may include, but are not limited to a physical keyboard or keypad, a touchpad, a speaker, a microphone, etc. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface. In various embodiments, the sensor 1270 may include one or more sensing devices to determine environmental conditions and / or location information related to the system. In some embodiments, the sensors may include, but are not limited to, a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may also be part of, or interact with, the baseband circuitry and / or RF circuitry to communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[0200] In various embodiments, the display 1250 may include a display, such as a liquid crystal display and a touch screen display. In various embodiments, the communication system 1200 may be a mobile computing device such as, but not limited to, a laptop computing device, a tablet computing device, a netbook, an Ultrabook, a smartphone, an AR / VR glasses, etc. In various embodiments, system may have more or less components, and / or different architectures. Where appropriate, methods described herein may be implemented as a computer program. The computer program may be stored on a storage medium, such as a non-transitory storage medium.

[0201] A person having ordinary skill in the art understands that each of the units, algorithm, and steps described and disclosed in the embodiments of the present disclosure are realized using electronic hardware or combinations of software for computers and electronic hardware.Whether the functions run in hardware or software depends on the condition of application and design requirement for a technical plan. A person having ordinary skill in the art can use different ways to realize the function for each specific application while such realizations should not go beyond the scope of the present disclosure. It is understood by a person having ordinary skill in the art that he / she can refer to the working processes of the system, device, and unit in the above-mentioned embodiment since the working processes of the above-mentioned system, device, and unit are basically the same. For easy description and simplicity, these working processes will not be detailed.

[0202] It is understood that the disclosed system, device, and method in the embodiments of the present disclosure can be realized with other ways. The above-mentioned embodiments are exemplary only. The division of the units is merely based on logical functions while other divisions exist in realization. It is possible that a plurality of units or components are combined or integrated in another system. It is also possible that some characteristics are omitted or skipped. On the other hand, the displayed or discussed mutual coupling, direct coupling, or communicative coupling operate through some ports, devices, or units whether indirectly or communicatively by ways of electrical, mechanical, or other kinds of forms.

[0203] The units as separating components for explanation are or are not physically separated. The units for display are or are not physical units, that is, located in one place or distributed on aplurality of network units. Some or all of the units are used according to the purposes of the embodiments. Moreover, each of the functional units in each of the embodiments can be integrated in one processing unit, physically independent, or integrated in one processing unit with two or more than two units.

[0204] If the software function unit is realized and used and sold as a product, it can be stored in a readable storage medium in a computer. Based on this understanding, the technical plan proposed by the present disclosure can be essentially or partially realized as the form of a software product. Or, one part of the technical plan beneficial to the conventional technology can be realized as the form of a software product. The software product in the computer is stored in a storage medium, including a plurality of commands for a computational device (such as a personal computer, a server, or a network device) to run all or some of the steps disclosed by the embodiments of the present disclosure. The storage medium includes a USB disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a floppy disk, or other kinds of media capable of storing program codes.

[0205] While the present disclosure has been described in connection with what is considered the most practical and preferred embodiments, it is understood that the present disclosure is not limited to the disclosed embodiments but is intended to cover various arrangements made without departing from the scope of the broadest interpretation of the appended claims.

Claims

What is claimed is:

1. A wireless communication method for data plane service, performed by a network node, comprising: receiving, from a data plane service supplicant (DPSS), a data plane service request, wherein the data plane service request comprises one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; verifying the DPSS based on the data plane service request; and transmitting a data pipeline service subscribe request to one or more functional entities, wherein the data pipeline service subscribe request comprises data plane service parameters corresponding to each respective functional entity.

2. The method of claim 1, wherein the network node comprises a data plane access controller (DPAC).

3. The method of claim 1, wherein the DPSS comprises a user equipment (UE), a radio access network (RAN) function node, a core network function (core NF) node, an operation, administration and maintenance (OAM) function node, or an application function (AF) node.

4. The method of claim 1, wherein if the DPSS is verified, validating data plane network data service descriptors based on capabilities, policies, and / or applicable data protection regulations of a serving mobile network operator corresponding to a location or an environment of the DPSS.

5. The method of claim 4, further comprising: upon successful validation, obtaining a data pipeline identifier; selecting one or more local functional entities that support a data plane service operation; and transmitting data plane service parameters to the selected functional entities.

6. The method of claim 5, further comprising: transmitting a data pipeline service subscribe request to the selected functional entities, wherein at least one functional entity operates as a data sink and others operate as metadata sources for the data plane service operation.

7. The method of claim 6, further comprising: receiving a pipeline service subscribe response from each of the selected functional entities, the pipeline service subscribe response indicating confirmation of participation in a data pipeline operation.

8. The method of any one of claims 1 to 7, further comprising:transmitting, to the DPSS, a service notification comprising an operation status indicating initiation of the data plane service.

9. The method of any one of claims 1 to 8, further comprising: receiving, from a data consumer functional entity, a metadata transaction subscribe request comprising one or more metadata profiles required to support the data plane service operation.

10. The method of claim 9, further comprising: initiating one or more metadata subscribe requests to metadata source functional entities based on the one or more metadata profiles; and receiving metadata from the metadata source functional entities.

11. The method of claim 10, further comprising: aggregating the metadata; transmitting an aggregated metadata to the data consumer functional entity; and receiving, from the data consumer functional entity, a completion notification or analytic result to finalize the data plane service operation.

12. The method of any one of claims 1 to 11, further comprising initiating a cross-domain data pipeline operation by involving a data pipeline orchestration controller (DPOCa) to communicate with one or more remote domain orchestration controllers (DPOCbs) for functional entity selection and coordination.

13. The method of claim 12, wherein the data plane service request is exchanged between the DPOCa and the DPOCb.

14. The method of claim 12 or 13, wherein, upon confirmation of readiness from selected functional entities acting as data pipeline contributors, the network node notifies the DPSS of successful initiation or completion of the data plane service operation.

15. The method of any one of claims 1 to 14, wherein the network node obtains a data pipeline identifier from a data pipeline identifier pool based on whether the data plane service operation involves a cross-domain pipeline.

16. The method of claim 15, wherein, for a cross-domain operation, the network node coordinates with a DPOCa to negotiate the data pipeline identifier with a remote domain through an iterative exchange of pipeline identifier requests and responses until a mutually agreed identifier is selected.

17. The method of claim 15 or 16, wherein, upon completion of the data plane service operation, the network node releases the data pipeline identifier to the data pipeline identifier pool and notifies the DPSS of an operation status.

18. A network node, comprising: a transmitter configured to receive, from a data plane service supplicant (DPSS), a data planeservice request, wherein the data plane service request comprises one or more of the following: a data plane network data service descriptor identifier indicating a type of a data-driven network operation, a data plane service supplicant correlation identifier to correlate the data plane service request between the DPSS and the network node, a DPSS identifier (DPSSID), a digital signature of the DPSS, or a public key of the DPSS; and a verifier configured to verify the DPSS based on the data plane service request; wherein the transceiver is further configured to transmit a data pipeline service subscribe request to one or more functional entities, and the data pipeline service subscribe request comprises data plane service parameters corresponding to each respective functional entity.

19. The network node of claim 18, wherein the network node comprises a data plane access controller (DPAC).

20. The network node of claim 1, wherein the DPSS comprises a user equipment (UE), a radio access network (RAN) function node, a core network function (core NF) node, an operation, administration and maintenance (0AM) function node, or an application function (AF) node.

21. The network node of claim 18, wherein if the DPSS is verified, validating data plane network data service descriptors based on capabilities, policies, and / or applicable data protection regulations of a serving mobile network operator corresponding to a location or an environment of the DPSS.

22. The network node of claim 21, wherein upon successful validation, the transceiver is configured to obtain a data pipeline identifier; the verifier is configured to select one or more local functional entities that support a data plane service operation; and the transceiver is configured to transmit data plane service parameters to the selected functional entities.

23. The network node of claim 22, wherein the transceiver is configured to transmit a data pipeline service subscribe request to the selected functional entities, and at least one functional entity operates as a data sink and others operate as metadata sources for the data plane service operation.

24. The network node of claim 23, wherein the transceiver is configured to receive a pipeline service subscribe response from each of the selected functional entities, and the pipeline service subscribe response indicates confirmation of participation in a data pipeline operation.

25. The network node of any one of claims 18 to 24, wherein the transceiver is configured to transmit, to the DPSS, a service notification comprising an operation status indicating initiation of the data plane service.

26. The network node of any one of claims 18 to 25, wherein the transceiver is configured to receive, from a data consumer functional entity, a metadata transaction subscribe request comprising one or more metadata profiles required to support the data plane service operation.

27. The network node of claim 26, wherein the verifier is configured to initiate one or more metadata subscribe requests to metadata source functional entities based on the one or more metadata profiles; and the transceiver is configured to receive metadata from the metadata source functional entities.

28. The network node of claim 27, wherein the verifier is configured to aggregate the metadata; the transceiver is configured to transmit an aggregated metadata to the data consumer functional entity; and the transceiver is configured to receive, from the data consumer functional entity, a completion notification or analytic result to finalize the data plane service operation.

29. The network node of any one of claims 18 to 28, wherein the verifier is configured to initiate a cross-domain data pipeline operation by involving a data pipeline orchestration controller (DPOCa) to communicate with one or more remote domain orchestration controllers (DPOCbs) for functional entity selection and coordination.

30. The network node of claim 29, wherein the data plane service request is exchanged between the DPOCa and the DPOCb.

31. The network node of claim 29 or 30, wherein, upon confirmation of readiness from selected functional entities acting as data pipeline contributors, the transceiver notifies the DPSS of successful initiation or completion of the data plane service operation.

32. The network node of any one of claims 18 to 31, wherein the transceiver obtains a data pipeline identifier from a data pipeline identifier pool based on whether the data plane service operation involves a cross-domain pipeline.

33. The network node of claim 32, wherein, for a cross-domain operation, the verifier is configured to coordinate with a DPOCa to negotiate the data pipeline identifier with a remote domain through an iterative exchange of pipeline identifier requests and responses until a mutually agreed identifier is selected.

34. The network node of claim 32 or 33, wherein, upon completion of the data plane service operation, the verifier releases the data pipeline identifier to the data pipeline identifier pool, and the transceiver notifies the DPSS of an operation status.

35. A network device, comprising: a memory; a transceiver; and a processor coupled to the memory and the transceiver; wherein the network device is configured to perform the method of any one of claims 1 to 17.

36. Anon-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 17.

37. A chip, comprising: a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 17.

38. A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 17.

39. A computer program product, including a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 17.

40. A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 17.

Images