Radio access network architecture and terminal device

Abstract

The present application provides a wireless access network architecture that can provide other newly added characteristics in addition to legacy connections, such as computing, data, trust, and intelligence, etc. These newly added characteristics are task-based collaboration across nodes, multi-dimensional resources (e.g., computations, data, algorithms and connections, etc.), whereby a centralized inter-station coordination approach may be provided to provide inter-regional and within-regional task coordination. The wireless access network architecture comprises cluster control nodes and business service nodes, the business nodes provide task scheduling and execution functions, and the cluster control nodes provide a region-level centralized coordination function of the business nodes and a coordination function among cross-region cluster control nodes. The centralized inter-station coordination mode can improve the inter-station coordination efficiency.

Description

Radio access network architecture and terminal devices Technical Field

[0001] The embodiments of the present application relate to the field of communications, and more specifically, to a radio access network (RAN) architecture and a terminal device. Background Art

[0002] Existing radio access network (RAN) architectures, such as the fifth-generation (5G) RAN architecture, are flat. In this architecture, information exchange and negotiation between a base station and its neighbors is performed via the Xn interface, a distributed collaboration mechanism that results in low inter-station collaboration efficiency.

[0003] Summary of the Invention

[0004] This application provides a wireless access network architecture that can improve inter-station collaboration efficiency and provide new services beyond connection services.

[0005] In a first aspect, a radio access network architecture (or radio access network equipment) is provided, which is deployed in a radio access network RAN ​​and includes a cluster control node and a service service node;

[0006] The cluster control node is used to provide a regional centralized coordination function for a plurality of the business service nodes, and a coordination function between the cluster control nodes across regions;

[0007] The business service node is used to provide the functions of scheduling and executing tasks.

[0008] This technical solution provides a layered RAN architecture consisting of cluster control nodes (cNodes) and service serving nodes (sNodes) as access network equipment. The cNodes centrally manage and coordinate tasks for the service serving nodes, supporting centralized inter-site collaboration and improving inter-site collaboration efficiency compared to a flat RAN architecture.

[0009] Optionally, the wireless access network architecture in this application can also be replaced by descriptions of wireless access network equipment, access network equipment, network equipment, base station, access network device, etc.

[0010] Furthermore, this layered RAN architecture enables more efficient connectivity services by building native integration and fusion of multi-dimensional heterogeneous resources. Intrinsic network capabilities refer to capabilities (functions, attributes, etc.) derived from inherent network factors. Beyond basic connectivity services, new services such as computing, data, intelligence, and trust can be efficiently delivered.

[0011] In this application, a "region" refers to a geographic area (i.e., a geographic region) that can be large or small, and can be regular or irregular in shape. Examples include a circle with a radius of 1 km originating from a specific location, or the combined coverage area of ​​one or more base stations. cNodes can provide centralized coordination within and across regions.

[0012] Building on the concept of "region," cross-region task coordination refers to the coordination of tasks within the geographic scope of two or more regions. For example, if two base stations in different regions are neighbors, cross-region inter-station negotiation is required to minimize mutual interference.

[0013] In combination with the first aspect, in certain implementations of the first aspect, the cluster control node provides a control plane function of the connection on the air interface, and the service service node provides a user plane function of the connection on the air interface; or,

[0014] The cluster control node does not provide a connection function on the air interface, and the business service node provides a control plane function and a user plane function of the connection on the air interface.

[0015] Specifically, the present application provides multiple options for implementing the above-mentioned RAN architecture functions, such as connection architecture, task architecture and trusted architecture. Depending on the different RAN architecture options, the functions provided by the cluster control node and the business service node are different. For details, please refer to the description in the embodiments of the specification.

[0016] In this application, the RAN architecture can be a non-SBA-based architecture or an SBA-based architecture.

[0017] In conjunction with the first aspect, in some implementations of the first aspect, the RAN architecture is an architecture based on a non-service-based architecture (SBA);

[0018] The non-SBA-based architecture includes:

[0019] The cluster control node and the business service node are connected to each other via a Y1 interface;

[0020] The cluster control node and other cluster control nodes are connected to each other via a Y2 interface;

[0021] The business service nodes are interconnected via Y3 interfaces.

[0022] It should be understood that the Y1 interface to the Y3 interface are merely one way of representing interfaces. The letter "Y" can be replaced by any other letter, and the numbers 1, 2, and 3 are merely for distinguishing different interfaces. Alternatively, other methods may be used to represent these interfaces. For example, the Y1 interface to the Y3 interface may be represented as the first interface, the second interface, and the third interface, respectively. This interface representation herein does not constitute any limitation on the RAN architecture provided in this application. Other interfaces herein are similar, for example, the T2 interface to the T9 interface, and will not be repeated below.

[0023] In this application, a non-SBA RAN architecture is adopted to fully consider the various deployment scenario requirements of base stations, such as not deploying on the cloud or not having the need for flexible expansion / reduction.

[0024] In combination with the first aspect, in certain implementations of the first aspect, the cluster control node is connected to the core network through one or more of the following interfaces:

[0025] Connecting to the task control function TCF and the task processing function TPF of the core network through the T2 interface;

[0026] Connecting to the network access function NAF of the core network via a T3 interface;

[0027] The core network is connected via a T4 interface and a connection function control plane CF-C.

[0028] In conjunction with the first aspect, in certain implementations of the first aspect, the business service node is connected to the core network through one or more of the following interfaces:

[0029] Connecting to the network access function NAF of the core network via a T5 interface;

[0030] Connecting to the core network's connectivity function control plane CF-C via a T6 interface;

[0031] The core network is connected via a T7 interface and a connection function user plane CF-U.

[0032] As in the above-mentioned implementation method, if the RAN architecture provided in this application adopts a non-SBA architecture, the cluster control nodes, the business service nodes, the cluster control nodes and the business service nodes, and the cluster control nodes and the business service nodes are connected to different core network elements through different interfaces.

[0033] In conjunction with the first aspect, in certain implementations of the first aspect, the RAN architecture is an SBA-based architecture; the SBA-based architecture includes:

[0034] The cluster control node provides a first serviced interface (Sc);

[0035] The business service node provides a second service interface (Ss);

[0036] The first service-oriented interface and the second service-oriented interface are connected to a service bus of the RAN.

[0037] If the RAN architecture provided in this application adopts the SBA architecture, the cluster control node and the business service node respectively provide service interfaces, and the cluster control node and the business service node respectively interact with other network elements through their respective service interfaces.

[0038] Because the SBA architecture decomposes network functions (NFs), and all NFs can be connected to the communication system through interfaces, the SBA-based RAN architecture will bring, but is not limited to, the following advantages:

[0039] Flexible deployment: Since NFs are service-oriented interfaces, their functions are independent and can be deployed on different servers as needed. They can also be deployed and maintained independently.

[0040] Scaling / reducing capacity is simpler: Capacity expansion only requires connecting new NFs to the system without affecting the existing network operation, and capacity reduction can directly remove obsolete NFs from the network;

[0041] Easy functional expansion: If there are no changes to the external service interface, the functions and performance of the NF can be independently enhanced and evolved without relying on other NFs;

[0042] Good openness: NFs use service-oriented interfaces. The network functions provided by each NF can be called by any other network element (or NF). This makes it easy to add new NFs and is suitable for NF development and openness.

[0043] Reduced maintenance costs: Different NFs are isolated through APIs, making fault location easier and reducing the degree of coupling between NFs.

[0044] Load sharing: The same network functions can be shared and provide network function services, thereby sharing the load;

[0045] Stronger disaster recovery capability: If any network function fails, intelligent network management can temporarily remove it from service and transfer the service to other network functions with the same function for processing.

[0046] In conjunction with the first aspect, in some implementations of the first aspect, the RAN architecture includes one of the following connection architectures:

[0047] A first connection architecture, wherein the control plane CP and the user plane UP of the air interface of the first connection architecture are separated, the cluster control node has the CP function of the connection, and the service service node has the UP function of the connection; or

[0048] The second connection architecture: the CP and UP of the air interface of the second connection architecture are not separated, the cluster control node does not provide a connection function, and the business service node provides a CP function and a UP function of the connection.

[0049] In this implementation, the RAN architecture can be designed as a connection-based architecture. Under the non-SBA-based architecture, it can be specifically divided into a first connection architecture with CP / UP separation and a second connection architecture with CP / UP non-separation.

[0050] In combination with the first aspect, in some implementations of the first aspect, the RAN architecture includes a third connection architecture, and the CP and UP of the air interface of the third connection architecture are separated;

[0051] The cluster control node provides the first service-based interface, where the first service-based interface is used for invoking a core network element to transmit control plane signaling of a connection, and the first service-based interface is also used for invoking other cluster control nodes to provide a mobility signaling function;

[0052] The business service node provides the second service-based interface, which is used for calling the core network network element to transmit user plane data. The second service-based interface is also used for calling other business service nodes to provide mobility data forwarding function, wherein data forwarding between the business service nodes is controlled by the cluster control node.

[0053] In combination with the first aspect, in some implementations of the first aspect, the RAN architecture includes a fourth connection architecture, and a CP and a UP of an air interface of the fourth connection architecture are not separated;

[0054] The business service node provides the second service-oriented interface, where the second service-oriented interface is used for calling the core network element to transmit control plane signaling and user plane data of the connection;

[0055] The second service-oriented interface is also used for calling other business service nodes to provide mobility signaling interaction and data forwarding functions.

[0056] Optionally, the "core network element" in this document may also be referred to as a core network element, and the network element may also be represented as a node, function, network function, device, etc., without limitation.

[0057] In the above two implementation methods, the RAN architecture can be designed as a connection-based architecture. Under the SBA-based architecture, it can be specifically designed as a third connection architecture with CP / UP separation and a fourth connection architecture with CP / UP non-separation.

[0058] In conjunction with the first aspect, in some implementations of the first aspect, the RAN architecture is a task architecture for a first function, where the first function includes one or more of computing, data, intelligence, and trust;

[0059] The task architecture includes:

[0060] The cluster control node is configured to provide a control plane function and a data processing function of the first function;

[0061] The business service node is configured to provide part of the control plane function and user plane function of the first function, wherein the user plane function includes task scheduling TS and task execution TE;

[0062] Among them, the cluster control node and the business service node manage tasks through the Y1 interface, the cluster control nodes negotiate tasks through the Y2 interface, the cluster control node and the core network element negotiate tasks between network domains through the T2 interface, and the business service nodes perform task signaling or task data interaction between TEs through the Y3 interface.

[0063] "Network domain" can generally be divided into access network domain, core network domain, and network management domain.

[0064] In this implementation, the RAN architecture can not only efficiently provide basic connectivity services but also offer new features such as computing, data, intelligence, and trust. These new services are collectively referred to as primary functions in this application. The RAN architecture can be designed as a mission architecture based on these new features. Optionally, the mission architecture can be specifically designed as a non-SBA-based architecture.

[0065] In conjunction with the first aspect, in some implementations of the first aspect, the RAN architecture is a task architecture for a first function, where the first function includes one or more of computing, data, intelligence, and trust;

[0066] The task architecture includes:

[0067] The cluster control node provides the first service-based interface for transmitting task negotiation signaling and task data across network domains; the first service-based interface is also used for calling other cluster control nodes for transmitting task negotiation signaling and task data across regions;

[0068] The business service node provides the second service-oriented interface for the cluster control node to interact with the business service node in task control signaling and transmit task data; the second service-oriented interface is also used for calling other business service nodes for transmitting task data between the business service nodes.

[0069] In this implementation, the RAN architecture can be designed as a task architecture based on new features. Specifically, the task architecture can be designed as an SBA-based architecture.

[0070] In the above mission architecture, including non-SBA-based mission architecture or SBA-based mission architecture, compared with the existing 5G RAN architecture, it can natively support the deep integration of connectivity, computing, data and algorithms (four elements of resources) at the architectural level, coordinate these individual functions and resources in multiple facilities, and more flexibly provide on-demand AI, computing and data services to the network itself or applications, and guarantee QoS.

[0071] In combination with the first aspect, in some implementations of the first aspect, the RAN architecture further includes a trusted engine TWE and a trusted device TWG, the cluster control node includes the TWE and the TWG, and the business service node includes the TWG.

[0072] The TWE is used to provide global decision-making and management information of the trusted surface for the network, and to provide trusted policy input, activation and management of trusted services for the TWG;

[0073] The TWG is used to receive configuration and management of the TWE to implement trusted capabilities.

[0074] In this implementation, the RAN architecture can be designed as a trusted architecture based on a trusted plane. In one implementation, the trusted architecture can be specifically designed as a non-SBA-based architecture.

[0075] In conjunction with the first aspect, in certain implementations of the first aspect, the RAN architecture further includes a trusted enabling function (TEF) and a trusted device function (TGF), and the TEF and the TGF are independently mounted on a service bus of the RAN.

[0076] The TEF is used to provide global decision-making and management information of the trusted surface for the network, and provide trusted policy input, activation and management of trusted services for the TGF; the TGF receives the configuration and management of the TEF to implement trusted capabilities;

[0077] The TEF provides a third service interface (Se);

[0078] The TGF provides a fourth service-oriented interface (Sg);

[0079] The third service-oriented interface and the fourth service-oriented interface both provide the following functions:

[0080] Trusted service call, trusted information subscription, and trusted function management.

[0081] In this implementation, the RAN architecture can be designed as a trusted architecture based on a trusted plane, specifically an SBA-based architecture. Compared to other RAN architectures, this trusted architecture adds trusted functions, and decouples trusted functions from business code, meeting the information and cyberspace security, privacy protection, and security resilience requirements of end-to-end networks and applications.

[0082] In combination with the first aspect, in some implementations of the first aspect, the RAN supports connectivity and a first function other than connectivity, where the first function includes one or more of computing, data, and intelligence;

[0083] With respect to the relationship between the connection and the first function, the design of the air interface protocol stack adopts one of the following options:

[0084] Option 1: The first function is integrated into the control plane of the connection and the user plane of the connection;

[0085] Option 2: The first function is integrated into the control plane of the connection to form a fused control plane, the user plane of the connection remains unchanged, and an independent task data plane for the first function is added;

[0086] Option 3: Add a task control plane and a task data plane for the first function, and keep the control plane and user plane of the connection unchanged;

[0087] Option 4: Add independent computing planes, data planes, and intelligent planes for the first function, while keeping the control plane and user plane of the connection unchanged.

[0088] In this implementation, the air interface protocol stack is redesigned to support the RAN architecture composed of cNode / sNode to provide new services (such as computing, data, intelligence, AI, and trust).

[0089] With option 1, each functional plane can share a protocol stack, making implementation simpler. With option 2, the control plane of the new feature and the control plane of the connection are integrated, while the user plane of the new feature is designed independently. With option 3, the protocol stack of the new feature (for example, computing, data, trust, and intelligent collaboration) and the protocol stack of the connection are independent. With option 4, the new features are further subdivided, and independent functional planes are added for different new features, such as independent computing planes, data planes, and intelligent planes. Each newly added independent functional plane is more targeted, more flexible in design, and has high operational efficiency.

[0090] In view of the relationship between new features and connections, the above four design methods of the air interface protocol stack, from option one to option four, the functional definitions of each aspect tend from integration to independence.

[0091] In combination with the first aspect, in some implementations of the first aspect, the Y1 interface includes a Y1 user plane interface Y1-U and a Y1 control plane interface Y1-C;

[0092] The Y2 interface includes a Y2 user plane interface Y2-U and a Y2 control plane interface Y1-C;

[0093] The Y3 interface includes a Y3 user plane interface Y3-U and a Y3 control plane interface Y3-C;

[0094] The T2 interface between the cluster control node and the core network includes a T2 user plane interface T2-U and a T2 control plane interface T2-C. The T2-U is an interface between the cluster control node and the task processing function TPF of the core network, used for transmitting task data. The T2-C is an interface between the cluster control node and the task control function TCF of the core network, used for transmitting task signaling.

[0095] The T3 interface between the cluster control node and the core network includes a T3 control plane interface T3-C, where the T3-C is an interface between the cluster control node and the network access function NAF of the core network, and is used for transmission of connection signaling;

[0096] The T4 interface between the cluster control node and the core network also includes a T4 control plane interface T4-C for transmitting connection signaling or transparent transmission task signaling;

[0097] The T5 interface between the business service node and the core network also includes a T5 control plane interface T5-C for transmitting connection signaling or transparent transmission task signaling;

[0098] The T6 interface between the business service node and the core network also includes a T6 control plane interface T6-C for transmitting connection signaling or transparent transmission task signaling;

[0099] The T7 interface between the business service node and the core network also includes a T7 user plane interface T7-U, which is used to transmit connection data or transparently transmit task data.

[0100] In this implementation, the network element interface (also called the ground interface) is redesigned to support the RAN architecture composed of cNode / sNode to provide new services (such as computing, data, intelligence, AI, and trust).

[0101] In combination with the first aspect, in some implementations of the first aspect, the RAN supports connectivity and a first function other than connectivity, where the first function includes one or more of computing, data, and intelligence;

[0102] The end-to-end protocol stack uses one of the following options:

[0103] Option 1: The first function is integrated into the control plane of the connection and the user plane of the connection;

[0104] Option 2: The first function is integrated into the control plane of the connection to form a fused control plane, the user plane of the connection remains unchanged, and an independent task data plane for the first function is added;

[0105] Option 3: Add a task control plane and a task data plane for the first function, and keep the control plane and user plane of the connection unchanged;

[0106] Option 4: Add independent computing planes, data planes, and intelligent planes for the first function, while keeping the control plane and user plane of the connection unchanged.

[0107] This implementation redesigns the end-to-end protocol stack to support the cNode / sNode RAN architecture and deliver new features (such as computing, data, intelligence, AI, and trust). In light of the relationship between these new features and connectivity, the four end-to-end protocol stack designs, from Option 1 to Option 4, shift the functional definition of each aspect from convergence to independence.

[0108] In combination with the first aspect, in some implementations of the first aspect, the protocol layer of the air interface includes layer 2, and layer 2 includes a sublayer supporting the first function.

[0109] In this implementation, layer 2 of the air interface protocol stack includes a sublayer that supports the first function. Specifically, a new function may be added to an existing function layer, or a sublayer that implements the new function may be added, without limitation.

[0110] In conjunction with the first aspect, in some implementations of the first aspect, the layer 2 includes at least one of the following sub-layers:

[0111] Task resource scheduling TRS sublayer;

[0112] Task Packet Data Convergence Protocol T-PDCP sublayer;

[0113] Task Service Data Adaptation Protocol T-SDAP sublayer;

[0114] The TRS sublayer provides a logical channel for the RLC sublayer, the T-PDCP sublayer provides a radio bearer for the T-SDAP sublayer, and the T-SDAP provides a core network task and a connection quality of service (QoS) flow.

[0115] The task resource data (TRD) sublayer includes one or more of the following functions: artificial intelligence (AI) training, AI reasoning and AI model processing, protocol mode parsing and local collaboration parameters, collaborative mode process execution, and collaborative interaction information transmission and processing.

[0116] For the task data plane, the task PDU sublayer is used for data transmission of trusted services between the terminal and the RAN and core network;

[0117] For the RCSP sublayer of the computing plane, the functions of the RCSP sublayer include endogenous computing resource addressing, computing data routing and forwarding, computing session identification, and computing session priority;

[0118] The DFCP sublayer for the independent data plane is used for control signaling and service data processing of the independent data plane;

[0119] The ETP sublayer for the independent trusted plane is used for processing trusted data packets. The functions of the EIP sublayer also include encryption and decoding as well as integrity protection and integrity verification;

[0120] The TBP layer for the independent trusted data plane is used for trusted service data transmission between the terminal and the RAN, core network, or between the RAN and the core network.

[0121] In this implementation, Layer 2 can implement corresponding functions by adding at least one sublayer, thereby supporting the RAN architecture to provide one or more new services.

[0122] In combination with the first aspect, in some implementations of the first aspect, the protocol layer of the air interface further includes layer 3, and layer 3 further includes a sublayer supporting the first function.

[0123] In this implementation, layer 3 of the air interface protocol stack is redesigned to support the RAN architecture composed of cNode / sNode to provide new services (such as computing, data, intelligence, AI, and trust).

[0124] In combination with the first aspect, in some implementations of the first aspect, the RAN architecture further provides a trusted function, which is decoupled from other functions of the RAN.

[0125] In this implementation, faced with the contradiction between security technology's need to deeply serve the communication network and its need to continuously evolve independently of the communication network, this application considers resolving this contradiction by decoupling security capabilities from network capabilities. Expanding from security to trustworthiness, this application considers decoupling trustworthiness from network capabilities, enabling the continuous evolution and advancement of trustworthiness capabilities.

[0126] In combination with the first aspect, in certain implementations of the first aspect, the RAN architecture provides a first function, and the quality of service QoS mechanism of the RAN architecture includes a QoS mechanism for the first function, wherein the QoS mechanism for the first function includes a QoS mechanism on the network side and a QoS mechanism on the terminal side, and the first function includes one or more of computing, data, intelligence and trust.

[0127] For the primary functions supported by the RAN architecture (for example, one or more new services such as computing, data, intelligence, and trust), a task-specific QoS mechanism needs to be designed to ensure task-specific QoS evaluation.

[0128] In a second aspect, a terminal device is provided, including a control plane protocol stack and a data plane protocol stack, wherein the control plane protocol stack includes one of the following:

[0129] The control plane protocol stack includes a first sublayer, the first sublayer supports transmission of control signaling of a first function, the first function including one or more of computing, data, intelligence, and trust; or,

[0130] The control plane protocol stack includes a first sublayer, the first sublayer supports transmission of control signaling and routing functions of a first function, the first function including one or more of computing, data, intelligence, and trust;

[0131] Furthermore, the data plane protocol stack of the first function supports an arbitrary routing mechanism.

[0132] Based on this technical solution, the terminal device includes a control plane protocol stack and a data plane protocol stack that support the first function (for example, new services such as computing, data, intelligence and trust), and provides a terminal side protocol stack design solution for the RAN architecture to support the first function.

[0133] In a third aspect, the present application provides a method for transmitting a message, which is applied to a wireless communication system, wherein an access network device of the wireless communication system includes a cluster control node and a service node, and the method includes:

[0134] The cluster control node receives an RRC establishment request message from the UE, where the RRC establishment request message is used to request establishment of an RRC connection for the UE;

[0135] The cluster control node establishes the RRC connection for the UE;

[0136] The cluster control node sends an initial UE message to the network access function NAF;

[0137] The NAF allocates a corresponding connectivity function control plane CF-C to the UE based on the initial UE message;

[0138] The UE and the CF-C transmit a non-access stratum NAS message.

[0139] Optionally, in an implementation of the third aspect, the method further includes:

[0140] The cluster control node receives an initial context establishment request message from the CF-C;

[0141] The cluster control node establishes security configuration and RRC reconfiguration of the UE;

[0142] The cluster control node sends an initial context establishment response to the CF-C.

[0143] Optionally, in an implementation of the third aspect, the method further includes:

[0144] The cluster control node sends address information of a serving service node to the CF-C, where the serving service node is a service node selected by the cluster control node to provide service for the UE;

[0145] The cluster control node sends the context of the UE to the serving service node;

[0146] The serving service node establishes a PDU session of the UE with the CF-C based on the context of the UE;

[0147] The serving service node performs data transmission with the UE and the CF-C based on the PDU session.

[0148] In a fourth aspect, the present application provides a method for transmitting data, the method comprising:

[0149] The connection function CF network element receives downlink data from the UE and buffers the downlink data;

[0150] The CF network element determines, according to the connection management (CM) state of the UE, to page the UE or establish a user plane for the UE;

[0151] If the UE is in a CM idle state, the CF network element pages the UE;

[0152] If the UE is in a CM connected state, the CF network element establishes a user plane for the UE.

[0153] Optionally, in an implementation of the fourth aspect, the method further includes:

[0154] After receiving the paging, the UE initiates a service request process to the network.

[0155] Optionally, in an implementation of the fourth aspect, the method further includes:

[0156] The CF network element establishes a user plane for the UE, including:

[0157] The CF network element sends information about the PDU session of the UE to the cluster control node;

[0158] The cluster control node selects a service node for the UE based on the information of the PDU session;

[0159] The service node establishes a user plane for the UE.

[0160] In a fifth aspect, the present application provides a method for transmitting data, which is applied to a wireless communication system, wherein an access network device of the wireless communication system includes a cluster control node and a service node, and the method includes:

[0161] The cluster control node receives an uplink data transmission request from the UE;

[0162] The cluster control node sends the context of the UE to the service node corresponding to the UE;

[0163] The cluster control node allocates communication resources to the UE, sends scheduling information of the UE to the service node, and schedules the UE to perform uplink data transmission;

[0164] The UE sends uplink data to the service node;

[0165] The service node receives and demodulates the uplink data, and feeds back the data demodulation result to the cluster control node.

[0166] Optionally, in an implementation of the fifth aspect, the method further includes:

[0167] The cluster control node determines whether to retransmit the uplink data according to the data demodulation result.

[0168] Optionally, in an implementation manner of the fifth aspect, when the cluster control node determines to retransmit the uplink data, the method further includes:

[0169] The cluster control node allocates retransmission resources, sends scheduling information of the UE to the service node, and schedules the UE to retransmit;

[0170] The UE retransmits uplink data;

[0171] The service node receives the retransmitted data and performs demodulation;

[0172] The service node sends the demodulated retransmitted data to the connection function CF network element.

[0173] In a sixth aspect, the present application provides a method for transmitting data, the method comprising:

[0174] The task anchor TA receives the service workflow request;

[0175] The TA sends a data request and a computing power request to the data storage function DSF and the computing anchor CA respectively based on the service workflow request;

[0176] The TA sends a task configuration delivery request to the application function AF to the connection function CF of the UE related to the task;

[0177] The CF issues a request based on the task configuration to establish a task connection with the corresponding target UE;

[0178] The task control function TCF sends a task configuration request to the cluster control node.

[0179] Optionally, in an implementation of the sixth aspect, the method further includes:

[0180] The cluster control node decomposes the task based on the task configuration request of the TCF and sends subtasks to the UE and / or service node corresponding to the task;

[0181] The UE and / or the service node sends feedback of the service workflow request to the requesting node of the service workflow through the CF based on whether the subtask is executed.

[0182] In a seventh aspect, the present application provides a method for performing task collaboration, the method comprising:

[0183] The first cluster control node receives a service workflow request;

[0184] The first cluster control node requests the second cluster control node to perform task coordination;

[0185] If the second cluster control node accepts the task collaboration, it sends the decomposed subtasks to the corresponding service node and / or UE;

[0186] The second cluster control node feeds back the task coordination result to the first cluster control node;

[0187] The second cluster control node receives the execution results of the corresponding service node and / or UE for the subtask, and summarizes the execution results of the subtask to obtain a task execution result;

[0188] The second cluster control node feeds back the task execution result to the first cluster control node.

[0189] Optionally, the method of any one of the above-mentioned aspects 3 to 7 can be executed by a corresponding node, or can also be executed by a chip or circuit having the corresponding functions of the node. This application does not limit this, and the above description is illustrated using the node as an example.

[0190] In addition, optionally, the node can also be replaced by a device, an entity, a network entity, a communication device, a communication module, a network element, a communication node, etc. This application is described using a device or a node as an example.

[0191] In an eighth aspect, a communication device is provided, comprising at least one processor coupled to at least one memory, wherein the at least one processor is used to execute a computer program or instruction stored in the at least one memory so that the communication device has the functions of the wireless access network device described in the first aspect or the terminal device described in the second aspect, or so that the communication device executes a method as described in any aspect from the third aspect to the seventh aspect, or any implementation method of any aspect.

[0192] In the ninth aspect, a chip is provided, comprising a processor and a communication interface, wherein the communication interface is used to receive information and / or data to be processed and send the information and / or data to be processed to the processor, and the processor is used to process the information and / or data to be processed, so that the communication device installed with the chip has the functions of the wireless access network equipment as described in the first aspect or the terminal device as described in the second aspect, or so that the communication device executes a method as described in any aspect from the third aspect to the seventh aspect, or any implementation method of any aspect.

[0193] In the tenth aspect, a computer-readable storage medium is provided, in which computer instructions are stored. When the computer instructions are executed on a computer, the functions of the wireless access network device as described in the first aspect or the terminal device as described in the second aspect are implemented, or the method of any aspect from the third aspect to the seventh aspect, or any implementation method of any aspect, is implemented.

[0194] In the eleventh aspect, a computer program product is provided, which includes a computer program code. When the computer program code is run on a computer, the functions of the wireless access network device as described in the first aspect or the terminal device as described in the second aspect are implemented, or the method of any aspect from the third aspect to the seventh aspect, or any implementation method of any aspect, is implemented.

[0195] In a twelfth aspect, a wireless communication system is provided, comprising the wireless access network device as described in the first aspect, and optionally further comprising the terminal apparatus as described in the second aspect.

[0196] Optionally, in the third to eleventh aspects above, the wireless access network device may include an sNode and / or a cNode in the embodiments of the present application.

[0197] For the technical effects of the technical solutions of the third to twelfth aspects, reference can be made to the corresponding description of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0198] Figure 1 is a schematic diagram of a flat RAN architecture.

[0199] FIG2 is a schematic architecture diagram of a communication system applicable to an embodiment of the present application.

[0200] FIG3 is a schematic diagram of the RAN architecture provided in this application.

[0201] FIG4 is a schematic diagram showing the changes in the design paradigm of the RAN architecture provided in this application.

[0202] FIG5 is a schematic diagram comparing the Hic collaboration scenario and the collaboration triggered by the connection.

[0203] FIG6 is a schematic diagram of an overall system architecture applicable to this application.

[0204] Figure 7 is a schematic diagram of the overall architecture and interfaces of a non-SBA RAN.

[0205] Figure 8 is a schematic diagram of the overall architecture and interfaces of the SBA-based RAN.

[0206] FIG9 is a schematic diagram of a non-SBA connection architecture 1 .

[0207] FIG. 10 is a schematic diagram of a non-SBA connection architecture 2 .

[0208] FIG11 is a schematic diagram of UE data transmission under a non-SBA connection architecture.

[0209] FIG12 is a schematic diagram of inter-station negotiation in a non-SBA connection architecture.

[0210] FIG13 is a schematic diagram of inter-station negotiation of the SBA-based connection architecture 1.

[0211] FIG14 is a schematic diagram of inter-station negotiation based on the SBA connection architecture 2.

[0212] Figure 15 shows the non-SBA task architecture.

[0213] FIG16 is a schematic diagram of task signaling and task data interaction between network elements.

[0214] FIG17 is a schematic diagram of task signaling and task data interaction between network elements at the air interface.

[0215] FIG18 is a schematic diagram of the interaction between task signaling and task data of T-NAS.

[0216] Figure 19 shows the task architecture based on SBA.

[0217] Figure 20 is a schematic diagram of the ground interface based on the non-SBA trusted architecture.

[0218] FIG21 is a schematic diagram of trusted signaling interaction between UE, AN and CN under a non-SBA-based trusted architecture.

[0219] FIG22 is a schematic diagram of a trusted architecture based on SBA.

[0220] Figure 23 is a schematic diagram of the functional division of cNode and sNode.

[0221] Figure 24 is a schematic diagram of the RAN architecture and service function plane options provided in this application.

[0222] Figure 25 shows two design methods of the control plane protocol stack.

[0223] FIG26 is a schematic diagram of a data plane protocol stack design method for the routing layer.

[0224] FIG27 is a schematic diagram illustrating the relationship between the trusted functional aspect and business characteristics.

[0225] FIG28 is a schematic diagram of the control plane protocol stack—task signaling (distributed T-NAS: RAN connection architecture 1).

[0226] FIG29 is a schematic diagram of the control plane protocol stack—task signaling (distributed T-NAS: RAN connection architecture 2).

[0227] FIG30 is a schematic diagram of the control plane protocol stack - task signaling (centralized T-NAS).

[0228] FIG31 is a schematic diagram of the user plane protocol stack-task data.

[0229] FIG32 is a schematic diagram of the control plane protocol stack - connection signaling.

[0230] FIG33 is a schematic diagram of the user plane protocol stack-connection data.

[0231] Figure 34 is a schematic diagram of an independent computing surface protocol stack - computing surface data.

[0232] FIG35 is a schematic diagram of an independent data plane protocol stack - data plane signaling.

[0233] FIG36 is a schematic diagram of an independent data plane protocol stack—data plane data.

[0234] FIG37 is a schematic diagram of an independent trusted plane protocol stack - trusted plane signaling.

[0235] FIG38 is a schematic diagram of an independent trusted plane protocol stack - trusted plane data.

[0236] Figure 39 is a schematic diagram of the ground interface user plane protocol stack.

[0237] Figure 40 shows the protocol stack of Y1-C and Y1-U.

[0238] Figure 41 shows the protocol stack of Y2-C and Y2-U.

[0239] Figure 42 shows the protocol stack of Y3-C and Y3-U.

[0240] Figure 43 shows the protocol stack of T2-U and T2-C.

[0241] Figure 44 shows the protocol stack of T3-C.

[0242] Figure 45 shows the protocol stack of T4-C.

[0243] Figure 46 shows the protocol stack of T5-C.

[0244] Figure 47 shows the protocol stack of T6-C.

[0245] Figure 48 shows the protocol stack of T7-U.

[0246] Figure 49 shows the protocol stack of T8-C and T8-U.

[0247] Figure 50 shows the protocol stack of T9-C and T9-U.

[0248] Figure 51 shows the protocol stack of SC-C and SC-U.

[0249] Figure 52 shows the protocol stack of SS-C and SS-U.

[0250] Figure 53 shows the Se protocol stack.

[0251] Figure 54 shows the Sg protocol stack.

[0252] Figure 55 is a schematic diagram of UE / RAN tasks – end-to-end control plane protocol stack (connection architecture 1).

[0253] Figure 56 is a schematic diagram of UE / RAN tasks - end-to-end user plane protocol stack (connection architecture 1).

[0254] Figure 57 is a schematic diagram of UE / RAN tasks – end-to-end control plane protocol stack (connection architecture 2).

[0255] Figure 58 is a schematic diagram of UE / RAN tasks - end-to-end user plane protocol stack (connection architecture 2).

[0256] Figure 59 is a schematic diagram of the UE / CN task-end-to-end control plane protocol stack (task architecture 1a).

[0257] Figure 60 is a schematic diagram of the UE / CN task - end-to-end control plane protocol stack (task architecture 1b).

[0258] Figure 61 is a schematic diagram of the UE / CN task-end-to-end user plane protocol stack (task architecture 1a / 1b).

[0259] Figure 62 is a schematic diagram of the UE / CN task-end-to-end control plane protocol stack (task architecture 2a / 2b).

[0260] Figure 63 is a schematic diagram of the UE / CN task-end-to-end user plane protocol stack (task architecture 2a / 2b).

[0261] Figure 64 is a schematic diagram of the CN / RAN inter-task – end-to-end control plane protocol stack.

[0262] Figure 65 is a schematic diagram of the CN / RAN inter-task – end-to-end user plane protocol stack.

[0263] Figure 66 is a schematic diagram of RAN / inter-RAN tasks – end-to-end control plane protocol stack.

[0264] Figure 67 is a schematic diagram of RAN / inter-RAN tasks – end-to-end user plane protocol stack.

[0265] Figure 68 is a schematic diagram of the connection-end-to-end control plane protocol stack.

[0266] Figure 69 is a schematic diagram of a connection-end-to-end user plane protocol stack.

[0267] Figure 70 is a schematic diagram of the end-to-end computing plane protocol stack - computing plane data.

[0268] Figure 71 is a schematic diagram of the end-to-end data plane protocol stack-computing plane signaling.

[0269] Figure 72 is a schematic diagram of the end-to-end data plane protocol stack - data plane data.

[0270] Figure 73 is a schematic diagram of multi-level collaboration of independent intelligent surfaces.

[0271] Figure 74 is a schematic diagram of the end-to-end trusted plane protocol stack - trusted plane signaling.

[0272] Figure 75 is a schematic diagram of the end-to-end trusted plane protocol stack - trusted plane data.

[0273] Figure 76 is a schematic diagram of the connection data flow.

[0274] Figure 77 is a diagram of task data flow.

[0275] Figure 78 is a schematic diagram of independent data plane-data flow.

[0276] Figure 79 is a diagram of independent trusted surface – data flow.

[0277] Figure 80 is a schematic diagram of system information broadcasting.

[0278] Figure 81 shows three schemes for task anchor points to obtain connection anchor point identifiers.

[0279] Figure 82 shows two schemes for connecting anchor points to obtain task anchor point identifiers.

[0280] Figure 83 is a schematic diagram of three methods of computing power distribution.

[0281] Figure 84 is a schematic diagram of the logical relationship between AI use case generation, AI services and AI tasks provided in this application.

[0282] Figure 85 shows a three-layer closed loop centered on tasks.

[0283] Figure 86 shows the mapping relationship between each indicator dimension of QoAIS and QoS in each resource dimension.

[0284] Figure 87 is a schematic diagram of the core features of the task-centric architecture.

[0285] Figure 88 is a schematic diagram of mission-centric key technologies.

[0286] Figure 89 is a panoramic view of mission-centered key technologies.

[0287] Figure 90 shows the impact of the task-centric framework on the interface.

[0288] Figure 91 shows the task-centric logical architecture and functions.

[0289] Figure 92 shows how task-centric network AI is deployed.

[0290] Figure 93 is a schematic diagram of the task deployment and execution process.

[0291] Figure 94 is a diagram of task deployment.

[0292] Figure 95 is a schematic diagram of task deployment for connected UEs.

[0293] Figure 96 is a schematic diagram of task deployment for idle UEs.

[0294] Figure 97 shows the interfaces and protocol stacks affected by the task.

[0295] Figure 98 is a schematic diagram of split inference.

[0296] Figure 99 is a schematic diagram of AI task attributes.

[0297] Figure 100 is a schematic diagram of task mobility.

[0298] Figure 101 is a schematic diagram showing the difference between single-point task configuration and collaborative task configuration.

[0299] Figure 102 is a schematic diagram of a collaborative task configuration scheme.

[0300] FIG103 is a schematic diagram of another collaborative task configuration scheme.

[0301] FIG104 is a schematic diagram of the configuration between executors.

[0302] Figure 105 is a schematic diagram of multi-path reporting of collaborative AI tasks.

[0303] FIG106 is a schematic diagram of an interactive scenario of task information for a collaborative AI task.

[0304] Figure 107 shows some possible ways to carry task data (T-SRB / T-DRB carries task data).

[0305] Figure 108 is a schematic diagram of the task data reporting solution in the CU / DU and CP / UP separation scenarios.

[0306] Figure 109 is a schematic diagram of the solution for T-DRB carrying task data.

[0307] Figure 110 is a schematic diagram of the real-time adjustment of the four elements of the task when the task environment changes.

[0308] Figure 111 is a schematic diagram of task data transmission when the task is completed (idle UE idle task data transmission).

[0309] Figure 112 is a schematic diagram of task data transmission when the task is completed (RAN triggers CN to perform paging).

[0310] Figure 113 is a schematic diagram of the task adjustment process when the terminal performs switching.

[0311] Figure 114 is a schematic diagram of the real-time coordination of the four elements of the task.

[0312] FIG115 is a schematic diagram of task context migration in a switching scenario.

[0313] Figure 116 is a schematic diagram of early acquisition of neighboring cell task configuration in a UE mobility scenario.

[0314] Figure 117 is a schematic diagram of obtaining the neighboring cell AI model in a UE mobile scenario.

[0315] Figure 118 is a schematic diagram of neighboring AI model broadcasting.

[0316] Figure 119 is another schematic diagram of neighboring AI model broadcasting.

[0317] Figure 120 is another schematic diagram of neighboring AI model broadcasting.

[0318] Figure 121 is a schematic diagram of the separation of control and data nodes.

[0319] Figure 122 is a schematic diagram of low-frequency assisting high-frequency under the separation of control and data nodes.

[0320] Figure 123 is a schematic diagram of multi-RAT aggregation with control and data Node separation.

[0321] Figure 124 is a schematic diagram of multi-RAT aggregation (TRS layer splitting) under control and data node separation.

[0322] Figure 125 is a schematic diagram of the network topology with control and data nodes separated.

[0323] Figure 126 is a schematic diagram of the separation of upstream and downstream nodes.

[0324] Figure 127 is a schematic diagram of uplink and downlink spectrum separation.

[0325] Figure 128 is a schematic diagram of uplink and downlink spectrum separation - flexible carrier transmission.

[0326] Figure 129 is a schematic diagram of uplink and downlink spectrum separation-cooperative carrier.

[0327] Figure 130 is a schematic diagram of the computing surface - control, execution, and transmission.

[0328] Figure 131 is an example of computing power status reporting.

[0329] Figure 132 is a schematic diagram of real-time adjustment of model segmentation points.

[0330] Figure 133 shows the computing session protocol stack.

[0331] Figure 134 is a schematic diagram of calculating surface mobility.

[0332] Figure 135 is a schematic diagram of the overall framework of the data plane.

[0333] FIG136 is a schematic diagram showing a DA controller arranging functional modules to form a data pipeline.

[0334] Figure 137 is a schematic diagram of the data pipeline.

[0335] Figure 138 shows the three link modes of DDRB carried by the data plane.

[0336] Figure 139 shows three modes of data forwarding on the data plane.

[0337] Figure 140 is an example of the data plane DFCP-U protocol layer format design.

[0338] Figure 141 is another example of the data plane DFCP-U protocol layer format design.

[0339] Figure 142 is a schematic diagram of data plane mobility.

[0340] Figure 143 is a schematic diagram of the HiC collaboration scenario.

[0341] Figure 144 is a schematic diagram of the efficient organization of Hic.

[0342] Figure 145 is a schematic diagram of the Hic logical functional architecture.

[0343] Figure 146 shows the Hic deployment architecture.

[0344] Figure 147 is a schematic diagram of the Hic deployment architecture based on the RAN architecture provided in this application.

[0345] Figure 148 is a schematic diagram of the DropOut descriptor.

[0346] Figure 149 is a schematic diagram of the dropout descriptor sent by the network.

[0347] Figure 150 is a schematic diagram of UE reporting the dropout descriptor.

[0348] Figure 151 is a schematic diagram of the downlink transmission descriptor.

[0349] Figure 152 is a schematic diagram of the data feature measurement process.

[0350] Figure 153 is a schematic diagram of the transition from core network central control to multi-party balanced trust.

[0351] Figure 154 is a schematic diagram of the E2E initial access process.

[0352] Figure 155 is a schematic diagram of the process of initiating a service request on the network side of the connection process.

[0353] Figure 156 is a schematic diagram of the data sending and receiving process of the connection process.

[0354] Figure 157 is a schematic diagram of the task issuance process.

[0355] Figure 158 is another schematic diagram of the task issuance process.

[0356] Figure 159 is a schematic diagram of the communication device provided in this application.

[0357] Figure 160 is another schematic diagram of the communication device provided in this application. DETAILED DESCRIPTION

[0358] The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0359] First, a brief introduction to the relevant technologies and concepts involved in this application is given.

[0360] Base Station: A wireless base station in the network, also known as a network element of the wireless access network, responsible for all functions related to the air interface, including but not limited to the following:

[0361] (1) Wireless link maintenance function: maintains the wireless link with the terminal and is responsible for the protocol conversion between wireless link data and IP data quality monitoring;

[0362] (2) Radio resource management functions, including the establishment and release of radio links, scheduling and allocation of radio resources, etc.

[0363] (3) Some mobility management functions, including configuring terminals to perform measurements, evaluating the quality of terminal radio links, and making decisions about terminal handovers between cells.

[0364] The base station can send signals to the terminal device and also receive signals from the terminal device.

[0365] Operator or network management system: For example, the public land mobile network (PLMN) is a network established and operated by the government or an operator approved by it to provide land mobile communication services to the public. For example, it can be a mobile operator, a China Unicom operator, or a China Telecom operator.

[0366] Terminal equipment: Also known as user equipment (UE) or mobile station, it can be vehicle-mounted, portable, or handheld. The physical device and mobile user can be completely independent. All user information can be stored in a subscriber identity module (SIM) card, which is used in the mobile station. The terminal can directly interact with the base station over the air interface. The terminal can send and / or receive signals and is referred to as a transmitting UE or a receiving UE.

[0367] Core Network: Simply put, a mobile network can be divided into three parts: the base station subsystem, the network subsystem, and system support (such as security management). The core network is located within the network subsystem. Its main function is to connect call requests or data requests from the air interface to different networks.

[0368] The core network's primary functions are providing user connectivity, user management, and service bearer services. As a bearer network, it provides an interface to external networks. Establishing user connections involves one or more functions, including mobility management (MM), call management (CM), switching / routing, and voice notification (combined with intelligent network services to establish connections to intelligent network peripheral devices). User management includes user descriptions, quality of service (QoS), user communication records (accounting), a virtual home environment (VHE) (interactions with the intelligent network platform provide a virtual home environment), and security (security measures are provided by the authentication center, including security management of mobile services and security processing for access to external networks). Bearer connections include connections to external public switched telephone networks (PSTN), external circuit and packet data networks, the Internet, intranets, and short message service (SMS) servers. The core network can provide basic services including mobile office, e-commerce, communications, entertainment services, travel and location-based services, telemetry services - simple messaging services (monitoring and control), etc.

[0369] Figure 1 shows a schematic diagram of the 5G RAN architecture. As shown in Figure 1, the 5G RAN architecture is flat. Base stations exchange information and negotiate with adjacent base stations via the Xn interface. This inter-station interaction and negotiation is distributed, or in other words, flat. Consequently, inter-station negotiation is inefficient.

[0370] The technical solution provided by this application is introduced below.

[0371] The network elements in the embodiments of the present application include RAN nodes and terminals. RAN nodes can send signals and / or data to terminals and receive signals and / or data from terminals. Terminals can receive signals and / or data from RAN nodes and send signals and / or data to RAN nodes. The RAN nodes may specifically include the cluster control nodes and service service nodes described in the embodiments below, as detailed below.

[0372] The embodiments of the present application are applicable to both homogeneous and heterogeneous network scenarios. There are no restrictions on transmission points, and multi-point coordinated transmission between macro base stations, micro base stations, and macro base stations can be used. This applies to both FDD and TDD systems. Furthermore, the embodiments of the present application are also applicable to low-frequency scenarios (sub-6G), high-frequency scenarios (above 6G), terahertz, and optical communications.

[0373] The embodiments of this application can be applied to 5G communication systems, 6G communication systems, or future evolved communication systems, or other communication systems, etc., and this application does not limit this. This application can be applied not only to communications between access network devices and terminals, but also to communications between access network devices, communications between terminals, communications between vehicles, the Internet of Things, the Industrial Internet, etc. The following embodiments of this application are illustrated by taking the communication between a terminal and an access network device as an example.

[0374] Figure 2 is a schematic diagram of the architecture of a communication system applicable to an embodiment of the present application. For example, the architecture may include a RAN, a terminal, a core network (CN), and the like. Furthermore, an external network may also be included. The RAN, as provided in this application, may also be referred to as a RAN node, RAN device, or access network device, and may include a cluster control node and a service service node, as described below.

[0375] The following describes in detail the architecture of the RAN provided in this application.

[0376] In addition to providing basic connection services, the RAN provided in this application also needs to provide one or more of various new service capabilities (collectively referred to as the first function in this article) such as computing, data, trust, intelligence, and perception, effectively enabling everything as a service (XaaS) in future communication systems. Among them, connection services refer to services corresponding to connection functions provided within and outside the network, such as accessing the network, establishing links, closing links, controlling resource scheduling or allocation strategies, and quality of service (QoS). Therefore, future communication systems need to achieve efficient provision of new service capabilities by building endogenous collaborative capabilities of integrating and integrating multi-dimensional heterogeneous resources, which will drive the reconstruction of future radio access network (RAN) architecture.

[0377] To this end, this application proposes a layered RAN architecture that can more efficiently provide traditional connection services and new services beyond connection, which can also be called new features. Specifically, the RAN system includes cluster control nodes (cNodes) and service service nodes (sNodes). The cNodes and sNodes together constitute the access network equipment (or base stations). The use of a layered architecture will bring the following benefits:

[0378] 1) For connections:

[0379] a) On the air interface, separation of UE control signaling and data (high and low frequency) can be achieved;

[0380] b) Between stations, centralized inter-station negotiation replaces distributed inter-station negotiation, which improves collaboration efficiency;

[0381] 2) For tasks: cNodes centrally manage and coordinate sNode computing, data, connection, and other resources, resulting in wider collaboration and higher efficiency;

[0382] 3) In terms of trust: cNode is centrally trusted by sNode.

[0383] First, the overall architecture and functional division of the RAN architecture are introduced.

[0384] Figure 3 is a schematic diagram of the RAN architecture provided by this application. The main functions of the RAN architecture are divided into the following three layers:

[0385] (1) RAN service layer: In addition to providing traditional connection services, it mainly provides various new service capabilities such as computing services, data services, intelligent services, trusted services, and artificial intelligence (AI) services to CN network elements and end users within the network, further enriching future network systems. For example, the 6th generation th geberation,6G), business capabilities;

[0386] (2) RAN Functional Protocol Layer: To support the provision of the above-mentioned XaaS services, the RAN functional protocol layer, in addition to implementing traditional connectivity capabilities, needs to securely and efficiently coordinate the distributed heterogeneous resources (e.g., computing, data, AI models, etc.) provided by the RAN infrastructure layer, and support the RAN service layer in providing these new service capabilities within the network in the form of tasks. To this end, the RAN functional protocol layer will collaborate with the control plane and user plane of traditional connections through the addition of a new functional plane to efficiently manage and control the multi-dimensional resources provided by the RAN infrastructure layer, thereby providing new service functions that go beyond connectivity and providing QoS guarantees for these new service functions.

[0387] (3) RAN infrastructure layer: including spectrum resources in multiple frequency bands, distributed computing resources, storage resources, full-scenario access facilities with full coverage in air, space, land, and sea, reconfigurable smart surfaces, sensing facilities, and various types of terminals.

[0388] RAN services will achieve resource coordination and service QoS assurance for multiple types of resources and multiple nodes in the form of tasks. This will ultimately bring a new dimension to future wireless communication networks (from the single dimension of connection services to new service dimensions such as connection, computing, data, intelligence, trust, algorithms, and perception that are encapsulated and provided in the form of tasks), enabling service level agreements (SLAs) for various AI, perception, computing, data, and other services to be guaranteed, thereby further expanding the application scenarios of wireless communication networks.

[0389] The following describes the core impact of the solution provided in this application on the RAN architecture from multiple aspects, including tasks, computing, data, intelligence, and trust.

[0390] 1) Mission

[0391] The task-centric network architecture introduces new network AI orchestration, task control, and a task resource layer. Task control uses control-plane signaling to provide real-time control of multiple nodes (such as UEs, base stations, and core network elements) and the four essential resources (connectivity, computing, data, and algorithms) in the resource layer. Task-centricity is a native network AI architecture that enables efficient execution of AI tasks within the network.

[0392] Figure 4 is a diagram showing the changes in the task architecture. As shown in Figure 4, due to the introduction of tasks, the network architecture provided by this application needs to achieve the following key changes in design paradigm:

[0393] Change 1: The management and control objects in wireless network systems have changed from "sessions" to "tasks";

[0394] Change 2: Management resources have shifted from connection resources to the four-element resources of connection, computing, data, and algorithms;

[0395] Change 3: From "session control" to "task control";

[0396] Change 4: From "session QoS" to "task QoS".

[0397] 2) Calculation

[0398] In addition to providing basic connectivity (CF), nodes in the 6G infrastructure also offer additional computing capabilities. To efficiently utilize communication and computing resources, real-time perception of both communication and computing resource states is required, along with coordinated control of these resources. This ensures that, in dynamic and complex wireless network environments, end-to-end QoS requirements for future new services, such as ultra-low latency, high data security and privacy, and sustainable energy conservation, are met. The deep integration of communication and computing can better enable new capabilities (such as endogenous intelligence and ubiquitous perception) in communication networks (e.g., 6G networks) and new services (such as immersive extended reality (XR), digital twins, and cloud universes).

[0399] 3) Data

[0400] The existing 5G communication network is built based on sessions, and its user plane is used to carry session data. It cannot meet the "on-path computing" and "arbitrary topology" support required for 6G data carrying. The user plane cannot carry new data types of the 6G network. For this reason, this application introduces new data functions.

[0401] The new data function provides trusted data services for applications and users, mainly providing eight categories of data services. The service descriptions of these eight categories of data services are as follows:

[0402] ● Raw data: The collected or collected raw data is fed into applications such as AI;

[0403] ●Data preprocessing: data cleaning, filtering, aggregation, fusion and other preprocessing services;

[0404] Data storage: Centralized or distributed storage services can be provided on data agents (DAs), data storage functions (DSFs), or distributed ledge technology (DLTs);

[0405] Data privacy and security protection: Provide end-to-end data privacy and security protection technology;

[0406] Data sharing / transaction: trusted data sharing and transaction;

[0407] Data traceability: traceability / audit services, public key, decentralized identity (DID) and other distribution services;

[0408] Data analysis: Analyze and mine data based on AI, machine learning (ML), and big data to provide intelligent services.

[0409] ●Data dictionary: wireless network feature dataset.

[0410] Data functions consist of data orchestration (DO), data control (DC), data agent (DA), trusted anchor agent (TAA), and data storage function (DSF). DC, DA, and TAA can be deployed in base stations, and DA can be deployed in terminals.

[0411] 4) Heterarchical intelligent collaboration (HiC)

[0412] Multi-level intelligent collaboration aims to provide an endogenous distributed collaboration mechanism for network elements and terminals at all levels within the network. Through collaboration, the intelligence within the network can flow, thereby improving the performance and efficiency of network AI.

[0413] Figure 5 is a comparative diagram of the Hic collaboration scenario and the collaboration triggered by the connection. The collaboration scenario of HiC is characterized by large scale, large traffic and high degree of freedom, while the connection-based collaboration in the traditional network is only a small-scale collaboration, see the left figure of Figure 5, such as neighbor station switching, coordinated multiple points (CoMP), etc., which can no longer support HiC. For this reason, this application introduces intelligent functions to establish collaborative channels between network elements and terminals at all levels of the network, efficiently organize intelligent collaboration between network elements and terminals, and ensure that collaboration is manageable and controllable. The collaboration scenario of Hic is shown in the right figure of Figure 5.

[0414] The main functions of HiC include one or more of the following:

[0415] ● Collaboration can be controlled and managed, and the lifecycle of collaboration instances can be managed, including the creation of collaboration instances, the allocation of instance identifiers (IDs), and the startup, deletion, and update of collaborations.

[0416] ● Provides a collaborative instruction set that can be combined into various collaborative patterns to efficiently organize the collaborative process between network elements and terminals.

[0417] ●Supports the transmission of diverse intelligent representations between network elements, transfers intelligent knowledge between heterogeneous devices, promotes continuous learning and evolution of the network, and continuously optimizes network AI performance and improves network AI efficiency

[0418] Supports the establishment and maintenance of large-scale collaboration sets. Collaboration instances can span different RAN cluster control nodes, such as the cluster node mentioned above. Network elements have the ability to autonomously initiate, join, and exit collaboration instances.

[0419] ●The collaborative pattern is extensible and flexibly supports various collaborative learning methods.

[0420] 5) Credibility

[0421] Trustworthiness refers to the ability to meet the requirements of information and cyberspace security, privacy protection, and risk-oriented resilience for end-to-end networks and applications. A multi-mode trust model is a key characteristic of trustworthiness in future communication networks (such as 6G networks). This includes the consensus model supported by 6G blockchain technology, the bridge model where home network operators provide authentication and authorization to users, and the endorsement model based on third-party trust. Equilibrium trust is the fundamental principle of trustworthiness. This involves democratically negotiating trustworthiness among the terminal, access network, core network, and application parties, with or without reference to centralized policy recommendations from network intelligence, to achieve an optimal outcome. Trustworthiness as a service (TAS) is the target outcome of trustworthiness, providing trustworthiness as a service. Specifically, this includes blockchain services, remote attestation services, and privacy protection services.

[0422] The new features of the aforementioned communication networks, such as tasks, computing, data, multi-level intelligent collaboration, and trust, will be fully and detailed below.

[0423] 1. Overview of RAN architecture.

[0424] The introduction of new features (or new capabilities) in the RAN architecture mentioned above is the main driving force behind the transformation of the RAN architecture. The essential feature of these new features is task-based collaboration across multiple nodes and multi-dimensional resources (such as computing, data, algorithms, connections, etc.). From the perspective of the RAN architecture, it is necessary to introduce centralized coordination nodes to provide task coordination within and between regions. Therefore, the RAN nodes in this application can be divided into:

[0425] cNode (cluster Node): A cluster control node provides regional-level centralized coordination of multiple service nodes, as well as cross-regional coordination between cluster control nodes. It serves as the task anchor within a cluster (or within the region where the cNode provides centralized coordination). Over the air interface, it provides no connectivity or only connectivity control (depending on the design options of the RAN architecture, the functionality provided varies).

[0426] sNode (serving Node): A service node that provides task scheduling and execution. It provides connection control and / or data functions over the air interface (the functions provided vary depending on the design options of the RAN architecture).

[0427] Alternatively, cNode and sNode may also be referred to as network elements (NEs), respectively, without limitation. If the functions of cNode and sNode are enabled (microservice architecture is adopted within the base station), the network functions within cNode and sNode can be further defined.

[0428] In 5G, core network functions have implemented the SBA architecture, while the RAN is still based on the traditional non-service-based (non-SBA) architecture. In the solution provided by this application, there are two ways for RAN architecture evolution: one is the traditional non-service-based architecture (non-SBA) and the other is the service-based architecture (SBA).

[0429] The following uses the 6G communication system as an example to illustrate the RAN architecture provided in this application, for example, using 6G-RAN as an example.

[0430] 1) RAN Architecture 1: Non-SBA-based 6G-RAN Architecture

[0431] Figure 6 is a schematic diagram of the overall system architecture applicable to the present application. The cNode and sNode are interconnected via the Y1 interface. The cNode and cNode are interconnected via the Y2 interface. The cNode is also connected to the 6GC via the Tx interface, more specifically, to the network access function (NAF) via the T3 interface and to the connectivity function-control (CF-C) via the T4 interface. The cNode is also connected to the task control function (TCF) / task process function (TPF) via the T2 interface.

[0432] sNodes are connected to each other via the Y3 interface. sNodes are also connected to the 6GC via the Ty interface, more specifically, to the NAF via the T5 interface, to the connectivity function control plane (CF-C) via the T6 interface, and to the connectivity function user plane (CF-U) via the T7 interface.

[0433] Figure 7 shows the overall architecture and interfaces of a non-SBA RAN. The interfaces between the various functions are shown in Figure 7. Whether the user plane is service-oriented is decoupled from whether the control plane is service-oriented. Therefore, the CF-U can be directly connected to the BAS bus (i.e., the user plane is also service-oriented) or connected only to the CF-C and sNodex (i.e., the user plane is non-service-oriented).

[0434] RAN Architecture 2: 6G RAN Architecture Based on SBA

[0435] Figure 8 is a schematic diagram of the overall SBA-based RAN architecture and interfaces. The RAN utilizes the SBA interface, where the CN service bus and the RAN service bus can share a common bus or be two independent buses with interconnected interfaces. The service-based interface provided by the cNode is temporarily designated Sc (hereinafter referred to as the first service-based interface), and the service-based interface provided by the sNode is temporarily designated Ss (hereinafter referred to as the second service-based interface). This diagram illustrates two independent buses.

[0436] Based on the above-mentioned overall RAN architecture, it is further divided into connection-based architecture, task-based architecture and trust-based architecture, which are respectively referred to as connection architecture, task architecture and trust architecture, and are explained below.

[0437] a) Connection Architecture

[0438] i. Non-SBA architecture

[0439] For pure connection architecture, there are two methods:

[0440] Connection Architecture 1 (i.e., non-SBA-based connection architecture 1)

[0441] (Air interface) CP / UP separation: On the air interface, the cNode has the control plane function of the connection, and the sNode has the user plane function of the connection.

[0442] Figure 9 is a schematic diagram of non-SBA connection architecture 1. The cNode communicates with the NAF (UAM) via the T3 interface for initial UE access and exchanges connection control signaling with the CF-C via the T4 interface. The sNode communicates with the CF-U via the T7 interface and transmits UE data packets. cNodes exchange UE handover-related signaling via the Y2 interface and control sNode user data forwarding via the Y1 interface. SNodes forward user data via the Y3 interface. Direct user plane connections effectively reduce forwarding latency.

[0443] Connection Architecture 2 (i.e., Connection Architecture 2 based on non-SBA)

[0444] (Air interface) CP / UP are not separated: On the air interface, the cNode has no connection function, and the sNode has the control plane and user plane functions of the connection.

[0445] Figure 10 shows a schematic diagram of non-SBA connection architecture 2. The sNode exchanges UAM signaling with the NAF over the T5 interface, controls the connection with the CF-C over the T6 interface, and establishes a data bearer with the CF-U over the T7 interface for user data transmission. UE handover signaling and data packet forwarding are exchanged between sNodes over the Y3 interface.

[0446] Figure 11 is a schematic diagram of UE data transmission under the non-SBA connection architecture. From the UE's perspective, different connection architectures have different functions. Among them:

[0447] Connection Architecture 1 – (Air Interface) CP / UP Separation:

[0448] For communication between UE and RAN, the control plane communicates directly with the cNode, and the user plane communicates directly with the sNode;

[0449] For communication between UE and CN, the control plane communicates with CF through cNode; the user plane communicates with CF through sNode.

[0450] Connection Architecture 2 – (Air Interface) CP / UP Not Separated:

[0451] When UE communicates with RAN, both the control plane and the user plane communicate directly with the sNode;

[0452] The communication between UE and CN, control plane and user plane are all through sNode and CF.

[0453] For the above two connection architectures, there are also two ways of inter-station negotiation signaling related to specific connection services.

[0454] Figure 12 shows a schematic diagram of inter-node negotiation in a non-SBA connection architecture. Method a: direct negotiation between cNodes, or unified negotiation between sNodes by the cNodes; Method b: direct negotiation between sNodes without the participation of cNodes.

[0455] Through the above combinations, multiple connection architecture solutions 1a, 1b, 2a, and 2b can be formed; the specific functions of each solution will not be repeated here.

[0456] ii.SBA Architecture

[0457] Connection Architecture 1 - (Air Interface) CP / UP Separation (i.e., Connection Architecture 1 based on SBA)

[0458] Figure 13 illustrates inter-station negotiation in SBA-based connection architecture 1. In this architecture, the cNode provides an Sc interface for the NAF and CF-C to use for transmitting connection control signaling. Furthermore, the cNode also uses the Sc interface for other cNodes to call, providing mobility signaling functionality.

[0459] The connection relationship between network elements is as follows:

[0460] NAF / CF-C->cNode

[0461] cNode->cNode

[0462] In this application, the symbol "->" is used to indicate that there is a connection relationship between network elements. For example, NAF / CF-C->cNode indicates that the NAF / CF-C and cNode can be connected through the corresponding interface, which will not be repeated below.

[0463] The sNode provides an Ss interface for CF-U to use for user data transmission. Furthermore, the sNode is also used by other sNodes through the Ss interface to provide mobility data forwarding. Data forwarding between sNodes is controlled by the cNode.

[0464] The connection relationship between network elements is as follows:

[0465] CF-U->sNode

[0466] sNode->sNode

[0467] cNode->sNode

[0468] Connection Architecture 2 – (Air Interface) CP / UP Not Separated (i.e., Connection Architecture 2 Based on SBA)

[0469] Figure 14 illustrates inter-station negotiation in SBA-based connection architecture 2. In this architecture, the sNode provides an Ss interface for the NAF, CF-C, and CF-U to use for transmitting connection control signaling and user data, respectively. Furthermore, the sNode is also available to other sNodes via the Ss interface, providing mobility signaling and data forwarding.

[0470] The connection relationship between network elements is as follows:

[0471] NAF / CF-C / CF-U->sNode

[0472] sNode->sNode

[0473] In the SBA-based connection architecture 2, the Sc function provided by the cNode does not provide any connection-related services, but only provides task-related services.

[0474] b) Task Architecture

[0475] i. Non-SBA architecture

[0476] Figure 15 shows the non-SBA task architecture. The cNode is responsible for the control plane functions of the newly added features, such as the task anchor (TA) and data processing functions (for example, when the cNode has computing power, it can also deploy a task scheduler (TS) and a task executor (TE) to perform data processing tasks). The sNode is responsible for some of the control plane and user plane functions of the newly added features, such as TS and TE. Task management is performed between cNodes and sNodes via the Y1 interface; task negotiation is performed between cNodes via the Y2 interface; inter-domain task negotiation is performed between cNodes and TCF via the T2 interface; and task signaling or data exchange between TEs is performed between sNodes via the Y3 interface.

[0477] Figure 16 illustrates the interaction of task signaling and task data between network elements. Task control between network elements includes cNode control of sNodes, task negotiation between cNodes, and task negotiation between TCF and cNodes. For new data services, cNodes have added a new DC function to manage DAs within a domain and their orchestration. For the new HiC feature, cNodes have added a new HicC function to manage collaboration instances, HicAs, and configure collaboration patterns.

[0478] RAN data plane data is transmitted to the core network by the cNode, which aggregates sNode data plane data and exchanges it with the TPF via the T2-U interface. Alternatively, the sNode exchanges data with the TPF via a direct connection interface. When the TCF acts as a TA, task control of the cNode is performed via the direct connection interface (T2-C); task data is exchanged between the TPF and the cNode (T2-U). When the cNode acts as a TA, task control and task data exchange with the sNode are performed via the direct connection interfaces (Y1-C and Y1-U). When the cNode acts as a TA, task signaling negotiation and task data exchange with adjacent cNodes are performed via the direct connection interfaces (Y2-C and Y2-U). Optionally, direct connection between the sNode and the TPF may be supported in the future.

[0479] Figure 17 shows the task signaling and task data exchange over the air interface. When the cNode acts as a TA, task control interaction with the UE is performed directly through the task resource control (TRC) interface or through an sNode. Task data exchange between the UE and the sNode is performed through the task resource data (TRD) interface, and task data between the UE and the cNode is forwarded from the sNode to the cNode.

[0480] Figure 18 illustrates the interaction of task signaling and task data within T-NAS. When the TCF acts as the TA, task control signaling with the UE is performed via the T-NAS interface, which has four modes (Task Architecture 1a, Task Architecture 1b, Task Architecture 2a, and Task Architecture 2b). Task data interaction is forwarded from the sNode to the cNode, processed (optionally) by the cNode, and then sent to the TPF.

[0481] 1) Mission Architecture 1a - Distributed T-NAS:

[0482] Based on connection architecture 1, the TCF has T-NAS capabilities. TCF's UE task control can be directly encapsulated into T-NAS messages and delivered through the cNode. The cNode also delivers UE task control directly without transiting through the sNode. Furthermore, because the CF-C also has connected T-NAS capabilities, both the TCF and CF-C have distributed T-NAS capabilities.

[0483] 2) Mission Architecture 1b - Distributed T-NAS:

[0484] Based on connection architecture 1, it is similar to task architecture 1a, except that forwarding is done by sNode.

[0485] 3) Mission Architecture 2a - Centralized T-NAS:

[0486] Based on connection architecture 1, the TCF does not have T-NAS capabilities. After all task control signaling is sent to the CF-C, the CF-C generates T-NAS messages and sends them to the UE via the cNode, or the CF-C generates T-NAS messages instead. In this case, only the CF-C has T-NAS capabilities (i.e., T-NAS proxy), so it is called centralized T-NAS.

[0487] 4) Mission Architecture 2b - Centralized T-NAS:

[0488] Based on connection architecture 2, it is similar to task architecture 2a, except that forwarding is done by sNode.

[0489] ii.SBA Architecture

[0490] Regarding the task architecture, the architecture after adopting SBA is shown in Figure 19.

[0491] Figure 19 is a schematic diagram of the SBA-based task architecture, in which the cNode provides an Sc interface for TCF to call, for cross-region task negotiation signaling and task data transmission; and through the Sc interface, it is called by the cNode for cross-cNode task negotiation signaling and task data transmission.

[0492] The connection relationship between network elements is as follows:

[0493] ●TCF / TPF->cNode

[0494] cNode->cNode

[0495] sNode provides the Ss interface for cNode to call, which is used for task control signaling interaction and task data transmission between cNode and sNode; and through the Ss interface, it is called by sNode for task data transmission between sNodes.

[0496] The connection relationship between network elements is as follows:

[0497] cNode->sNode

[0498] sNode->sNode

[0499] Note: The relationship between the RAN SBA bus and the CN SBA bus can be sharing the same bus (such as the CN bus) or being independent buses, but the sharing method is more efficient.

[0500] c) Trusted Architecture

[0501] i. Non-SBA architecture

[0502] Figure 20 is a schematic diagram of the ground interface based on a non-SBA trusted architecture. Specifically, for the trusted plane, the cNode adds a trustworthiness engine (TWE) to provide the network with global decision-making and management information for the trusted plane. It provides trusted policy input, activation, and management of trusted services to the trusted plane enabler (TWG) in a static or dynamic manner. Specific functions include, but are not limited to, one or more of the following:

[0503] Ledger anchoring functions include blockchain node capability discovery, capability deployment, full lifecycle management of chain creation / management / revocation, chain status management, on-chain strategy configuration, and node access authorization management for the blockchain (BC);

[0504] Network global trust policy functions, including intelligent generation, storage, and notification of network global trust policies to other parties;

[0505] Remote measurement service functions, including storing proof results, reference values, proof evidence, generating remote proof challenges, and verifying proof evidence;

[0506] Privacy protection service function;

[0507] Third-party security protection function.

[0508] Both cNode and sNode have added TWG, which provides a trusted surface enabling module for the network, accepts TWE configuration and management, and implements trusted capabilities. Specific functions include but are not limited to one or more of the following:

[0509] Trusted policy negotiation and decision-making capabilities, including negotiation mode configuration, input parameter generation and storage, and trusted policy generation functions;

[0510] Cryptographic capabilities, supporting encryption and decryption based on symmetric and asymmetric keys, signatures, basic hash algorithms, as well as the calling and configuration of homomorphic encryption and post-quantum encryption;

[0511] Authorization verification capability, supporting static authorization verification function and token-based authorization verification;

[0512] 6G blockchain capabilities, including client, micro-node, light node, full-node and other modes, with transaction generation, query, broadcast, verification, consensus, communication, smart contract and storage;

[0513] Situational awareness capabilities, supporting traffic monitoring, asset monitoring, and log collection;

[0514] Remote measurement and verification capabilities, supporting remote measurement and verification based on trusted platform modules (TPM) and software guard extensions (SGX);

[0515] Privacy protection capabilities support the generation and storage of user permissions, and the calling and configuration of various privacy protection algorithms.

[0516] Figure 21 is a diagram of the trusted signaling interaction between the UE, AN, and CN in a non-SBA-based trusted architecture. The trusted signaling transmission method from the UE and RAN to the CN's trustworthiness enabler function (TEF) and trustworthiness gear function (TGF) is as follows:

[0517] TEF: There are two connection modes between the TEF and the cNode / sNode. One connection mode is that the CN TEF can directly connect to the cNode / sNode, supporting the T8 and T9 interfaces in Figure 20. The RAN's trusted signaling is sent directly to the CN TEF / TGF, and the UE's trusted signaling is sent to the CN TEF / TGF via the cNode / sNode, without requiring forwarding by other core network elements. The other connection mode is that the CN TEF does not need to be connected to the cNode / sNode. The T8 and T9 interfaces in Figure 20 do not exist. The trusted signaling between the CN TEF and the RAN / UE must be forwarded by the CF, reusing the T4, T6, and T7 interfaces.

[0518] TGF: TGF is not connected to cNode / sNode. All trusted signaling with RAN / UE needs to be forwarded by CF, reusing T4, T6, and T7 interfaces.

[0519] ii.SBA Architecture

[0520] Figure 22 is a schematic diagram of an SBA-based trusted architecture. As shown, in the SBA-based trusted architecture, the TWE / TWG are both mounted on the serial bus interface (SBI) bus as network functions along with the cNode / sNode, becoming the Trustworthiness Engine Function (TEF) and the Trustworthiness Gear Function (TGF). The RAN TEF provides an external Se interface (referred to herein as the third service-oriented interface), while the RAN TGF provides an external Sg interface (referred to herein as the fourth service-oriented interface).

[0521] As mentioned above, the RAN nodes in this application include cNode and sNode. The functional division of cNode and sNode is introduced below.

[0522] 2. Functional division

[0523] In different architectures, the functions of cNode and sNode are different.

[0524] FIG23 is a schematic diagram showing the functional division of cNode and sNode.

[0525] Regarding connectivity, taking the above RAN connectivity architecture 1 as an example, the cNode has one or more of the following functions:

[0526] -Cross-cell resource negotiation, signaling / data bearer control, mobility management or measurement control, etc.

[0527] Regarding new features, cNode has one or more of the following functions:

[0528] -Task Anchor (TA), which has functions such as task decomposition and merging, and manages the TE resources under it, such as allocating a corresponding TE node to each task and the computing / data / model resources of each TE node for the task;

[0529] The computing anchor (CA) has functions such as decomposition and merging of computing tasks, as well as management of the TE resources under it. For example, it allocates a corresponding computing executor (CE) node to each task and the computing resources of each CE node for that task;

[0530] -Data Control (DC), which has coarse-grained orchestration of data tasks, assembles data pipelines in the local domain based on DA capabilities and data service requests, receives DA capability reports, and implements registration and deregistration of DAs;

[0531] - Multi-agent Collaboration Control (HicC), which collects the collaborative capabilities of network elements and terminals at all levels, receives collaboration requests, creates collaboration instances, configures collaboration patterns, manages collaborative QoS, and optimizes the collaboration process.

[0532] - Trusted Web Engine (TWE) provides global decision-making and management information for the trusted surface of the network. It provides trusted policy input, activates, and manages trusted services for the trusted surface enabler module (TWG) in a static or dynamic manner. Specifically, it includes functions such as ledger anchoring, global trusted web policy, remote measurement, privacy protection, and third-party security protection.

[0533] - Trusted Workbench (TWG) provides a trusted surface enabling module for the network, accepts configuration and management from TWE, and implements trusted capabilities. Specifically, it includes trusted policy negotiation and decision-making, cryptography, authorization verification, 6G blockchain, situational awareness, remote measurement and verification, and privacy protection.

[0534] Optionally, cNode can also deploy computing and data processing capabilities, and optionally support functions such as TE / CE / DA.

[0535] For connections, sNode has one or more of the following functions:

[0536] -Data radio bearer management, air interface resource scheduling for user data, etc.

[0537] Regarding new features, cNode has one or more of the following functions:

[0538] -Task Scheduling (TS), which has the function of scheduling task resources, such as allocating real-time resources to each task (corresponding TE nodes, and the computing / data / model resource allocation of each TE node for the task, etc.);

[0539] -Task Execution (TE), which has the task execution function and uses the corresponding resources to execute specific tasks according to the resource control / scheduling of TA or TS;

[0540] - Computing scheduler (CS), which has the resource scheduling function of computing tasks, such as allocating real-time resources to each computing task (corresponding TE nodes and the computing resource allocation of each TE node for the task, etc.);

[0541] - Compute Execution (CE), which has the function of executing computing tasks and uses the corresponding resources to execute specific computing tasks according to the resource control / scheduling of CA or CS;

[0542] -Data agent (DA), which has the function of executing data tasks and executes specific data tasks according to the control of DO or DC;

[0543] - Multi-agent Collaboration Agent (HicA), which has the function of executing intelligent collaboration and executing specific collaboration processes. This includes parsing collaboration patterns and configuring local collaboration parameters, generating and processing collaborative interaction information, and training and reasoning AI / ML.

[0544] - Trusted Workgroup (TWG), see the functions of TWG above.

[0545] For connections, the CN NAF performs one or more of the following functions:

[0546] - Authentication and certification of initial access;

[0547] - Selection function for initial connection.

[0548] For connections, the CN NF-C has one or more of the following functions:

[0549] - Subsequent signaling functions other than initial access and initial selection, specifically including one or more of NAS security, mobility management, UE IP address allocation, PDU session control, etc.

[0550] For connections, the CN NF-U has one or more of the following functions:

[0551] - Responsible for mobility anchor point, PDU processing, etc.

[0552] In response to new features, CN TCF has the following functions:

[0553] -One or more of the above functions such as TA, CA, HicC, TS, CS, DC, etc.

[0554] For new features, CN TPF has one or more of the following functions:

[0555] -The above-mentioned TE, CE, DA, HicA and other functions.

[0556] Regarding trustworthiness, CN TEF has one or more of the following functions:

[0557] - The functionality of the aforementioned TWE.

[0558] Regarding trustworthiness, the CN TGF has one or more of the following functions:

[0559] - The functions of the above TWG.

[0560] The following describes the air interface under the RAN architecture of this application.

[0561] 3. Air interface.

[0562] Figure 24 is a schematic diagram of the RAN architecture and service function options provided by this application. As shown in Figure 24, there are four design methods for the air interface protocol stack based on the relationship between new features and connections:

[0563] Option 1: The control plane and user plane of the connection remain unchanged, and all newly added features (referred to herein as newly added features, new features, or first functions) are integrated into them;

[0564] Option 2: Based on Option 1, separate the task data plane and the user plane of the connection, while keeping everything else unchanged.

[0565] Option 3: The control plane and user plane of the connection remain unchanged, and the mission control plane and mission data plane are added;

[0566] Option 4: The control plane and user plane remain unchanged, and the computing plane, data plane, and intelligent plane are added.

[0567] For Option 4, the newly added planes have their own control planes and user planes, which are not shown in Figure 24. From Option 1 to Option 4, the functional definitions of each plane tend to be independent instead of integrated.

[0568] Each option is described in detail below.

[0569] Before introducing specific options, we first discuss various ways to design the protocol stack, as shown in Figure 25.

[0570] FIG25 is a schematic diagram of two design methods of the control plane protocol stack of each functional plane, specifically:

[0571] Method 1: Signaling between the UE and the base station / core network (CN) is transmitted over traditional RRC / NAS channels. Application messages are added to the existing channels to support the transmission of control signaling for the newly added functional plane.

[0572] Method 2: A new layer is defined for signaling between the UE and the base station / CN. This layer can terminate at the base station or be forwarded by the base station to the CN for termination. Therefore, in addition to transmitting functional information, this new protocol layer also serves routing purposes (either base station termination or CN termination).

[0573] The air interface protocol stack of the UE includes a control plane protocol stack and a data plane protocol stack, wherein the control plane protocol stack includes a first sublayer, the first sublayer supports the transmission of control signaling of the first function, or the first sublayer supports the transmission of control signaling of the first function and routing function, and the first function includes one or more of computing, data, intelligence, and trust. It should be understood that the first sublayer generally refers to the sublayer that supports the transmission of control signaling of the first function, and this application does not limit the specific implementation of the first sublayer.

[0574] Figure 26 shows the design of the data plane protocol stack for the routing layer. As shown in Figure 26, the data plane protocol stack of each functional plane needs to support an arbitrary routing mechanism. There are three approaches for the routing layer:

[0575] Method 1: Add routing information to an existing layer. For example, the base station adds routing identifier information (such as source node identifier, destination node identifier, and QoS information) to the existing T-PDCP layer of the air interface. During uplink transmission, the base station parses this information and terminates it. During downlink transmission, the base station adds routing information to this layer. As shown in Figure 28, the base station adds routing information to the T-PDCP layer.

[0576] Option 2: Add an independent routing layer, designed to provide more decoupled and clear functionality (i.e., service and routing are decoupled). Base stations use information from this routing layer to perform routing and, optionally, modify routing information. Furthermore, the air interface routing layer between the UE and RAN and the routing layer between the RAN and CN (TPF) can be defined independently.

[0577] ●Method 3: Add routing information to the newly added service layer.

[0578] FIG27 is a schematic diagram illustrating the relationship between trusted functions and business characteristics.

[0579] 1) (Business data related) Trusted signaling / trusted data transmission (such as trusted function control signaling corresponding to encryption and decryption of connection data, and key data information, etc.)

[0580] Opt1: Through the service's control plane and bearer, and associated transmission (such as the transmission of key information used for encryption and decryption of service data);

[0581] opt2: through the service's data plane and bearer, and associated transmission (such as the transmission of key information used for encryption and decryption of service data);

[0582] Opt3: independent transmission via independent trusted control plane and signaling (relative to service signaling);

[0583] opt4: independent trusted data plane, data bearer, and independent transmission (relative to service signaling).

[0584] 2) Data transmission related to business data (such as business data after encryption and protection)

[0585] Opt1 - Business plane bearer: For the data sending end, the business calls the trusted module function to obtain encrypted data, and transmits the trusted business data through the business plane and bearer; the receiving end performs the same operation;

[0586] Opt2-Trusted plane bearer: For the data sending end, the business or application layer sends the original data to the trusted party, which encrypts the data and transmits the business data after the trusted processing through the trusted plane and bearer; the receiving end performs the same operation.

[0587] 3) (Business-independent) trusted signaling / data transmission (trusted business signaling and data, such as blockchain)

[0588] Opt 1: Integration with the service plane and channel-associated transmission (e.g., Option 1 in 3.1, Option 2 in 3.2, and Option 3 in 3.3 below);

[0589] Opt 2: Independent trusted plane (as in Option 4 in 3.4 below, with additional trusted planes, specifically including a trusted control plane and a trusted data plane).

[0590] 3.1. Option 1: Shared Functional Surface

[0591] 1) Mission

[0592] The control surface design is different for different mission architectures.

[0593] ●Task Architecture 1a / 1b (Distributed T-NAS)

[0594] For RAN connection architecture 1 / 2 (CP / UP separation or non-separation) + task architecture 1a / 1b (distributed T-NAS), Figures 28 and 29 show the control plane protocol stack. Specifically, Figure 28 shows the control plane protocol stack - task signaling (distributed T-NAS: RAN connection architecture 1), and Figure 29 shows the control plane protocol stack - task signaling (distributed T-NAS: RAN connection architecture 2).

[0595] In the above example, user connection data is forwarded to the NAF / CF-C, and task signaling is forwarded to the TCF. For RAN connection architecture 1, this is forwarded by the cNode; for RAN connection architecture 2, this is forwarded from the sNode to the cNode, and then from the cNode to the TCF.

[0596] ● Mission Architecture 2a / 2b (Centralized T-NAS)

[0597] For RAN connection architecture 1 / 2 (CP / UP separation, non-separation) + task architecture 2a / 2b (centralized T-NAS), see Figure 30, which shows the control plane protocol stack, where:

[0598] - The functions of the T-PDCP, RLC, and TRS sublayers (terminated at the cNode or sNode on the network side) are described in detail in the Air Interface - Protocol Layer section below;

[0599] -The TRC terminates on the network side at the cNode (RAN Connection Architecture 1) or sNode (RAN Connection Architecture 2). Its functions are described in Section 6.3 below.

[0600] - T-NAS control protocol (terminated by NAF and CF-C, or TCF on the network side) performs the functions listed in TS25.501[3], such as authentication, mobility management, security control, etc.

[0601] For RAN connection architecture 1, packets are forwarded by the cNode; for RAN connection architecture 2, packets are forwarded by the sNode.

[0602] For task data, when cNode is TA, UE first sends the task data to sNode, which then sends it to cNode, and cNode finally processes the task data (for example, merges and processes it with other TE subtask data), or UE directly sends it to sNode, which processes and terminates the data.

[0603] For task data, when TCF is TA, the UE first sends the task data to the sNode, which then sends it to the cNode. The cNode processes the data (for example, summarizes the task data) and sends it to the corresponding TPF.

[0604] For RAN connection architecture 1 / 2 (RAN connection architecture 1 means CP / UP separation, and RAN connection architecture 2 means CP / UP unseparated), Figure 31 shows the user plane protocol stack. The functions of the TRD, T-SDAP, T-PDCP, RLC, and TRS sublayers (terminated at the sNode on the network side) are described in detail below.

[0605] 2) Connection

[0606] When the shared functional plane is used, the cNode interacts directly with the NAF / CF-C for connection signaling. At this time, the air interface protocol stack performs functional fallback, from the task fallback to the connection protocol stack, as shown in Figure 32:

[0607] T-NAS: Fallback to NAS;

[0608] TRC: Fallback to RRC;

[0609] ●T-SDAP: fall back to SDAP;

[0610] ●TRS: Fall back to MAC.

[0611] For connection data, sNode interacts directly with CF-U. At this time, the air interface protocol stack performs function fallback, from the task fallback to the connection protocol stack, as shown in Figure 33:

[0612] Task PDUs: fall back to Data PDUs;

[0613] ●TRD: Fall back to transparent mode;

[0614] ●T-SDAP: fall back to SDAP;

[0615] ●TRS: Fall back to MAC.

[0616] 3.2 Option 2: Integrated control plane + connection user plane + mission data plane

[0617] In option 2, the user plane protocol stack of the connection remains unchanged.

[0618] In addition, a new independent task data page has been added.

[0619] In addition, the connection control plane and the mission control plane are merged, such as the fused control plane protocol stack in Option 1.

[0620] 3.3 Option 3: Connection Control / User Plane + Mission Control / Data Plane

[0621] In option 3, the control plane protocol stack and user plane protocol stack of the connection remain unchanged.

[0622] Added task control plane protocol stack and task data plane protocol stack.

[0623] 3.4. Option 4: Connected control plane / user plane + independent function plane

[0624] 3.4.1 Independent Calculation Surface

[0625] Computing connection control provides real-time awareness of the status of computing connections, providing support for connection resource control, quality control, terminal status, and mobility. It also controls the computing connections required for transmitting computing data, including support for establishing, modifying, migrating, reestablishing, and deleting computing connections, and supports the allocation of connection resources. The transmission of computing connections between computing execution functions becomes a computing wireless session.

[0626] Computational execution control allocates computing resources used by node computational execution functions, controls the amount of computational operations executed, controls computational quality, and supports terminal mobility. Computational resource control perceives the status of computing resources in real time and controls their allocation, such as adding, modifying, deleting, and releasing them. Computational quality control orchestrates computational operations and configures computational process parameters (such as computational accuracy, quantization accuracy, and sparsification) based on resource quantity, accuracy, and latency requirements. Computational resource control (CRC) can implement computational execution control functions at the TRC layer, T-NAS layer, Tx-AP (e.g., T2 application protocol (T2AP) to T9 application protocol (T2AP)), and Yx-AP (e.g., Y1 application protocol (Y1AP) to Y3 application protocol (Y3AP)) layers, enabling computational execution control of UE and base station computational functions.

[0627] Computing and communication services will belong to different service types. The transport bearer for computing data and the transport bearer for communication data (PDU sessions connecting terminals and data networks (DNs) include the data radio bearer between terminals and base stations, and the GPRS tunneling protocol for the user plane (GTP-U) tunnel between base stations and CF-U (i.e., 6G UPF)) need to be distinguished. GPRS stands for General Packet Radio Service (GPRS). Furthermore, due to differences in service models, computing data may have unique interaction patterns between participating network nodes (such as model segmentation, inference, or training, where terminals collaborate with the network), as well as specific requirements for connection quality, it is possible to design new bearer protocols for computing data transmission. Computing plane transport involves the introduction of new bearer methods at the bearer level, such as the Computing Radio Bearer (CRB) at the air interface and the Computing Bearer (CB) at the 6G inter-station interface. Furthermore, a new Radio Computing Session Protocol (RCSP) is introduced at the session level, referred to as an RCSP session. RCSP enables end-to-end computing data exchange between computing execution functions and completes computing collaboration among multiple nodes. RCSP uses computing session identifiers to identify different computing tasks and perform corresponding QoS control.

[0628] Figure 34 illustrates the protocol stack for an independent computing plane using RAN connection architecture 1 as an example. The signaling portion reuses the task control plane protocol stack, while the data portion uses a new computing plane protocol stack (e.g., a new RSCP protocol layer is added for computing data transmission).

[0629] 3.4.2 Independent Data Plane

[0630] For each data service task, DC orchestrates and selects the DA to execute the task, and sends the functions it needs to perform (such as data collection, data preprocessing or data analysis, etc.) to each DA involved.

[0631] Data plane control signaling messages do not require routing; all DAs that receive data plane signaling messages are considered endpoints. Initial data plane control messages, such as UE-DC registration requests and data bearer establishment, are transmitted via RRC signaling. Subsequent control signaling is transmitted via DFCP-C.

[0632] Data plane service data messages support any topology and one or more of the following three routing methods:

[0633] 1) The DC sends routing information to each DA. The data packet carries the data service identifier (DSID). The DC searches the routing table based on the DSID and forwards the data to the next-hop DA.

[0634] 2) The DC sends the routing information to the entry DA, and then carries the routing information in the header of each data packet. After receiving the data packet, the DA decodes the packet header and obtains the next-hop DA based on the routing information;

[0635] 3) Using an encoding method, assign a DA ID (DAID) to each DA according to the rules, calculate the data pipe identity (DPID), and obtain the next-hop DA based on DPID% DAID. The rules are implementation-dependent and are not limited.

[0636] After receiving the data plane service data reported by the UE, the base station decides whether to process the data packet based on the DC's functional indication. After completion, it re-encapsulates the DFCP-U data packet and sends it to the next-hop DA, or terminates the data packet.

[0637] The control message protocol stack of the independent data plane is shown in Figure 35 (taking protocol stack design method 2 as an example), and the business message protocol stack of the independent data plane is shown in Figure 36.

[0638] 3.4.3 Independent Intelligent Surface

[0639] The intelligent plane supports HiC intelligent collaboration services. Network elements at all levels must possess HiC-related logical functions and protocol interfaces to enable collaboration between intelligent network elements within the network. The intelligence on network elements primarily serves the various functional features of the network itself, and secondly, supports AI tasks and models deployed within the network by third parties.

[0640] The control layer of intelligent collaboration must ensure efficient organization of collaboration patterns. This requires querying and reporting the collaboration capabilities of each network element, determining the collaboration set, issuing collaboration requests, creating collaboration instances, and configuring parameters within the collaboration pattern. Furthermore, real-time configuration updates and optimizations are required to adapt to network changes and collaboration status changes during the collaboration process.

[0641] Intelligent representations of interactions between intelligent network elements, including gradients, models, and knowledge. Unlike traditional mobile service data, these interactions are generated, transmitted, and terminated within the network. Over the air interface, this primarily involves collaborative interactions between cNodes, sNodes, and the core network's Transmission Power Supply (TPF) and the UE.

[0642] 3.4.4 Independent Trust Surface

[0643] The trusted plane executes the function calls of TWE and TWG, providing trusted support for other planes, such as the connection plane, task plane, computing plane, data plane, and intelligence plane, to meet their security requirements. Taking encryption and integrity protection as an example, after completing measurement and authentication, the trusted control plane generates NAS-like encryption keys, NAS-like integrity keys, T-PDCP encryption keys, and T-PDCP integrity keys, and distributes them to other planes, which then perform encryption and integrity protection.

[0644] The trusted control plane performs trust establishment and configuration, including the management of trusted functions, control of internal enablers, and trusted negotiation. Control of internal enablers includes blockchain creation and updates, blockchain / chain node management, blockchain capability deployment, capability discovery, capability activation, operational parameters, chain node identity management, dynamic node joining and leaving; identity authentication for secure access, such as obtaining authentication vectors and authentication parameters; device trustworthiness measurement, such as obtaining trusted proof vectors and trusted proof parameters; and key negotiation for homomorphic processing.

[0645] Figure 37 is a schematic diagram of an independent trusted control plane protocol stack. The trustworthiness UE-Core network protocol, TUCP, is primarily responsible for trusted signaling transmission between the UE and the core network, the trustworthiness UE-RAN protocol, TURP, is primarily responsible for trusted signaling transmission between the UE and the access network, and the encryption and integrity protection protocol, EIP, is primarily responsible for encryption and decryption and integrity protection of trusted data. The functions of TUCP and TURP are performed by TWE and TWG. The non-security-related functions of EIP are performed by other modules in the UE / sNode / cNode except TWE and TWG. There are two options for security-related functions:

[0646] Option 1: TWG provides TruA ​​functionality (i.e., parameters and configurations required for security negotiation and security functions, such as encryption, decryption, and integrity protection keys, and privacy protection identifiers), as well as Enabler functionality (e.g., encryption, decryption, and integrity protection functions of the Crypto Enabler).

[0647] Option 2: TWG provides the TruA ​​function, and other modules in the UE / sNode / cNode except TWE and TWG perform the function.

[0648] The independent trusted business plane processes and transmits trusted data, including the specific business processes of the TWE and TWG after trust is established and configured. Trusted data can include synchronized data such as blockchain transactions / blocks, situational awareness data, homomorphically encrypted ciphertext and computational results, Trusted Root management data, and keys. The trusted business plane protocol stack is shown in Figure 38. The EIP layer is primarily responsible for encryption, decryption, and integrity protection of trusted data, while the Trustworthiness Bearer Protocol (TBP) is primarily responsible for packet processing of trusted data. The TBP protocol layer determines endpoints based on packet headers. All TBP functions are performed by the TWE and TWG, while the EIP functions are the same as described above.

[0649] The following describes the network element interfaces under the RAN architecture provided by this application.

[0650] 4. Network element interface.

[0651] The network element interface, also known as the ground interface, is also divided into the control plane protocol stack and the user plane protocol stack based on its purpose.

[0652] For the control plane protocol stack, if a non-SBA interface is used, the 5G "xx-AP / SCTP / IP"-based solution can be considered for reuse; if an SBA interface is used, the 5G CN "restful / SCTP / IP"-based solution can be considered for reuse.

[0653] For the user plane protocol stack, if a non-SBA interface is used, several enhancement solutions are considered, as shown in Figure 39:

[0654] Solution 1: Reuse 5G solutions, such as the protocol stack based on "GTP-U / UDP / IP";

[0655] Solution 2: GTP-U / QUIC / IP-based protocol stack;

[0656] Solution 3: Protocol stack based on RDMA / IB transmission / IB network;

[0657] Solution 4: GTP-U / SRv6-based protocol stack;

[0658] Solution 5: Protocol stack based on "GTP-U / Model or Data Identification".

[0659] The following describes the interfaces of the control plane and user plane in detail, taking Solution 1 as an example.

[0660] 4.1 Non-SBA Interface

[0661] i.Y1 Interface

[0662] The Y1 user plane interface (Y1-U) is defined between the cNode and the sNode. The user plane protocol stack of the Y1 interface is shown in Figure 42. The transport network layer is built on top of IP transport and uses GTP-U over UDP / IP to carry user plane PDUs between the cNode and the sNode.

[0663] The Y1 control plane interface (Y1-C) is defined between the cNode and the sNode. The control plane protocol stack for the Y1 interface is shown in Figure 40. The transport network layer is built on top of IP transport. To reliably transmit signaling messages, the Stream Control Transmission Protocol (SCTP) is added on top of IP. The application layer signaling protocol is called Y1AP (Y1application protocol). The SCTP layer provides guaranteed delivery of application layer messages. During transmission, IP layer point-to-point transport is used to deliver signaling PDUs.

[0664] ii.Y2 Interface

[0665] See Figure 41 for the user plane interface and control plane interface of the Y2 interface.

[0666] The Y2-user plane interface (Y2-U) is defined between cNodes and is used to transmit task data or UE communication data (for example, data forwarding when a UE is switched between two cNodes).

[0667] The Y2 control plane interface (Y2-C) is defined between cNodes and is used to transmit not only connection-only signaling but also task signaling.

[0668] iii.Y3 Interface

[0669] For the user plane interface and user plane interface of the Y3 interface, please refer to Figure 42.

[0670] The Y3-User Plane interface (Y3-U) is defined between sNodes and is used to transmit connection data (UE communication data) or task data (for example, transferring the context of a task in which an sNode participates to another sNode).

[0671] The Y3 control plane interface (Y3-C) is defined between sNodes and is used only for signaling of tasks or connections.

[0672] iv.T2 Interface

[0673] For the user plane interface and user plane interface of the T2 interface, please refer to Figure 43.

[0674] The T2 user plane interface (T2-U) is defined between the cNode and the TPF and is used to transmit task data.

[0675] The T2 control plane interface (T2-C) is defined between the cNode and the TCF and is used to transmit task signaling.

[0676] v.T3 Interface

[0677] The T3 control plane interface (T3-C) is defined between the cNode and the NAF, as shown in Figure 44. T3-C is used to transmit connection signaling.

[0678] vi.T4 Interface

[0679] The T4 control plane interface (T4-C) is defined between the cNode and the CF-C, as shown in Figure 45. T4-C is used to transmit connection signaling or transparent task signaling (T-NAS).

[0680] vii.T5 Interface

[0681] The T5 control plane interface (T5-C) is defined between the sNode and the NAF, as shown in Figure 46, and is used to transmit connection signaling or transparent task signaling (T-NAS).

[0682] viii.T6 Interface

[0683] The T6 control plane interface (T6-C) is defined between the sNode and the CF-C (connection architecture 2: if the cNode is unaware of the connection, the sNode assumes all connection-related functions), as shown in Figure 47. It is used to transmit connection signaling or transparent task signaling (T-NAS).

[0684] ix.T7 Interface

[0685] The T7 control plane interface (T7-U) is defined between the sNode node and the CF-U, as shown in Figure 48, and is used to transmit connection data or transparently transmit task data.

[0686] xi.T8 Interface

[0687] See Figure 49 for the control plane interface and user plane interface of the T8 interface.

[0688] The T8 control plane interface (T8-C) is defined between the cNode and the TEF and is used to transmit trusted signaling.

[0689] The T8 data plane interface (T8-U) is defined between the sNode and TEF and is used to transmit trusted data.

[0690] xii.T9 Interface

[0691] See Figure 50 for the control plane interface and user plane interface of the T9 interface.

[0692] The T9 control plane interface (T9-C) is defined between the sNode and the TEF and is used to transmit trusted signaling.

[0693] The T9 data plane interface (T9-U) is defined between the sNode and the TEF and is used to transmit trusted data.

[0694] 4.2 SBA interface

[0695] iS-c Interface

[0696] The Sc interface provides different functions depending on the RAN connection architecture. For example, for RAN connection architecture 1 (CP / UP separation), the cNode provides connection-related signaling functions; for RAN connection architecture 2 (CP / UP non-separation), the cNode does not provide connection functions.

[0697] For the task architecture, cNode provides the functions of task signaling and task data transmission through SC-C and SC-U, as shown in Figure 51.

[0698] ii.Ss Interface

[0699] The Ss interface provides different functions depending on the RAN connection architecture. For example, for RAN connection architecture 1 (CP / UP separation), the sNode provides connection-related data forwarding functions; while for RAN connection architecture 2 (CP / UP integration), the sNode provides connection signaling control and data forwarding functions.

[0700] For the task architecture, sNode provides the functions of task signaling and task data transmission through SS-C and SS-U, as shown in 52.

[0701] iii.Se Interface

[0702] The Se (service-engine) interface is the external interface of the TWE in the SBA and provides one or more of the following functions:

[0703] -Trusted service calls (including network global trusted policy services, blockchain services, remote attestation services, etc.);

[0704] - Trusted information subscription (including capability information, network global trust strategy, blockchain capability information, etc.);

[0705] -Trusted function management (engine hierarchical management).

[0706] The Se interface supports the Se-AP protocol, as shown in Figure 55. Figure 53 is the Se protocol stack.

[0707] iiii.Sg Interface

[0708] The Sg (service-gear) interface is the external interface of the TWG in the SBA and provides one or more of the following functions:

[0709] -Trusted service invocation (security capability information, authentication, authorization, blockchain, situational awareness, remote attestation, etc.);

[0710] - Trusted information subscription (subscription status, capability information);

[0711] -Trusted Function Management (TEF Management TGF).

[0712] The Sg interface supports the Sg-AP protocol, as shown in Figure 54, which is the Sg protocol stack.

[0713] The following describes the end-to-end protocol stack under the RAN architecture provided by this application.

[0714] 5. End-to-end protocol stack.

[0715] 5.1. Option 1: Shared Functional Surface

[0716] Specifically, the shared functional plane means that various functions (including the first function proposed in this application, such as trust, computing, intelligence, etc.) share a protocol stack.

[0717] 5.1.1 Tasks

[0718] The task interface involves four types of interfaces: the task interface between UE and RAN, the task interface between UE and TCF, the task interface between RAN and CN, and the task interface between RAN and RAN, which are described below respectively.

[0719] 1) Type 1: Task interface between UE and RAN

[0720] There can be different task architectures for different connection architectures.

[0721] RAN connection architecture 1 - (air interface) CP / UP separation

[0722] For RAN connection architecture 1-CP / UP separation, task signaling and data between UE and cNode (RAN acts as a TA to control UE to perform tasks), there are two end-to-end control plane protocol stack and user plane protocol stack: non-SBA and SBA solutions.

[0723] If a non-SBA interface is used, the end-to-end control plane protocol and user plane protocol stack for UE / RAN tasks are shown in Figures 55 and 56 respectively:

[0724] ■Signaling: UE<->cNode, signaling communication between UE and cNode does not require transit;

[0725] ■Data: UE<->sNode<->cNode. Data communication between UE and cNode must be transferred through sNode.

[0726] If using SBA interface:

[0727] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0728] RAN connection architecture 2 - (air interface) CP / UP not separated

[0729] For the RAN connection architecture 2-CP / UP not separated, the task signaling and data between UE and cNode (RAN acts as the TA to control UE to perform tasks), the end-to-end control plane protocol stack and user plane protocol stack have two solutions: non-SBA and SBA.

[0730] If a non-SBA interface is used, the end-to-end control plane protocol stack and user plane protocol stack for UE / RAN tasks are shown in Figures 57 and 58 respectively:

[0731] ■Signaling: UE<->sNode<->cNode, the signaling communication between UE and cNode needs to be transferred through sNode;

[0732] ■Data: UE<->sNode<->cNode. Data communication between UE and cNode must be transferred through sNode.

[0733] If using SBA interface:

[0734] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0735] 2) Type 2: Task interface between UE and TCF

[0736] Different interface designs are used for different task architectures.

[0737] ●Task Architecture 1a / 1b (Distributed T-NAS)

[0738] For task signaling and data between UE and TCF (CN acts as TA to control UE to perform tasks), for task architecture 1a / 1b (distributed T-NAS), there are two end-to-end control plane protocol stack and user plane protocol stack solutions: non-SBA and SBA.

[0739] If a non-SBA interface is used, refer to Figures 59 to 61: Figures 59 to 61 are respectively the end-to-end control plane protocol stack for tasks between UE / CN (for task architecture 1a), the end-to-end control plane protocol stack for tasks between UE / CN (for task architecture 1b), and the end-to-end user plane protocol stack for tasks between UE / CN (for task architecture 1a / 1b).

[0740] ■Signaling: UE<->cNode / (cNode+sNode)<->TCF. The signaling communication between UE and TCF needs to be transferred through cNode / (cNode+sNode);

[0741] ■Data: UE<->sNode<->cNode<->TCF. The communication between UE and TCF needs to be transferred through multiple nodes of sNode and cNode.

[0742] If using SBA interface:

[0743] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0744] ● Mission Architecture 2a / 2b (Centralized T-NAS)

[0745] For task signaling and data between UE and TCF (CN acts as TA to control UE to perform tasks), for task architecture 2a / 2b (centralized T-NAS), there are two end-to-end control plane protocol stack and user plane protocol stack solutions: non-SBA and SBA.

[0746] If the SBA interface is adopted, as shown in Figures 62 to 63: Figures 62 to 63 are respectively the end-to-end control plane protocol stack for tasks between UE / CN (for task architecture 2a / 2b) and the end-to-end user plane protocol stack for tasks between UE / CN (for task architecture 2a / 2b).

[0747] ■Signaling: UE <-> cNode / (sNode+cNode) <-> NAF / CF-C <-> TCF. The signaling communication between UE and TCF needs to be transferred through multiple nodes such as cNode / (sNode+cNode) and NAF / CF-C.

[0748] ■Data: UE<->sNode<->cNode<->TPF. Data communication between UE and TPF needs to be transferred through multiple nodes of sNode and cNode.

[0749] If using SBA interface:

[0750] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0751] 3) Type 3: Task interface between RAN and TCF

[0752] For task signaling and data between RAN nodes and CN nodes (CN and RAN negotiate to perform tasks), there are two end-to-end control plane protocol stack and user plane protocol stack: non-SBA and SBA solutions.

[0753] If a non-SBA interface is used, as shown in Figures 64 and 65, they respectively show the end-to-end control plane protocol stack for tasks between CN / RAN and the end-to-end user plane protocol stack for tasks between CN / RAN:

[0754] ■Signaling: sNode<->cNode<->TCF. The signaling communication between sNode and TCF must be transferred through the cNode. Task signaling and data exchange between CN and RAN can only be carried out between TCF and cNode (as peer TA / TS).

[0755] ■Data: sNode<->cNode<->TCF. Data communication between sNode and TCF must be transferred through cNode.

[0756] The cNode further decomposes the TCF tasks to the sNode for execution (it can also be decomposed to the UE for execution).

[0757] If using SBA interface:

[0758] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0759] 4) Type 4: RAN-to-RAN task interface

[0760] cNode2, as the TA, requests the neighboring cNode1 (TA) to perform tasks. There are also two solutions: non-SBA and SBA.

[0761] If a non-SBA interface is used, Figures 66 and 67 show the end-to-end control plane protocol stack for inter-RAN tasks and the end-to-end user plane protocol stack for inter-RAN tasks, respectively:

[0762] ■Signaling: sNode / cNode1<->cNode2;

[0763] ■Data: sNode / cNode1<->cNode2.

[0764] If using SBA interface:

[0765] ■cNode provides the Sc interface, and sNode provides the Ss interface.

[0766] 5.1.2 Connection

[0767] For the connection, the end-to-end control plane protocol stack and user plane protocol stack are shown in Figure 68 and Figure 69 respectively:

[0768] If using a non-SBA interface:

[0769] ■Signaling: UE<->cNode<->NAF / CF-C. Signaling communication between UE and NAF / CF-C must be transferred through the cNode;

[0770] ■Data: UE<->sNode<->CF-U. Data communication between UE and CF-U must be transferred through sNode;

[0771] If using SBA interface:

[0772] ■ Ground interface: cNode provides Sc interface, sNode provides Ss interface;

[0773] ■Air interface: cNode provides Sc-Uu interface, sNode provides Ss-Uu interface;

[0774] ■Air interface: The UE provides the S-UE-Uu interface (including T-NAS layer services, TRC layer services, T-PDCP layer services, RLC layer services, TRS layer services, and PHY layer services, etc.).

[0775] 5.2 Option 2: Fusion Control Surface

[0776] In option 2, the user plane protocol stack of the connection remains unchanged.

[0777] In addition, a new independent task data page has been added.

[0778] Optionally, the connection control plane and the mission control plane are merged, such as the fused control plane protocol stack in Option 1.

[0779] 5.3. Option 3: Mission Control / Data Plane

[0780] In this option, the control plane protocol stack and data plane protocol stack of the connection remain unchanged.

[0781] Added task control plane protocol stack and task data plane protocol stack.

[0782] 5.4. Option 4: Independent Functional Surface

[0783] Specifically, the independent function plane refers to adding one or more of an independent computing plane, a data plane, and an intelligent plane for the first function, while keeping the connected control plane and user plane unchanged.

[0784] 5.4.1 Independent Calculation Surface

[0785] The control signaling protocol stack for the computing plane is as follows:

[0786] Air interface computing connection control can be implemented based on the existing RRC protocol mechanism, that is, by modifying the RRC protocol or invoking basic RRC protocol functions to support computing connection control. Computation execution control is implemented by CRC, which can be independent of RRC or integrated with RRC to form xRC, which can serve as a sub-function of TRC. CRC is used to control the computing resources occupied by the computing execution function, the amount of computing operations, and the computing quality.

[0787] The computing connection control between UE and core network can support the control of computing connection by modifying or enhancing the basic functions of NAS; computing execution control can realize the maintenance of computing execution function address, computing tasks, computing power map information, etc. through TCF (task control function).

[0788] The following describes the calculation connection control function and the calculation execution control function respectively.

[0789] ●Calculation connection control function can be realized in TCF or through CF-C enhancement

[0790] Computing connection control perceives the status of computing connections in real time, controls connection resources and quality of computing connections, and supports terminal status perception and business continuity assurance under mobility; controls the computing connections required for transmitting computing data, such as supporting the establishment, modification, migration, reconstruction, and deletion of computing connections, and supports the allocation of connection resources.

[0791] ●Computational execution control functions can be implemented in TCF or through independent CMF functions

[0792] Computational execution control allocates computing resources used by node computational execution functions, controls the amount of computational operations executed, controls computational quality, and supports terminal mobility. Computational resource control perceives the status of computing resources in real time and controls their deployment.

[0793] The computing connection control and computing execution control between the base station and the core network can be achieved through TCF to maintain the computing execution function address, computing tasks, computing power map information, etc. The computing execution control function interaction between TCF and the base station can be achieved based on the T2-AP mechanism.

[0794] The service protocol stack for the computing plane is as follows:

[0795] The transmission part of the computing plane is used to transmit computing data between computing execution functions of different nodes, which means that the data of the computing plane does not need to be transmitted to the DN. Therefore, the design of the computing plane transmission mechanism needs to be different from the traditional communication user plane.

[0796] Figure 70 shows the service plane protocol stack for the end-to-end computing plane. The computing plane transmission method introduces new bearer methods at the bearer layer, such as the computing radio bearer (CRB) in the air interface and the computing bearer (CB) in the ground interface. It also introduces a new radio computing session protocol (RCSP) at the session layer. The computing session can also be called an RCSP session. An RCSP session can include only the CRB in the air interface (computing collaboration between the terminal and the base station), only the CB in the ground interface (computing collaboration between the base station and the core network), or both the CRB in the air interface and the CB in the ground interface (computing collaboration between the terminal and the core network).

[0797] 5.4.2 Independent Data Plane

[0798] Figures 71 and 72 show the control signaling protocol stack for the data plane and the service protocol stack for the data plane, respectively. The cNode and TCF are connected via the T2-C interface for transmitting data plane signaling, while the cNode and TPF are connected via the T2-U interface for transmitting data plane data.

[0799] 5.4.3 Independent Intelligent Surface

[0800] Figure 73 illustrates multi-level collaboration within an independent intelligent plane. As shown in Figure 73, HiC supports intelligent collaboration between network elements and terminals at all levels within the network, including scenarios such as terminal-to-base station, terminal-to-core network, base station-to-base station, and base station-to-core network. At the control layer, HiC can be deployed in layers. Local collaboration control functions are deployed on cNodes to facilitate collaboration within the cNode range. Global collaboration control functions are deployed on the core network's TCF to coordinate collaboration between cNode regions and between the RAN and core network domains.

[0801] 5.4.4 Independent Trust Surface

[0802] Figure 74 shows the end-to-end trusted control plane protocol stack. Trusted signaling is transmitted between the UE and the CN using the TUCP protocol, transparently transmitted through the access network. Trusted signaling is transmitted between the UE and the access network using the TURP protocol. Trusted signaling is transmitted between access network nodes using the Y1-AP, Y2-AP, and Y3-AP. Trusted signaling is transmitted between the access network and the core network CF using the T8-AP and T9-AP. The EIP provides encryption, decryption, and integrity protection for trusted signaling. The functions of TUCP and TURP are all performed by the TWE and TWG. The functions of the EIP are the same as those described above. The trusted functions of the T8-AP and T9-AP are also performed by the TWE and TWG.

[0803] Figure 75 shows the end-to-end trusted service plane protocol stack. Trustworthy data is transmitted between the UE, access network, and core network via the Trustworthiness Bearer Protocol (TBP). The EIP provides encryption, decryption, and integrity protection for trusted data. TBP functions are entirely performed by the TWE and TWG, while the EIP functions are the same as described above.

[0804] 6. Air interface-protocol layer.

[0805] 6.1. Layer 1 (physical layer), please refer to the relevant description of protocol 38.300.

[0806] 6.2, Layer 2.

[0807] 6.2.1. Overview.

[0808] For connections, 6G Layer 2 is divided into the following sublayers: Task Resource Scheduling (TRS), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Task Service Data Adaptation Protocol (T-SDAP). Among them, the layer 2 provided in this application includes a sublayer that supports the first function, and the sublayer that supports the first function includes at least one of the following:

[0809] -The physical layer provides the TRS Sublayer transmission channel;

[0810] -TRS Sublayer provides RLC Sublayer logical channels;

[0811] -RLC Sublayer provides RLC channels to T-PDCP Sublayer;

[0812] -T-PDCP Sublayer to T-SDAP Sublayer radio bearer;

[0813] -T-SDAP Sublayer provides QoS flows for 6GC tasks and connections;

[0814] -TRD Sublayer provides task data encapsulation (only task data and HiC data);

[0815] -RSCP Sublayer provides calculation data encapsulation (only for independent calculation surfaces);

[0816] -DFCP Sublayer provides data encapsulation (only independent data plane);

[0817] -comp. Packet header compression or uplink data compression;

[0818] -Segm.Packet segmentation;

[0819] - Control channel (BCCH, PCCH are not depicted for clarity).

[0820] Radio bearers are divided into two groups: Data Radio Bearers (DRBs) for user plane data and Signalling Radio Bearers (SRBs) for control plane data.

[0821] 6.2.2 TRS Sublayer

[0822] Based on the connection characteristics, TRS reuses the existing MAC functions of the connection:

[0823] ●Services and functions provided:

[0824] - Mapping between logical channels and transport channels;

[0825] - Multiplexing / demultiplexing TRS SDUs belonging to one or different logical channels into transport blocks (TBs), which are transmitted to / from the physical layer on the transport channel;

[0826] -Dispatch information report;

[0827] - Error correction via HARQ (one HARQ entity per cell in case of CA);

[0828] - Prioritization between UEs through dynamic scheduling;

[0829] - Priority handling between logical channels of a UE through logical channel priority handling;

[0830] - Priority handling between overlapping resources of a UE;

[0831] -filling.

[0832] Logical channel

[0833] The control channel is only used to transmit control signaling information:

[0834] - Broadcast Control Channel (BCCH): A downlink channel used to broadcast system control information.

[0835] - Paging Control Channel (PCCH): a downlink channel that carries paging messages.

[0836] - Common Control Channel (CCCH): A channel used to transmit control information between the UE and the network. This channel is used for UEs that do not have an RRC connection with the network.

[0837] Dedicated Control Channel (DCCH): A point-to-point bidirectional channel that carries dedicated control information between the UE and the network. Used by UEs with an RRC connection.

[0838] Traffic channels are only used to transmit user plane information:

[0839] - Dedicated Traffic Channel (DTCH): A point-to-point channel dedicated to one UE for transmitting user information. DTCH can exist in both uplink and downlink.

[0840] ●Mapping to transmission channels

[0841] In the downlink, the following connections exist between logical channels and transport channels:

[0842] -BCCH can be mapped to BCH;

[0843] -BCCH can be mapped to DL-SCH;

[0844] -PCCH can be mapped to PCH;

[0845] -CCCH can be mapped to DL-SCH;

[0846] -DCCH can be mapped to DL-SCH;

[0847] -DTCH can be mapped to DL-SCH.

[0848] In the uplink, the following connections exist between the logical channel and the transport channel:

[0849] -CCCH can be mapped to UL-SCH;

[0850] -DCCH can be mapped to UL-SCH;

[0851] -DTCH can be mapped to UL-SCH.

[0852] HARQ

[0853] -HARQ functionality ensures transmission between peer entities at Layer 1. When downlink / uplink spatial multiplexing is not configured at the physical layer, a single HARQ process supports the transmission of one TB. When downlink / uplink spatial multiplexing is configured at the physical layer, a single HARQ process supports one or more TBs.

[0854] In response to new features such as tasks and calculations, TRS adds one or more of the following functions:

[0855] ●Services and functions provided:

[0856] - Mapping between logical channels and transport channels of tasks;

[0857] - Multiplexing / demultiplexing of TRS SDUs belonging to one or different logical channels of tasks and connections into transport blocks (TBs), which are transmitted to / from the physical layer on the transport channel;

[0858] -Computing resource scheduling information report;

[0859] -Computing resource status information report;

[0860] - Dynamic or semi-static scheduling of computing resources for UEs on the network side;

[0861] - Prioritization of computing resources for different tasks of a UE;

[0862] If an independent data plane is used, TRS adds the following features to address new data characteristics:

[0863] ●Services and functions provided:

[0864] - Mapping between logical channels and transport channels for data;

[0865] - Multiplexing / demultiplexing of data and connected TRS SDUs belonging to one or different logical channels into transport blocks (TBs), which are transmitted to / from the physical layer on the transport channel;

[0866] - Scheduling priority processing of data plane bearers and SRBs and DRBs;

[0867] 6.2.3 RLC Sublayer

[0868] For connection characteristics, all functions of the connection RLC layer are reused:

[0869] ●Transmission mode: Acknowledged Mode (AM), Unacknowledged Mode (UM), Transparent Mode (TM)

[0870] ●Business and functions

[0871] -Transmission of upper layer PDUs;

[0872] - Independent of sequence numbering (UM and AM) in PDCP;

[0873] - Error correction via ARQ (AM only);

[0874] - Segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;

[0875] - Reassemble the SDU (AM and UM);

[0876] -Duplicate detection (AM only);

[0877] - RLC SDU discard (AM and UM);

[0878] -RLC reconstruction;

[0879] - Protocol error detection (AM only).

[0880] ARQ function

[0881] -ARQ retransmits RLC SDU or RLC SDU segment based on RLC status report;

[0882] -RLC uses polling RLC status reporting when needed;

[0883] - The RLC receiver may also trigger an RLC status report upon detecting a lost RLC SDU or RLC SDU segment.

[0884] 6.2.4 T-PDCP Sublayer

[0885] For connection characteristics, all functions of the connection PDCP layer are reused:

[0886] - Data transmission (user plane or control plane);

[0887] - Maintain PDCP SN;

[0888] -Header compression and decompression using ROHC protocol;

[0889] -Header compression and decompression using the EHC protocol;

[0890] - Compression and decompression of uplink PDCP SDU: only based on DEFLATE UDC;

[0891] - encryption and decryption;

[0892] -Integrity protection and integrity verification;

[0893] -Timer-based SDU discard;

[0894] - For split bearer, routing;

[0895] -repeat;

[0896] - Reorder and deliver in sequence;

[0897] - Out of order submission;

[0898] -Duplicate discard.

[0899] 6.2.5 T-SDAP Sublayer

[0900] For connection features, reuse all the functions of the connection SDAP layer as follows:

[0901] -Mapping between QoS flows and data radio bearers;

[0902] - Marking of QoS Flow ID (QFI) in DL and UL packets.

[0903] In response to new features such as tasks, computing, data, and AI, T-SDAP adds the following functions:

[0904] -Task id to task QFI mapping;

[0905] - Mapping between task QoS flows and data radio bearers;

[0906] -Mark the Task QoS Flow ID (Task QFI) and its corresponding Task id in DL and UL data packets.

[0907] 6.2.6 TRD Sublayer

[0908] In response to new task features, a new TRD layer is added with the following functions:

[0909] - New AI training / inference / model processing functions (compression / pruning / quantization / security, etc.)

[0910] 6.2.7 Task PDUs Sublayer

[0911] If the non-independent functional plane is used, a new Task PDUs layer is added to target the characteristics of the task data plane. This layer is responsible for the transmission of trusted service data between the UE and the base station / CN and has the following functions:

[0912] -Task data format (such as the format design of computing data, definition of AI training or inference data format, etc.).

[0913] 6.2.8 RCSP Sublayer

[0914] If an independent computing surface is used, a new RCSP layer is added to address the new features of the computing surface. It has the following functions:

[0915] - Endogenous computing power resource addressing, computing data routing and forwarding, computing session identification, computing session priority, etc.

[0916] 6.2.9 DFCP Sublayer

[0917] If an independent data plane is used, a new DFCP layer is added to address the new features of the data plane. It is divided into DFCP-C and DFCP-U, which are used for data plane control signaling and service data processing respectively.

[0918] DFCP-C performs the following functions:

[0919] -Start and stop data service tasks;

[0920] -Configuration of data service task routing information;

[0921] - Push and update of data protection technology;

[0922] - Reporting of statistical information.

[0923] DFCP-U performs the following functions:

[0924] - Mapping of data service task ID to data plane radio bearer;

[0925] -Data privacy protection (implemented by calling the trusted surface interface);

[0926] - Compression of data packets;

[0927] -Data routing and forwarding;

[0928] -Data collection, data preprocessing, data analysis, data openness, etc.

[0929] 6.2.10 EIP Sublayer

[0930] If an independent trusted plane is used, a new EIP layer is added to handle trusted packets based on the new features of the trusted plane. The EIP reuses the functions of the PDCP layer and adds the following features:

[0931] - Encryption and decryption (quantum-resistant key length);

[0932] -Integrity protection and integrity verification (quantum-resistant key length).

[0933] 6.2.11 EIP Sublayer

[0934] TBP Sublayer

[0935] If an independent trusted plane is used, a new TBP layer is added to address the characteristics of the trusted data plane. This layer is responsible for transmitting trusted service data between the UE and the base station / CN, and between the base station and the CN. It has the following functions:

[0936] - Blockchain transaction / block synchronization data;

[0937] - Situational awareness data;

[0938] -Homomorphically encrypted ciphertext, calculation results and other data;

[0939] -Trusted Root management data;

[0940] -Key.

[0941] 6.2.12 Layer 2 data flow

[0942] For connected data transmission, no changes are required. An example of a Layer 2 data flow is shown in Figure 76. The TRS generates a transport block by concatenating two RLC PDUs from RBx and one RLC PDU from RBy. The two RLC PDUs from RBx correspond to one IP packet (n and n+1), respectively, while the RLC PDU from RBy is a fragment of one IP packet (m).

[0943] For task data transmission, the protocol stack needs to be modified: compared to the connection, a new TRD layer is added for task data generation, such as AI data generation (such as gradient information in federated learning) or AI model encoding and decoding. An example of a layer 2 data flow is shown in Figure 77, where the TRS generates a transport block by concatenating two RLC PDUs from RBx corresponding to different task IDs and one RLC PDU from RBy corresponding to another task ID. The two RLC PDUs from RBx correspond to a TRD packet (n and n+1), respectively, while the RLC PDU from RBy is a fragment of a TRD packet (m).

[0944] In addition, since they share the same transmission channel (air interface), the task data bearer and the connection data bearer can also be multiplexed and packaged into one TRS PDU for transmission.

[0945] If an independent data plane is used, the protocol stack is modified for data plane data transmission. Compared with the connection, the SDAP layer is reduced and the DFCP layer is added to generate data plane data. The data service ID is mapped to the data bearer DDRB. Figure 78 shows the data flow of the independent data plane.

[0946] If an independent trusted plane is used, the protocol stack is modified for trusted plane data transmission. By comparing connections, the SDAP layer is reduced and the TBP layer is added. Input data is formed into homomorphic computation inputs. After homomorphic computation is performed, the homomorphic output data is unpacked and forwarded as data plane messages. See Figure 79.

[0947] 6.3 Layer 3

[0948] In this application, Layer 3 of the air interface may include a sublayer that supports the first function. For example, in one implementation, Layer 3 includes a TRC layer, which includes existing functions of the RRC layer and functions related to the aforementioned new features (or the first function). For a detailed description of the TRC layer, see 6.3.1.

[0949] 6.3.1 TRC

[0950] Exemplarily, TRC inherits the existing functions of the original RRC (for example, RRC state maintenance (idle / inactive / connected), generation, scheduling and transmission of system broadcast messages (MIB, SIB1~SIBx), admission control, UE capability acquisition, NAS signaling transmission, etc.), and also adds new features related to tasks, calculations, data, AI, etc., such as one or more of the configuration, modification, deletion, mobility and other functions of tasks. Among them, the system information broadcast is shown in Figure 80. As shown in the figure, the MIB message is sent by the cNode through the BCH period, and the SIB1 message is sent through the DL-SCH period. Other system information (SI) (including system information that is not broadcast in the minimum system message) can be broadcast and sent in the RRC idle / inactive state, or can be sent through RRC dedicated signaling in the RRC connected state, and can be sent periodically or based on the UE's request (i.e., on-demand sending method).

[0951] In terms of connection characteristics, the main services and functions of the RRC sublayer on the Uu interface are reused, including:

[0952] - Broadcast system information related to AS and NAS;

[0953] -Paging initiated by 6GC or 6G-RAN;

[0954] - Establish, maintain, and release TRC connections between the UE and 6G-RAN, including:

[0955] -Addition, modification and release of carrier aggregation;

[0956] -Add, modify, and release dual connectivity in 6G-RAN or between 5G-RAN and 6G-RAN.

[0957] - Security features including key management;

[0958] - Establishment, configuration, maintenance and release of Signalling Radio Bearers (SRBs) and Data Radio Bearers (DRBs);

[0959] - Mobile features include:

[0960] - Handover and context transfer;

[0961] -UE cell selection and reselection and control of cell selection and reselection;

[0962] - Inter-RAT mobility;

[0963] -QoS management function;

[0964] -UE measurement reporting and reporting control;

[0965] - Detection and recovery of radio link failures;

[0966] -T-NAS message transmission from the core network to the UE or from the UE to the core network.

[0967] For new features such as tasks, calculations, and HiC, TRC adds one or more of the following functions:

[0968] - Establishment, configuration, maintenance and release of Mission Radio Signaling Bearer (T-SRB) and Mission Radio Data Bearer (T-DRB);

[0969] - Configuration, modification, and deletion of computing resources, as well as allocation and scheduling of computing resources (semi-static);

[0970] -Configuration, modification, and deletion of data resources;

[0971] -Configure, modify, and delete model resources;

[0972] -Configure, modify, and delete collaboration patterns;

[0973] -Task-based switching and context transfer;

[0974] -Task-based QoS management function.

[0975] If an independent data plane is used, TRC adds one or more of the following features to address new data characteristics:

[0976] -Establishment, configuration, maintenance and release of data radio data bearer (DDRB);

[0977] -Data-based QoS management function;

[0978] -Handling of wireless data bearers during handover;

[0979] -Handling of radio data bearers during call reestablishment;

[0980] -Registration of DA.

[0981] In response to new trusted features, TRC adds one or more of the following functions:

[0982] - Establishment, configuration, maintenance, and release of Trusted Radio Signaling Bearer (Trust-SRB) and Trusted Radio Data Bearer (Trust-DRB);

[0983] -Perception, registration, and deregistration of UE trusted capabilities;

[0984] -Configuration, modification, activation and deletion of UE trusted capabilities;

[0985] -Handling of wireless trusted bearers during handover;

[0986] -Handling of wireless trusted bearers during call reestablishment;

[0987] - Parsing T-NAS (TUCP) T-NAS message transmission to / from the core network and / or to the UE;

[0988] -QoS management function based on trusted bearer;

[0989] -Security negotiation between UE and base station: such as security policy negotiation and key negotiation;

[0990] - Trusted information subscription for UE and base station: such as requirement tags, capability tags, response tags, and network global trusted policies;

[0991] - UE and base station authentication: identity authentication for secure access, such as authentication vectors and authentication parameters;

[0992] - UE and base station authorization: including static authorization and token-based authorization;

[0993] - Blockchain for UE and base station: Blockchain creation, update, and blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, and dynamic node joining and exit;

[0994] -Trustworthiness metrics for UE and base station: device trustworthiness metrics, such as trustworthiness proof vectors and trustworthiness proof parameters;

[0995] - Situational awareness of UE and base station: configuration information for situational awareness, such as parameter type, parameter type, and parameter information extraction;

[0996] -Homomorphic processing between UE and base station: key negotiation, algorithm configuration.

[0997] 6.3.2 TURP

[0998] If an independent trusted plane is used, a new TURP layer is added to address the new features of the trusted control plane, providing one or more of the following functions:

[0999] - Establishment, configuration, maintenance, and release of Trusted Radio Signaling Bearer (Trust-SRB) and Trusted Radio Data Bearer (Trust-DRB);

[1000] -Perception, registration, and deregistration of UE trusted capabilities;

[1001] -Configuration, modification, activation and deletion of UE trusted capabilities;

[1002] -Handling of wireless trusted bearers during handover;

[1003] -Handling of wireless trusted bearers during call reestablishment;

[1004] - Parsing T-NAS (TUCP) T-NAS message transmission from the core network to the UE or from the UE to the core network;

[1005] -QoS management function based on trusted bearer;

[1006] -Security negotiation between UE and base station: such as security policy negotiation and key negotiation;

[1007] - Trusted information subscription for UE and base station: such as requirement tags, capability tags, response tags, and network global trusted policies;

[1008] - UE and base station authentication: identity authentication for secure access, such as authentication vectors and authentication parameters;

[1009] - UE and base station authorization: including static authorization and token-based authorization;

[1010] - Blockchain for UE and base station: Blockchain creation, update, and blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, and dynamic node joining and exit;

[1011] -Trustworthiness metrics for UE and base station: device trustworthiness metrics, such as trustworthiness proof vectors and trustworthiness proof parameters;

[1012] - Situational awareness of UE and base station: configuration information for situational awareness, such as parameter type, parameter type, and parameter information extraction;

[1013] -Homomorphic processing between UE and base station: key negotiation, algorithm configuration.

[1014] The following introduces the network element interface-protocol layer under the RAN architecture provided by this application.

[1015] 7. Network element interface-protocol layer.

[1016] 7.1. RAN ground interface - signaling.

[1017] 1)Y1-AP

[1018] The main functions of Y1-AP include one or more of the following:

[1019] -Context information that needs to be exchanged between the cNode and sNode (for connection architecture 1, the cNode maintains the control signaling and context information of the connection and needs to inform the sNode; for connection architecture 2, the sNode maintains the control signaling and context information of the connection and needs to inform the cNode);

[1020] -Context information of interactive tasks is required between cNode and sNode.

[1021] -When there is no Y3 interface between sNodes, Y3 interface transparent transmission and forwarding (forwarded via cNode) can be performed through the Y1-AP of the Y1 interface;

[1022] - Trusted context information needs to be exchanged between cNode and sNode.

[1023] 2) Y2-AP

[1024] The main functions of Y2-AP include one or more of the following:

[1025] -CNodes exchange connection information with each other (such as handover signaling, inter-site RRM negotiation, etc.);

[1026] -CNodes exchange task information with each other (such as task request messages, task response messages, task reassignment messages, task deletion messages, task status query messages, task exception reporting messages, etc.).

[1027] -CNodes need to exchange trusted context information with each other.

[1028] 3)Y3-AP

[1029] The main functions of Y3-AP include one or more of the following:

[1030] -SNodes exchange connection information with each other (for connection architecture 2, such as handover signaling, inter-station RRM negotiation, etc.).

[1031] - sNodes exchange task information with each other (such as task data exchange, where task data can be calculation results, data processing results, intelligent representation of multi-agent collaboration, etc.).

[1032] - Trusted context information needs to be exchanged between cNode and sNode.

[1033] 4) T2-AP

[1034] The main functions of T1-AP include:

[1035] -The cNode and TCF exchange task information (such as task request messages, task response messages, task reassignment messages, task deletion messages, task status query messages, task exception reporting messages, etc.).

[1036] 5) T3-AP

[1037] The main functions of T3-AP include:

[1038] - The cNode and NAF exchange connection information (only for connection architecture 1, such as initial access and initial selection signaling messages).

[1039] 6) T4-AP

[1040] The main functions of T4-AP include:

[1041] - The cNode and the CF-C exchange connection information (only for connection architecture 1, such as other signaling messages except the initial access and initial selection signaling messages).

[1042] 7) T5-AP

[1043] The main functions of T5-AP include:

[1044] - The sNode exchanges connection information with the NAF (only for connection architecture 2, such as initial access and initial selection signaling messages).

[1045] 8) T6-AP

[1046] The main functions of T6-AP include:

[1047] - Connection information is exchanged between the sNode and the CF-C (only for connection architecture 2, such as other signaling messages except the initial access and initial selection signaling messages).

[1048] 9) T8-AP

[1049] The main functions of T8-AP include one or more of the following:

[1050] -cNode trust capability perception, registration, and deregistration;

[1051] -Configure, modify, activate and delete cNode trusted capabilities;

[1052] -Security negotiation between cNode and CN: such as security policy negotiation and key negotiation;

[1053] - Trusted information subscription of cNode and CN: such as demand tags, capability tags, response tags, and global trusted network policies;

[1054] -cNode and CN authentication: identity authentication for secure access, such as authentication vectors and authentication parameters;

[1055] -Encryption and integrity of signaling between cNode and BN;

[1056] -cNode and CN authorization: including static authorization and token-based authorization;

[1057] - CN controls the cNode blockchain: blockchain creation, updates, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, dynamic node joining, dynamic node exit;

[1058] -CN situational awareness control of cNode: parameter type, parameter type configuration, parameter information extraction;

[1059] - Trustworthiness metrics of cNode and CN: device trustworthiness metrics, such as trustworthy proof vectors and trustworthy proof parameters;

[1060] -Homomorphic processing between cNode and CN: key negotiation and algorithm configuration.

[1061] 10) T9-AP

[1062] The main functions of T9-AP include one or more of the following:

[1063] -sNode trust capability perception, registration, and deregistration;

[1064] -Configuration, modification, activation and deletion of sNode trust capabilities;

[1065] -Security negotiation between sNode and CN: such as security policy negotiation and key negotiation;

[1066] - Trusted information subscription of sNode and CN: such as demand tags, capability tags, response tags, and global trusted network policies;

[1067] - Authentication and authorization of sNode and CN: identity authentication for secure access, such as authentication vector and authentication parameters;

[1068] -Encryption and integrity of signaling between sNode and CN;

[1069] -sNode and CN authorization: including static authorization and token-based authorization;

[1070] -CN's control over sNode blockchain: blockchain creation, update, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, dynamic node joining, dynamic node exit;

[1071] -CN situational awareness control of sNode: including parameter types, parameter type configuration, and parameter information extraction;

[1072] - Trust metrics of sNode and CN: device trustworthiness metrics, such as trustworthy proof vectors and trustworthy proof parameters;

[1073] -Homomorphic processing between sNode and CN: key negotiation and algorithm configuration.

[1074] 7.2 RAN Ground Interface - Data

[1075] Used to transmit user data or task data (including computing data, HiC data, business data, etc.), trusted data, etc.

[1076] 7.2.1 Task PDUs Layer

[1077] To address the characteristics of the task data plane, a new Task PDUs layer is added to transmit trusted service data between the UE and the base station / CN. It has the following functions:

[1078] -Task data format (such as the format design of computing data, definition of AI training or inference data format, etc.).

[1079] 7.2.2 TBP Layer

[1080] If an independent trusted plane is used, a new TBP layer is added to address the new features of the trusted data plane, providing one or more of the following functions:

[1081] - Blockchain transaction / block synchronization data;

[1082] - Situational awareness data;

[1083] -Homomorphically encrypted ciphertext, calculation results and other data;

[1084] -Trusted Root management data;

[1085] -Key.

[1086] 8. 6G Identities

[1087] 8.1 UE Identities

[1088] 8.2 Network Identities

[1089] As an example, the following identifiers are used in 6G-RAN to identify a specific network entity:

[1090] ●CF-C Name: used to identify a CN CF-C.

[1091] ●NAF Name: used to identify a CN NAF.

[1092] ●TCF Identifier / Name: used to identify a CN TCF.

[1093] ●TPF Identifier / Name: used to identify a CN TPF.

[1094] ●TEF Identifier / Name: used to identify a CN TEF.

[1095] ●TGF Identifier / Name: used to identify a CN TGF.

[1096] ●cNode Identifier (cNode ID): used to identify a cNode in a PLMN.

[1097] ●sNode Identifier (sNode ID): used to identify an sNode in a PLMN.

[1098] Tracking area identifier (TAI): used to identify the tracking area.

[1099] 8.3 Service Identities

[1100] As an example, the following identifiers are used in 6G-RAN to identify a specific service entity:

[1101] ●Task ID: When a UE supports multiple tasks simultaneously, it is used to distinguish different tasks and their signaling or data.

[1102] 8.4 TWE / TWG Identification

[1103] TWE and TWG are distinguished by an identifier, which is bound to the deployed node. The node identifier of the message endpoint can be determined based on the TWE / TWG identifier.

[1104] 9. Mobility and state transition.

[1105] 9.1 Task Mobility

[1106] As mentioned above, the 6G network has added new task features, including computing, AI training, AI reasoning and other tasks. In order to ensure the QoS of the connection and task respectively, the connection and task may not be migrated at the same time during switching. For example, when the computing resources of the target base station are insufficient, only the connection may be migrated, and the task may not be migrated. Therefore, the 6G network may face the situation where the connection anchor point and the task anchor point are separated. For scenarios where the user requests the base station or the base station requests the user to perform a task, when the user moves outside the coverage area of ​​the task anchor point, it is necessary to consider how the task anchor point communicates with the user. The following describes the solutions provided by this application for users requesting base stations to perform tasks and base stations requesting users to perform tasks, respectively. The base station here can be the cNode or sNode mentioned above.

[1107] (1) The user requests the base station to perform a task

[1108] A user initiates a computing or AI task to a base station. The base station, taking into account the task size, its own resources, and the resources of surrounding nodes, can break down the task and assign it to neighboring stations or devices within the cell for execution. The base station, acting as the task anchor, collects the results of each execution entity after the task is completed and feeds them back to the user. After the user initiates the task, if they move to the cell of a new base station, the connection anchor will switch to the new base station to ensure uninterrupted connection service. However, the task anchor may not change. In this case, how the task anchor sends the results to the user is a question that needs to be considered.

[1109] Since the user is no longer within the coverage area of ​​the task anchor, direct transmission over the air interface is impossible. The task anchor needs to first route the result to the user's current connection anchor, which then sends it to the user over the air interface. Therefore, the key to solving this problem is how the task anchor finds the user's connection anchor. The following, combined with Figure 81, provides three optional solutions provided by this application, such as Solutions 1 to 3 below.

[1110] Option 1

[1111] As shown in the accompanying figure, during a handover, the source base station sends a handover request message to the target station containing the user's task anchor identifier, namely the task anchor's base station ID / IP, and its corresponding UE ID, such as the temporary mobile subscriber identifier (TMSI). After receiving this message, the target base station sends its identifier to the task anchor based on the task anchor's ID or IP.

[1112] Option 2

[1113] During handover, the UE sends the task anchor point identifier, which includes the task anchor point's base station ID / IP and the UE ID, such as TMSI, to the target base station. The target base station then sends the connection anchor point identifier, which includes the target base station ID / IP and the corresponding UE ID, to the task anchor point.

[1114] Option 3

[1115] Before sending the result, the task anchor point first requests the CF-C of the core network to query the user's connection anchor point. The core network queries the user's current connection anchor point based on the UE ID and sends its identifier to the task anchor point.

[1116] (2) The base station requests the user to perform a task

[1117] The base station assigns a subtask to a user in its coverage area. Upon completion, the user sends feedback to the base station. When a user moves to a new base station's cell, they can no longer communicate directly with the task anchor. Instead, they must first send the task results to the connecting base station, which then forwards them to the task anchor. Therefore, in this scenario, the key lies in finding the task anchor using the connecting base station (the user's connection anchor). Two possible solutions are presented below, as shown in Figure 82: Scenario 1 and Scenario 2.

[1118] Option 1

[1119] When a base station assigns a task to a user, it carries information such as the task ID and the task anchor identifier (e.g., base station ID / IP). Therefore, when users report task results, they can encapsulate the task anchor identifier in the task result packet header. When the connection anchor receives this packet, it can determine the task anchor identifier by parsing the packet header.

[1120] Option 2

[1121] During handover, the source base station sends a handover request message to the target base station containing the task anchor point identifier, including the base station ID / IP of the task anchor point and the corresponding UE ID. Compared with solution 1, this solution can reduce the transmission of air interface information.

[1122] 9.2 Computational Mobility

[1123] Mobility management is a basic function of wireless networks, which is used to ensure that users enjoy uninterrupted services when they are on the move. Connection state mobility management is usually referred to as switching, which means to ensure that users in the connection state can continue to receive network connection services during the movement. The switching process includes a switching preparation phase, a switching execution phase, and a switching completion phase. In the traditional switching preparation phase, the source base station sends a switching request including the UE's connection context information, and the target site determines whether to receive the source site's switching request for the user based on the UE's connection context information and its own load information. In this application, the switching request sent by the source base station (source-sNode, S-sNode) of the general computing fusion needs to include not only the UE's connection context information but also the UE's computing context information. The target site (target-sNode, T-sNode) determines whether to switch the connection and migrate the calculation based on the UE's connection, computing context and its own load information, thereby ensuring the UE's computing service quality. The UE's connection context information includes: the UE's cell-radio network temporary identifier (C-RNTI) at the source station, the radio resource management (RRM) configuration during the UE's inactive time, the UE's antenna information, the mapping rules between QoS flows and data radio bearers (DRBs), UE capability information, and measurement results reported by the UE. The UE's computing context information includes: the computing resource status of the source station, the overhead of computing migration (including communication overhead, communication latency, QoS guarantees, etc.), the execution status of computing tasks on the S-sNode, and other information.

[1124] The following describes the scheduling under the RAN architecture provided by this application.

[1125] 10. Scheduling.

[1126] In the RAN architecture provided in this application, the TRS layer not only has the functions of the original medium access control (MAC) layer, but also has task-related functions. Since the connection-related functions have not been modified, this article focuses on the new functions of the TRS layer brought about by the introduction of new features such as tasks. Regarding content related to connection scheduling, such as basic scheduling operations, uplink scheduling, downlink scheduling, measurement mechanisms related to connection scheduling, uplink and downlink rate control, etc., please refer to the introduction of protocol 38.300 and will not be described in detail in this article.

[1127] 10.1 Task Scheduling

[1128] Taking a task deployment as an example, TS schedules computing power for TE in three ways, as shown in Figure 83:

[1129] Opt1 - TS no control, TE full control: no differentiated QoS;

[1130] Opt2 - Weak TS control, strong TE control (Cloud AI mode): TE can independently decide the allocation of each time slot based on a percentage, but TS cannot accurately control the CPU time slot.

[1131] Opt3 - TS strong control, TE weak control (communication mode): Controls TE CPU timeslot allocation in real time or near real time.

[1132] The following describes the QoS mechanism under the RAN architecture provided by this application. In summary, due to the introduction of new task features, in addition to the existing connection QoS mechanism, this application also proposes a task QoS mechanism. As mentioned above, the new features are collectively referred to as the first function in this application. Therefore, it can also be said that the QoS mechanism includes QoS mechanisms for the first function (for example, one or more of computing, data, intelligence, and trust).

[1133] 11. QoS mechanism

[1134] 11.1 Task QoS Mechanism

[1135] The task QoS mechanism, that is, the QoS mechanism for the first function, can specifically include the following three aspects:

[1136] 1) Network-side QoS mechanism;

[1137] 2) Terminal-side QoS mechanism;

[1138] 3) Quality of AI Service (QoAIS).

[1139] Among them, both the network-side QoS mechanism and the terminal-side QoS mechanism need to be enhanced based on the existing QoS mechanism. For example, the network-side QoS mechanism needs to be enhanced as follows: design new QoS indicators; design a new mechanism that generates QoS flows without CN participation and not based on IP quintuples. Taking into account scenarios where communication and tasks share computing resources, such as CU cloud deployment, and communication and tasks share communication resources, such as air interface RB resources, GTP tunnels and other transmission channels / bandwidth, etc., the terminal-side QoS mechanism can be enhanced as follows: as an example, communication is always prioritized; or, as another example, a unified computing QoS and communication QoS strategy is designed.

[1140] The following focuses on QoAIS.

[1141] It's important to understand that given the diverse demands for 6G network AI across various industries, translating user needs into requirements for network AI service capabilities that the network can understand is a pressing issue. 6G networks will no longer simply serve as conduits for traditional communications services. Different intelligent application scenarios will have varying requirements for the quality of AI services, necessitating a set of metrics that quantitatively or hierarchically convey user needs and the combined effectiveness of network orchestration and control across AI elements (including connectivity, computing, data, and algorithms). To this end, this article proposes the concept of Quality of Access (QoAIS), a set of metrics and process mechanisms for evaluating and ensuring the quality of AI services.

[1142] The AI ​​services of 6G networks can be divided into AI data, AI training, AI reasoning, and AI verification. Each type of AI service requires a set of QoAIS. In the design of the specific indicator system, the QoS of traditional communication networks mainly considers the connection-related performance indicators such as the latency and throughput of communication services. In addition to traditional communication resources, 6G networks will also introduce distributed heterogeneous computing resources, storage resources, data resources, AI algorithms and other resource elements for AI service orchestration. Therefore, it is necessary to comprehensively evaluate the service quality of the network's endogenous AI from multiple dimensions such as connection, computing power, algorithms, and data. Therefore, the design of the QoAIS indicator system of this application takes into account multiple aspects such as performance, overhead, security, privacy, and autonomy.

[1143] Table 1 provides a QoAIS indicator design method for AI training services.

[1144] Table 1: QoAIS indicator system for AI training services

[1145] QoAIS is an important input to the network's endogenous AI orchestration management system and control functions. The management and orchestration system decomposes and maps the top-level QoAIS to generate QoS requirements for AI tasks, and then maps the task QoS to the QoS requirements for multi-dimensional resources such as connection, computing, data, and algorithms. Continuous protection is achieved through the design of relevant mechanisms on the management plane, control plane, and user plane. Figure 84 shows a schematic diagram of the logical relationship between AI use cases, AI services, and AI tasks provided in this application. It should be noted that an AI use case is an AI service request made by a user to the network in an intelligent application scenario. An AI use case may involve the call of one or more types of network-endogenous AI services (such as AI training, verification, and reasoning services).

[1146] As mentioned above, QoAIS is an important input to the 6G network AI management and orchestration (NAMO) and control functions. The NAMO needs to decompose the top-level QoAIS and map it to the QoS requirements for connectivity, computing, data, and algorithms. The logical relationship between this process and the three-layer control functional entities is shown in Figure 85. As shown in Figure 85, from the perspective of the entire end-to-end process, after NAMO receives an external service request, it submits the corresponding AI service to TA for execution. The entire end-to-end process of real-time AI services includes the following functions:

[1147] ① Generate or import AI use cases. An AI use case is an AI service request made by a user to the network in an intelligent application scenario. An AI use case may involve the invocation of one or more types of network-native AI services (such as AI training, verification, and inference services).

[1148] ② Decompose the use case into one or more AI services;

[1149] ③ Decompose the AI ​​service into one or more AI tasks (AI Task, AIT), and decompose the QoAIS corresponding to the AI ​​service into the QoS of the AI ​​task;

[1150] ④Determine the anchor point location of AIT;

[1151] ⑤ Decompose task QoS into resource QoS requirements, clarifying the requirements for the four elements of resources required for AIT, including connectivity, computing, data, and algorithms / models;

[1152] ⑥Determine and configure the four elements of resources required for the task, including node selection (selecting nodes participating in the calculation, nodes providing data, and nodes providing algorithms / models), establishing connections between nodes, or updating the above configurations;

[1153] ⑦ Within the scope of the selected participating nodes, determine and adjust the distribution of computing, optimize the quality of communication connections, determine and collect the required data for processing, and determine and replace or optimize the algorithm model in real time to ensure the achievement of task QoS and thus QoAIS;

[1154] As mentioned above, the management layer has poor real-time performance and acquires a wide range of network information, but with coarse granularity. The control layer, on the other hand, has strong real-time performance and can obtain more accurate information, but its data range is relatively limited. Furthermore, the management layer cannot obtain real-time information on the status of air interface links and terminal-side resources. Therefore, some functions are best implemented at either the management or control layer, while others can be better achieved through collaboration between the management and control layers.

[1155] Another scenario involves network AI capability requirements generated by the control plane, such as a user submitting an AI service request to the network via control signaling. The end-to-end process for this scenario requires further analysis. For example, one possible approach is for the TA to first determine whether the request is an AI service or an AI task. If the request is the former, NAMO will execute it; if the request is the latter, the TA will handle it.

[1156] After the task trigger source passes the service workflow to TA, TA maps it to the task instance and deploys it to a specific network element with computing power for execution.

[1157] Task triggers come in two flavors: one originates within the network, such as network optimization tasks initiated by the RAN itself; the other originates from third parties. The network receives service requests from third parties through capability exposure, orchestrates the services, and creates a workflow with the required QoS guarantees. This workflow is then passed to the TA, which maps it into a specific task instance for execution. The workflow includes the resources required for the task and the dependencies between tasks. The TA first creates an instance for each task, assigns a task ID, and parses each task's QoS from the service QoS, completing the mapping from service QoS to task QoS.

[1158] To ensure the achievement of QoAIS, the aforementioned hierarchical management and control logic architecture is implemented through a "three-layer closed loop." The TS layer ensures the achievement of task QoS within the TA's resource allocation range by real-time monitoring and optimization of the four resource elements. If the TS layer is unable to provide task QoS guarantees, the TA layer will modify the overall resource allocation, such as adjusting the network nodes involved in the task, replacing the model repository, or replacing the data repository. If the TA layer is unable to provide task QoS guarantees, NAMO will be assigned to optimize the situation. NAMO can modify the anchor point location of the AI ​​task or re-decompose the mapping between AI services and AI tasks.

[1159] Figure 86 shows the mapping relationship between each indicator dimension of QoAIS and the QoS on each resource dimension. As shown in Figure 86, the QoAIS indicators of AI services are decomposed into QoAIS indicators on tasks and each indicator dimension, and then further mapped to QoS indicators on each resource dimension, which are guaranteed by the management plane, the control plane of each resource dimension, and the user plane mechanism. The QoS indicators on each resource dimension in Figure 86 can be divided into indicators suitable for quantitative evaluation (such as various resource overheads) and indicators suitable for hierarchical evaluation (such as security level, privacy level, and autonomy level). For the former type of indicators, this application proposes a quantification scheme for some indicators, such as training time, algorithm performance boundary, calculation accuracy, various resource overheads, etc.

[1160] Table 2: Mapping of AI training service performance QoAIS to various resource dimensions

[1161] In the above description of the RAN architecture provided by this application, a general description of the new features provided by this application, such as tasks, computing, trust, and intelligence, was provided. To provide a clearer and more comprehensive understanding of these new features and their impact on the RAN architecture, each of these new features is further elaborated below.

[1162] 12. New feature of 6G - Tasks.

[1163] 12.1. Driving force.

[1164] This section aims to explain why network AI is necessary and its relationship with cloud AI and mobile edge computing (MEC AI).

[1165] 1) Network AI

[1166] In the 5G era, cloud AI architectures have been widely adopted to provide services such as centralized computing, big data analysis, and AI training and inference. The traditional "end-pipe-cloud" architecture is a decoupled design: the end-device provides data, the mobile network provides the communication pipeline, and the cloud provides AI capabilities. Coordinating these separate functions and resources across multiple facilities to effectively deliver flexible, smooth, and stable services while ensuring quality of experience (QoE) is extremely challenging. Furthermore, for latency-sensitive ultra-reliable low-latency communication (URLLC) services, MEC deploys application servers close to base stations, achieving closer proximity to end users and lower latency than cloud AI. However, this still essentially deploys the AI ​​platform at the application layer. Joint optimization of connectivity and AI resources still requires cross-layer collaboration within the MEC, which cannot avoid the aforementioned issues of cloud AI.

[1167] To address the issues of slow speed, long latency, low privacy, and high carbon emissions associated with deploying AI functions at the application layer, such as cloud and MEC, network AI extends computing power from the cloud to locations physically closer to end users, providing data storage and processing, AI capabilities, and enhanced security within the network. Furthermore, the "end-edge-cloud" architecture is more effective in supporting compute-intensive, latency-sensitive, security-assured, and privacy-sensitive applications, such as interactive VR / AR gaming, autonomous driving, and smart manufacturing.

[1168] To this end, this application considers providing a complete AI environment and AI-as-a-Service (AIaaS) within the network, introducing the concept of Network AI to clearly distinguish it from existing Cloud AI. Network AI primarily addresses scenarios requiring high real-time performance, high security and privacy requirements, or the choice of performing data processing within the network to reduce overall energy consumption (i.e., bringing computing to data rather than the traditional process of bringing data to computing). Network AI can be a beneficial supplement to Cloud AI.

[1169] 2) Application scenarios of network AI.

[1170] In 6G, AI capabilities are no longer limited to the application layer; they are deeply integrated with the network. The relationship between AI and the network can be broadly categorized into three application scenarios: network element intelligence, network intelligence, and business intelligence. Network element intelligence refers to the native intelligence of network element devices; network intelligence refers to the collaborative generation of network-level collective intelligence by multiple intelligent network elements; and business intelligence refers to the intelligent services provided by the entire wireless communication system for services. These services are generally triggered by external services and executed by the wireless network. This is particularly true for scenarios involving terminal participation, where the business logic can be transparent to the wireless communication system. Through these network element intelligence and network intelligence, AI services are provided internally within the network; and through business intelligence, corresponding AI services are provided externally.

[1171] 3) Why should network architecture natively support AI, and what challenges are faced?

[1172] To support the three aforementioned application scenarios, the 6G network-native AI architecture must be based on a unified framework. This framework builds a complete, distributed AI environment within the 6G network, supporting different types of AI training and inference. Specifically, these include: 1) Network AI can leverage the inherent AI capabilities of network elements and terminals (e.g., connectivity, computing, data, AI training, and inference capabilities); 2) It can provide on-demand AI, computing, and data services to the network itself and applications; and 3) it can provide AI QoS assurance services in complex wireless environments, including heterogeneous, dynamic, and fully distributed environments.

[1173] Compared with the centralized, homogeneous, and stable AI environment provided by the cloud, the network AI architecture faces the following technical challenges: 1) Distributed AI requires deploying AI on a large number of core network elements, base stations, and UEs. It is necessary to consider the efficient management of a large number of nodes from the architectural design perspective to avoid centralized management of nodes becoming a bottleneck; 2) The computing power, memory, data, and algorithm capabilities of different nodes vary greatly, and it is necessary to consider the efficient management of heterogeneous nodes from the architectural design perspective; 3) The real-time changes in the wireless environment and the dynamic changes in computing load require timely updates of dynamically changing states from the architectural design perspective. Therefore, this application will shift from a session-centric to a task-centric approach in architectural design to address the above challenges.

[1174] 4) Typical characteristics of native AI network architecture.

[1175] Traditional wireless networks are session-centric, managed based on session granularity, and implement QoS guarantees for sessions.

[1176] Figure 87 shows the core features of the task-centric architecture. As shown in the figure, the network AI proposed in this application requires a native intelligent architecture design from an architectural perspective, and natively supports the deep integration of connections, computing, data, and algorithms at the architectural level. Therefore, the key to the design of native intelligent architecture is essentially to support real-time control based on the deep integration of four elements, that is, task-granular control, and support for task QoS guarantee mechanisms. This application refers to the architecture that supports these two basic capabilities as a task-centric architecture.

[1177] 12.2. Task Overview.

[1178] Task: The coordinated use of computing, algorithms, connections, and data to achieve a specific goal. This goal originates from an AI use case, which can be one or more AI training or AI inference tasks. The mapping of AI use cases to tasks is flexible. As described above, an AI use case can be decomposed into one or more AI services, which can be further decomposed into one or more AI workflows, and an AI workflow can be further decomposed into one or more tasks.

[1179] Task-centric: This approach focuses on tasks as the management object, supports task lifecycle management, and ensures task QoS and smooth execution through the coordination and deployment of computing, algorithms, connections, and data. Task QoS is derived from the AI ​​QoS decomposition and mapping of AI services, and is related to the specific mapping of AI use cases to tasks.

[1180] Based on the above analysis, the 6G network architecture needs to achieve the following key shifts in design paradigm:

[1181] ●Change 1: Control objects change from “sessions” to “tasks”

[1182] Compared with traditional "conversations", the technical objectives and technical means of AI tasks are different from those of conversations.

[1183] From a technical perspective, traditional communication systems provide conversational services, typically between specific terminals or between terminals and application servers, ultimately aiming to transmit user data (including voice). However, network AI has a different purpose. For example, network element intelligence and network intelligence, as mentioned above, provide intelligent services to the network, aiming to improve communication network efficiency. Service intelligence, on the other hand, aims to provide third-party intelligent services at the app level.

[1184] From a technical perspective, traditional communications services require maintaining user-granular connection pipes (such as end-to-end tunnels from UE to base station and base station to core network), as well as lifecycle management and QoS assurance mechanisms for these connection pipes to deliver data transmission services with guaranteed QoS. AI, on the other hand, is a data- and compute-intensive service with the following differentiated characteristics compared to conversations: Firstly, AI introduces new resource dimensions, including computing power (such as CPUs, GPUs, and NPUs), data (such as those used and generated by AI), and algorithms (such as neural network models and reinforcement learning). Therefore, 6G networks require the introduction of new resource management mechanisms. Secondly, factors such as single-point computing bottlenecks, data privacy protection, and storage bottlenecks for extremely large models make it difficult for a single node to efficiently implement AI services. These services can only be achieved through the coordination of computing power, algorithms, and data across multiple nodes. Therefore, 6G networks require the introduction of new inter-node coordination mechanisms.

[1185] Based on these two differences, it's clear that the "conversational" system cannot support native AI. Therefore, a new "task" system is needed to support these new mechanisms (including new resource management mechanisms and new inter-node coordination mechanisms). This article will define a "task" as achieving a specific goal by coordinating multi-node, multi-dimensional resources at the 6G network level.

[1186] ●Change 2: Management resources shift from connection resources to four-element resources

[1187] The "session" system establishes channels for user data transmission and allocates corresponding connection and air interface resources, while the "task" system allocates the four essential resources to complete AI tasks. Taking AI inference tasks as an example, the executor must first obtain information on resources such as computing, data, and algorithms before executing the relevant task. For example, computing information refers to the computing resource time slot or percentage corresponding to a task, data information refers to data collected in real time by the executor or externally input data, and algorithm information includes possible AI models such as graph neural networks (GNNs) and convolutional neural networks (CNNs), or AI algorithms such as reinforcement learning (RL). Taking federated learning tasks as an example, multiple executors collaborate to jointly train an AI model, utilizing allocated connection resources to transmit gradient information during the training process. In summary, with the introduction of tasks, managed resources shift from connections to the four essential resources of connection, computing, data, and algorithms.

[1188] ●Change 3: From “session control” to “task control”

[1189] Unlike traditional session control, the task control system in network AI primarily provides the following functions: 1) decomposition / mapping of external services into internal tasks; 2) decomposition / mapping of service QoS into task QoS; and 3) provision of mechanisms for four-factor and multi-node collaboration, orchestrating and real-time control of the four-factor resources across multiple nodes in the infrastructure layer, ultimately enabling distributed serial / parallel processing at the task granularity and ensuring real-time QoS. For simple service requests, one service can be mapped to one task; for complex services (such as the integration of multiple service flows or extremely computationally intensive service requests involving only a single service flow), these can be mapped to multiple nodes for system execution.

[1190] The following is an explanation of function 3). Generally speaking, the execution of a specific AI task requires collaboration in two dimensions:

[1191] 1) Synergy of the four elements of resources

[1192] The execution of a task may require some or all of the four essential resources: connectivity, computing, data, and algorithms. For example, the configuration of these four essential resources is provided during the task deployment phase, and real-time scheduling of these resources is performed during task execution.

[1193] 2) Multi-node collaboration

[1194] In traditional communication networks, connection-related computing is mostly performed within a single network element, and computing power sharing and coordination between network elements is generally not required. With the increasing number of AI scenarios accompanied by large-scale AI training, AI inference of large models, and massive amounts of perceptual image processing, the computing power requirements far exceed those of traditional communication networks. Simply expanding the computing capacity of each network element will result in excessively high network deployment costs. Distributed computing, on the other hand, can collaboratively complete tasks through computing power sharing. Therefore, collaborative tasks (i.e., tasks involving multi-node collaboration) require inter-node computing power coordination. Secondly, with increasingly stringent requirements for data privacy protection, for example, raw UE data cannot be uploaded to the network for training due to privacy concerns. Federated learning, through collaborative learning and gradient transfer, addresses this issue to a certain extent. Collaborative tasks require data-level coordination between multiple nodes. Finally, to support endogenous AI, model training consumes significant computing and storage resources. A good model also needs to be shared within the network to improve overall network efficiency. Collaborative tasks require AI model-level coordination between multiple nodes.

[1195] ●Change 4: From session QoS to task QoS

[1196] 6G networks will no longer simply serve as conduits for traditional communications services. Different intelligent application scenarios will have varying requirements for the quality of AI services. This requires a set of metrics that can quantitatively or hierarchically convey user needs and the comprehensive effectiveness of network orchestration and control of AI elements (including connectivity, computing, data, and algorithms). To this end, this article proposes the concept of Quality of Access (QoAIS).

[1197] The QoS of traditional communication networks mainly considers connection-related performance indicators such as the latency and throughput of communication services. In addition to traditional communication resources, 6G networks will also introduce new resource dimensions such as computing power, algorithms, and data, requiring the expansion of corresponding evaluation indicators. At the same time, as the global intelligent application industry generally strengthens its attention to data security and privacy and users increase their demand for network autonomy, performance-related indicators will no longer be the only indicators that users pay attention to in the future. The demand for overhead, security, privacy, and autonomy will gradually deepen, thus becoming a new dimension for evaluating service quality. Therefore, the QoAIS indicator system proposed in this application needs to expand its content from the above two aspects.

[1198] For example, the QoAIS indicator evaluation dimensions and content for AI training services include:

[1199] 1) Performance: performance metrics, training time, generalization, reusability, robustness, interpretability, consistency between loss function and optimization objective, fairness, etc.

[1200] 2) Overhead: storage overhead, computational overhead, transmission overhead, energy consumption, etc.

[1201] 3) Security: storage security, computing security, transmission security, etc.

[1202] 4) Privacy: data privacy level, algorithm privacy level, etc.

[1203] 5) Autonomy: fully autonomous, partially manually controllable, fully manually controllable, etc.

[1204] The management and orchestration system achieves continuous QoAIS assurance by designing relevant mechanisms at the management, control, and user levels.

[1205] 12.3 Key Technologies

[1206] Figure 88 is a schematic diagram of key mission-centric technologies. Compared to traditional communication networks, the mission-centric framework proposed in this application involves the following changes:

[1207] ●New features:

[1208] CN: Added network functions (NF) such as TCF and TPF;

[1209] RAN: Added TA, TS, TE and other functions;

[1210] UE: Added TE and other functions.

[1211] ●New protocol stacks: mission control plane protocol stack and mission user plane protocol stack;

[1212] Control plane: Enhanced T-NAS layer, TRC layer, TRS layer, etc.

[1213] User plane: Added TRD layer and enhanced T-SDAP layer.

[1214] Figure 89 is a panoramic view of key task-centric technologies. As shown in Figure 89, task-based granularity management and control has the following benefits:

[1215] Unified state maintenance: state libraries of the four resource elements (such as connection library, computing power library, model library, and database, etc.) are maintained (quasi-real time);

[1216] Unified task management and control: granular task deployment, execution, and QoS assurance, including near-real-time coordination of four elements (algorithms / data and connections / computing power) and TE adjustments. Algorithms and data coordination are implemented at the TRC layer, while connections and computing power coordination are implemented at the TRS layer.

[1217] Unified general calculation scheduling: real-time general calculation scheduling of different tasks;

[1218] Unified multi-task scheduling: Different tasks share resources (connection, computing, etc.), and differentiated QoS guarantees are provided among multiple tasks;

[1219] Unified bearer maintenance: used to transmit task information.

[1220] In addition, the task-centric framework will have an impact on the interface. As shown in Figure 90, since TE may be deployed in UE and various network element nodes, the task interface will involve various 3GPP interfaces, such as:

[1221] Uu interface;

[1222] RAN ground interface;

[1223] ●Inter-CN interface.

[1224] That is, task-related signaling needs to be transmitted on these interfaces. The specific content of task-related signaling is described in other parts of this document and will not be repeated here.

[1225] To achieve the aforementioned task-centric architecture requirements and goals, the following will focus on the task control logical architecture and its deployment methods.

[1226] ● Logical architecture of task control

[1227] Existing communication systems consist of a management domain and a control domain. Network management equipment deployed in the management domain operates and manages network elements through non-real-time management-plane signaling (typically at the minute level). The control domain, which includes core network equipment, base stations, and terminal devices, uses more real-time control-plane signaling (typically at the millisecond level). For example, the end-to-end tunnel established during a user voice call is typically completed within tens of milliseconds.

[1228] Figure 91 is a diagram of the task-centric task management logic architecture and functions.

[1229] As shown in Figure 91, task control includes two major logical functions: network AI management orchestration and task control. Based on the different real-time requirements of each stage of task control, the scope of task control and other factors, this application introduces NAMO to complete the decomposition, mapping and AI business flow orchestration from AI business to tasks. NAMO is usually non-real-time and is generally deployed in the management domain; task control introduces the task anchor function (TA), task scheduling function (TS), and task execution function (TE) at the control level to perform hierarchical control of tasks to find a balance between task scope and real-time task scheduling.

[1230] If tasks are managed and controlled only through NAMO in the management domain, the following problems may occur:

[1231] 1) NAMO cannot directly manage UEs. Tasks involving UEs must be deployed through the application layer, which is not perceived by the network. Therefore, it is impossible to achieve the coordination of the four elements to control and ensure task QoS.

[1232] 2) NAMO signaling has a long delay (typically at the minute level), which results in delayed task control and makes it difficult to meet strict task QoS requirements.

[1233] 3) NAMO manages many nodes, and if highly centralized task control is performed, signaling consumption will be high.

[1234] Therefore, the RAN architecture provided in this application introduces a task anchor point TA to be responsible for the life cycle management of the task; this node is deployed at the control level, which can ensure the real-time and fast transmission of signaling (millisecond level), making task control more real-time and efficient; in scenarios with a larger task scope, the TA deployment location may be higher (for example, deployed in the core network). If there is a real-time requirement for the control of four-element resources, the TS can be deployed close to the TE to perceive the connection resource status in more real time, as well as to perform real-time QoS quality monitoring and resource adjustment.

[1235] Based on the above three-level architecture of TA, TS, and TE, the functional characteristics of each logical function are explained below.

[1236] Task anchor function TA: Mainly responsible for the life cycle management of tasks, completing task deployment, startup, deletion, modification, monitoring, etc. based on task QoS requirements, including regulating the four-element resources to perform coarse-grained QoS guarantees in the initial deployment stage of the task.

[1237] Task Scheduling (TS): This function is primarily responsible for controlling and scheduling the task execution phase and comprises two major modules: information collection and resource management. Information collection requires TS to monitor the computing load, data processing capabilities, currently used algorithm models, and communication channel conditions of multiple nodes in real time. Based on this information collection, TS offers more real-time resource management capabilities than TA. For example, as the network environment changes, TS can monitor and ensure QoS in real time through real-time adjustments to models and data, or real-time scheduling of connections and computing power.

[1238] Task Execution (TE): This function is primarily responsible for the specific execution of tasks, as well as any information and data exchange related to business logic. A single service request may be mapped or decomposed into multiple tasks, deployed and executed on multiple TEs. Furthermore, data and information may be exchanged between different TEs during task execution. For example, federated learning across multiple nodes requires the transmission of intermediate gradient information between nodes. Regarding the relationship between TEs and the number of tasks, a single TE can execute a single task or support multiple parallel tasks. Specific task types can include computation, data processing, AI training, and AI reasoning.

[1239] ●Task control deployment architecture

[1240] TA management of TEs requires real-time and flexibility. Deploying a RAN TA within the RAN domain is more appropriate for managing RAN TEs. Similarly, a CN TA within the core network (CN) domain performs similar functions for CN TEs. This is because TE status changes in real time (e.g., CPU load, memory, battery life, UE channel conditions, etc.). Deploying a TA / TS locally reduces management latency. Furthermore, according to wireless network design logic, the CN and RAN need to be decoupled as much as possible. For example, RAN RRM and radio transmission technology (RTT) optimization should not be CN-aware. Conversely, if a CN TA manages RAN TEs and performs RAN tasks, this would lead to strong coupling of service logic. Therefore, this application proposes deploying TA / TS independently in both the CN and RAN domains to achieve real-time management and service decoupling. The following four use cases briefly illustrate the necessity and rationale for CN TA and RAN TA. It should be noted that the use cases presented here are merely illustrative; other deployment scenarios and architectures are possible, and are not fully listed here.

[1241] Taking federated learning between base stations and terminals as an example, the following details how to deploy TAs, TSs, and TEs. It should be noted that the following examples using federated learning are primarily intended to illustrate the deployment of TAs, TEs, and TSs, and do not focus on the specific functional division of base stations into cNodes and sNodes. Therefore, the following examples use base stations as a whole.

[1242] Figure 92 illustrates the deployment of task-centric network AI. The gNB, as an example of a base station, corresponds to the base station in a 5G network. A gNB can be flexibly deployed as a separate centralized unit (CU) and distributed unit (DU). For example, the CU can be deployed in the cloud to meet non-real-time signaling control and data transmission needs, while the DU can be deployed closer to the UE to meet real-time resource allocation and data transmission / retransmission needs.

[1243] Scenario 1: Base station (e.g., gNB) + UE scenario

[1244] In this scenario, the gNB acts as both the TA and the TS, and the UE acts as the TE. The UE is both the computing power provider and the task executor, accepting the gNB's task management and task scheduling (e.g., connection establishment between the UE and the base station, real-time scheduling of air interface resources, and allocation and real-time adjustment of AI models).

[1245] Scenario 2: Base station CU + base station DU scenario

[1246] In this scenario, CU is both TA and TS, and DU is TE; at this time, DU is the computing power provider and task executor.

[1247] Scenario 3: Base station CU + base station DU + UE scenario

[1248] In this scenario, the CU is the TA, the DU is the TS, and the UE is the TE. The UE provides computing power and executes tasks, while the CU manages the tasks. The DU perceives the tasks assigned to the UE and schedules the four resource elements (QoRs) and ensures real-time QoS for these tasks. Furthermore, the TA and TS are deployed separately, with the TS deployed lower than the TA. This allows for more real-time awareness of the TE's connection, computing power, and algorithm status, enabling more real-time monitoring of task QoS and rapid adjustment of the four resource elements.

[1249] Scenario 4: CN + base station (e.g., gNB) + UE

[1250] In this scenario, CN is the TA, gNB is the TS, and UE is the TE. In this case, UE is the computing power provider and task executor.

[1251] As can be seen from the examples of the above four scenarios, TA, TS, and TE are only logical functions. These functions can be deployed on the same logical node or different logical nodes depending on different scenarios. From the perspective of logical nodes, a single node can simultaneously have multiple logical functions (such as any combination of TA, TS, and TE).

[1252] The following describes how to ensure task QoS based on the aforementioned task control logic architecture.

[1253] ●Task QoS guarantee

[1254] As mentioned above, to ensure the achievement of QoAIS, the hierarchical control logic architecture is implemented through a "three-layer closed loop." As shown in Figure 93, the process after a task is triggered can be divided into four stages: task deployment and initiation, task execution, task update, and task completion.

[1255] Figure 93 illustrates the task deployment and execution process. After the task's trigger source passes the service workflow to the task controller (TA), the TA maps it to a task instance and deploys it to a specific network element with computing power for execution. Task deployment involves the following two aspects.

[1256] (1) Creation and allocation of task instances

[1257] The TA receives a service workflow at the entry point, which can be mapped into one or more tasks. The TA creates an instance for each task, assigns a task ID, and sets the task QoS. These tasks are then assigned to specific network elements for execution.

[1258] Task allocation requires information about the distribution of computing and connection resources in the network. This information is managed by the TS and reported to the TA. The TS can be deployed in the core network or at a base station, managing resources within its respective domain. For example, a TS deployed at a base station maintains the computing power of each node in the base station and that of connected terminals. Computational and connection information can be periodically reported to the TA by the TS, or proactively queried by the TA from its TS.

[1259] TA makes reasonable resource allocation based on the computing power requirements of each task and the computing power resources of the current network. For example:

[1260] The workflow is instantiated as three tasks. The computing power reported by TS1 can support two tasks, and the computing power reported by TS2 can support the third task. Therefore, the allocation scheme for these tasks is: deploy tasks 1 and 2 to the resources managed by TS1, and deploy task 3 to the resources managed by TS2. The specific allocation scheme depends on the algorithm implementation and needs to consider multiple factors such as QoS guarantees, resource capabilities, and energy consumption.

[1261] In addition, there is a situation in network AI where some tasks have specified network elements that must participate, such as specifying certain terminals to participate (data is on the terminal). In this case, the mandatory items need to be used as constraints in the task allocation algorithm.

[1262] When a task instance is assigned to a TS's subordinate resources, the TA sends a signaling request to create a TE for that task. Due to the dynamic nature of wireless networks and the parallel deployment of multiple tasks, if the corresponding computing resources are unavailable when the TS receives the TE creation signaling request, it will reject the signaling request and require the TA to reallocate the resource to another TS. Otherwise, the signaling request is accepted, the TE is created, and a receipt is sent to the TA, which contains the TE-related information.

[1263] (2) Task parameter configuration

[1264] After creating the executor TE for the task, you can deploy the task to the corresponding TE and send the parameter configuration required for execution. The configuration includes:

[1265] Basic execution information of the task, such as input, output, and model;

[1266] ●Task QoS, such as convergence time, accuracy, energy consumption, etc.;

[1267] ● The workflow relationship between multiple tasks. After configuration, the business interaction between TEs does not require TA to perform command control.

[1268] There are two options for sending task parameter configurations to TE:

[1269] Option 1: Transit through TS. TS establishes the task context based on the task configuration, allowing for real-time scheduling control of the task.

[1270] Option 2: Distribute configurations to the TS and TE separately. The two configurations can have different contents. The configuration distributed to the TS is used to establish the task context, and the configuration distributed to the TE is used for task execution.

[1271] ●Task execution control

[1272] Task execution is performed on the TE, which handles the task independently according to the business logic. Data exchange between TEs does not require additional control by the TA; instead, it is defined in the business logic. The TA only needs to configure the dependencies between TEs when configuring task parameters.

[1273] For example, when multiple TEs are conducting federated training, a client TE (or client TE) will automatically push the gradient to the server TE after completing local training, without notifying the TE, which then instructs the server on subsequent actions. This is crucial to avoid overloading the TE by interfering with business logic.

[1274] It is important to note that in task deployment, the computing / connection resources managed by the TS can be deployed to multiple tasks. For example, if the TS is deployed on a base station, the base station can create TEs for multiple tasks, and multiple UEs connected to the base station can also create TEs to execute tasks. When multiple tasks are deployed and executed simultaneously, conflicts require scheduling by the TS, as follows:

[1275] 1) Scheduling in bandwidth sharing scenarios is divided into two categories: signaling and data, as shown in a) and b) below:

[1276] a) Control signaling scheduling between TS and TE. For example, if multiple UEs are performing tasks under the base station TS, the parameter adjustment instructions issued by the TS need to be scheduled on the task-signaling radio bearer (T-SRB);

[1277] b) Data scheduling for service interactions between TEs. For example, a base station deploys a federated parameter server. Ten UEs act as federated clients to upload gradients to the parameter server (PS). TS is required to schedule task-data ratio bearers (T-DRBs).

[1278] 2) Scheduling in computing power sharing scenarios: Scheduling computing power based on the computing power requirements of multiple tasks and task QoS.

[1279] A task is a process, and the computing power requirements are constantly changing, requiring real-time scheduling. For example, in neural network training tasks, the computing power requirements of different layers vary significantly. Furthermore, environmental changes during task execution can affect the QoS of the task, requiring real-time TS control. This section will be incorporated into the third phase of task updates for a unified description.

[1280] ●Task update

[1281] Wireless network environments are unstable and subject to real-time dynamic changes, such as user mobility, interference fluctuations, and service emergencies, which can affect ongoing tasks. Therefore, task management and control functions must be aware of changes in the task execution environment in real time to adjust task parameter configurations to ensure smooth task execution and guarantee task QoS.

[1282] Figure 94 is a diagram of task deployment.

[1283] In the three-layer task management architecture, the TS is responsible for detecting changes in the network environment. Network environment changes can be categorized into two types based on whether the task topology changes. The topology here refers to the networking relationship between the TA, TS, and TE corresponding to a task deployment.

[1284] Category 1: The topology remains unchanged. For example, changes in link QoS (users moving further away, interference increasing) or computing power (a new app running on a terminal) do not change the topology.

[1285] The second category: topology changes, such as user status changes (entering inactive / idle), handover, UE lost, extremely low terminal power requiring task termination, etc.

[1286] After TS detects a change in the task execution environment, its processing strategy is as follows:

[1287] (1) In scenarios where the topology relationship has not changed, the TS directly updates the configuration in real time to ensure the smooth execution of the task and QoS guarantee. For example, in a task jointly performed by a base station and a terminal, if the link QoS changes, the base station TS can ensure that the inference task continues to execute by configuring a new inference model split point.

[1288] (2) In the scenario where the topology relationship changes, since TS can only see the subordinate tasks, it cannot evaluate the impact on the overall workflow when the topology relationship changes, and therefore cannot make reasonable configuration adjustments. It is necessary to notify TA, who will make adjustments and reorganize the topology relationship of the overall task.

[1289] ● Mission completed

[1290] After the task is completed, two aspects of processing need to be performed: one is the feedback of the task execution result, and the other is the deletion of the task instance.

[1291] (1) Task execution result feedback

[1292] After the task is completed, the execution result may be fed back in two ways:

[1293] One is to output the execution results directly to the trigger source, such as the network training model, inference results, etc.

[1294] The other is to use the execution results directly in the network, and only the result acquisition address is fed back to the trigger source, such as the AI ​​model of the RRM algorithm within the RAN.

[1295] The triggering method used by TE for the task execution result and the address of the trigger source can be brought down as parameters when the task is deployed and actively pushed by TE; or it can be used to notify TA of the task completion and have TA issue a push instruction carrying the push method and trigger source address.

[1296] (2) Task instance deletion

[1297] After task execution completes, the task instance needs to be deleted. This is part of the task lifecycle management and is managed by the task agent (TA). After receiving the task results, the TE sends a message to the TA notifying it of the task completion, along with the task ID. The TA then sends a command to the TS associated with the task to delete the task context and TE. Upon receiving the command, the TS deletes the task context and sends a command to delete the corresponding TE, reclaiming the computing power and updating its own computing power status.

[1298] 12.3.1 Task Deployment

[1299] 1. Single-point task deployment

[1300] The configuration of single-point AI tasks is described in detail using AI inference tasks as an example from the following aspects:

[1301] Aspect 1: The operations and corresponding messages required for real-time control of tasks.

[1302] Figure 95 is a diagram showing the task deployment method for connecting to UEs. As shown in the figure, for real-time control messages of tasks, the task anchor (which can be a network-side device or UE) can implement the following methods to the executor (which can be a network-side device or UE):

[1303] - Mode 1: request / response mode. For the task anchor point's task configuration for the device or UE, the executor has a corresponding reply response message for each task configuration information to inform the result of this configuration (success, failure, partial success, etc.).

[1304] - Mode 2: config mode (no response message). For the AI ​​task configuration (idle / inactive) of the task anchor to the UE, each task configuration message is considered successful by default, so the executor does not need to send a response message to the configuration party.

[1305] Table 4 below summarizes all task-related configuration messages and the configuration parameters they carry:

[1306] Table 4: Task deployment message table

[1307] The second aspect: through which interfaces is real-time control of tasks achieved?

[1308] Figure 96 is a diagram showing the task deployment method for idle UEs. As shown in the figure, for the scenario where the task anchor is the RAN device and the task executor is the UE, the RAN has three ways to configure the UE's task signaling and different TRC states for the UE:

[1309] 1) Method 1: For idle UEs, tasks are configured / reconfigured through system information block (SIB) broadcast signaling;

[1310] 2) Mode 2: For an inactive UE, the task is configured / reconfigured through a TRCReconfig message or a TRCRelease message. The TRCReconfig message is sent by the base station when the inactive UE was previously in the connected state. After receiving the message, the UE does not enter the inactive state. The TRCRelease message is also sent by the base station when the inactive UE was previously in the connected state. However, after receiving the message, the UE immediately enters the inactive state.

[1311] 3) Mode 3: For the connected UE, configure / reconfigure the task through the TRCReconfig message.

[1312] Furthermore, for scenarios where the task anchor is a network device (CN or RAN) and the task executor is also a network device, the task configuration is implemented through the following interfaces. Taking the 5G interface as an example, the task anchor (assuming it is a CU) configures the AI ​​task on the RAN device through the following interfaces:

[1313] CU->DU: newly defined F1 message;

[1314] CP->UP: Newly defined E1 message;

[1315] gNB->gNB: Newly defined Xn message;

[1316] CN->gNB: Newly defined Ng message;

[1317] Regarding the interfaces between devices and the newly defined messages mentioned above, Figure 97 can concisely reflect the interfaces and definitions.

[1318] After discussing the configuration message above, the following describes what information is carried in the configuration message to complete the specific parameter configuration of the task, such as the third aspect.

[1319] Aspect 3: What parameters are involved in real-time control of tasks?

[1320] Taking AI as an example, the information carried in the configuration message is divided into three categories. For a configuration message, the parameters contained therein can be any one or a combination of multiple parameters in the three categories, without limitation.

[1321] 1) (Algorithm) AI model:

[1322] ■Configuration parameters: task ID, input parameters, model description, output parameters (optional. If they are parameters defined by the standard protocol, they do not need to be additionally defined or carried in the configuration message).

[1323] ■Independent reasoning: Algorithm ID (optional, configured only when independent reasoning is used)

[1324] Input parameters: Input can be specific parameters, such as those defined by 3GPP, or data collected by the UE itself or provided by the network (in this case, CPU offloading).

[1325] Figure 98 is a schematic diagram of split inference. The input parameters and output parameters are the model's input and output parameters, respectively. In many cases, performing AI / ML model inference entirely on the terminal or network side can lead to an imbalance in computing and wireless communication resources between the terminal and the network, as well as security and privacy issues. Therefore, it is possible to consider rationally splitting AI / ML inference tasks so that they can be performed jointly on both the terminal and the network. This can reduce the pressure on the device's computing power, memory, storage, power consumption, and network transmission, reduce AI / ML inference latency and energy consumption, and improve inference accuracy and efficiency. The principle of AI / ML model splitting is to offload computations that consume more computing power and energy to network-side nodes, while retaining latency-sensitive computations or computations that must remain on the terminal under certain privacy protection rules. As an example, the terminal will execute an AI / ML operation up to a specific portion, or execute an AI / ML model up to a specific layer, and send the generated intermediate data to the network. The network-side node is responsible for executing the remaining portion of the AI / ML operation or the remaining layers of the AI / ML model and feeding the inference results back to the terminal. The selection of model split points needs to be based on the computing power consumed by each layer, the amount of data, etc., and several alternative split points should be set, and the appropriate split point should be selected based on the terminal computing power and network conditions.

[1326] 2) QoS: The QoS indicator corresponding to the task; for example, for a single-point AI inference task, this could be a combination of latency and reliability (e.g., 3ms + 99.99%).

[1327] 3) AI task attributes:

[1328] Figure 99 is a schematic diagram of AI task attributes. As shown in the figure, AI task attributes include parameters such as geographic area, timer, number of executions of AI reasoning tasks, and application granularity of the AI ​​model. For example, the application granularity of the AI ​​model includes a cell-level AI model, that is, the AI ​​model is applicable to all UEs in the cell; and a user-level AI model is only applicable to some UEs.

[1329] ■Geographical scope:

[1330] 1) When an idle / inactive UE goes out of geographical range, it automatically deletes old AI tasks and notifies the base station (optional);

[1331] 2) When the connected UE goes out of geographical range, old AI tasks and base station deletion tasks are automatically deleted (optional);

[1332] ■ Timeliness: When a timer expires, the idle / inactive / connected UE will delete the task; the configuration can be retained / deleted (which can be configured in advance by the base station or predefined by the protocol).

[1333] 1) Real-time: uses the Request / Response model, where the Response carries the task result;

[1334] 2) Non-real-time type: uses the Request / Response+Indicate model, where the Indicate carries the task result;

[1335] AI inference task execution count: This setting applies only to non-algorithmic AI inference tasks. It supports one-shot, periodic, or event-based configurations, as well as periodic task management based on a timer+number (i.e., the number of AI inference task executions).

[1336] ■ Application granularity: Applies to UE granularity, UE type, cell granularity, cell pair granularity, gNB granularity, CN granularity, and area granularity (e.g., tracking area code (TAC), RAN-based notification area code (RANAC)).

[1337] For the specific parameters of the above tasks, the UE side behavior is as follows:

[1338] ■Geographical scope:

[1339] Assume that each cell broadcasts the area ID and task configuration information (optional);

[1340] Figure 100 is a schematic diagram of task mobility. As shown in the figure, two cells are used as an example, represented by cell 1 and cell 2. Cell 1 broadcasts Area ID = 1 and task configuration 1, while cell 2 broadcasts Area ID = 2 and task configuration 2. Exemplarily, the broadcast message may be a system information block (SIB).

[1341] 1) When an idle / inactive UE goes out of geographical range, it automatically deletes old AI tasks and notifies the base station (optional);

[1342] 2) When the connected UE goes out of geographical range, old AI tasks and base station deletion tasks are automatically deleted (optional);

[1343] 3) When an idle / inactive / connected UE accesses a new cell, it first determines whether it needs to re-acquire the task configuration (and AI model configuration) based on the corresponding area ID in the cell's SIB.

[1344] If it is a new area:

[1345] Delete the task configuration corresponding to the old area;

[1346] Reread the SIB and obtain the task configuration information corresponding to the cell.

[1347] If it is not a new area:

[1348] There is no need to re-acquire the task configuration information of the cell.

[1349] ■ Timeliness: When the timer expires, the idle / inactive / connected UE will delete the task; the configuration can be retained / deleted (which can be configured in advance by the base station or predefined by the protocol).

[1350] After receiving the task-related timer configured by the base station and starting the task, the UE starts the timer immediately;

[1351] ●After the timer on the UE side times out, stop / delete the task.

[1352] ■Task execution times: This setting applies only to non-algorithmic AI reasoning tasks. It supports one-shot, periodic, or event configurations, as well as timer+number-based task management for periodic tasks.

[1353] After receiving the task-related parameters configured by the base station and starting the task, the UE counts the number of times the task is executed (initial value = 0, +1 for each execution; or initial value = N (total number of times), -1 for each execution);

[1354] ●After the UE side executes the pre-configured number of times (N times), it stops / deletes the task.

[1355] 2. Collaborative task configuration

[1356] The main differences between the configuration of single-point tasks and collaborative tasks are shown in Figure 101. The main differences are:

[1357] 1) Number of executors: The number of executors in a single-point task is 1; the number of executors in a multi-point collaboration task is greater than or equal to 2;

[1358] 2) Simultaneous configuration success: In a single-point task, the task is successful if a single executor is successfully configured. However, in multi-point collaboration, since multiple executors need to be configured simultaneously, some executors may be configured successfully while others may not. The main issue to be addressed in this scenario is how to roll back or recover the configuration.

[1359] 3) Task reconfiguration: Single-point tasks can only be configured by the anchor point to the executor; in multi-point collaboration, in addition to the configuration / reconfiguration of the task anchor point to the executor, executor 1 can also reconfigure executor 2.

[1360] 4) Path configuration: There are multiple paths for collaborative information interaction between multiple executors in a collaborative task. The specific path to report through needs to be pre-configured to the executor.

[1361] Compared to configuring single-point AI tasks, configuring collaborative AI tasks involves the collaborative configuration of two or more executors, so more issues need to be considered, such as configuration loss, inter-executor configuration, and multi-path reporting.

[1362] 1) Question 1: Configuration Association

[1363] Compared to single-point AI task configuration, collaborative AI task configuration involves the coordinated configuration of two or more executors, and therefore requires additional consideration of configuration fallback in the event of configuration failure of one or more executors. To address this, the present application provides two solutions, as shown in Solution 1 and Solution 2 below.

[1364] Solution 1: Configure simultaneously (in no particular order)

[1365] Figure 102 is a schematic diagram of a collaborative AI task configuration scheme. As shown in the figure, in single-point AI task configuration, the task anchor only configures tasks for one executor. In collaborative AI task configuration, however, the task anchor can simultaneously configure tasks for multiple executors. This example uses two executors, executor 1 and executor 2, as an example. This means that the configuration of executor 2 is independent of the successful configuration of executor 1.

[1366] However, one problem with this solution is that if the configuration of executor 1 fails and the configuration of executor 2 succeeds, the configurations of executors 1 and 2 are out of sync, so they cannot collaborate on the task. In this case, additional signaling is required to roll back the configuration, for example, rolling back the configuration of the collaborative task that was previously successfully configured on executor 2 to the state before the configuration.

[1367] Solution 2: Configure simultaneously (in order)

[1368] Figure 103 is a schematic diagram of another collaborative AI task configuration scheme, in which the configuration of the collaborative task of the task anchor for executor 2 depends on whether the configuration of the task anchor for executor 1 has been successful; for example, if the task anchor successfully configures executor 1, it will continue to configure executor 2; otherwise, if the configuration of executor 1 fails, the task anchor will not configure the collaborative task for executor 2.

[1369] 2) Question 2: Inter-executor configuration

[1370] Taking two executors as an example, inter-executor configuration means that the task anchor does not directly configure executor 2, but executor 1 configures executor 2.

[1371] Figure 104 is a schematic diagram of inter-executor configuration. The specific steps are as follows:

[1372] Step 1: The configuration of the task anchor point for the executive 1 includes a parameter list. For example, the parameter list may include task id, {model id+model configuration}, etc., and optionally, carry the identification information or type information of the executive 2, such as Node id / UE id, Node type / UE type, etc.

[1373] Step 2: Execute the configuration of the first degree executive 2, including the following parameters:

[1374] - Option 1: (task id, {model id + model configuration});

[1375] - Option 2: (task id, {model id + model configuration}), (task id, model id).

[1376] Step 3: Executor 1 or Executor 2 feeds back the latest model to the task anchor, including parameters (task id, model id).

[1377] 3) Question 3: Multipath reporting

[1378] For CU / DU separation and CP / UP separation scenarios, the collaborators can be CP, UP, and DU respectively cooperating with the UE, and the reporting path is also configured to the UE by the task anchor point, such as configuring the reported layer name and node name.

[1379] When the task anchor assigns a task to Executor 1 / 2, you can specify the path for reporting the task results:

[1380] Opt1: Node name, such as CU-CP, CU-UP, DU

[1381] Opt2: Layer name, such as TRS layer, TRC layer, T-SDAP layer, etc.

[1382] Opt3: Node name and layer name

[1383] Figure 105 is a schematic diagram of multi-path reporting of collaborative AI tasks.

[1384] When executor 2 reports the task execution result, considering the difficulty of enhancing the TRS CE / T-SDAP Control PDU, it may not be reported directly to executor 1. Instead, it may be reported to other network elements (such as the task anchor point). In this case, it needs to be transparently or non-transparently forwarded to executor 1 and carry one or more of the following parameters:

[1385] Task id, result (intermediate output, gradient information, etc.) or UE identifier.

[1386] The information reporting path configuration for collaborative tasks can be the configuration of the task anchor to the executor, or the configuration of the executor to other executors (for example, the configuration of executor 1 to executor 2).

[1387] For scenarios that require forwarding (for example, the UE in the above scenario has different collaborative tasks with the CU-CP, CU-UP, and DU at the same time, and needs to report different collaborative information to the above different nodes; and the reporting channel configured by the task anchor / executor 1 for the executor 2 (UE in this case) is path 2 (for example, carrying collaborative information in the TRC layer), it can also be other paths, and the solution is similar). After the CU-CP parses the TRC signaling and obtains the corresponding collaborative information, it determines that it is not sent to itself and needs to be further forwarded (transparently or non-transparently) to other entities (such as DU, CU-UP and other network elements), then the CU-CP needs to perform the following additional operations:

[1388] Step 1: Determine whether this information is for you

[1389] Explicit method: For example, each collaboration information reported by the UE includes the identifier of other network elements or protocol layer identifiers:

[1390] Method 1: Network element identifier (such as CU-UP or DU, CU-CP, etc.);

[1391] Method 2: Protocol layer identification (e.g., TRS / PHY needs to be subsequently forwarded to DU, T-SDAP needs to be forwarded to CU-UP, and TRC needs to be processed by CU-CP);

[1392] Implicit method (task id): For example, if a task is configured, there can only be one reporting path configuration. In this way, the task id and the reporting path are mapped one-to-one. The corresponding forwarding entity can be further determined by the task id carried in the collaborative task information subsequently reported by the UE.

[1393] Step 2: If you need to forward it to other entities:

[1394] Transparent forwarding: The collaborative information is forwarded to the destination NE in its entirety without parsing its specific content.

[1395] Non-transparent forwarding: parse the specific content first, then reorganize the message and send it to the destination network element.

[1396] The following describes task bearers, specifically signaling bearers and data bearers.

[1397] 12.3.2 Task Carrying

[1398] 12.3.2.1 Data Carrier

[1399] Figure 106 shows an example of an interactive scenario for task information, for example:

[1400] Scenario 1: Computational / data (serial) tasks, centralized business flow processing;

[1401] Scenario 2: Computational / data (serial) tasks, distributed business flow processing;

[1402] Scenario 3: AI training task (FL), gradient reporting, and updated model delivery;

[1403] ●Scenario 4: AI reasoning task (joint reasoning), interactive intermediate output.

[1404] In order to transmit mission data in wireless communication networks, the following problems need to be solved:

[1405] 1) Question 1: Is TRB carried via signaling or data?

[1406] Figure 107 shows some possible ways to carry task data. As shown in Figure 107, one possible way (as shown in Opt1 in the figure) is to carry task data through SRB (the SRB carrying task data is represented as T-SRB in the figure), but this method may have the following problems:

[1407] 1) Limited number (3, not considering NSA and QoE);

[1408] 2) No differentiated QoS;

[1409] 3) Maximum limit (16*9k), cannot support very large models / data.

[1410] Another way (Opt2 in the figure) is to carry task data through DRB (the figure will carry task data

[1411] DRB is represented by T-DRB. This method may have the following problems:

[1412] ■Problem 1 - Non-transparent transmission: Currently, the base station transparent transmission mode is used, and a new non-transparent transmission mode is needed (i.e., base station analysis and termination are required);

[1413] ■Question 2 - QoS related issues:

[1414] For example, QoS indicators: computing, AI, perception and communication QoS indicators are different; task QoS and communication QoS use different QoS indicators;

[1415] Another example is the QoS mechanism: (RAN AI4NET scenario) without CN participation, the mechanism by which the CN generates QoS and transmits it to the RAN cannot be reused; without carrying IP information, the IP QoS flow mapping mechanism cannot be reused;

[1416] ■Problem 3-Protocol Stack:

[1417] New TRD (task resource data) - native AI layer;

[1418] Very large models / data: PDCP SDU (limited by 9k) cannot carry large models;

[1419] (Uu)SDAP+: QoS flow DRB mapping mechanism cannot be reused;

[1420] ■ Question 4 - Load bearing:

[1421] The protocol stack is different and requires a dedicated task bearer.

[1422] The solutions to issues 1 to 4 above regarding DRB-carrying task data are as follows:

[1423] (1) Solution 1 for Problem 1:

[1424] Added new logical channel (LCH) types, such as "DRB type";

[1425] ◆ “Task type” or “Data type” (traditional session data). That is, data is divided into session data and task data, and is identified by datatype and task type respectively.

[1426] (2) Solution 2 for Problem 2

[1427] The current status and solution of Problem 2 are shown in Figure 108.

[1428] Scenario 1: When the UE and DU perform FL, how do they transmit gradient information? One solution is to use T-SRBs for transmission and CU forwarding: the UE and CU interact, and the CU forwards the information to the DU, but this results in excessive latency. Another solution is to use DCI / UCI / MAC CE to carry task information, and the DU parses and processes the DCI / UCI / MAC CE. However, this approach has the disadvantages of small data volumes and inflexible data formats.

[1429] Scenario 2: How do you transmit gradient information when the UE and CU-CP are performing FL? One solution is to use a T-SRB bearer. The UE and CU-CP interact, and when the DU detects a T-SRB bearer, it directly forwards the information to the CU-CP. This has similar disadvantages to SRB, including size limitations and no QoS levels.

[1430] Scenario 3: The UE and CU-UP perform computation offloading. How can intermediate computation results be transmitted? One solution is to use T-DRB bearer, which can reuse the existing mechanism (UE interacts with DU, and DU detects a T-DRB bearer and directly forwards it to CU-CP). However, CU-UP can currently only transparently transmit T-DRBs and cannot parse and terminate them.

[1431] The solution 2 provided by this application to solve the above problem 2 is as follows:

[1432] Full-stack T-DRB

[1433] 1)DU protocol stack

[1434] Originally: Only PHY and TRS;

[1435] Now: PHY, TRS, and T-DRB (PHY / MAC / RLC / PDCP / SDAP / TRD).

[1436] 2) CU-CP protocol stack

[1437] Original: T-SRB;

[1438] Now: T-SRB and T-DRB.

[1439] 3) CU-UP protocol stack

[1440] Originally: Only T-DRB;

[1441] Now: No new additions.

[1442] DU forwarding policy:

[1443] Originally: DCI / UCI / MAC CE is for itself, SRB is for CU-CP, and DRB is for CU-UP;

[1444] Now: Based on different T-DRB numbers, it is decided whether to use it for itself (path 1), transfer it to the CU-CP, or transfer it to the CU-UP.

[1445] CU-CP forwarding policy:

[1446] Originally: T-DRB reception is not supported;

[1447] Now: Receive T-DRB and terminate unconditionally (path 2);

[1448] CU-UP forwarding policy:

[1449] Original: Receive DRB and transparently transmit to UPF;

[1450] Now: Identify which ones are for you (path 3) and which ones are for UPF (path 4) based on the T-DRB ID.

[1451] (3) Solution 3 for Problem 3

[1452] (Uu)SDAP+: The QoS flow to DRB mapping mechanism cannot be reused; a new task ID to DRB mapping is required.

[1453] AI layer:

[1454] Due to the PDCP SDU size limit (9k), in order to support the transmission of larger models, a segmentation / concatenation function needs to be added to the TRD layer;

[1455] TRD function: Added AI training / inference / model processing functions (compression / pruning / quantization / security, etc.);

[1456] ◆Data layer / computing layer / perception layer: supports data plane / computing plane, etc.

[1457] (4) Solution 4 for Problem 4

[1458] FIG109 is a schematic diagram of a solution for carrying task data through T-DRB.

[1459] The cNode / sNode configures different DRBs for the UE and maps task data to DRBs 1 and 2; and data data to DRBs 3 and 4.

[1460] After receiving uplink DRB data, the cNode / sNode distinguishes between DRB IDs 1 and 2 and processes and terminates them. DRB IDs 3 and 4 need to be forwarded to the CF-U.

[1461] 12.3.3 Task Control

[1462] 1. Wireless environment adaptation.

[1463] 6G networks support endogenous AI, deeply integrating connectivity, computing, algorithms, and data to open up multi-point collaborative channels and provide a complete operating environment for AI tasks. Unlike traditional network architectures, which are centered around session connections, 6G endogenous AI is task-centric, providing lifecycle management, scheduling, control, and execution of tasks.

[1464] Because wireless network environments are unstable and subject to real-time dynamic changes, such as user mobility, interference fluctuations, and service emergencies, they can affect ongoing tasks. Therefore, task management and control functions must be aware of changes in the task execution environment in real time to adjust task parameter configurations to ensure smooth task execution and guarantee task QoS.

[1465] Changes in the network environment can be divided into two categories according to whether the task topology relationship has changed.

[1466] The first category: The topology remains unchanged. Examples include changes in link QoS (users moving further away, interference increasing), computing power (a new app running on a terminal), etc., which do not change the topology. The second category: Topology changes, such as changes in terminal status (such as a terminal entering the inactive / idle state), terminal handover, and TE dropout.

[1467] The processing procedures for these two types of environmental changes are different and are described below.

[1468] ●Topological relationships change

[1469] Because the TS only sees subordinate tasks, it cannot assess the impact of topology changes on the overall workflow and, therefore, cannot make appropriate configuration adjustments. Instead, it needs to notify the task manager (TA), who then makes adjustments and restructures the overall task topology. For example, if a user switches to another station, if the TS simply migrates the task context to the new station, the latency in data exchange between the TE and the UE on the source station will increase, compromising the overall QoS of the service. In this case, the TA should assess the impact of the UE handover latency on the overall workflow and adjust the relevant task configuration to ensure the overall QoS of the service.

[1470] The core processing flow is shown in Figure 110, which is a schematic diagram of the real-time adjustment of the four elements of the task when the task environment changes.

[1471] Step 1: When TS senses that the task execution environment has changed and will affect the topology of the task, it needs to notify TA, which will make decisions, modify the task configuration, and update the topology.

[1472] Step 2: TS sends a "Task Execution Environment Change Notification" message to TA, carrying the task ID, change reason, etc. The change reason may include information elements (IEs) such as category, object, and magnitude.

[1473] Step 3: After receiving the change notification, the TA makes an adjustment decision, modifies the task configuration, and reorganizes the topology. The decision-making plan depends on the algorithm implementation. The final configuration modification can be roughly divided into the following levels:

[1474] (1) TS changes. The task execution body remains unchanged, and the relevant task context is established on the new TS, and the new TS is updated to the task topology. For example, after the user switches to a new base station, the task context is established on the new base station TS;

[1475] (2) TE change. Abandoning the previous execution body of the task and switching to the new execution body requires moving all the intermediate execution processes such as data / model / configuration to the new TE. It may also be necessary to select a new TS corresponding to the new TE. If there is business interaction between multiple TEs of the task, the topological relationship between the TEs also needs to be updated.

[1476] (3) TA changes. If the topology relationship changes beyond the management domain of the current TA and enters a new TA management domain, it is necessary to re-establish a complete task execution environment under the new TA, which is equivalent to creating a new task.

[1477] Step 4: After the decision plan is made, the new configuration is distributed to the relevant network elements.

[1478] Here are a few specific examples to illustrate:

[1479] ●Case 1: Adjustment when the terminal enters the idle state

[1480] Figure 111 is a diagram of task data transmission for idle UEs. As shown in Figure 111, when the UE enters the idle state, the tasks previously deployed on the UE cannot be scheduled and controlled, nor can they interact with TS and TE. The task QoS cannot be guaranteed, and the task execution environment needs to be adjusted. The process is as follows:

[1481] Step 1: Based on the previously established task context, the TS where xNB1 is located recognizes that the UE is currently executing a related task, triggering the task context change process. The UE enters idle mode and determines that this is a task topology change, requiring notification to the TA.

[1482] Step 2: xNB1 sends a task environment change notification to the TA, including the task ID, change reason, etc. For example, the change reason includes: category = UE IDLE, object = UE ID.

[1483] Step 3: After receiving the notification, the TA identifies its role in the overall task based on the UE ID and decides on an adjustment plan. As mentioned above, the decision-making plan is a specific algorithm implementation. Here, as an example, the TA pages the corresponding UE, establishes the UE task context on the new base station xNB2, and updates the topology.

[1484] Step 4: The TA triggers the core network to page the UE and confirm that the UE is newly connected to base station xNB2

[1485] Step 5: Configuration is delivered, UE task context is created on TS@xNB2, and the topology is updated. TS@xNB2 represents the task scheduler on xNB2. This description will not be repeated in the following embodiments.

[1486] In the above TA decision example, step 4 requires adding interactive messages between TA and CN, as well as adding task awareness functionality on CN. As shown in Figure 112, Figure 112 is a schematic diagram of task data transmission when a task is completed.

[1487] The RAN (specifically, the TA) triggers a paging request to the core network. The paging reason needs to add a new category, task. The core network's paging process can reuse the existing paging process, but after the page is received, a task awareness function needs to be added. After the UE accesses the new base station, the CN notifies the TA of the new base station information.

[1488] ●Case 2: Adjustment after terminal switching

[1489] During task execution, if a UE switches to another base station, the original base station will no longer be able to schedule and control the UE's task, and the task QoS cannot be guaranteed. Therefore, the task execution environment needs to be adjusted. Figure 113 shows the task adjustment process when the terminal performs a handover.

[1490] Step 1: After the UE switches, the TS on xNB1 identifies that the UE has related tasks in progress through the previously created task context, triggering the task processing flow. When the UE switches, it determines that the task topology relationship has changed and needs to notify the TA.

[1491] Step 2: xNB1 sends a task environment change notification to the TA, including the task ID, change reason, etc. As an example, the change reason includes: category = UE HO, object = UE ID.

[1492] Step 3: After receiving the notification, TA identifies the link in the entire task based on the UE ID and decides on the adjustment plan. As an example, the adjustment plan can be to keep the base station TE unchanged, establish the context of the UE task in the new base station xNB2, and update the topology relationship.

[1493] Step 4: Configure and deliver, create a UE task context on TS@xNB2, and update the topology.

[1494] 2. Real-time collaboration of the four elements.

[1495] Figure 114 is a schematic diagram of real-time collaboration of the four elements.

[1496] Real-time coordination of the four elements of a task refers to adjusting other related elements at the task level, as the environment or the state of a certain element changes, in order to achieve better performance or energy conservation, for example:

[1497] Connection → Algorithm (i.e., adjusting the algorithm based on changes in connection status): The UE and base station perform joint reasoning, and the base station adjusts the UE-side model:

[1498] ■UE battery level / UE CPU load, for example, when the battery level is low or the load is high, the split point is adjusted forward;

[1499] ■Connection status, for example, when bandwidth is low, adjust the split point to a position in the middle with less output;

[1500] Model → Connection (i.e., adjusting connection resources based on model changes): UE and base station perform federated learning:

[1501] ■After the base station adjusts the UE model, different models or segmentation points have different gradient information sizes, and thus different air interface resources (SPS or GF) are allocated.

[1502] Data → Node (i.e., adjusting nodes based on data)

[1503] ■The base station selects UE reports based on the non-independent identically distribution (non-IID) principle.

[1504] 12.3.4 Mobility

[1505] Due to the mobility of terminals, task status updates are more complex, and the following issues need to be considered:

[1506] ●Question 1: For the old task of the UE in the source cell, after the UE moves and switches / resides in the target (new) cell, how is the computing context of the old task migrated, and whether the TA / TS is migrated to enable the continued execution of the old task.

[1507] ●Problem 2: After the UE moves to / reselects a target (new) cell, the configuration of a new task in the target (new) cell takes time. How can the UE obtain the configuration of the new task as early as possible and use it in advance?

[1508] In response to the above problems, this application proposes corresponding solutions, such as Solution 1 and Solution 2 below.

[1509] Solution 1 for Problem 1 above is shown in FIG115 , which is a schematic diagram of task context migration in a switching scenario. Specifically, Solution 1 is as follows:

[1510] ■The execution body of the old task (of the source cell) is switched / not switched along with the switching of the task anchor point:

[1511] Negotiation: Task progress information needs to be exchanged to decide whether to migrate the executor / task anchor, etc.

[1512] The source transfers the remaining computational capacity to the target, for example, computing power (task completion / remaining computational capacity), algorithms (AI models, data, etc.);

[1513] ■Target decision whether to switch execution bodies;

[1514] If a handover is performed: the UE computing context is transferred from the source base station to the target base station:

[1515] Training tasks: algorithm (learned model, unupdated gradient information), data (unlearned), etc.

[1516] Reasoning tasks: data (remaining inputs), algorithms (remaining models), etc.

[1517] ● Solution 2 for the above problem 2 is shown in Figure 116, which is a schematic diagram of early acquisition of neighboring cell task configuration in a UE mobility scenario. Specifically, Solution 2 is as follows:

[1518] ■New task configuration (of the target cell): To reduce configuration signaling overhead, new / old task configurations (such as computing power, algorithms, data, connections, etc.) need to be transmitted between stations; for connected UEs: perform handover; for idle UEs: perform reselection.

[1519] Optionally, for connected UEs, there are the following two solutions, which are illustrated below in conjunction with Figure 117.

[1520] Opt 1: To reduce the configuration overhead of the AI ​​task assigned to the UE by the target cell, the following process can be included:

[1521] Step 1: The source cell transfers its task configuration information to the target cell (the existing handover (HO) process can be reused, but the task configuration is carried along).

[1522] Step 2: The target cell performs delta configuration based on the configuration of the old task obtained (for example, if the task has 10 parameters in total, and the configuration of 9 parameters is the same in the configuration of the source cell and the target cell, the target cell only needs to send the different parameter to the UE);

[1523] Step 3: The target cell sends the delta configuration to the source cell (carrying the task configuration);

[1524] Step 4: The source cell transparently transmits the configuration of the target cell to the UE in the HO CMD (carrying the task configuration).

[1525] Opt2: In order to avoid carrying the task configuration in step 3 of the above-mentioned Opt1 solution, only the task configuration index can be carried in this step, thereby reducing the configuration overhead of the ground interface and the air interface; but at this time, the enhancement requires adding step 0 so that the index relationship of {task id, task configuration} can be carried in advance through the Xn setup message after the base station is started, as shown in Solution 2 in Figure 125.

[1526] For idle UEs, the following three solutions are provided (eg, option 1, option 2a, and option 2b).

[1527] Option 1: As shown in Figure 118, in order to enable the UE to quickly obtain the neighboring cell AI task configuration and apply it as soon as possible (compared to this solution, the UE needs to reselect and camp on the target cell and obtain the task configuration of the target cell by reading the SIB of the target cell; this solution can save the UE time in reading the target cell SIB), the following process is used:

[1528] Step 1: Start the message through the inter-station interface and obtain the task configuration information of the neighboring cell;

[1529] Step 2: The cell broadcasts the task configuration information of the neighboring cells through SIB;

[1530] Option 2a: As shown in Figure 119, each cell broadcasts its own area ID. UEs can assume that cells with the same area ID have the same task configuration.

[1531] Step 1: Obtain the task configuration information (including area ID) of the neighboring area through the inter-station interface;

[1532] Step 2: The cell broadcasts the task configuration information (including area ID) of the neighboring cell through SIB.

[1533] Optionally, if the area ID of the local cell is different from the area ID of the neighboring cell, more task configuration information is requested from the neighboring cell;

[1534] Step 3: The cell requests the neighboring cell’s AI model;

[1535] Step 4: Neighboring cell feedback;

[1536] Step 5: The cell broadcasts the neighboring cell model in the SIB.

[1537] Option 2b: As shown in Figure 120, exchange area ID and task configuration parameters through Xn setup (regardless of whether the area IDs of the two cells are the same)

[1538] Step 1: Obtain the task configuration information of the neighboring area (including area ID + task configuration parameters) through the inter-station interface;

[1539] Step 2: The cell broadcasts the task configuration information of the neighboring cell (including area ID + task configuration parameters (optional)) through the SIB. When the area ID of the cell is different from that of the neighboring cell, the area ID + task configuration parameters of the neighboring cell are broadcast at the same time. Otherwise, only the area ID of the neighboring cell is broadcast (because the task configuration parameters are the same as those of the cell).

[1540] 13. New feature of 6G - Connection+ (i.e. hyperconnectivity).

[1541] Fully decoupled network architecture, supporting:

[1542] ●Separation of control and data nodes

[1543] Applicable scenarios: minimalist carrier (carrier is only used for data transmission), extreme energy saving (dynamically turning on / off sNode), and extreme radio access technology (RAT) aggregation (cNode centrally controls LTE, NR, and 6G);

[1544] ● Uplink and downlink Node separation

[1545] Applicable scenarios: UL-only Node (increase uplink coverage / throughput, enable TDD heterogeneous ratio, enable full-duplex), heterogeneous networks;

[1546] ● Uplink and downlink spectrum separation

[1547] Applicable scenarios: Spectrum cloudification, separate management of uplink and downlink carriers;

[1548] ● Uplink and downlink RF separation

[1549] Applicable scenarios: Unified independent radio frequency (RF) management (optimized RF scheduling).

[1550] ●Separation of perception / AI control and execution

[1551] Applicable scenarios: cNode centralized AI management and control.

[1552] 13.1. Separation of Control and Data Nodes

[1553] Figure 121 shows the separation of control and data. As shown in the figure, the cNode provides connection control and is responsible for CP functions, including the main information block (MIB), system information block (SIB), synchronization signal and PBCH block (SSB), paging, and task resource control (TRC).

[1554] The sNode provides the data function of the connection. Specifically, the sNode provides the data transmission function. Physical layer control information, such as downlink control information (DCI) and uplink control information (UCI), can be carried by the sNode or the cNode, thereby realizing a minimalist data carrier.

[1555] Separating control and data nodes enables high-frequency, efficient transmission. Figure 122 shows a schematic diagram of low-frequency support for high-frequency transmission under this separation. As shown in Figure 122, low-frequency cNodes assist high-frequency sNodes, aiding in fast beam alignment at the high frequency and reducing beam scanning overhead and access latency.

[1556] The separation of control and data nodes can enable network energy conservation. The cNode dynamically shuts down and opens the sNode based on the number of connected users and user service needs, reducing network energy consumption while ensuring data services.

[1557] Separating control and data nodes enables extreme multi-RAT aggregation, such as 5G and 6G aggregation, as shown in Figure 123. cNodes can provide dynamic, standard-aware physical layer switching and aggregation. While terminals connect to a single TRC standard, cNodes can enable them to seamlessly support air interface switching or aggregation between two different standards.

[1558] The protocol stack for extreme multi-RAT aggregation is shown in Figure 124, which shows control and data node separation and multi-RAT aggregation (TRS layer offload). The multi-RAT protocol stack shares a single PDCP, RLC, and TRS layer. Unlike dual connectivity (DC) offloads traffic at the PDCP layer and carrier aggregation (CA) offloads traffic at the TRS layer, extreme aggregation offloads multiple RATs at the physical layer, enabling joint physical layer processing and thus enabling fast and efficient multi-RAT collaboration.

[1559] Figure 125 shows a network topology diagram with separate control and data nodes. As shown in Figure 125, control always comes from the cNode. Independent RRUs provide ultra-wide coverage, while the cNode performs centralized connection control and centrally handles functions such as interference coordination and resource allocation.

[1560] 13.2. Separation of Uplink and Downlink Nodes

[1561] The nodes for uplink and downlink access can be different. UL-only nodes can be deployed in the network. These nodes only have a receiving module and no transmitting module, for example, no power amplifier. UL-only nodes are low-cost and easy to deploy. Dense deployment of UL-only nodes can significantly improve network performance, including one or more of the following:

[1562] Improve uplink SNR, UL coverage and throughput;

[1563] Physical isolation of uplink and downlink enables heterogeneous TDD;

[1564] Uplink and downlink physical isolation enable full-duplex.

[1565] Traditional solutions for improving uplink coverage include heterogeneous TDD (TDD), where macro and small cell TDD ratios differ, or full-duplex technology. However, self-interference and cross-interference are major challenges for full-duplex and heterogeneous TDD. Deploying UL-only nodes can increase the distance between DL and UL RRHs, reducing the power of self-interference and thus reducing the implementation complexity of advanced receivers. Furthermore, UL RRHs can be brought closer to the UE, thereby increasing UL received power and reducing cross-interference with neighboring DL RRHs. Spatially separating DL and UL RRHs enables full-duplex or heterogeneous TDD.

[1566] Uplink and downlink node separation can also be applied to heterogeneous networks (HetNets), as shown in Figure 126, including the following scenarios:

[1567] 1) Low-frequency + high-frequency TRP, downlink access to the high-frequency TRP, uplink access to the low-frequency TRP (low-frequency UL or supplementary uplink (SUL));

[1568] 2) Macro+Pico TRP: When the UE is at the edge of the Pico cell coverage, it accesses the Pico cell for uplink and the macro cell for downlink.

[1569] Uplink and downlink nodes are separated. Key technologies include independent uplink and downlink node management, independent uplink and downlink power control, and independent uplink mobility management.

[1570] 13.3 Uplink and Downlink Spectrum Separation

[1571] 5G uses paired uplink and downlink spectrum management, or cell-based management. A cell can consist of paired uplink and downlink FDD spectrum, TDD spectrum, or TDD plus SUL spectrum. 6G uses independent uplink and downlink spectrum management, or UE-centric uplink and downlink carrier resource pool management. This allows for flexible selection of the optimal carrier from both the downlink and uplink carrier resource pools, ensuring the UE always has the primary carrier, optimal link at any time, zero handover latency, and resource sharing between carrier pools, providing optimal capacity balance and optimal edge coverage performance.

[1572] Uplink and downlink spectrum separation, including:

[1573] Flexible carrier switching: As shown in Figure 127, multi-carrier coordinated TDD ratio, multiple carriers are combined into one FDD spectrum, reducing transmission / feedback delay;

[1574] Flexible carrier transmission: As shown in Figure 128, for each uplink / downlink data transmission, the initial transmission is sent on a high frequency. If there is a retransmission, for example, if the initial transmission fails and a NACK is fed back, the retransmission is sent on a low frequency. Semi-static / dynamic switching between multiple carriers increases uplink transmission opportunities and improves coverage; low-frequency retransmissions assist high-frequency retransmissions, improving high-frequency robustness.

[1575] ● Collaborative carrier: As shown in Figure 129, dynamic data switching is performed between multiple carriers. Large data packets are scheduled for transmission at high frequencies, while small data packets or UEs that cannot be paired are scheduled for transmission at low frequencies, thereby improving high-frequency spectrum efficiency.

[1576] 13.4 Uplink and Downlink RF Separation

[1577] Uplink and downlink RF are managed independently. RF includes antennas, radio frequency channels, and other resources. UE RF can be flexibly scheduled by the base station as a resource, supporting:

[1578] ●Flexible indication of the number of antennas used for data transmission or reception: When a UE transmits data on a single carrier, the base station can instruct the UE how many antennas to use, enabling super uplink. Supports switching all transmit antennas to a single carrier.

[1579] ● Flexible indication of the number of antennas used for channel sounding: For SRS antenna selection, the base station instructs the UE on how many antennas and ports to use for SRS transmission on a single carrier. This allows all transmit antennas to be used for SRS transmission on a single carrier, enabling fast antenna selection.

[1580] ●Flexible instruction RF switching for carrier pool management: The base station instructs the UE to switch RF for measurement of another carrier, thereby maintaining the channel quality information of each carrier in the carrier pool.

[1581] ●Flexible indication of collaborative RF group: Utilizes RF collaboration between UEs to form multiple transmit and receive antennas and transmit and receive channels.

[1582] 13.5 Separation of Perception / AI Control and Execution

[1583] The AI ​​control unit (AICU) is the AI ​​management and control unit for one or more RANs or UEs. It serves as an AI training and computing center, using collected data as training input and providing trained models or parameters for communications or AI services. Deployed on a cNode, the AI ​​CU can perform operations without involving perception, or it can perform perception-assisted AI. For example, the AI ​​CU can use perception information as part or all of its AI training input dataset, thereby implementing a perception-based AI framework.

[1584] AI agent is used to assist the AI ​​control unit in AI operations. The AI ​​agent can focus on AI model execution and related transmission functions. The AI ​​agent is deployed on the sNode.

[1585] The sensing control unit (SCU) is the sensing management and control unit for one or more RANs or UEs. It serves as the perception computing and processing center, using collected sensor data as input to provide the measurement information required for communication or perception services. Perception can include positioning and other sensing functions, such as IoT and environmental sensing features.

[1586] A sensing agent can perform perception operations to provide perception and AI services. For example, it can perform measurements to collect data and provide perception information as part or all of its AI training input data set.

[1587] The AI ​​control unit and perception control unit on the cNode implement centralized AI and perception management, solving the problems of complex interactions and difficult coordination among multiple agents in distributed AI / perception architectures.

[1588] 14. New features of 6G - computing services.

[1589] 14.1 Driving Force

[1590] With technological innovations such as the internet, big data, cloud computing, artificial intelligence, and blockchain, various industries are facing more urgent demands for communications and computing. Communication networks, as pipelines connecting users and transmitting data, can be used to efficiently utilize diverse distributed computing resources, enabling perceptual computing. For example, edge computing deployed within communication networks can reduce end-to-end latency and improve the service experience, which has become a hot topic in the industry. Diverse computing resources and the convergence of communications and computing have become important technological trends in the industry.

[1591] In 6G networks, computing resources will be distributed across a wide range of infrastructure, including central clouds, edge clouds, network equipment, and even terminal devices. 6G CaaS leverages various network-based distributed computing resources to provide endogenous computing services on demand. This approach is particularly effective for devices with limited computing resources or power consumption, and for intelligent services with extreme performance requirements or high data security and privacy requirements. 6G Communication as a Service (CaaS) will enable the on-demand "flow" of various 6G distributed computing resources, breaking through the performance limitations of single-point computing and improving the overall efficiency of computing applications.

[1592] To realize 6G CaaS and better provide users with inclusive computing services, the 6G architecture must natively support integrated computing and convergence, enabling intelligent scheduling of ubiquitous computing resources across the network and deep collaboration with connectivity resources, enabling the 6G network to become a dual infrastructure for connectivity and computing. The goal of integrated computing and convergence in 6G networks is to achieve optimal efficiency of network and computing resources while meeting AI QoS requirements in dynamic and complex wireless environments. Currently, integrated computing and convergence in the industry generally take the form of external computing resources and internal computing resources. External computing resources, such as edge computing, jointly optimize the communication resources of network nodes and the computing resources of compute nodes through management plane functions. Internal computing resources utilize the network's inherent computing resources, enabling network nodes to possess not only control and forwarding capabilities but also computing power.

[1593] The deep integration of communications and computing is a key technical feature of AI native to 6G networks. AI services provided through traditional cloud AI require more effective fundamental safeguards for data security and privacy, and distributed computing resources and AI models require more efficient sharing to support the delivery of required AI services to users at a relatively low cost and with guaranteed service quality. The inherent AI capabilities of 6G networks, namely artificial intelligence-as-a-service (AIaaS) delivered through network AI, are expected to address these challenges and serve as a valuable complement to cloud AI in scenarios requiring extreme performance, high security, and privacy. In network AI scenarios, how to efficiently collaborate with communications and distributed computing resources to provide users with lower latency and jitter, higher overall efficiency, and guaranteed AI QoS remains an unresolved challenge. A key technical challenge is the convergence of communications and computing, achieving deeper, real-time collaboration between communications and computing to ensure the end-to-end ultra-low latency, high data security and privacy, and sustainable energy savings required by future new services in dynamic and complex wireless network environments.

[1594] 14.2. Calculation Surface Overview

[1595] Figure 130 is a schematic diagram of the computing plane. As shown in Figure 130, the computing plane includes a computing control section, a computing execution section, and a computing data transmission section (referred to as the computing transmission section). The computing control section includes computing execution control and computing connection control. The computing execution section refers to the process by which the computing execution function of a node (such as a RAN node or a UE node) uses computing resources allocated by computing control to execute computing tasks. The computing transmission section refers to the process by which computing execution functions of different nodes exchange computing data using computing connections, thereby enabling different nodes to collaborate to complete computing tasks.

[1596] Computing connection control perceives the status of computing connections in real time, controls connection resources and quality of computing connections, and supports terminal status perception and business continuity assurance under mobility; controls the computing connections required for transmitting computing data, such as supporting the establishment, modification, migration, reconstruction, and deletion of computing connections, and supports the allocation of connection resources.

[1597] Computational execution control allocates computing resources used by node computational execution functions, controls the amount of computational operations executed, controls computational quality, and supports terminal mobility. Computational resource control perceives the status of computing resources in real time and controls their deployment, such as adding, modifying, deleting, and releasing them. Computational quality control orchestrates computational operations and configures computational process parameters (such as computational accuracy, quantization accuracy, and sparsification) based on resource quantity, accuracy, and latency requirements. Computational execution control also supports terminal mobility, computational resource address management, access control for computing services, control of terminal computing resources, and computational resource management and control when multiple computing resources are aggregated.

[1598] Computing control functions are divided into core network domain (xCN) computing control and RAN domain computing control, depending on the technical domain they belong to. RAN domain computing control includes the TRC+ function for implementing computing radio bearers and managing and controlling computing bearers; computing resource control (CRC) functions for implementing and managing atomic computing tasks, including requesting, establishing, updating, and deleting tasks; and real-time scheduling of computing resources. It also provides real-time awareness of computing power status and reports overall computing power information to the xCN domain computing execution control function, facilitating its maintenance of a global computing power map.

[1599] On the one hand, in scenarios where multiple nodes collaborate to complete computing tasks, the quality of the computing connection and the quality of the computational execution will jointly determine the quality of the entire computing task, thus allowing for joint optimization. On the other hand, the fact that computing connections and communication connections share connection resources will exacerbate the dynamic nature of the connection resource state. The dynamically changing resource state will have a real-time impact on computing quality, requiring joint consideration. Furthermore, for mobile terminals executing computing tasks, their computing connection and computational execution control will be executed synchronously, and the state and quality targets of the computing connection and computing resources will both influence their switching decisions. Therefore, there is a need and possibility for the integration of computational execution control and computational connection control on the computing plane, namely, "comprehensive fusion control."

[1600] Inter-computing convergence supports mutual awareness and collaboration among computing services, achieving the rational allocation of computing resources and computing connection resources. For example, inter-computing convergence control can, through the computing resource control component, perceive in real time changes in computing resources required for radio bearer services due to user mobility and dynamic user environment changes, thereby adjusting computing resources in real time. Alternatively, through the computing connection control component, it can perceive the computing resource status in real time and dynamically adjust the user's connection bandwidth to continuously ensure the QoS of computing services. For example, the inter-computing convergence control function on the cNode / sNode can manage the computing connection between the terminal and the base station, as well as control computing access during cell handover or the addition of secondary cells.

[1601] 14.3 Key Technologies

[1602] 14.3.1 Computing Power Perception

[1603] Computing power awareness specifically refers to the 6G native AI network's need to perceive computing power resource information, such as computing power type, amount of computing power resources, and computing power resource usage status. This computing power awareness enables the perception of heterogeneous physical resources such as GPUs, CPUs, and field programmable gate arrays (FPGAs). Secondly, the 6G native AI network needs to understand the type and amount of computing power required by different algorithms, such as artificial intelligence (AI), machine learning, and neural networks, to achieve the appropriate scheduling of computing resources.

[1604] Optionally, the UE needs to report computing power capability and computing power status to the base station.

[1605] ●Capability reporting

[1606] Step 1: The base station transmits information for instructing the terminal to report computing power mode / method through SIB / TRC and other means, such as reporting type, reporting granularity and reporting path.

[1607] 1) Reporting type: CPU, GPU, NPU, FPGA, etc.; or storage, memory, power, etc., to avoid terminals whose computing power does not meet the base station's requirements from reporting terminal computing power, resulting in invalid reporting and wasted bandwidth resources;

[1608] 2) Reporting granularity: For example, 1 / 10 / 100 CPU scheduling granularity, 1 / 10 / 100MB storage and memory scheduling granularity, 1% / 5% / 10% power scheduling granularity, or a combination of these resource scheduling granularities, can prevent terminals with computing power capabilities lower than the base station scheduling granularity from reporting their computing power, thus reducing computing power reporting overhead;

[1609] 3) Reporting path: L1, L2, L3 signaling; the reporting path may also be a method predefined by the protocol, such as reporting in one or more of L1, L2, or L3 signaling.

[1610] Step 2: The terminal reports computing power based on the reporting mode / method. The terminal uses L1 / L2 / L3 signaling to report computing power according to the configured reporting granularity and reporting type.

[1611] 1) For example, L1 signaling, such as whether the random access preamble indicates whether the terminal includes computing power resources greater than the reporting type and reporting granularity broadcast by the network side (the network side broadcasts the grouping of random access preambles, the computing power capabilities included by the terminal using the preamble of group 0 are less than the reporting type and reporting granularity broadcast by the network side; the computing power capabilities included by the terminal using the preamble of group 1 are greater than or equal to the reporting type and reporting granularity broadcast by the network side).

[1612] 2) For example, in L2 signaling, the computing capacity TRS CE includes the maximum number of computing resource combinations supported by the terminal;

[1613] 3) For example, L3 signaling, UECapabilityInformation signaling includes: UE logic, parallel computing, neural network computing, dedicated computing power and other types of computing power capabilities UE storage capacity, power capacity information, the specific information of computing power may include frequency, number of cores, number of multiplication and addition calculations supported per second, number of point multiplications, number of convolutions, number of floating-point calculations, number of operations, or one or more of the maximum number of supported computing power resource combinations.

[1614] ●Hashrate status reporting

[1615] Step 1: The base station transmits information indicating the mode / method of terminal computing power reporting through SIB / TRC and other means.

[1616] 1) Resource combination identification information: computing power configuration ID, index, etc.

[1617] 2) The resource type corresponding to the resource combination identifier: CPU, GPU, NPU, FPGA, etc.; or storage, memory, power, etc.; or the resource corresponding to the resource combination can be one or more of the above types.

[1618] 3) Resource size corresponding to the resource combination identifier: The computing power resources include the number of computing power type scheduling granularities, such as 1 / 10 / 100 CPU scheduling granularity, 1 / 10 / 100MB storage and memory scheduling granularity, and 1% / 5% / 10% power scheduling granularity;

[1619] 4) Resource combination status repo...

Claims

1. A radio access network RAN ​​architecture, characterized in that: Deployed in the radio access network RAN, including cluster control nodes and business service nodes; The cluster control node is used to provide a regional centralized coordination function of a plurality of the business service nodes, and a coordination function between the cluster control nodes across regions; The business service node is used to provide the functions of scheduling and executing tasks.

2. The RAN architecture according to claim 1, wherein: The cluster control node provides a control plane function of the connection on the air interface, and the business service node provides a user plane function of the connection on the air interface; or, The cluster control node does not provide a connection function on the air interface, and the business service node provides a control plane function and a user plane function of the connection on the air interface.

3. The RAN architecture according to claim 1 or 2, characterized in that: The RAN architecture is based on a non-service based architecture (SBA); The non-SBA based architecture includes: The cluster control node and the business service node are connected to each other via a Y1 interface; The cluster control node and other cluster control nodes are connected to each other via a Y2 interface; The business service nodes are interconnected via Y3 interfaces.

4. The RAN architecture according to any one of claims 1 to 3, characterized in that: The cluster control node is connected to the core network via one or more of the following interfaces: Connecting with the task control function TCF and the task processing function TPF of the core network via the T2 interface; Connecting to the network access function NAF of the core network via a T3 interface; The connection function control plane CF-C of the core network is connected via the T4 interface.

5. The RAN architecture according to any one of claims 1 to 4, characterized in that: The business service node is connected to the core network via one or more of the following interfaces: Connecting to the network access function NAF of the core network via a T5 interface; Connecting to the core network's connection function control plane CF-C via a T6 interface; The connection function user plane CF-U is connected to the core network through the T7 interface.

6. The RAN architecture according to claim 1 or 2, characterized in that: The RAN architecture is an SBA-based architecture; The SBA-based architecture includes: The cluster control node provides a first serviced interface (Sc); The business service node provides a second service interface (Ss); The first service-oriented interface and the second service-oriented interface are connected to a service bus of the RAN.

7. The RAN architecture according to any one of claims 3 to 5, characterized in that: The RAN architecture includes a connection architecture of one of the following: A first connection architecture, in which the control plane CP and the user plane UP of the air interface of the first connection architecture are separated, the cluster control node has a CP function of the connection, and the business service node has a UP function of the connection; or The second connection architecture, the CP and UP of the air interface of the second connection architecture are not separated, and the cluster control node does not provide The business service node provides the CP function and UP function of the connection.

8. The RAN architecture according to claim 6, wherein: The RAN architecture includes a third connection architecture, and the CP and UP of the air interface of the third connection architecture are separated; The cluster control node provides the first service-based interface, the first service-based interface is used for calling a core network element to transmit control plane signaling of a connection, and the first service-based interface is also used for calling other cluster control nodes to provide a mobility signaling function; The business service node provides the second service-based interface, which is used for calling the core network network element to transmit user plane data. The second service-based interface is also used for calling other business service nodes to provide mobility data forwarding function, wherein data forwarding between the business service nodes is controlled by the cluster control node.

9. The RAN architecture according to claim 6, wherein: The RAN architecture includes a fourth connection architecture, and the CP and UP of the air interface of the fourth connection architecture are not separated; The business service node provides the second service-based interface, where the second service-based interface is used for calling a core network element to transmit control plane signaling and user plane data of the connection; The second service-oriented interface is also used for calling other business service nodes to provide mobility signaling interaction and data forwarding functions.

10. The RAN architecture according to any one of claims 3 to 5, characterized in that: The RAN architecture is a mission architecture for a first function, wherein the first function includes one or more of computing, data, intelligence, and trust; The task architecture includes: The cluster control node is used to provide a control plane function and a data processing function of the first function; The business service node is used to provide part of the control plane function and the user plane function of the first function, and the user plane function includes task scheduling TS and task execution TE; Among them, the cluster control node and the business service node manage tasks through the Y1 interface, the cluster control nodes negotiate tasks through the Y2 interface, the cluster control node and the core network element negotiate tasks between network domains through the T2 interface, and the business service nodes perform task signaling or task data interaction between TEs through the Y3 interface.

11. The RAN architecture according to claim 6, wherein: The RAN architecture is a mission architecture for a first function, wherein the first function includes one or more of computing, data, intelligence, and trust; The task architecture includes: The cluster control node provides the first service-oriented interface for the transmission of task negotiation signaling and task data across network domains; the first service-oriented interface is also used for calling other cluster control nodes for the transmission of task negotiation signaling and task data across regions; The business service node provides the second service-oriented interface for the cluster control node to interact with the business service node in task control signaling and for task data transmission; the second service-oriented interface is also used for calling other business service nodes for task data transmission between the business service nodes.

12. The RAN architecture according to any one of claims 3 to 5, characterized in that: The RAN architecture further includes a trusted engine TWE and a trusted device TWG, the cluster control node includes the TWE and the TWG, the business service node includes the TWG, The TWE is used to provide the network with global decision-making and management information of the trusted surface and to provide the TWG with Provides trusted policy input, activation and management of trusted services; The TWG is used to receive configuration and management of the TWE to execute trusted capabilities.

13. The RAN architecture according to claim 6, wherein: The RAN architecture further includes a trusted enabling function TEF and a trusted device function TGF, wherein the TEF and the TGF are independently mounted on a service bus of the RAN; The TEF is used to provide global decision-making and management information of the trusted surface for the network, and provide trusted policy input, activation and management of trusted services for the TGF; the TGF receives the configuration and management of the TEF to execute trusted capabilities; The TEF provides a third service-oriented interface (Se); The TGF provides a fourth service-oriented interface (Sg); The third service-oriented interface and the fourth service-oriented interface both provide one or more of the following functions: Trusted service invocation, trusted information subscription, and trusted function management.

14. The RAN architecture according to any one of claims 1 to 13, characterized in that: The RAN supports connectivity and a first function other than connectivity, wherein the first function includes one or more of computing, data, and intelligence; With respect to the relationship between the connection and the first function, the design of the air interface protocol stack adopts one of the following options: Option 1: The first function is integrated into the control plane of the connection and the user plane of the connection; Option 2: The first function is integrated into the control plane of the connection to form a fused control plane, the user plane of the connection is kept unchanged, and an independent task data plane for the first function is added; Option 3: adding a task control plane and a task data plane for the first function, and keeping the control plane and the user plane of the connection unchanged; Option 4: Add independent computing plane, data plane and intelligent plane for the first function, and keep the control plane and user plane of the connection unchanged.

15. The RAN architecture according to any one of claims 3 to 5, characterized in that: The Y1 interface includes a Y1 user plane interface Y1-U and a Y1 control plane interface Y1-C; The Y2 interface includes a Y2 user plane interface Y2-U and a Y2 control plane interface Y1-C; The Y3 interface includes a Y3 user plane interface Y3-U and a Y3 control plane interface Y3-C; The T2 interface between the cluster control node and the core network includes a T2 user plane interface T2-U and a T2 control plane interface T2-C, wherein the T2-U is an interface between the cluster control node and the task processing function TPF of the core network, and is used for the transmission of task data, and the T2-C is an interface between the cluster control node and the task control function TCF of the core network, and is used for the transmission of task signaling; The T3 interface between the cluster control node and the core network includes a T3 control plane interface T3-C, where the T3-C is an interface between the cluster control node and the network access function NAF of the core network, and is used for transmission of connection signaling; The T4 interface between the cluster control node and the core network also includes a T4 control plane interface T4-C, which is used to transmit connection signaling or transparent transmission task signaling; The T5 interface between the business service node and the core network also includes a T5 control plane interface T5-C, which is used to transmit connection signaling or transparent transmission task signaling; The T6 interface between the business service node and the core network also includes a T6 control plane interface T6-C, which is used to transmit connection signaling or transparent transmission task signaling; The T7 interface between the business service node and the core network also includes a T7 user plane interface T7-U, which is used to transmit connection data or transparently transmit task data.

16. The RAN architecture according to any one of claims 1 to 13, characterized in that: The RAN supports connectivity and a first function other than connectivity, wherein the first function includes one or more of computing, data, and intelligence; The end-to-end protocol stack uses one of the following options: Option 1: The first function is integrated into the control plane of the connection and the user plane of the connection; Option 2: The first function is integrated into the control plane of the connection to form a fused control plane, the user plane of the connection is kept unchanged, and an independent task data plane for the first function is added; Option 3: adding a task control plane and a task data plane for the first function, and keeping the control plane and the user plane of the connection unchanged; Option 4: Add independent computing plane, data plane and intelligent plane for the first function, and keep the control plane and user plane of the connection unchanged.

17. The RAN architecture according to any one of claims 1 to 16, characterized in that: The protocol layers of the air interface include layer 2, and the layer 2 includes a sublayer supporting the first function.

18. The RAN architecture according to claim 17, wherein: The layer 2 comprises at least one of the following sub-layers: Task resource scheduling TRS sublayer; Task Packet Data Convergence Protocol T-PDCP sublayer; Task Service Data Adaptation Protocol T-SDAP sublayer; The TRS sublayer provides a logical channel for the RLC sublayer, the T-PDCP sublayer provides a radio bearer for the T-SDAP sublayer, and the T-SDAP provides a task of the core network and a quality of service QoS flow for the connection; Task resource data TRD sublayer, the TRD sublayer includes one or more of the following functions: artificial intelligence AI training, AI reasoning and AI model processing, protocol mode parsing and local collaboration parameters, collaborative mode process execution, and collaborative interaction information sending, receiving and processing; For the task PDU sublayer of the task data plane, the task PDU sublayer is used for data transmission of trusted services between the terminal and the RAN and the core network; For the RCSP sublayer of the computing plane, the functions of the RCSP sublayer include endogenous computing resource addressing, computing data routing forwarding, computing session identification and computing session priority; The DFCP sublayer for the independent data plane is used for control signaling and service data processing of the independent data plane; The ETP sublayer for the independent trusted plane is used for processing trusted data packets. The functions of the EIP sublayer also include encryption and decoding as well as integrity protection and integrity verification; The TBP layer for the independent trusted data plane is used for trusted service data transmission between the terminal and the RAN, the core network, or between the RAN and the core network.

19. The RAN architecture according to claim 17 or 18, wherein: The protocol layer of the air interface also includes layer 3, and layer 3 also includes a sublayer supporting the first function.

20. The RAN architecture according to any one of claims 1 to 19, characterized in that: The RAN architecture also provides trusted functions that are decoupled from other functions of the RAN.

21. The RAN architecture according to any one of claims 1 to 20, characterized in that: The RAN architecture provides a first function, and the service quality QoS mechanism of the RAN architecture includes a QoS mechanism for the first function, wherein the QoS mechanism for the first function includes a QoS mechanism on the network side and a QoS mechanism on the terminal side, and the first function includes one or more of computing, data, intelligence and trust.

22. A terminal device, characterized in that: Including control plane protocol stack and data plane protocol stack, The control plane protocol stack includes one of the following: The control plane protocol stack includes a first sublayer, the first sublayer supports transmission of control signaling of a first function, the first function including one or more of computing, data, intelligence and trust; or, The control plane protocol stack includes a first sublayer, the first sublayer supports transmission of control signaling of a first function and a routing function, the first function including one or more of computing, data, intelligence and trust; And, the data plane protocol stack of the first function supports any routing mechanism.

23. A communication device, characterized in that: The device comprises at least one processor coupled to at least one memory, wherein the at least one processor is used to execute a computer program or instruction stored in the at least one memory so that the communication device has the function of the RAN architecture as described in any one of claims 1 to 21, or the function of the terminal device as described in claim 22.

24. A chip, characterized in that: It includes a processor and a communication interface, the communication interface is used to receive information and / or data to be processed, and send the information and / or data to be processed to the processor, the processor is used to process the information and / or data to be processed, so that the communication device installed with the chip has the function of the RAN architecture as described in any one of claims 1 to 21, or the function of the terminal device as described in claim 22.

25. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and when the computer instructions are executed on a computer, the functions of the RAN architecture according to any one of claims 1 to 21 or the functions of the terminal device according to claim 22 are implemented.

26. A computer program product, characterized in that The computer program product comprises a computer program code, and when the computer program code runs on a computer, the functions of the RAN architecture according to any one of claims 1 to 21 or the functions of the terminal device according to claim 22 are implemented.

27. A wireless communication system, characterized in that: It comprises the radio access network RAN ​​architecture as claimed in any one of claims 1 to 21 and / or the terminal device as claimed in claim 22.

Images