Toward Native Artificial Intelligence in 6G Networks: System Design, Architectures, and Paradigms

6G RAN is envisioned to embrace heterogeneous resources organized in ad hoc manner, which may cover terrestrial and non-terrestrial communication at the same time. Base stations (BSs) could be fixed, or mobile (e.g. cars, drones, or even satellites). Moreover, 6G RAN should be capable to support dynamic AI service deployment with critical performance requirements.

Intelligence inclusive RAN is more than installing racks of servers at the edge location and local break out of the traffic for edge processing. Instead, it should provide deeply converged communication and computing capability. Therefore, a 6G BS (denoted as xNB for consistency with 5G) can be further divided into two parts: control base station (cNB) and service base station (sNB). The cNB provides control function (e.g., including connectivity and computing control) in a large area, while the sNB provides high-speed data transmission and computing services in a smaller area, e.g., cell level. The separation of the cNB and the sNB has the following advantages: (1) cNB can provide more efficient resource coordination and heterogeneous resource convergence control among sNBs and user equipment (UEs); (2) It can facilitate the deployment, since cNB can provide good coverage with lower frequency, while sNB can provide good throughput and energy-efficiency with higher frequency; (3) it can reduce overhead for common control purpose.

Both cNB and sNB share some similarities with the 5G RAN like the control plane (CP) and user plane (UP) functions. For example, the control functions provided by the cNB include common and UE-specific computing resource control and radio resource control (such as Master/System Information Block (MIB/SIB), paging, and UE-specific radio resource control (RRC) signaling). Meanwhile, we argue that it is worthwhile to introduce an independent computing plane (CmP), which could be utilized to host certain services (e.g., AI or other third party applications) and other extended CN functions. As shown in Figure 2, the sNB is responsible to logically separate the CP, UP and CmP services.

When AI services are deployed at RAN level, they need to establish the connection between terminals and these functions directly in order to provide high-performance communication. This is essential especially for real-time AI services. Therefore, new interfaces between CmP and CP, and between CmP and UP shall be defined to support the dynamic service deployment, which will be further explored in our future work.

Conventional communications systems are connection-oriented, for which a typical service could be establishing connection between two specific terminals. Therefore, the communication source and destination are clearly defined by end users and the services that they intend to use or the other users that they plan to communicate with. In 6G, other than connectivity-oriented services, it should provide AI-based services, for instance predictive QoS for a car to perform full autonomous driving. In order to cater such services, connections are explicitly or implicitly established between many terminals and network equipment in a proactive or reactive manner and computation resource shall be scheduled as well. Hence it requires to perform coordination and communication among multi-terminals, multi-xNBs and multi-computing resources in the form of Tasks. Typical scenarios of tasks could be the provisioning of AI services to enhance the reliability for field level communication in smart manufacturing scenario, or the adoption of AI services at the xNBs in a specific region for better resource utilization. In order to perform these tasks, task-oriented communication happens by executing the very same actions (e.g., establishing connectivity, and computing resource allocation) across numerous distributed nodes with proper coordination. It poses new challenges to design the network function plane in 6G, and new functionalities may emerge in order to perform task management and control. For instance, as illustrated in Figure 2, task control plane (T-CP) and user plane (T-UP) could be specifically designed in cNB and sNB, respectively. Meanwhile, novel task protocol stack could be carried on 6G radio control signaling (e.g., RRC), or radio data protocol (e.g., PDCP or SDAP) to transmit task messages and implement task decomposition, distribution, activation, etc. Task management entity might be designed outside of RAN, e.g., as a CN function.

In order to create a highly customized and secured network environment for users, user-centric concept shall be introduced to design the system architecture, so as to support users’ participation in network service definition and operation, and provide users full control of data ownership. In order to fulfill this design, the network architecture shall be divided as user service node (USN) and network service node (NSN). For example, USN contains customized services and network policies at end user level to meet diversified service requirements in the 6G era. As a byproduct, it could further support to establish the user profiling as the reflection of physical entity.

The 6G system will inherently generate a huge amount of diverse data from both technical and business domains. An independent data plane in 6G could contribute to organizing and managing data efficiently while also considering privacy protection. (1) Infrastructure: all types of physical and virtual resources in the mobile communication system evolve to potential data sources. The data plane could help to accumulate the diverse data from the heterogeneous infrastructure. (2) Operation and Business Supporting: This data plane could conveniently store and analyze useful information for network operation and management, including physical equipment status, system operation information, service provisioning information, etc. On the other hand, benefiting from all data related to the business logic (e.g., customer relationship, partner relationship management) and more importantly customer subscription related information (e.g., user personal data or enterprise level data), the data plane could grant customers (no matter subscriber type or enterprise type) the capabilities to have full control of their own data. (3) Vertical Industries: Similarly, vertical industries could find room to store their interested data related to use-case operation, admiration and maintenance. Also, the data could be safely stored and securely accessed via their own repositories. (4) Terminal: The data plane could add special space for terminals to store computing and communication resource related data, service usage profile, and sensing knowledge. Notably, data collection shall comply with the regional or national data protection policies and regulations of the data source in terms of usage rights and obligations, e.g., GDPR (General Data Protection Regulations).

Depending on the regulation and data usage policy, data processing functions could be executed on the data plane or it could be plugged in the other planes (e.g., if raw data cannot be exported to data plane, it shall be pre-processed in the data source). Nowadays, collecting and storing sensitive data is often accompanied with privacy risks and responsibilities of protecting the privacy embedded in the data. Therefore, it is essential to have data desensitization modules as the key data processing services in the data plane. Meanwhile, data policy enforcement modules in the data plane, which handle data according to the regulatory as well as non-regulatory rules (e.g., geographic restriction), will be executed by default to ensure the integrity and legitimate of data processing. Data plane contains data processing model libraries to support different data services. Moreover, it also exposes its capabilities to other planes and perform access control for entities to access and utilize its data services.

On data plane, (raw or processed) data could be stored flexibly in a structured or unstructured format through centralized or fully distributed method. Uniformed interfaces should be further defined to facilitate internal customers of the mobile communication system, e.g., network service plane, and intelligent plane. Moreover, it could also be easily extended to provide data to external customers, e.g., vertical industry players, and enterprises.

AI service orchestration focuses on the parsing and orchestration of network AI services. An AI service is mapped to a logical AI workflow, which refers to a set of (independent) processing modules. Depending on specific AI services, logical AI workflows could consist of several modules that utilize different AI models, such as support-vector machine (SVM), recurrent neural network (RNN), long short-term memory (LSTM), and convolutional neural network (CNN).

The logical AI workflow may obtain data from the data plane, and the entry module may further perform data processing in sequence. This processing may be serial processing or based on directed acyclic graph. In addition, logical AI workflow shall take QoS requirements of the related services into consideration. Logical AI workflows are mapped to physical resources during service deployment. Each processing module defined in the logic AI workflow needs to be assigned with specific parameters or hyperparameters, which are stored as models in the AI hub. If basic data services are involved, e.g., data collection and pre-processing, relevant functional modules shall be used from the data plane.

It is worthwhile to note here that many deep learning technologies are extremely inefficient (e.g., in terms of energy use). There are many works towards optimizing neural networks by a certain extent of compressing (e.g., audio and image processing in smart phones). It is interesting and essential to understand the capability constraints and the feasibility of AI technologies before performing AI service orchestration.

AI workflows need to be mapped to specific resources for execution, including relevant components (e.g., a graphical processing unit, and a network connection). This is implemented by the infrastructure orchestrator upon heterogeneous and distributed resources at large scale.

As the names imply, the AI service manager focuses on the status maintenance and management of AI services, by issuing administration policies to add, modify, and delete logical and physical AI workflows. Similarly, the infrastructure manager is responsible for managing distributed communication and computing resources. The foregoing NAMO function belongs to a logical function, and is specifically deployed and mapped to physical entities in different infrastructure layers, including xNBs, UEs, etc.

NAMO should be a native multi-domain solution, where domains could be different regional networks of a mobile operator or networks from different mobile operators. Moreover, in order to enable easy deployment and attract external service providers, NAMO should be capable to coordinate resources through standardized interfaces and protocol. Put differently, AI services should be easily deployed in 6G (at the edge or centrally) and the intelligent plane should allow convenient service operation (e.g., deployment, update, migration, and termination). It is essential to understand which technical components fall into the scope of standardization (e.g., 3GPP), and which could rely on open source approach. For instance, typical AI workflow orchestration framework like Kubeflow and modelarts could be leveraged to accelerate the design of AI workflows. Continuous integration/continuous development (CI/CD) approach shall be adopted, especially to bring seamless service development and provisioning.

Basically, in large-scale multi-agent intelligent systems, the complex relationship among agents usually causes great difficulty for policy learning. In many multi-agent systems, the interactions between agents often take place locally, which means that agents neither need to coordinate with all other agents nor need to coordinate with others all the time. Traditional methods attempt to use pre-defined rules to capture the interaction relationship between agents. However, these methods cannot be directly used in a large-scale environment due to the difficulty of transforming the complex interactions between agents into operation rules. Table I provides a list of some typical multi-agent machine learning algorithms. It can be observed that these state-of-the-art multi-agent learning algorithms share some similarities, i.e., one of the most important part is that these algorithms require a centralized or decentralized training or execution mechanism and have to interact among agents by networks. In this regard, we argue the following networking ingredients are essential and will lately show that the networking ingredients could provide superior performance than totally independent multi-agent learning.

• •

  We can model the relationship between agents by a complete graph and leverage graph neural networks (GNNs) to further utilize the embedded relationship. Given the wide existence of topology in cellular networks, GNNs could be naturally enhanced in the intelligence plane with the explicit knowledge from the data plane.

• •

  Federated Learning enables mobile terminals to collaboratively learn a shared prediction model while keeping all the training data on device, decoupling the gradient update and the original data. Such a federated learning framework, which could significantly enhance the privacy, cannot neglect the effect of networks.

• •

  Stigmergy aims to complete complex tasks by a small amount of indirect information exchange like the pheromone left by ants in their walking paths. Similarly, digital pheromone is often leveraged in the stigmergy to act as the intermediate information. Accordingly, local information update among partially networked agents becomes necessary, so as to update the digital pheromone and reduce the behavioral localities [8].

Next, we manifest the importance of networking in multi-agent systems. Due to the space limitation, we primarily consider the positive impact of network-assisted multi-agent learning via a mixed-autonomy traffic control scenario [9] as depicted in Figure 3. As a representative showcase, there are totally 14 vehicles running circularly along a one-way lane that resembles a shape “eight (i.e., 8)” and an intersection is located at the lane. Besides, each vehicle must adjust its acceleration to pass through this intersection in order to increase the average speed, but slamming on the brakes will be forced on vehicles that are about to crash, further terminating the current epoch, which is $150$ second. Furthermore in this article, the scenario is slightly modified by assigning the related local state of the entire environment to each vehicle, including the position and speed of its own, and the vehicle ahead and behind. Each vehicle collects its local state per $0.1$ second, and optimizes its acceleration accordingly by periodically computing the gradient from a $256$-minibatch.

In order to testify the performance of multi-agent learning, these 14 vehicles can be categorized into two classes, namely, 7 cars underlying simulation of urban mobility (SUMO) and 7 independent reinforcement learning (IRL) or federated IRL (FIRL)-empowered cars, where FIRL implies the existence of network assistance and IRL means not. Besides, considering that SUMO is an open source, human being-level, highly portable and widely used traffic simulation package [9], we treat 14 SUMO cars as the baseline. Figure 4 clearly verifies the advantage of FIRL over IRL and the gradual approaching of FIRL towards the baseline, and demonstrates the importance of network assistance.

Figure 4 also depicts three typical cloud-based AI (instead of inclusive AI) scenarios. Notably, the “FIRL-D” method simulates a direct latency increase by synchronously delaying the gradient uploading and the local neural network updating for all cars by 4 epochs and 2 epochs respectively. Furthermore, the “FIRL-D-OR” method checks the performance when the out-of-order among the neural network update packets occurs due to the multi-path and the fact that the latest neural network updated packet is possibly overridden by a previously delayed one. Meanwhile, “FIRL-D-LM” examines the case where the network quality is rather low and the uploading periodicity has to enlarge from $25.6$ second to $150$ second by locally merging 6 consecutive minibatchs. It can be observed that, synchronously increasing the network latency has trivial impact on the performance. However, the other cases leads to apparent performance degradation, which could better manifest the advantages to have the inclusive AI.