Data Plane Design for AI-Native 6G Networks

1 Introduction

Data plays a pivotal role in the deployment of artificial intelligence (AI) in 6G networks, necessitating massive amounts of high-quality training and test datasets. Incomplete or erroneous datasets can result in unreliable models, which will generate suboptimal output. However, the process of massive data collection is often labor-intensive and time-consuming. These challenges critically hinder access to sufficient quantities of high-quality datasets for AI applications.

Unprecedented volumes of data will be generated, transmitted, processed, and stored by an enormous number of data-driven applications that leverage the radio frequency (RF) sensing capability inherent in 6G networks. By leveraging this capability, a 6G network can effectively transform itself into a "sensor" that reads data from the physical world. Consequently, 6G sensing data will emerge as a vital data source for training AI models, driving the development of generative and interactive AI services. Specifically, if 1% of the capacity of 6G networks is allocated for sensing, the 6G sensing data volume is expected to reach the quettabyte (10³⁰) level per day for on-device AI models and the zettabyte (10²¹) level per day for cloud-based AI models at base stations (BSs). If this data is efficiently used for AI model training, the models can better adapt to real-world scenarios and deliver customized AI services.

As a fundamental component of 6G, network AI will employ a deep-edge architecture to facilitate extensive machine learning (ML) in a distributed and collaborative manner. Its primary objective is to intelligently connect a multitude of distributed intelligent agents for large-scale deployment of AI. This requires efficient, high-capacity, and low-latency transmission of massive amounts of data, including model parameters across a vast array of intelligent agents, which are crucial elements in the data as a service (DaaS) ecosystem. From the DaaS perspective, the network must provide flexible support for machine learning operations (MLOps), that is, to automate and streamline ML workflows and deployments.

1.1 Current Network Architecture for Connectivity Services

In today's typical mobile network architecture, the control plane (CP) and user plane (UP) play a key role in providing wireless access services for mobile users. The CP handles tasks such as establishing connections and controlling the forwarding of UP data, commonly referred to as session management within the 5G core. The UP is designed to forward network packets to their intended destinations efficiently. The following sections describe the CP and UP in more details.

1.1.1 Control Plane (CP): Service-based Interface

Figure 1 illustrates the service-based architecture (SBA) defined by the 3rd Generation Partnership Project (3GPP). In the SBA, the CP functions and common data repositories of a 5G network are distributed across a set of interconnected network functions (NFs). Each NF is granted permission to access the services provided by other NFs [1]. The SBA has a service-based interface (SBI) between the interconnected NFs on the 5G core (5GC) CP. The SBI acts as a communication bus, using the HTTP/2 protocol for communication across all the CP functions.

Figure 1 SBA of 5GC

In 5G networks, HTTP/2 connections are peer-to-peer connections, with messages flowing in both directions between NFs. An NF establishes a connection to another NF before sending request messages to it, and the receiving NF responds via the same connection. If the receiving NF needs to send messages to the originating NF, it sets up another connection in the opposite direction. These signaling messages contain small data packets of predefined sizes, and therefore, the overall traffic volume scales proportionally with the number of active user equipments (UEs).

1.1.2 User Plane (UP): GTP-U Tunnel

As illustrated in Figure 2, data traffic on the UP is carried by protocol data unit (PDU) sessions established between the UEs and the user plane function (UPF) deployed in the core network (CN) across the radio access network (RAN). To guarantee data transmission quality, data packets are first mapped to appropriate quality of service (QoS) flows and then transmitted through a specific data radio bearer (DRB) between the UE and the RAN node and then through an N3 GTP-U tunnel between the RAN node and the UPF in the CN. This paradigm can be considered session-oriented because data flows in dedicated tunnels.

Figure 2 5G PDU session

Both the CP and UP operate within a communication session-centric framework. The signaling procedures and user data packets are inherently associated with the UEs. Specifically, the CP sets up UP data tunnels for each session, facilitating signaling message exchange among various entities, including UEs, BSs, and CN functions, to maintain state synchronization.

1.2 Challenges

In addition to its primary function of providing connectivity services for UEs, 6G will expand into the realm of AI and sensing services, collectively referred to as "beyond-connectivity services." These services differ from traditional connectivity services, necessitating a shift from a connectivity-centric network design to a data-centric one. Consequently, the two planes of CP and UP are no longer applicable due to the following reasons.

• Massive data volume: 6G networks are expected to handle unprecedented amounts of data, a significant part of which will be generated by "beyond-connectivity services." The actual data volume in 6G networks is expected to significantly surpass current ITU-R forecasts, which are only based on mobile subscribers' data consumption [2]. With 6G's ubiquitous sensing capabilities, massive amounts of data will be generated and fed into algorithms designed to construct digital twins of the physical world. At the same time, with intelligence enabled, the distributed UEs and BSs, the CN, and the cloud will generate "AI data," including gradients, parameters, models, and tokens, which constitute yet another massive volume of non-connectivity data. Such enormous amounts of data cannot be handled by the CP (e.g., the SBI), which features reliable transmission of small data packets and short-term connections.
• Complex data topologies: Emerging 6G services involve complex data topologies across various data producers and consumers. The RAN nodes, UEs, and NFs are not connected in a simple and linear point-to-point manner. Unlike connectivity services, which are delivered only to UEs, "beyond-connectivity services" can reach any authenticated and authorized subscriber with network access. The current UP (e.g., the PDU session) establishes only one-to-one communication tunnels between the UEs and the UPF. This connection-oriented paradigm is incapable of handling the complex data topologies in 6G "beyond-connectivity services."
• Data orchestration requirement: Different from wireless access, the AI or sensing services run on demand, meaning that different AI or sensing services require the collaboration of different UEs, BSs, and NFs for service provisioning. From the service orchestration viewpoint, multiple UEs, BSs, and NFs with sensing capability/ computing power need to be orchestrated to deliver a service such as distributed learning. This requires automatic translation of service requirements into network configurations, which cannot be achieved with the current network structure.

With the advent of 5G and beyond, the ecosystem of connected intelligent devices is expanding rapidly, resulting in a significant increase in the amounts of data requiring real-time processing. Conventional session-centric approaches, which heavily rely on centralized brokers, are insufficient to meet the communication flow management requirements of large-scale distributed AI systems and collaborative sensing networks. Additionally, the conventional approaches face challenges in scaling up and meeting the latency and privacy requirements of the device-edge-cloud computing continuum. Thus, there is a pressing need for an innovative network architecture tailored for data management and processing in AI-capable 6G networks.

2 Data Plane (DP) for DaaS

Inspired by the decoupling of the CP and design of the UP in the CN, we propose a dedicated data plane (DP) in the 6G network architecture to improve the overall network flexibility and efficiency. The DP is capable of facilitating data flow on any topology, enabling flexible data services and efficient on-path data processing. Specifically, it breaks down service requirements into distinct data processing functions, including data collection, pre-processing, and analytics. It coordinates various network components involved in meeting service requirements [3]. The primary objective of the DP, which transmits non-connectivity data, is to streamline management and control. The non-connectivity data will be fed into AI algorithms for iterative optimization. The DP serves as the foundation for providing data services for both internal and external applications and services. Within the DP, two key components are defined: DO and DA, which are elaborated in the following sections.

2.1 Data Orchestration (DO)

Figure 3 Architecture of the 6G DP

In contrast to connectivity services, for which the network establishes tunnels from the UEs to the UPF, non-connectivity services require the involvement of multiple entities in service provisioning and delivery. These entities must collaborate effectively through proper orchestration. As illustrated in Figure 3, the DO serves as a conductor of the DP, overseeing data flows across network elements. By analyzing service requirements and translating them into network configurations, the DO ensures precise data flow within the DP — the data is delivered to the right processing units and applications at the right time.

The DO includes four essential components: DA registration, data flow engine, data flow management, and policy control. DA registration collects the capabilities of all DAs under the DO's management and uses the collected information to ensure efficient resource utilization. The data flow engine determines the sequence of actions and data transformations that need to be performed (e.g., filtering, aggregation, and forwarding) based on the service requirements and, by doing so, ensures that the data flows effectively across the system. Data flow management is responsible for overseeing the actual routing of data packets across the orchestrated data topology, considering factors such as network congestion, latency requirement, and resource availability. Policy control decides on policies regarding data security, access control, and privacy, ensuring that sensitive data is handled appropriately.

2.2 Data Agent (DA)

The DAs act as intelligent intermediaries within the DP throughout the data service lifecycle. They perform a range of functions, including data preprocessing, data transformation, local decision-making, data caching, and security enforcement. Specifically, DAs filter, aggregate, and compress raw data — for example, the in-phase and quadrature (I/Q) signals of ISAC data — to reduce network traffic and processing overhead. DAs convert sensing data into formats suitable for network AI algorithms or applications to facilitate data transmission. In distributed data processing scenarios, DAs perform basic analysis and make decisions based on locally collected data, thus eliminating the need for constant communication with centralized entities. Additionally, DAs support data caching to facilitate frequent data access and intermediate processing results, resulting in faster retrieval and enhanced efficiency. DAs also strengthen data security by implementing access control mechanisms and encryption protocols.

DAs can be deployed on various network nodes, such as UEs, BSs, network edge nodes, and CN nodes. DAs deployed on UEs or BSs perform preliminary data acquisition and local processing, including filtering and compression, before transmission. Deployed on edge computing nodes, they further process and analyze data, and potentially trigger real-time actions, feed the outcome to downstream DAs equipped with AI algorithms, or perform other actions. Furthermore, centralized DAs located in the CN can potentially handle more complex tasks like data aggregation from multiple data sources or feed data to centralized AI algorithms.

Based on the implementation mode, DAs can be classified into two types: embedded DAs and standalone DAs. Embedded DAs function as part of a network entity and are generally responsible for data collection and preprocessing. Standalone DAs play dedicated roles assigned by the DO. The data processing function (DPF) and data storage function (DSF) are two examples of standalone DAs that can be deployed in the RAN or CN. The DPF is responsible for processing data, including ISAC and AI data, while the DSF acts as a repository for long-term data storage.

2.3 Data Communication Proxy (DCP)

The implementation of DOs and DAs presents another challenge — the traditional data traffic pattern cannot meet the requirements of new data topologies. Particularly, a typical "beyond-connectivity service" powered by either network AI or wireless sensing involves a data topology composed of multiple data sources, data processing functions, and data sinks. Network AI and wireless sensing are transforming the mobile network into a data-intensive computing and big data analytics platform. However, traditional session-centric data communication methods for data transmission are insufficient to handle the data traffic generated by the "multiple-input-multiple-output" pattern. To address this issue, we propose a new logical function, namely the DCP, to handle the massive sensing and AI data featuring complex topologies and on-path data processing in 6G networks. As depicted in Figure 4, this function can provide efficient data distribution, overcoming the limitations of the traditional "connect-then-communicate" model.

Figure 4 DCP implementation options

In the current network architecture, data is ingested into the NFs via the UPF. In contrast, in our proposed architecture, the DCP serves as an intermediary data collector. It receives data and then efficiently distributes it to the corresponding NFs. By decoupling data producers from data consumers, the DCP enables asynchronous data exchange, allowing data producers to continue operating without waiting for responses from the consumers. The DCP can be implemented as a distributed system that comprises a message broker and multiple message queues. The message broker acts as an intermediary between the data sender and the receiver. It performs topic-based message routing from a publisher to a subscriber. The message queue is a data structure or container that facilitates communication between applications by sending, receiving, and storing messages. The Publish/Subscribe (Pub/Sub) communication pattern is used as the asynchronous messaging architecture, enabling messages to flow between entities without the need for the sender and the recipient to know each other's identity. The data producers publish messages of specific topics (that is, data categories into which messages can be organized) to the broker, and subscribers register their interest in specific topics with the broker.

There are two implementation options for the DCP: stateful DCP and stateless DCP. A stateful DCP stores the subscription and topic information in a table, and message routing is performed based on table lookup. A stateless DCP does not store the subscription and topic information locally, and message routing is performed based on the in-band information contained within the messages. The in-band information is a numerical representation of the data topology orchestrated and configured by the DO. In our implementation, which is described in detail in Section 3, data forwarding is realized as a modulo operation with the numerical representation of data topology as the input. The stateless DCP implementation has advantages, such as ultra-low latency data forwarding and high scalability, compared to the stateful implementation. Ultra-low latency is achieved by modulo-based data forwarding, which is much faster than the table lookup approach in the stateful implementation. High scalability is achieved by eliminating the massive configuration interactions between the DO and NFs involved in data service provisioning. In the stateless implementation, the DO needs to communicate only with the data source nodes for configuring the numerical representation of data topology contained within the data packets.

The DCPs can be deployed as independent NFs or reside with existing NFs. Figure 5 is an example of a computer vision task involving AI models for age and gender classification with human face detection and dog breed detection. In the example, the DO receives service requests and forms a data processing topology based on the capabilities of the registered DAs/DPFs. The data source is also considered a DA and assigned a unique topic ID, just like the participating DPFs. Here, the live video camera acts as the data source DA, publishing the video frame data with topic ID "Video" to the DCP. The DCP then pushes the video frame data to the queues and then to the data consumers who subscribed to the topic "Video." In this example, the data consumers are two DAs/DPFs, one powered by a human face detection model and the other with a dog breed detection model. After performing inference, the two DAs/DPFs publish new topics with IDs of "Human face" and "Dog" back to the DCP. The DCP then pushes the age/ gender detection results to the DAs/DPFs. In this process, data collection occurs asynchronously with model inference, enabling more sensing data to be collected during the prediction phase.

This DCP-based ML model orchestration is advantageous because the DCP allows an arbitrary number of queues to be bound to the broker. The same data can be reused across ML applications and the output of a model/epoch can be used as input in the upcoming model/epoch. The implementation of the DCP offers several advantages:

The DCP introduces buffers between the data producers and data consumers, ensuring a seamless and efficient data flow and preventing potential bottlenecks. This is particularly critical when handling large volumes of data, as any delay or interruption in data flows can significantly impact the performance of ML models.

The DCP accommodates variations in processing speed, preventing data loss while allowing all DPFs to operate at their own pace.

In collaboration with the DO, the DCP facilitates orderly task execution, which is crucial for successful ML model inference.

Figure 5 DCP-based ML model orchestration

3 Distributed Message Broker with Stateless Pub/Sub Messaging

3.1 Pub/Sub Paradigm

The advent of AI-powered applications, particularly those adopting advanced neural network architectures, requires a new approach to orchestrate and schedule AI processes within the in-network computing of 6G. We propose a stateless Pub/Sub messaging system to address the critical need for effective information flow management — from data sources to subscribers — on a large-scale distributed AI system.

The Pub/Sub paradigm decouples communication endpoints from one another and enables many-to-many data dissemination, such as in distributed learning, inferencing, and cooperative wireless sensing scenarios. This unique paradigm, featuring efficient data flow management, supports applications involving multiple data producers and consumers and can potentially meet the ML workflow management requirements, leading to substantial enhancement of network AI and MLOps capabilities. Additionally, the Pub/ Sub paradigm infuses more dynamism into ML workflow configuration, particularly in terms of response to real-time data or changes. Unlike traditional control flows, which are deterministic and pre-defined, the Pub/Sub paradigm allows for a more reactive and event-driven process, where various nodes on the data pipeline act as subscribers that listen to specific topics published by other nodes or publishers. The decoupling of data producers and consumers inherent in the Pub/Sub paradigm leads to better scalability and improved fault tolerance, as the failure of a single component does not directly impact other components.

3.2 CRT-based Stateless Message Broker

"Beyond-connectivity services" adopt the data-driven paradigm, in which the hidden value of data needs to be leveraged using statistical or ML methods. Considering that all nodes in a data topology need to process data and then send the data to downstream nodes, we propose an on-path data processing approach for the transmission of non-connectivity data, which reduces network bandwidth and ensures data privacy.

The traditional stateful message broker maintains a data forwarding table containing the destination addresses of all subscribers for each topic. Such a broker is required to look up the data forwarding table every time a message arrives, leading to more latency in data transmission. Another issue with the traditional broker is limited scalability, which results from all nodes having to maintain the data forwarding table.

To address these challenges, we propose to use a stateless approach to free the broker of "states." One of the solutions involves having the message data carry a coded "state" as in-band information. In this sense, the design goal of a stateless message broker is to find a function f that is capable of packetizing or transforming a data topology into numerical information suitable for encapsulation in data packets. In the meantime, its reverse function \(f^{-1} \) must be computationally simple. Considering these requirements, we design a function f and its reverse function \(f^{-1} \) based on the residue number system (RNS) and Chinese remainder theorem (CRT). According to the conventions of RNS literature, we refer to f as the reverse converter and \(f^{-1} \) as the forward converter.

• RNS

The RNS is a method for representing numbers and executing rapid calculations. It represents an integer as residues obtained by using a set of moduli. Because RNS arithmetic is executed digit-wise without carry propagation, a large number can be decomposed into smaller ones that can be operated on in parallel [4], leading to more efficient computation. The forward converter, shown on the right of Figure 6, converts a large integer X into a set of smaller integer residues (\(x_{1},x_{2},x_{3}\)) based on the chosen moduli \(M = (m_{1},m_{2},m_{3})\). These moduli are carefully selected to be coprime (mutually prime). Converting the number X to an RNS representation is a straightforward process — take the modulo X using each number in the moduli set, and the resulting set of numbers is the RNS representation of X. The formula is as follows:

\( x_i=Xmodm_{i} \)        (1)

For example, if X = 11 and the moduli set is (3, 4, 5), the RNS representation of 11 is (2, 3, 1), represented as follows:

\(11≡(2,3,1)_{RNS(3,4,5) }\)        (2)

Figure 6 RNS and CRT

• CRT

The CRT can be used as the reverse converter, since it can uniquely reconstruct an integer n from the residues of the Euclidean division of the integer by several integers that are pairwise coprime, as shown on the left of Figure 6. The formula is as follows:

\(P={\textstyle \Pi _{i=1}^{3}} m_{i} =m_{1}m_{2}m_{3}=3*4*5=60\)        (3)

\( M_i=\frac{P}{m_i},i=1,2,3,\)        (4)

\(CRTX=\left | \sum_{i=1}^{3}x_{i}M_{i} \left | M_{i}^{-1} \right |_{m_{i} } \right | _{P}\)        (5)

In these formulas, \( \left | M_{i}^{-1} \right |_{m_{i} } \) is the inverse modulo of \(M_{i}\).

In the context of the DCP, a data topology is represented as a tuple consisting of a moduliset and its residue representation, denoted as \((\vec{m},\vec{n} )\). The numerical representation X of a data topology is contained within the message data packets. The forward converter, which is computationally intensive and can be pre-calculated, is integrated into the data orchestration process for data forwarding. In this process, the residues represent the downstream data processing node within the data topology.

3.3 Performance Assessment

One of the primary design objectives of our distributed message broker with stateless Pub/Sub messaging is to minimize the message forwarding latency, which is crucial for "beyond-connectivity services" such as collaborative sensing and AI/ML-based autonomous driving. We define message forwarding latency as the time interval from when the first bit of an input message enters a queue to when the last bit exits the queue. Several factors, including the message size, message arrival rate, and processing capacity of the DCP, influence the end-to-end latency.

We conducted a performance comparison of our design against RocketMQ [5] — a distributed message queue system widely used in the information technology (IT) domain for its high-capacity, real-time, and zero-error transactions. RocketMQ operates in single replica mode, which means it is set up with only one broker and without replica nodes. We implemented the DCP in the same setup and conducted comparison experiments with the same hardware and software environment, as detailed in Table 1.

Figure 7 shows the message forwarding latency exhibited in the DCP and RocketMQ systems, respectively, for message sizes of 10¹ bytes to 10⁵ bytes. In the test, five messages of different sizes were forwarded by the two systems, with each message forwarded by both systems five times repeatedly to calculate the average latency. As shown in the figure, the RocketMQ system exhibits a message-forwarding latency that increases with the message size. A noticeable surge occurs when the message size reaches 10⁵ bytes. In contrast, the message-forwarding latency of our DCP design is stable at around 2 ms across all tested message sizes. Overall, our DCP design exhibits an average latency reduction of over 65% compared to RocketMQ for all message sizes, and the reduction is particularly pronounced for larger message sizes (e.g., 10⁵ bytes).

Table 1 Experimental environment for DCP implementation

Figure 7 Data forwarding latency of the DCP and RocketMQ systems

DCP's superiority over RocketMQ in message forwarding latency is mainly attributed to two factors:

• Stateless design: The DCP employs a stateless design, which eliminates the need to maintain and manage the complex state information for each message-forwarding operation. This design reduces the computational overhead associated with processing each message, thereby significantly lowering the message-forwarding latency.
• Elimination of message persistence: In DCP application scenarios, message persistence is not required. Therefore, we removed persistence-related components from the system. This further simplifies I/O operations and reduces the overhead of writing data to the disk, thereby improving the data-forwarding efficiency

In contrast, the RocketMQ system requires message persistence, resulting in significantly increased latency when processing large messages.

We also studied the message success rates for different message sizes at different message send intervals (2 ms, 3 ms, 4 ms, 5 ms, 10 ms, 50 ms, 100 ms, 300 ms, 500 ms, and 1,000 ms) in the DCP system. As shown in Figure 8, when the message size is within the range of 10³ bytes to 10⁵ bytes, the success rates at all send intervals are close to 100%. This indicates that the DCP system can effectively handle and successfully send messages of smaller sizes. However, when the message size increases to 10⁵ bytes and above, the success rates for all send intervals decrease.

Figure 8 Message success rate of the DCP system

The result suggests that the message send interval has minimal impact on the success rate for smaller message sizes; however, as the message size increases, shorter message send intervals lead to lower success rates. This is mainly due to network congestion or insufficient system processing capacity. Therefore, when designing a message transmission strategy, it is crucial to balance the message size and send interval in order to ensure high success rates, even in heavy-load scenarios.

Figure 9 Throughput of the DCP system

Additionally, we evaluated the DCP system's throughput for different message sizes (1 KB, 10 KB, 64 KB, and 128 KB) with configurations of 1, 2, 5, and 10 brokers, respectively. As shown in Figure 9, the DCP system's throughput increases as the number of brokers increases. For instance, when the message size is 1 KB, the throughput is 228.0 MB/s with 1 broker and 1,061.3 MB/s with 10 brokers. Similarly, when the message size is 128 KB, the throughput is 714.6 MB/s with 1 broker and 2,394.6 MB/s with 10 brokers.

The result also shows that the DCP system's throughput increases as the message size increases. This indicates that the DCP system is more efficient in handling larger messages as long as the send interval is appropriately managed to prevent the success rate from declining. Additionally, increasing the number of brokers has a more pronounced effect on enhancing the throughput for larger messages.

4 Conclusion

"Beyond-connectivity services," such as network AI and wireless sensing, generate and consume data that requires an efficient transmission mechanism capable of supporting complex data topologies and on-path data processing. However, the current network architecture employs a session-based model for managing UE communication data, which cannot meet the requirements of "beyond-connectivity services." To overcome this limitation, this research presents a dedicated DP for transmitting non-connectivity data. The incorporation of DO and DA enables the management of flexible data topologies, facilitating DaaS for network AI and wireless sensing through on-path processing of distributed data and ubiquitous computing. Additionally, we present an asynchronous data exchange mechanism, the DCP, which enhances data exchange efficiency among multiple data producers and consumers. As a stateless and distributed message broker, the DCP has shown to be particularly effective in scenarios requiring collaboration between multiple AI models and in ISAC sensing for environment reconstruction.