Radio access network architecture and terminal apparatus

Abstract

Provided in the present application is a radio access network architecture. The architecture may provide newly added characteristics other than the conventional connection, such as computing, data, trustability, intelligence, etc. The newly added characteristics relate to cross-node task-based collaboration, which involves multi-dimensional resources (e.g. computing, data, algorithms, connections, etc.), such that a centralized inter-station coordination method can be provided, so as to provide interregional and intraregional task coordination. The radio access network architecture comprises cluster nodes and serving nodes, wherein the serving nodes provide task scheduling and execution functions, and the cluster nodes provide a region-level centralized collaboration function for the serving nodes and a collaboration function for cross-region cluster nodes. By means of the centralized inter-station coordination method, the efficiency of inter-station collaboration can be improved.

Description

Wireless access network architecture and terminal device TECHNICAL FIELD

[0001] Embodiments of the present application relate to the field of communications, and more particularly, to a radio access network (RAN) architecture and a terminal device. BACKGROUND

[0002] Existing radio access network (RAN) architectures, such as the fifth generation (5G) RAN architecture, are flat architectures. In such an architecture, information exchange and negotiation between one base station and neighboring base stations is performed through an Xn interface, i.e., distributed coordination, which is inefficient.

[0003] SUMMARY

[0004] The present application provides a radio access network architecture that can improve inter-station coordination efficiency. In addition, new services in addition to connection services can also be provided.

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

[0006] The cluster control node is configured to provide regional-level centralized coordination functions for a plurality of service serving nodes and coordination functions between the cluster control nodes across regions.

[0007] The service serving node is configured to provide scheduling and execution functions for tasks.

[0008] The technical solution provides a hierarchical RAN architecture, which is composed of a cluster control node (cNode) and a service serving node (sNode) to form an access network device. The cluster control node centrally manages and coordinates the service serving nodes, supports centralized inter-station coordination, and can improve inter-station coordination efficiency compared to flat RAN architectures.

[0009] Optionally, the radio access network architecture in the present application can also be described as a radio access network device, an access network device, a network device, a base station, an access network apparatus, etc.

[0010] In addition, the hierarchical RAN architecture can more efficiently provide connection services by constructing native integrated and fused multi-dimensional heterogeneous resource coordination capabilities. The native capabilities of the network refer to capabilities (or functions, attributes, etc.) obtained based on the inherent factors of the network. In addition to basic connection services, new services such as computing, data, intelligence, and trust can also be efficiently provided.

[0011] In the present application, the "region" refers to a geographical range (i.e., a geographical region), which can be large or small, and can be regular or irregular in shape. For example, a circle with a specific location as the center and a radius of 1 km, or the common coverage of one or more base stations, etc. The cNode can provide centralized coordination within and between regions.

[0012] Based on the concept of "region", the "cross-region" task coordination refers to the coordination of tasks within the geographical range corresponding to two or more regions. For example, two base stations belonging to different regions are adjacent to each other, and cross-region inter-station coordination is needed to reduce mutual interference.

[0013] In combination with the first aspect, in some implementation forms of the first aspect, the cluster control node provides a control plane function of the connection over the air interface, and the service service node provides a user plane function of the connection over the air interface; or,

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

[0015] Specifically, the present application provides a plurality of options for implementing the above-mentioned RAN architecture functions, such as connection architecture, task architecture, and trusted architecture, etc. According to different RAN architecture options, the functions provided by the cluster control node and the service service node are different, which will be described in detail in the description embodiments.

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

[0017] In combination with the first aspect, in some implementation forms of the first aspect, the RAN architecture is a non-service-based architecture SBA-based architecture;

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

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

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

[0021] The service service nodes are connected to each other through a Y3 interface.

[0022] It should be understood that the Y1 interface-Y3 interface is only one way of representing the interface, and the letter "Y" can be replaced by any other letter, and the number 1, 2, and 3 are only used to distinguish different interfaces. Alternatively, other ways can also be used to represent these interfaces. For example, the Y1 interface-Y3 interface can also be represented as a first interface, a second interface, and a third interface, respectively. The interface representation in this paper should not constitute any limitation on the RAN architecture provided in this application. Other interfaces in this paper are similar, such as the T2 interface-T9 interface, which will not be repeated below.

[0023] In this application, the non-SBA-based RAN architecture can fully consider the various deployment scenarios of the base station, such as not being deployed on the cloud, or not having the need for flexible expansion / shrinking capacity, etc.

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

[0025] connected to a task control function (TCF) and a task processing function (TPF) of the core network through a T2 interface;

[0026] connected to a network access function (NAF) of the core network through a T3 interface;

[0027] connected to a connection function control plane (CF-C) of the core network through a T4 interface.

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

[0029] connected to a network access function (NAF) of the core network through a T5 interface;

[0030] connected to a connection function control plane (CF-C) of the core network through a T6 interface;

[0031] connected to a connection function user plane (CF-U) of the core network through a T7 interface.

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

[0033] In combination with the first aspect, in some 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 service interface (S-c);

[0035] The service service node provides a second service interface (S-s);

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

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

[0038] Since the SBA architecture splits network functions (NFs), all the NFs can be accessed into the communication system through interfaces, therefore, the SBA-based RAN architecture has the following advantages, including but not limited to:

[0039] Flexible deployment: since the NFs are service interfaces, the functions of the NFs are independent, and can be deployed on different servers as needed, and can be independently deployed and maintained;

[0040] Simple expansion and contraction: expansion only needs to access the new NF into the system, without affecting the operation of the existing network, and the NF to be eliminated can be directly retired;

[0041] Easy function extension: if there is no change to the external service interface, the function and performance of the NF can be independently enhanced and evolved without relying on other NFs;

[0042] Good openness: the NFs use service interfaces, and the network functions provided by each NF can be called by any network element (or NF), which is easy to add new NFs, suitable for the development and opening of NFs;

[0043] Reduced maintenance cost: the NFs are isolated through APIs, which is easier to locate faults, and the coupling between the NFs is low;

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

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

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

[0047] The first connection architecture has a control plane (CP) and a user plane (UP) separated in an air interface, the cluster control node has a connected CP function, and the service service node has a connected UP function; or

[0048] The second connection architecture has a CP and a UP not separated in an air interface, the cluster control node does not provide a connected function, and the service service node provides a connected CP function and a UP function.

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

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

[0051] The cluster control node provides the first service interface, the first service interface is used for calling of a core network element to transmit connected control plane signaling, and the first service interface is also used for calling of other cluster control nodes to provide mobility signaling functions;

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

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

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

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

[0056] Optionally, the "core network element" in the present disclosure can also be referred to as a network element of a core network, and the network element can also be represented as a node, a function, a network function, a device, etc., without limitation.

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

[0058] With reference to the first aspect, in some implementation manners of the first aspect, the RAN architecture is a task architecture for the first function, the first function including 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 service service node is configured to provide a partial control plane function and a user plane function of the first function, the user plane function including a task scheduling (TS) and a task execution (TE).

[0062] The cluster control node and the service service node perform management of tasks through the Y1 interface, the cluster control nodes perform negotiation of tasks through the Y2 interface, the cluster control node and the core network element perform negotiation of tasks between network domains through the T2 interface, and the service service nodes perform interaction of task signaling or task data between the TEs through the Y3 interface.

[0063] The network domain can be generally divided into an access network domain, a core network domain, and a network management domain.

[0064] In this implementation manner, the RAN architecture can not only efficiently provide basic connection services, but also provide new features such as computing, data, intelligence, and trust, which are collectively referred to as the first function in the present application. The RAN architecture can be designed as a task architecture based on new features. Optionally, the task architecture can be designed as a non-SBA-based architecture.

[0065] With reference to the first aspect, in some implementation manners of the first aspect, the RAN architecture is a task architecture for the first function, the first function including one or more of computing, data, intelligence, and trust.

[0066] The task architecture includes:

[0067] The cluster control node provides the first service interface, which is used for transmission of task negotiation signaling and task data across network domains, and is also used for calling of other cluster control nodes for transmission of task negotiation signaling and task data across areas.

[0068] The business service node provides the second service interface for the task control signaling interaction and task data transmission of the cluster control node to the business service node; and the second service interface is also used for calling of other business service nodes, so as to perform task data transmission between the business service nodes.

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

[0070] In the above task architecture, including a non-SBA-based task architecture or an SBA-based task architecture, compared with the existing 5G RAN architecture, the deep fusion of connection, calculation, data and algorithm (four-element resources) can be supported natively at the architecture level, the separate functions and resources can be coordinated in multiple facilities, the AI, calculation and data services and the like can be more flexibly provided on demand for the network itself or applications, and the QoS can be guaranteed.

[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 configured to provide global decision and management information of a trusted surface for a network, and provide trusted policy input, activate and manage trusted services for the TWG.

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

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

[0075] In combination with the first aspect, in some 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, respectively.

[0076] The TEF is configured to provide global decision and management information of a trusted surface for a network, and provide trusted policy input, activate and manage trusted services for the TGF; and the TGF receives configuration and management of the TEF to perform trusted capabilities.

[0077] The TEF provides a third service interface (S-e);

[0078] The TGF provides a fourth service interface (S-g);

[0079] The third service interface and the fourth service interface each provide the following functions:

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

[0081] In this implementation, the RAN architecture can be designed as a trusted architecture based on a trusted plane, and specifically can be designed as an SBA-based architecture. The trusted architecture adds a trusted function compared to other RAN architectures, and the trusted function is decoupled from the service code, which can meet the needs of end-to-end network and application information and network space security, privacy protection, and security resilience.

[0082] In combination with the first aspect, in some implementations of the first aspect, the RAN supports a first function in addition to the connection, and the first function includes one or more of computing, data, and intelligence;

[0083] For 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 one: the first function is integrated into the control plane of the connection and the user plane of the connection;

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

[0086] Option three: a task control plane and a task data plane are added for the first function, and the control plane and the user plane of the connection are kept unchanged;

[0087] Option four: an independent computing plane, data plane, and intelligence plane are added for the first function, and the control plane and the user plane of the connection are kept unchanged.

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

[0089] With option 1, each function plane can share one protocol stack, which is simpler to implement; with option 2, the control plane of the new feature is integrated with the control plane of the connection, and the user plane of the new feature is designed independently; with option 3, the protocol stack of the new feature (such as computing, data, trust, and intelligence collaboration) is independent of the protocol stack of the connection; with option 4, the new feature is further subdivided, and independent function planes are added for different new features, such as independent computing planes, data planes, and intelligence planes. Each newly added independent function plane is more targeted, the design is more flexible, and the running efficiency is high.

[0090] For 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 function definition of each aspect tends to be independent from fusion.

[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 a task processing function TPF of the core network, used for transmission of task data, and the T2-C is an interface between the cluster control node and a task control function TCF of the core network, used for transmission of task signaling;

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

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

[0097] The T5 interface between the service service node and the core network further includes a T5 control plane interface T5-C, used for transmission of connection signaling or transparent task signaling;

[0098] The T6 interface between the service service node and the core network further includes a T6 control plane interface T6-C, used for transmission of connection signaling or transparent task signaling;

[0099] The T7 interface between the service service node and the core network further includes a T7 user plane interface T7-U, used for transmission of connection data or transparent task data.

[0100] In this implementation, by redesigning the network element interface (also known as the ground interface), the RAN architecture composed of cNode / sNode provides new services (such as computing, data, intelligence, AI, and trust, etc.).

[0101] With reference to the first aspect, in some implementations of the first aspect, the RAN supports a first function in addition to the connection, the first function including one or more of computing, data, and intelligence.

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

[0103] Option one: the first function is fused into the control plane of the connection and the user plane of the connection;

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

[0105] Option three: a task control plane and a task data plane are added for the first function, and the control plane and the user plane of the connection remain unchanged;

[0106] Option four: a separate computing plane, data plane, and intelligence plane are added for the first function, and the control plane and the user plane of the connection remain unchanged.

[0107] In this implementation, by redesigning the end-to-end protocol stack, a RAN architecture composed of cNode / sNode is supported to provide new features (e.g., computing, data, intelligence, AI, and trust, etc.). For the relationship between the new features and the connection, the above four design methods of the end-to-end protocol stack, from option one to option four, the function definition of each plane tends to be independent from fusion.

[0108] With reference to the first aspect, in some implementations of the first aspect, the protocol layers of the air interface include layer 2, and the layer 2 includes a sublayer supporting the first function.

[0109] In this implementation, layer 2 of the air interface protocol stack includes a sublayer supporting the first function. Specifically, a new function can be added to the existing function layer, or a sublayer implementing the new function is added, without limitation.

[0110] With reference to the first aspect, in some implementations of the first aspect, the layer 2 includes at least one of the following sublayers:

[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 of the RLC sublayer, the T-PDCP sublayer provides a radio bearer of the T-SDAP sublayer, and the T-SDAP provides a task of a core network and a quality of service (QoS) flow of a connected service.

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

[0116] A task PDU sublayer for a task data plane is used for data transmission of trusted services between a terminal and the RAN and the core network.

[0117] An RCSP sublayer for a computing plane includes functions such as inborn computing resource addressing, computing data routing and forwarding, computing session identification, and computing session priority.

[0118] A DFCP sublayer for an independent data plane is used for control signaling and service data processing of the independent data plane.

[0119] An ETP sublayer for an independent trusted plane is used for processing of trusted data packets, and the EIP sublayer further includes functions such as encryption and decoding, and integrity protection and integrity verification.

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

[0121] In this implementation, layer 2 can achieve 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, thereby supporting the RAN architecture composed of cNode / sNode to provide new services (for example, 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, and the trusted function is decoupled from other functions of the RAN.

[0125] In the implementation, in the face of the contradiction between the deep service of the security technology to the communication network and the continuous evolution of the security technology independent of the communication network, the application considers adopting a method of decoupling the security capability and the network capability to solve the contradiction. From security expansion to trust, the application considers adopting a method of decoupling the trust and the network capability to provide the possibility for continuous evolution of the trust capability and always advanced.

[0126] In combination with the first aspect, in some implementations of the first aspect, the RAN architecture provides a first function, and a 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 network-side QoS mechanism and a terminal-side QoS mechanism, and the first function includes one or more of computing, data, intelligence, and trust.

[0127] For the first function (for example, one or more new services of computing, data, intelligence, and trust) supported by the RAN architecture, a QoS mechanism for a task needs to be designed to guarantee a quality of service (QoS) evaluation for the task.

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

[0129] The control plane protocol stack includes a first sublayer, the first sublayer supporting 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 supporting 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.

[0131] And the data plane protocol stack of the first function supports a mechanism of arbitrary routing.

[0132] Based on the technical solution, the terminal device includes a control plane protocol stack and a data plane protocol stack supporting a first function (for example, new services of computing, data, intelligence, and trust), and a terminal-side protocol stack design scheme of the RAN architecture supporting the first function is provided.

[0133] In a third aspect, a method of transmitting a message is provided, applied to a wireless communication system, an access network device of the wireless communication system including a cluster control node and a service node, the method including:

[0134] The cluster control node receives an RRC establishment request message from a UE, the RRC establishment request message being 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 a network access function (NAF);

[0137] The NAF allocates a corresponding connection function control plane (CF-C) for the UE based on the initial UE message;

[0138] The UE and the CF-C transmit non-access stratum (NAS) messages.

[0139] Optionally, in an implementation form 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 a security configuration and an RRC reconfiguration for the UE;

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

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

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

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

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

[0147] The service traffic 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 including:

[0149] A connection function (CF) network element receives downlink data of a UE and buffers the downlink data;

[0150] The CF network element determines, according to a connection management (CM) state of the UE, whether 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 CM connected state, the CF network element establishes a user plane for the UE.

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

[0154] The UE initiates a traffic request procedure to the network after receiving the paging.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0168] Optionally, in an implementation form of the fifth aspect, in a case where the cluster control node determines to perform retransmission on the uplink data, the method further comprises:

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

[0170] The UE performs uplink data retransmission;

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

[0172] The service node sends the demodulated retransmission data to a connection function (CF) network element.

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

[0174] A task anchor (TA) receives a service workflow request;

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

[0176] The TA sends a task configuration distribution request of an application function (AF) to a connection function (CF) related to a UE;

[0177] The CF establishes a task connection with a corresponding target UE based on the task configuration distribution request;

[0178] A task control function (TCF) sends a task configuration request to a cluster control node.

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

[0180] The cluster control node decomposes the task based on the task configuration request of the TCF, and sends sub-tasks to UEs and / or service nodes corresponding to the task;

[0181] The UEs and / or the service nodes send feedback of the service workflow request to a request node of the service workflow through the CF based on whether the sub-tasks are executed.

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

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

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

[0185] If the second cluster control node accepts the task coordination, the second cluster control node sends decomposed sub-tasks to corresponding service nodes and / or UEs;

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

[0187] The second cluster control node receives an execution result of the subtask of the corresponding service node and / or UE, and aggregates the execution result 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 in any one of the third aspect to the seventh aspect can be executed by a corresponding node, or can also be executed by a chip or circuit having a corresponding function of the node, and the present application does not limit this, and the above description is described by taking 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., and the present application is described by taking the device or node as an example.

[0191] An eighth aspect provides a communication apparatus, including at least one processor, the at least one processor being coupled with at least one memory, the at least one processor being configured to execute a computer program or instructions stored in the at least one memory, so that the communication apparatus has the function of the wireless access network device in the first aspect or the terminal device in the second aspect, or so that the communication apparatus executes the method in any one of the third aspect to the seventh aspect or any implementation manner of any one of the third aspect to the seventh aspect.

[0192] A ninth aspect provides a chip, including a processor and a communication interface, the communication interface being configured to receive to-be-processed information and / or data and send the to-be-processed information and / or data to the processor, the processor being configured to process the to-be-processed information and / or data, so that a communication apparatus in which the chip is installed has the function of the wireless access network device in the first aspect or the terminal device in the second aspect, or so that the communication apparatus executes the method in any one of the third aspect to the seventh aspect or any implementation manner of any one of the third aspect to the seventh aspect.

[0193] A tenth aspect provides a computer readable storage medium, the computer readable storage medium storing computer instructions, when the computer instructions are executed on a computer, the function of the wireless access network device in the first aspect or the terminal device in the second aspect is realized, or the method in any one of the third aspect to the seventh aspect or any implementation manner of any one of the third aspect to the seventh aspect is realized.

[0194] In an eleventh aspect, a computer program product is provided, which comprises computer program codes, when the computer program codes are run on a computer, cause the functions of the wireless access network device according to the first aspect or the terminal device according to the second aspect to be implemented, or cause the method according to any one of the third aspect to the seventh aspect, or any implementation manner of any aspect to be implemented.

[0195] In a twelfth aspect, a wireless communication system is provided, which comprises the wireless access network device according to the first aspect. Optionally, the wireless communication system further comprises the terminal device according to the second aspect.

[0196] Optionally, in the third aspect to the eleventh aspect, the wireless access network device can comprise the sNode and / or the cNode in the embodiments of the present application.

[0197] The technical effects of the technical solutions of the third aspect to the twelfth aspect can be referred to the corresponding descriptions of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0198] FIG. 1 is a schematic diagram of a flattened RAN architecture.

[0199] FIG. 2 is a schematic diagram of a communication system architecture suitable for embodiments of the present application.

[0200] FIG. 3 is a schematic diagram of a RAN architecture provided by the present application.

[0201] FIG. 4 is a schematic diagram of a change in design paradigm of the RAN architecture provided by the present application.

[0202] FIG. 5 is a schematic diagram of a Hic collaboration scenario and a comparison of connection-triggered collaboration.

[0203] FIG. 6 is a schematic diagram of a general system architecture suitable for the present application.

[0204] FIG. 7 is a schematic diagram of a non-SBA RAN general architecture and interfaces.

[0205] FIG. 8 is a schematic diagram of an SBA RAN general architecture and interfaces.

[0206] FIG. 9 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] FIG. 11 is a schematic diagram of data transmission of a UE under a non-SBA connection architecture.

[0209] FIG. 12 is a schematic diagram of inter-station negotiation under a non-SBA connection architecture.

[0210] Figure 13 is a schematic diagram of inter-station negotiation for SBA-based connection architecture 1.

[0211] Figure 14 is a schematic diagram of inter-station negotiation for SBA-based connection architecture 2.

[0212] Figure 15 is a non-SBA task architecture.

[0213] Figure 16 is a schematic diagram of inter-network element task signaling and task data interaction.

[0214] Figure 17 is a schematic diagram of inter-network element task signaling and task data interaction for air interface.

[0215] Figure 18 is a schematic diagram of inter-network element task signaling and task data interaction for T-NAS.

[0216] Figure 19 is an SBA-based task architecture.

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

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

[0219] Figure 22 is a schematic diagram of SBA-based trusted architecture.

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

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

[0222] Figure 25 is two design ways of control plane protocol stack.

[0223] Figure 26 is a schematic diagram of data plane protocol stack design for routing layer.

[0224] Figure 27 is a schematic diagram of relationship between service characteristics for trusted function plane.

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

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

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

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

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

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

[0231] Figure 34 is a diagram of the independent compute plane protocol stack - compute plane data.

[0232] Figure 35 is a diagram of the independent data plane protocol stack - data plane signaling.

[0233] Figure 36 is a diagram of the independent data plane protocol stack - data plane data.

[0234] Figure 37 is a diagram of the independent trusted plane protocol stack - trusted plane signaling.

[0235] Figure 38 is a diagram of the independent trusted plane protocol stack - trusted plane data.

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

[0237] Figure 40 is the protocol stack for Y1-C and Y1-U.

[0238] Figure 41 is the protocol stack for Y2-C and Y2-U.

[0239] Figure 42 is the protocol stack for Y3-C and Y3-U.

[0240] Figure 43 is the protocol stack for T2-U and T2-C.

[0241] Figure 44 is the protocol stack for T3-C.

[0242] Figure 45 is the protocol stack for T4-C.

[0243] Figure 46 is the protocol stack for T5-C.

[0244] Figure 47 is the protocol stack for T6-C.

[0245] Figure 48 is the protocol stack for T7-U.

[0246] Figure 49 is the protocol stack for T8-C and T8-U.

[0247] Figure 50 is the protocol stack for T9-C and T9-U.

[0248] Figure 51 is the protocol stack for SC-C and SC-U.

[0249] Figure 52 is the protocol stack for SS-C and SS-U.

[0250] Figure 53 is the S-e protocol stack.

[0251] Figure 54 is the S-g protocol stack.

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

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

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

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

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

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

[0258] Figure 61 is a diagram of UE / CN inter-task - end-to-end user plane protocol stack (task architecture la / lb).

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

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

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

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

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

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

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

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

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

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

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

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

[0271] FIG. 74 is a schematic diagram of end-to-end trusted surface protocol stack - trusted surface signaling.

[0272] FIG. 75 is a schematic diagram of end-to-end trusted surface protocol stack - trusted surface data.

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

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

[0275] FIG. 78 is a schematic diagram of independent data surface - data flow.

[0276] FIG. 79 is a schematic diagram of independent trusted surface - data flow.

[0277] FIG. 80 is a schematic diagram of system information broadcast.

[0278] FIG. 81 is three schemes of task anchor point acquiring connection anchor point identification.

[0279] FIG. 82 is two schemes of connection anchor point acquiring task anchor point identification.

[0280] FIG. 83 is a schematic diagram of three ways of computing power allocation.

[0281] FIG. 84 is a schematic diagram of logical relationship of AI use case generation, AI service and AI task provided by the present application.

[0282] FIG. 85 is a three-layer closed loop centered on task.

[0283] FIG. 86 is a mapping relationship between QoAIS index dimensions and QoS on each resource dimension.

[0284] FIG. 87 is a schematic diagram of core features of task-centered architecture.

[0285] FIG. 88 is a schematic diagram of key technologies of task-centered.

[0286] FIG. 89 is a panoramic view of key technologies of task-centered.

[0287] FIG. 90 is the impact of task-centered framework on interfaces.

[0288] FIG. 91 is a logical architecture and function of task-centered.

[0289] FIG. 92 is a deployment method of network AI centered on task.

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

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

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

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

[0294] Figure 97 is an interface and protocol stack of task impact.

[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 of 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] Figure 103 is a schematic diagram of another collaborative task configuration scheme.

[0301] Figure 104 is a schematic diagram of inter-executor configuration.

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

[0303] Figure 106 is a schematic diagram of an interaction scenario of task information of collaborative AI tasks.

[0304] Figure 107 is a schematic diagram of some possible ways of carrying task data (T-SRB / T-DRB carrying task data).

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

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

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

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

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

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

[0311] FIG. 114 is a schematic diagram of real-time collaboration of task four elements.

[0312] FIG. 115 is a schematic diagram of task context migration in handover scenario.

[0313] FIG. 116 is a schematic diagram of early acquisition of neighbor task configuration in UE mobility scenario.

[0314] FIG. 117 is a schematic diagram of acquisition of neighbor AI model in UE mobility scenario.

[0315] FIG. 118 is a schematic diagram of broadcast of neighbor AI model.

[0316] FIG. 119 is another schematic diagram of broadcast of neighbor AI model.

[0317] FIG. 120 is another schematic diagram of broadcast of neighbor AI model.

[0318] FIG. 121 is a schematic diagram of control and data node separation.

[0319] FIG. 122 is a schematic diagram of low frequency assisting high frequency in control and data node separation.

[0320] FIG. 123 is a schematic diagram of multi-RAT aggregation in control and data node separation.

[0321] FIG. 124 is a schematic diagram of multi-RAT aggregation (TRS layer offloading) in control and data node separation.

[0322] FIG. 125 is a schematic diagram of network topology in control and data node separation.

[0323] FIG. 126 is a schematic diagram of uplink and downlink node separation.

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

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

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

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

[0328] FIG. 131 is an example of computing power state reporting.

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

[0330] FIG. 133 is a computing session protocol stack.

[0331] FIG. 134 is a schematic diagram of computing surface mobility.

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

[0333] Figure 136 is a schematic diagram of DA controller orchestration function modules forming a data pipeline.

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

[0335] Figure 138 is three link modes of a data plane carrying DDRB.

[0336] Figure 139 is three modes of data forwarding of a data plane.

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

[0338] Figure 141 is another example of a 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 a HiC collaboration scenario.

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

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

[0343] Figure 146 is a Hic deployment architecture.

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

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

[0346] Figure 149 is a schematic diagram of a network issuing a dropout descriptor.

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

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

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

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

[0351] Figure 154 is a schematic diagram of an E2E initial access flow.

[0352] Figure 155 is a schematic diagram of a network side initiated service request flow of a connection flow.

[0353] FIG. 156 is a schematic diagram of a data transceiving flow of a connection flow.

[0354] FIG. 157 is a schematic diagram of a task issuing flow.

[0355] FIG. 158 is another schematic diagram of a task issuing flow.

[0356] FIG. 159 is a schematic diagram of a communication device provided by the present application.

[0357] FIG. 160 is another schematic diagram of a communication device provided by the present application. DETAILED DESCRIPTION

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

[0359] First, the related technologies and concepts involved in the present application are briefly introduced.

[0360] Base station: refers to a wireless base station in a network, which is also a network element of a radio access network, responsible for all functions related to the air interface, including but not limited to the following functions:

[0361] (1) Wireless link maintenance function, maintaining the wireless link with the terminal, and responsible for the protocol conversion of wireless link data and IP data quality monitoring;

[0362] (2) Wireless resource management function, including establishment and release of wireless link, scheduling and allocation of wireless resources, etc.

[0363] (3) Part of the mobility management function, including configuring the terminal to measure, evaluating the terminal wireless link quality, deciding the terminal handover between cells, etc.

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

[0365] Operator or network management system: for example, a public land mobile network (PLMN), a network established and operated by the government or its approved operators for the purpose of providing land mobile communication services to the public, which can be a mobile operator, a China Unicom operator, or a China Telecom operator, etc.

[0366] Terminal device: also called user equipment (UE) or mobile station, which can be vehicle-mounted, portable or handheld, etc. The physical device and mobile user can be completely independent. All information related to the user can be stored in the subscriber identity module (SIM) card, which can be used on the mobile station. The terminal can complete the interaction of the air interface with the base station. The terminal can send and / or receive signals, such as transmitting UE and receiving UE.

[0367] Core network: simply put, the mobile network can be divided into three parts, base station subsystem, network subsystem and system support part (such as security management, etc.). The core network part is located in the network subsystem, and the main function of the core network is to connect the call request or data request from the air interface to different networks.

[0368] The main function of the core network is to provide user connection, user management and service bearing, and provide an interface to the external network as a bearing network. The establishment of user connection includes one or more functions such as mobility management (MM), calling management (CM), switching / routing, voice notification (combined with intelligent network services to complete the connection relationship to intelligent network peripherals). User management includes user description, quality of service (Qos), user accounting, virtual home environment (VHE) (providing a virtual home environment with the intelligent network platform), security (provided by the authentication center Corresponding security measures, including security management of mobile services and security processing of external network access). The bearing connection includes the public switched telephone network (PSTN) to the outside, the external circuit data network and the packet data network, the Internet, the Intranet, and the short message service (SMS) server, etc. The basic services that the core network can provide include mobile office, e-commerce, communication, entertainment services, travel and location-based services, telemetry - simple message transmission services (monitoring control), etc.

[0369] FIG. 1 is a schematic diagram of a 5G RAN architecture. As shown in FIG. 1, the 5G RAN architecture is a flattened architecture, and the base station and the adjacent base station exchange information and negotiate through the Xn interface. The inter-station interaction and negotiation is distributed, or in other words, the flattened architecture, and therefore, the inter-station negotiation is inefficient.

[0370] The technical solutions provided in the present application are described below.

[0371] The network element in the embodiments of the present application relates to a RAN node and a terminal. The RAN node can send signals and / or data to the terminal and can also receive signals and / or data from the terminal. The terminal can receive signals and / or data from the RAN node and can also send signals and / or data to the RAN node. The RAN node can specifically include the cluster control node and the service node in the embodiments below, as described in detail below.

[0372] The embodiments of the present application are applicable to both homogeneous network and heterogeneous network scenarios, and there is no limitation on the transmission points, which can be multi-point cooperative transmission between macro base stations and macro base stations, micro base stations and micro base stations, and macro base stations and micro base stations. The embodiments of the present application are applicable to both FDD / TDD systems. In addition, the embodiments of the present application are also applicable to low frequency scenarios (sub 6G), high frequency scenarios (6G and above), terahertz, optical communication, etc.

[0373] The embodiments of the present application can be applicable to 5G communication systems, 6G communication systems, or future evolved communication systems, or other communication systems, etc., and the present application does not limit this. The present application can not only be applicable to the communication between access network devices and terminals, but also be applicable to the communication between access network devices, the communication between terminals, the communication of Internet of Vehicles, Internet of Things, Industrial Internet, etc. The embodiments of the present application are exemplarily illustrated by the communication between terminals and access network devices.

[0374] FIG. 2 is a schematic architecture diagram of a communication system applicable to the embodiments of the present application. Exemplarily, the architecture can include a RAN, a terminal, a core network (CN), etc. In addition, an external network can also be included. The RAN refers to the RAN provided in the present application, or is also referred to as a RAN node, a RAN device or an access network device, etc., and can include a cluster control node and a service node, as described in detail below.

[0375] The architecture of the RAN provided in the present application is described in detail below.

[0376] The RAN provided by the present application needs to provide one or more of various new service capabilities (hereinafter collectively referred to as first functions) such as computing, data, trust, intelligence, and perception in addition to providing basic connection services, effectively enabling everything as a service (XaaS) of future communication systems. Among them, the connection service refers to a service corresponding to the connection function provided within and outside the network, for example, accessing the network, establishing a link, closing a link, controlling resource scheduling or allocation strategy, and quality of service (QoS). Therefore, the future communication system needs to build an integrated and fused multi-dimensional heterogeneous resource collaboration capability to efficiently provide new service capabilities, which will drive the reconstruction of the future radio access network (RAN) architecture.

[0377] To this end, the present application proposes a layered RAN architecture that can more efficiently provide traditional connection services and new services beyond connection, which can also be referred to as new features. Specifically, the RAN system includes a cluster node (cNode) and a service node (sNode), and the cNode and the sNode together constitute an access network device (or base station). The adoption of a layered architecture will bring the following benefits:

[0378] 1) For connection:

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

[0380] b) Between stations, centralized inter-station negotiation replaces distributed inter-station negotiation, and the collaboration efficiency is higher;

[0381] 2) For tasks: The cNode centrally manages and collaborates the computing, data, and connection resources of the sNode, and the collaboration range is wider and the efficiency is higher;

[0382] 3) For trust: The cNode centrally manages the trust of the sNode.

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

[0384] FIG. 3 is a schematic diagram of the RAN architecture provided by the present application. The main functions of the RAN architecture will be divided into the following three layers:

[0385] (1) RAN service layer: In addition to providing traditional connection services, it mainly provides computing services, data services, intelligent services, trusted services, and artificial intelligence (AI) services for CN network elements and terminal users within the network, and provides various new service capabilities to enrich the service capabilities of future network systems, such as the sixth generation (6G). th

[0386] (2) RAN function protocol layer: In order to support the provision of the above-mentioned XaaS services, the RAN function protocol layer needs to securely and efficiently cooperate with the distributed heterogeneous resources (such as computing, data, AI model, etc.) provided by the RAN infrastructure layer, and support the RAN service layer to provide these new service capabilities in the form of tasks. To this end, the RAN function protocol layer will cooperate with the traditional connection control plane and user plane through the addition of a new function plane, efficiently manage and control the multi-dimensional resources provided by the RAN infrastructure layer, thereby providing new service functions beyond connection, and providing QoS guarantee for these new service functions.

[0387] (3) RAN infrastructure layer: including multi-layer frequency band spectrum resources, distributed computing resources, storage resources, space-ground-sea full-scenario full-coverage access facilities, reconfigurable intelligent surfaces, sensing facilities, and various types of terminals.

[0388] The services of the RAN will realize the cooperation of multi-type resources and multi-node resources and the service QoS guarantee in the form of tasks, which will ultimately bring new dimensions to future wireless communication networks (from single dimension of connection service to new service dimension of encapsulating and providing connection, computing, data, intelligence, trust, algorithm, and sensing in the form of tasks), and realize the service level agreement (SLA) guarantee of various AI, sensing, computing, data, and other services, thereby further expanding the application scenarios of wireless communication networks.

[0389] The following describes the core impact of the scheme provided by the present application on the RAN architecture from the aspects of tasks, computing, data, intelligence, and trust.

[0390] 1) Task

[0391] ​In the task-centered network architecture, the orchestration function of network AI, the task control function, and the task resource layer are newly introduced. Among them, the task control function is to control the multi-node (such as UE, base station, core network element, etc.) and four-element resources (i.e. connection, calculation, data and algorithm) in the resource layer in the form of control layer signaling. Task-centered is a native network AI architecture, which makes it possible for AI tasks to be efficiently executed in the network.

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

[0393] Change 1: The management and control object in the wireless network system changes from "session" to "task";

[0394] Change 2: The management and control resource changes from connection resource to four-element resource of connection, calculation, data and algorithm;

[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 function (CF), nodes in the 6G infrastructure also provide additional computing function. In order to efficiently utilize communication resources and computing resources, it is necessary to real-time perceive the communication resource state and the computing resource state, and to cooperatively control the communication resources and the computing resources, so as to guarantee that the end-to-end QoS requirements of future new services such as ultra-low latency, high data security and privacy, and sustainability energy saving are met in a dynamic and complex wireless network environment. Deep integration of communication and computing can better realize various new capabilities (such as endogenous intelligence, ubiquitous perception, etc.) and new services (such as immersive extended reality (XR), digital twin, cloud universe, etc.) of the communication network (such as 6G network).

[0399] 3) Data

[0400] The existing 5G communication network is based on session construction, and the user plane is used to carry session data, which cannot meet the "on-path calculation" and "arbitrary topology" support required by 6G data carrying. The user plane cannot carry new data types of 6G network, therefore, the present application introduces a new data function.

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

[0402] • Raw data: raw data collected or gathered, input to applications such as AI;

[0403] • Data pre-processing: data cleaning, filtering, aggregation, fusion, and other pre-processing services;

[0404] • Data storage: centralized or distributed storage services can be provided on data agents (DA), data storage functions (DSF), and distributed ledge technology (DLT);

[0405] • Data privacy and security protection: end-to-end data privacy and security protection technology is provided;

[0406] • Data sharing / trading: trusted data sharing and trading;

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

[0408] • Data analysis: analysis and mining based on AI, machine learning (ML), big data, and other technologies, providing intelligent services;

[0409] • Data dictionary: wireless network feature data set.

[0410] Data functions are composed of data orchestration (DO), data control (DC), data agent (DA), trust anchor agent (TAA), and data storage function (DSF). The base station can deploy DC, DA, and TAA. DA can be deployed in the terminal.

[0411] 4) Heterarchical intelligent collaboration (HiC)

[0412] Heterarchical intelligent collaboration is to provide a set of endogenous distributed collaboration mechanisms for network elements and terminals at all levels in the network, and to make the intelligence in the network flow through collaboration, thereby improving the performance and efficiency of network AI.

[0413] Figure 5 is a schematic diagram of the cooperation scenario of Hic and the cooperation of connection trigger. The cooperation scenario of Hic presents the characteristics of large scale, large flow and high degree of freedom, while the cooperation based on connection in the traditional network is only small range cooperation, such as station handover, coordinated multiple points (CoMP) and the like, which can not support Hic, as shown in the left part of Figure 5. Therefore, the intelligent function is introduced in the present application, so as to establish the cooperation channel among the network elements and terminals at each level of the network, efficiently organize the intelligent cooperation among the network elements and terminals, and ensure the controllability of cooperation. The cooperation scenario of Hic is shown in the right part of Figure 5.

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

[0415] The cooperation is controllable, and the life cycle management of cooperation instance is performed, including the creation of cooperation instance, the allocation of instance identifier (ID), the start, deletion and update of cooperation.

[0416] The cooperation instruction set is provided, which can be combined into various cooperation patterns, so as to efficiently organize the cooperation process among the network elements and terminals.

[0417] The diversified intelligent representation is supported among the network elements, the intelligent knowledge is transmitted among the heterogeneous devices, the network is continuously learned and evolved, and the AI performance and efficiency of the network are continuously optimized and improved.

[0418] The establishment and maintenance of large-scale cooperation set are supported, and the cooperation instance can cross different RAN cluster control nodes, such as the cluster node described above. The network element has the ability to independently initiate, join and exit the cooperation instance.

[0419] The cooperation pattern is extensible, and various cooperation learning modes are flexibly supported.

[0420] 5) Trustworthy

[0421] Trustworthiness is the capability to meet the end-to-end network and application security, privacy protection, and security resilience. Multi-mode trust model is a major feature of the trustworthiness of future communication networks (e.g., 6G networks), including consensus mode supported by 6G blockchain technology, bridge mode in which the home network operator provides authentication and authorization to users, and endorsement mode based on third parties. Equilibrium trust is a basic principle of trustworthiness, that is, the trustworthiness is negotiated among the terminal side, access network, core network, and application side, and the optimal result is obtained by balancing, with or without reference to the centralized strategy recommendation of network intelligence. Trustworthiness as a service is the target effect of trustworthiness, which provides trustworthiness functions in the form of services, including blockchain services, remote attestation services, privacy protection services, etc.

[0422] The new features of the communication network described above, such as tasks, computing, data, multi-level intelligent collaboration, and trust, will be introduced in detail below.

[0423] 1. Overview of RAN overall architecture

[0424] The introduction of new features (or new capabilities) in the above RAN architecture is the main driving force for 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, a centralized coordination node needs to be introduced to provide task coordination within and between regions. Therefore, the RAN nodes in this application can be divided into:

[0425] cNode (cluster Node): Cluster control node, providing centralized coordination functions of multiple service nodes in the region, and coordination functions between cluster control nodes across regions; within the cluster (or the cNode can provide centralized coordination in the corresponding region), providing the anchor function of the task; on the air interface, it does not provide connection function or only provides control function of connection (the provided functions are different according to different design options of RAN architecture);

[0426] sNode (serving Node): Service node, providing task scheduling and execution functions; on the air interface, it provides control and / or data functions of connection (the provided functions are different according to different design options of RAN architecture).

[0427] Optionally, the cNode and sNode can also be referred to as network elements (network element, NE) respectively without limitation. If the functions of the cNode and sNode are opened (micro-service architecture is adopted inside the base station), the network functions inside the cNode and sNode can be further defined.

[0428] In 5G, the core network function has realized the SBA architecture, while the RAN is still based on the traditional non-service (non-SBA) architecture. In the scheme provided in the present application, there are two ways for the evolution of the RAN architecture: one is the traditional non-service based architecture (non-SBA), and the other is the service based architecture (SBA).

[0429] Hereinafter, the RAN architecture provided in the present application is illustrated by taking the 6G communication system as an example, for example, taking the 6G-RAN as an example.

[0430] 1) RAN architecture 1: 6G-RAN architecture based on non-SBA

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

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

[0433] Figure 7 is a schematic diagram of the overall architecture and interfaces of a non-SBA RAN. The interfaces between functions are as shown in Figure 7. The design decouples whether the user plane is service-based or not from whether the control plane is service-based or not. Thus, the CF-U can be directly connected to the BAS bus (i.e., the user plane is also service-based), or the CF-U is only connected to the CF-C and sNode x (i.e., the user plane is not service-based).

[0434] 2) RAN Architecture 2: SBA-based 6G RAN architecture

[0435] Figure 8 is a schematic diagram of the overall architecture and interfaces of an SBA RAN, which uses SBA interfaces, where the CN service bus and the RAN service bus can be a common bus, or two independent buses with an interconnection interface. The service-based interface provided by the cNode is temporarily referred to as S-c (hereinafter referred to as the first service-based interface), and the service-based interface provided by the sNode is temporarily referred to as S-s (hereinafter referred to as the second service-based interface). This diagram is given in the form of two independent buses.

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

[0437] a) Connection Architecture

[0438] i. non-SBA architecture

[0439] For a pure connection architecture, there are two ways as follows:

[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 performs the UE initial access process through the T3 interface with the NAF (UAM) and performs connection control signaling interaction through the T4 interface with the CF-C; the sNode communicates with the CF-U through the T7 interface and transmits UE data packets. The cNodes perform UE handover related signaling interaction through the Y2 interface and control the user data forwarding of the sNode through the Y1 interface. The sNodes perform user data forwarding through the Y3 interface, and the user plane direct interface can effectively reduce the forwarding delay.

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

[0444] CP / UP not separated over the air: over the air, cNode has no connection function, sNode has the control plane and user plane function of connection.

[0445] Figure 10 is a schematic diagram of the connection architecture 2 of non-SBA. The sNode interacts with the NAF through the T5 interface for UAM signaling, and interacts with the CF-C through the T6 interface for connection control signaling, and establishes data bearer with the CF-U through the T7 interface and transmits user data. The sNode interacts with the UE through the Y3 interface for UE handover signaling and data forwarding.

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

[0447] • Connection architecture 1 - CP / UP separated over the air:

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

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

[0450] • Connection architecture 2 - CP / UP not separated over the air:

[0451] The communication between UE and RAN, the control plane and the user plane are both directly communicated with the sNode;

[0452] The communication between UE and CN, the control plane and the user plane are both communicated with the CF through the sNode.

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

[0454] Figure 12 is a schematic diagram of inter-station negotiation under the connection architecture of non-SBA. Among them, way a: direct negotiation between cNodes, or unified negotiation between sNodes by cNode; way b: direct negotiation between sNodes, cNode does not participate.

[0455] Through the above combination, 1a, 1b, 2a, 2b connection architecture schemes can be formed; the specific functions of each scheme are not repeated.

[0456] ii. SBA architecture

[0457] • Connection architecture 1 - CP / UP separated over the air (i.e., connection architecture 1 based on SBA)

[0458] Figure 13 is a schematic diagram of inter-station negotiation for connection architecture 1 based on SBA. Under this architecture, cNode provides S-c interface for NAF, CF-C to invoke, for transmitting control signaling of connection. In addition, cNode also provides mobility signaling function through S-c interface for other invocations of cNode.

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

[0460] NAF / CF-C -> cNode

[0461] cNode -> cNode

[0462] In the present application, the symbol "->" represents that the network elements have a connection relationship, for example, NAF / CF-C -> cNode means that NAF / CF-C and cNode can be connected through the corresponding interface, and the following will not be repeated.

[0463] sNode provides S-s interface for CF-U to invoke, for transmitting user data. In addition, sNode also provides mobility data forwarding function through S-s interface for other invocations of sNode, so as to provide mobility data forwarding function. At the same time, data forwarding between sNodes needs to be controlled by 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 is a schematic diagram of inter-station negotiation for connection architecture 2 based on SBA. Under this architecture, sNode provides S-s interface for NAF, CF-C, CF-U to invoke, respectively transmitting control signaling and user data of connection. In addition, sNode also provides mobility signaling interaction, data forwarding through S-s interface for other invocations of sNode.

[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 S-c function provided by the cNode does not provide any connection-related services, but only task-related services.

[0474] b) Task architecture

[0475] i. Non-SBA architecture

[0476] Figure 15 is a non-SBA task architecture. In which the cNode is responsible for the control plane function of the new feature, such as task anchor (TA) and data processing function (for example, when the cNode has computing power, it can also deploy task scheduler (TS) and task executor (TE) to execute data processing tasks). The sNode is responsible for part of the control plane and user plane function of the new feature, such as TS and TE. Among them: the cNode and the sNode manage tasks through the Y1 interface; the cNode and the sNode negotiate tasks through the Y2 interface; the cNode and the TCF negotiate tasks through the T2 interface; the sNode and the sNode exchange task signaling or data through the Y3 interface.

[0477] Figure 16 is a schematic diagram of task signaling and task data exchange between network elements. Among them, the task control between network elements can be the control of the cNode to the sNode, the task negotiation between cNodes, and the task negotiation between the TCF and the cNode. For new feature data services, the cNode adds DC function to manage DA within the domain and the arrangement of DA; for new feature HiC, the cNode adds HicC function to manage collaboration instances, manage HicA, and configure collaboration patterns.

[0478] The data plane data of the RAN is transmitted to the core network by the cNode, which aggregates the data plane data of the sNode, and transmits data to the TPF through the T2-U interface, or by the sNode through the direct connection interface to the TPF. When the TCF is the TA, the task control of the cNode is through the direct connection interface (T2-C); the task data is exchanged between the TPF and the cNode (T2-U). When the cNode is the TA, the task control and task data exchange between the sNode are through the direct connection interface (Y1-C and Y1-U). When the cNode is the TA, the task signaling negotiation and task data exchange between adjacent cNodes are through the direct connection interface (Y2-C and Y2-U). Optionally, in the future, the sNode and the TPF can also be directly connected.

[0479] Figure 17 is a schematic diagram of task signaling and task data interaction of air interface. When cNode acts as TA, the task control interaction with UE is through task resource control (TRC) direct interface or through sNode relay; the task data interaction between UE and sNode is through task resource data (TRD) data interface, and the task data between UE and cNode is forwarded by sNode to cNode.

[0480] Figure 18 is a schematic diagram of task signaling and task data interaction of T-NAS. When TCF acts as TA, the task control signaling interaction with UE is through T-NAS interface, which has four modes (task architecture 1a, task architecture 1b, task architecture 2a and task architecture 2b below); and the task data interaction is forwarded by sNode to cNode, and then sent to TPF after being processed (optional) by cNode.

[0481] 1) Task architecture 1a - distributed T-NAS:

[0482] Based on connection architecture 1, TCF has T-NAS capability, and the task control of TCF to UE can be directly encapsulated into T-NAS message and delivered through cNode, and the task control of cNode to UE is directly delivered without sNode relay. At the same time, since CF-C also has connection T-NAS capability, TCF and CF-C both have distributed T-NAS capability at the same time.

[0483] 2) Task architecture 1b - distributed T-NAS:

[0484] Based on connection architecture 1, similar to task architecture 1a, the difference is that it is forwarded by sNode.

[0485] 3) Task architecture 2a - centralized T-NAS:

[0486] Based on connection architecture 1, TCF has no T-NAS capability, and all task control signaling is sent to CF-C, and then CF-C generates T-NAS message and delivers it to UE through cNode, or CF-C generates T-NAS message instead; at this time, only CF-C has T-NAS capability (i.e. T-NAS proxy), so it is called centralized T-NAS.

[0487] 4) Task architecture 2b - centralized T-NAS:

[0488] Based on connection architecture 2, similar to task architecture 2a, the difference is that it is forwarded by sNode.

[0489] ii. SBA architecture

[0490] For task architecture, the architecture after SBA is shown in FIG. 19.

[0491] FIG. 19 is a schematic diagram of the task architecture based on SBA. Among them, the cNode provides the S-c interface for the TCF to call, for the task negotiation signaling and task data transmission across the area; and through the S-c interface, the cNode calls, for the task negotiation signaling and task data transmission across the cNode.

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

[0493] • TCF / TPF -> cNode

[0494] • cNode -> cNode

[0495] The sNode provides the S-s interface for the cNode to call, for the task control signaling interaction and task data transmission of the sNode by the cNode; and through the S-s interface, the sNode is called, for the task data transmission between the 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 independent bus, but the sharing mode is more efficient.

[0500] c) Trusted architecture

[0501] i. non-SBA architecture

[0502] FIG. 20 is a schematic diagram of the ground interface of the trusted architecture based on non-SBA. Among them, for the trusted surface, the cNode adds a trustworthiness engine (TWE), which provides global decision and management information for the trusted surface of the network, and provides trust policy input for the trustworthiness gear (TWG) in a static or dynamic manner, activates and manages the trust service. The specific functions include but are not limited to one or more of the following:

[0503] Ledger anchoring function, including capability discovery of blockchain nodes, capability deployment, full life cycle management of chain creation / management / cancellation, state management of chain, on-chain strategy configuration, and node access authorization management of block chain (BC), etc.

[0504] Network global trust policy function, including intelligent generation, storage and notification of network global trust policy to other parties based on smart contract;

[0505] Remote attestation function, including storage of proof results, reference values and proof evidence, generation of remote proof challenge, and verification of proof evidence;

[0506] Privacy protection service function;

[0507] Third-party security protection function.

[0508] Both cNode and sNode add TWG to provide trusted surface enabling module for the network, accept TWE configuration and management, and execute trusted capabilities. Specific functions include but are not limited to one or more of the following:

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

[0510] Cryptographic capabilities, supporting encryption and decryption, signature based on symmetric key and asymmetric key, basic hash algorithm, and call 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 block chain capability, including client, micro node, light node, full node and other modes, with transaction generation, query, broadcast, verification, consensus, communication, smart contract, and storage;

[0513] Situation awareness capability, supporting traffic monitoring, asset monitoring, and log collection;

[0514] Remote attestation and verification capability, supporting remote attestation and verification based on trusted platform module (TPM) and software guard extensions (SGX) ;

[0515] Privacy protection capability, supporting generation and storage of user permissions, and call and configuration of various privacy protection algorithms.

[0516] FIG. 21 is a schematic diagram of the trusted signaling interaction between the UE, the AN and the CN under the non-SBA-based trusted architecture. Among them, the trusted signaling transmission mode of the UE and the trustworthiness enabler function (TEF) and the trustworthiness gear function (TGF) of the RAN to the CN is as follows:

[0517] TEF: TEF has two connection modes with cNode / sNode. One connection mode is that CN TEF can be directly connected with cNode / sNode, supporting T8, T9 interfaces in FIG. 20, the trusted signaling of RAN is directly sent to CN TEF / TGF, and the trusted signaling of UE is sent to CN TEF / TGF through cNode / sNode, without the forwarding of other core network elements; another connection mode is that CN TEF can not be connected with cNode / sNode, T8, T9 interfaces in FIG. 20 do not exist, and the trusted signaling of CN TEF and RAN / UE needs to be forwarded by CF, reusing T4, T6, T7 interfaces.

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

[0519] ii. SBA architecture

[0520] FIG. 22 is a schematic diagram of the SBA-based trusted architecture. As shown in the figure, in the SBA-based trusted architecture, TWE / TWG are in the form of network functions and are mounted on the serial bus interface (SBI) bus together with cNode / sNode to become TEF (Trustworthiness Engine Function) and TGF (Trustworthiness Gear Function). Among them, RAN TEF provides S-e interface (referred to as third service interface herein) externally, and RAN TGF provides S-g interface (referred to as fourth service interface herein) externally.

[0521] As described above, the RAN node in the present application includes cNode and sNode, and the function division of cNode and sNode is introduced as follows.

[0522] 2. Function division

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

[0524] FIG. 23 is a schematic diagram of the functional division of cNode and sNode.

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

[0526] - Resource negotiation, signaling / data bearer control, mobility management or measurement control across cells, etc.

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

[0528] - Task anchor (TA), with functions such as task decomposition, merging, etc., and management functions for TE resources thereunder, such as assigning each task to a corresponding TE node, and computing / data / model resources of each TE node for the task, etc.

[0529] - Computing anchor (CA), with functions such as computing task decomposition, merging, etc., and management functions for TE resources thereunder, such as assigning each task to a corresponding computing executor (CE) node, and computing resources of each CE node for the task.

[0530] - Data control (DC), with functions such as coarse-grained orchestration of data tasks, combining data pipelines in the local domain according to the capabilities of DA and data service requests, receiving capability reports of DA and implementing registration and revocation of DA;

[0531] - HicC, with functions such as collecting collaboration capabilities of each level of network element and terminal, receiving collaboration requests, creating collaboration instances, configuring collaboration patterns and QoS management, and optimizing during collaboration processes;

[0532] - Trusted engine (TWE), providing global decision and management information for the trusted surface of the network, providing trusted policy input for the trusted surface enabling module TWG in a static or dynamic manner, activating and managing trusted services. Specifically, it includes functions such as ledger anchoring, network global trusted policy, remote measurement, privacy protection, and third-party security protection;

[0533] - Trusted device (TWG), providing an enabling module for the trusted surface of the network, accepting configuration and management from TWE, and performing trusted capabilities. Specifically, it includes functions such as trusted policy negotiation and decision, cryptography, authorization verification, 6G blockchain, situational awareness, remote measurement and verification, privacy protection, etc.

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

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

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

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

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

[0539] - task execution (TE), with execution function of tasks, according to the resource control / scheduling of TA or TS, thereby executing specific tasks using corresponding resources;

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

[0541] - computing execution (CE), with execution function of computing tasks, according to the resource control / scheduling of CA or CS, thereby executing specific computing tasks using corresponding resources;

[0542] - data agent (DA), with execution function of data tasks, according to the control of DO or DC, thereby executing specific data tasks;

[0543] - HicA (Heterogeneous Intelligent Collaborative Agent), with execution function of intelligent collaboration, executing specific collaboration processes; including analysis and configuration of local collaboration parameters of collaboration Pattern, generation and processing of collaboration interaction information, training and inference of AI / ML;

[0544] - trusted device (TWG), see the functions of TWG above.

[0545] For connection, CN NAF has one or more of the following functions:

[0546] - authentication and authorization of initial access;

[0547] - selection function of initial connection.

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

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

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

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

[0552] For new features, the CN TCF has the following functions:

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

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

[0555] - The above TE, CE, DA, HicA, etc. functions.

[0556] For trust, the CN TEF has one or more of the following functions:

[0557] - The above TWE functions.

[0558] For trust, the CN TGF has one or more of the following functions:

[0559] - The above TWG functions.

[0560] The following introduces the air interface under the RAN architecture of the present application.

[0561] 3. Air interface.

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

[0563] Option 1: The control plane and user plane of the connection remain unchanged, and all new features (referred to herein as new features or 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, and the others remain unchanged;

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

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

[0567] For option 4, in which each new surface has its own control plane and user plane, is not drawn in FIG. 24. From option 1 to option 4, the definition of the function of each surface tends to be independent from fusion.

[0568] The following will be described in detail for each option.

[0569] Before introducing specific options, discuss various design ways of the protocol stack, as shown in FIG. 25.

[0570] FIG. 25 is a schematic diagram of two design ways of the control plane protocol stack of each functional surface, specifically:

[0571] • Way 1: The signaling transmission between the UE and the base station / core network (CN) is transmitted through the traditional RRC / NAS channel, and the control signaling of the new functional surface is supported by adding application messages on the existing channel;

[0572] • Way 2: The signaling transmission between the UE and the base station / CN is newly defined as a layer, and the layer signaling can be terminated at the base station or forwarded to the CN by the base station and terminated at the CN. Therefore, in addition to being used to transmit functional information, the new protocol layer is additionally used for routing purposes (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 a first function, or the first sublayer supports the transmission of control signaling of the first function and a routing function, the first function includes one or more of computing, data, intelligence, and trust. It should be understood that the first sublayer generally refers to a sublayer that supports the transmission of control signaling of the first function, and the specific implementation of the first sublayer is not limited in the present application.

[0574] FIG. 26 is a design way of the data plane protocol stack for the routing layer, as shown in FIG. 26, the data plane protocol stack of each functional surface needs to support the mechanism of arbitrary routing, and there are the following three ways for the routing layer:

[0575] • Way 1: Add routing information to the existing layer, such as adding routing identification information (such as source node identification, destination node identification, QoS information, etc.) to the existing T-PDCP layer of the air interface; when going up, the base station analyzes the information and terminates; when going down, the base station adds routing information at this layer. As shown in FIG. 28, the base station adds routing information at the T-PDCP layer.

[0576] • Way 2: Add a separate routing layer, which is more decoupled and clear in design (i.e., decoupling of service and routing); the base station routes and modifies routing information (optional) according to the information of the routing layer. In addition, the air interface routing layer of the UE and the RAN side and the routing layer between the RAN and the CN (TPF) can be defined independently.

[0577] • Way 3: Add routing information on the new service layer.

[0578] Figure 27 is a schematic diagram of the relationship between trusted functions and service characteristics.

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

[0580] • opt1: transmission through the control plane and bearer of the service (such as transmission of key information for service data encryption and decryption);

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

[0582] • opt3: independent transmission through the independent trusted control plane and signaling bearer (relative to service signaling);

[0583] • opt4: independent transmission through the independent trusted data plane and data bearer.

[0584] 2) Service data related data transmission (such as service data after encryption and integrity protection)

[0585] • opt1 - service plane bearer: for the data sending end, the service calls the function of the trusted module to obtain the encrypted data, and transmits the service data processed by the trusted through the service plane and bearer; the receiving end performs the same operation;

[0586] • opt2 - trusted plane bearer: for the data sending end, the service or application layer sends the original data to the trusted, and the trusted encrypts the data, and transmits the service data processed by the trusted through the trusted plane and bearer; the receiving end performs the same operation.

[0587] 3) (unrelated to service) trusted signaling / data transmission (trusted own service signaling and data, such as blockchain)

[0588] • opt1: fusion with the service plane and transmission (options 1 of 3.1, option 2 of 3.2, and option 3 of 3.3 below);

[0589] • opt2: independent trusted plane (as in option 4 in 3.4 below, further new trusted plane, including trusted control plane and trusted data plane).

[0590] 3.1, Option 1: Shared function plane

[0591] 1) Tasks

[0592] For different task architectures, the control plane design is different.

[0593] • Task architecture 1a / 1b (distributed T-NAS)

[0594] For RAN connection architecture 1 / 2 (CP / UP split, non-split) + task architecture 1a / 1b (distributed T-NAS), as shown in FIG. 28 and FIG. 29, the protocol stack of the control plane is shown. Specifically, FIG. 28 is the control plane protocol stack-task signaling (distributed T-NAS: RAN connection architecture 1), and FIG. 29 is the control plane protocol stack-task signaling (distributed T-NAS: RAN connection architecture 2).

[0595] The above behavior example, the user's connection data is forwarded to NAF / CF-C, and the task signaling is forwarded to TCF. Among them, for RAN connection architecture 1, it is forwarded by cNode; for RAN connection architecture 2, it is forwarded by sNode to cNode, and forwarded to TCF by cNode.

[0596] • Task architecture 2a / 2b (centralized T-NAS)

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

[0598] -T-PDCP, RLC and TRS sublayers (terminated at cNode or sNode on the network side) functions are described in detail in the following air interface-protocol layer section;

[0599] -TRC is terminated at cNode (RAN connection architecture 1) or sNode (RAN connection architecture 2) on the network side, and its functions are described in detail in section 6.3 below;

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

[0601] Among them, for RAN connection architecture 1, it is forwarded by cNode; for RAN connection architecture 2, it is forwarded by sNode.

[0602] When the cNode is the TA, the UE first sends the task data to the sNode, then the sNode sends it to the cNode, and finally the cNode processes the task data (e.g., merges and processes it with the sub-task data of other TEs), or the UE sends it directly to the sNode, which processes and terminates the data.

[0603] For task data, when the TCF is TA, the UE first sends the task data to the sNode, then the sNode sends it to the cNode, and the cNode processes it (e.g., 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 is separated, and RAN connection architecture 2 means CP / UP is not separated), Figure 31 shows the protocol stack of the user plane. The functions of TRD, T-SDAP, T-PDCP, RLC and TRS sublayers (terminating at the sNode on the network side) are described in detail below.

[0605] 2) Connection

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

[0607] ●T-NAS: Fallback to NAS;

[0608] ●TRC: Revert to RRC;

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

[0610] ●TRS: Fallback to MAC.

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

[0612] ●Task PDUs: Revert to Data PDUs;

[0613] ●TRD: Revert to transparent mode;

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

[0615] ●TRS: Fallback to MAC.

[0616] 3.2 Option 2: Integrate the control plane, user plane, and task data plane.

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

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

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

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

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

[0622] Add a new task control plane protocol stack and a task data plane protocol stack.

[0623] 3.4, Option 4: Connect control panel / user panel + independent function panel

[0624] 3.4.1 Independent Calculation Surface

[0625] The computing connection control system monitors the status of computing connections in real time, providing support for connection resource control, quality control, terminal status, and mobility. It controls the computing connections required for transmitting computing data, supporting processes such as connection establishment, modification, migration, reconstruction, and deletion, and also supports the allocation of connection resources. The transmission of computing connections between computing execution functions constitutes a computing wireless session.

[0626] Computation execution control allocates computing resources used by node computing execution functions, controls the amount of computing operations performed, controls computing quality, and supports terminal mobility. Computation resource control monitors the status of computing resources in real time and controls their allocation, such as adding, modifying, deleting, and releasing resources. Computation quality control orchestrates computing operations and configures relevant parameters (such as computing precision, quantization precision, and sparsity) based on resource quantity, accuracy, and latency requirements. Computation resource control (CRC) can be implemented 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 computation execution control of UE and base station computing functions.

[0627] Computing and communication services will belong to different service types. The transmission bearers for computing data and communication data (PDU sessions connecting terminals and data networks (DN), including data radio bearers between terminals and base stations, and GPRS tunneling protocol for the user plane (GTP-U) tunnels between base stations and CF-U (i.e., 6G UPF)) need to be distinguished. GPRS stands for General Packet Radio Service. Furthermore, due to different service models—namely, the potential for unique interaction modes between computing data and participating network nodes (such as model segmentation inference or training in terminal-network collaboration), and specific requirements for connection quality—there is a possibility of designing new bearer protocols for computing data transmission. Computing plane transmission involves introducing new bearer methods at the bearer layer, such as computing radio bearers (CRB) in the air interface and computing bearers (CB) in the 6G inter-site interface, and introducing a new radio computing session protocol (RCSP) at the session layer, referred to as RCSP session. RCSP enables end-to-end computation data exchange between computation execution functions, facilitating computational collaboration among multiple nodes. RCSP identifies different computation tasks through computation session identifiers and performs corresponding QoS control.

[0628] Figure 34 illustrates the protocol stack of the independent computing plane using RAN connectivity architecture 1 as an example. The signaling portion can reuse the task control plane protocol stack, while the data portion uses a new computing plane protocol stack (such as adding an RSCP protocol layer for transmitting computing data).

[0629] 3.4.2 Independent Data Surface

[0630] For each data service task, the DC orchestration selects the DA to execute the task and assigns the required functions (such as data acquisition, data preprocessing, or data analysis) to each DA involved.

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

[0632] Data plane service data messages support arbitrary topology and support 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 looks up 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 DA at the ingress, 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 identifier (DAID) to each DA according to the rules, and calculate the data pipe identity (DPID). The next hop DA is obtained based on DPID%DAID. The rules mentioned depend on the specific implementation 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 according to the function indication of the DC. After processing, 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 for the independent data plane is shown in Figure 35 (taking protocol stack design method 2 as an example), and the service message protocol stack for 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. Each network element at every level needs to have HiC-related logical functions and protocol interfaces to enable intelligent network elements within the network to collaborate with each other. The intelligence on network elements primarily serves the various functional characteristics of the network itself, and secondly, it supports AI tasks and models deployed by third parties within the network.

[0640] At the control level of intelligent collaboration, it is necessary to ensure the efficient organization of collaboration patterns. This requires querying and reporting the collaboration capabilities of each network element, issuing collaboration requests after determining the collaboration set, creating collaboration instances, and configuring the parameters under the collaboration pattern. In addition, it is also necessary to perform real-time configuration updates and optimizations for network changes and collaboration status changes during the collaboration process.

[0641] Intelligent representations of interactions between intelligent network elements include gradients, models, and knowledge. Unlike traditional mobile service data, these intelligent representation interactions are generated, transmitted, and terminated within the network. At the air interface, this primarily includes collaborative interactions between cNodes, sNodes, and the core network TPF and UE.

[0642] 3.4.4 Independent Trust Surface

[0643] The Trusted Surface executes function calls to TWE and TWG, providing trusted support for other surfaces such as the Connection Surface, Task Surface, Computation Surface, Data Surface, and Intelligence Surface, meeting their security requirements. Taking encryption and integrity protection as an example, after the Trusted Control Surface completes measurement and authentication, it generates NAS-like encryption keys, NAS-like integrity protection keys, T-PDCP encryption keys, and T-PDCP integrity protection keys, which are then distributed to other surfaces, which perform encryption and integrity protection.

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

[0645] Figure 37 is a schematic diagram of the independent trusted control plane protocol stack. The Trustworthiness UE-Core network protocol (TUCP) is mainly responsible for trusted signaling transmission between the UE and the core network; the Trustworthiness UE-RAN protocol (TURP) is mainly responsible for trusted signaling transmission between the UE and the access network; and the Encryption and Integrity Protection Protocol (EIP) is mainly responsible for encryption, decryption, and integrity protection of trusted data. The functions of TUCP and TURP are executed by TWE and TWG. Non-security-related functions of EIP are executed by other modules within the UE / sNode / cNode besides TWE and TWG. Security-related functions have two options:

[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, privacy protection identifiers, etc.), as well as Enabler functionality (such as encryption / decryption and integrity protection functions of Crypto Enabler, etc.).

[0647] ●Option 2: TWG provides TruA ​​functionality, allowing other modules within the UE / sNode / cNode, excluding TWE and TWG, to perform functions.

[0648] The independent trusted business plane executes the processing and transmission of trusted data, including the specific business processes of TWE and TWG after trusted establishment and configuration. Trusted data may include blockchain transaction / block synchronization data, situational awareness data, homomorphically encrypted ciphertext, computation results, Trusted Root management data, and keys. The trusted business plane protocol stack is shown in Figure 38. The EIP layer is mainly responsible for the encryption, decryption, and integrity protection of trusted data, while the Trustworthiness Bearer Protocol (TBP) is mainly responsible for packet processing of trusted data. The TBP protocol layer can determine the endpoint based on the packet header. All TBP functions are executed by TWE and TWG, and the EIP function is as described above.

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

[0650] 4. Network element interface.

[0651] Network element interfaces, also known as ground interfaces, are divided into control plane protocol stacks and user plane protocol stacks based on their uses.

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

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

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

[0655] Option 2: Protocol stack based on "GTP-U / QUIC / IP";

[0656] Option 3: Protocol stack based on "RDMA / IB transport / IB network";

[0657] Option 4: Protocol stack based on "GTP-U / SRv6";

[0658] Option 5: Protocol stack based on "GTP-U / model or data identifier".

[0659] The following section will provide a detailed introduction to the interfaces of the control plane and user plane, using Scheme 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 GTP-U is used on top of UDP / IP to carry the user plane PDU between the cNode and the sNode.

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

[0664] ii.Y2 Interface

[0665] The user plane interface and control plane interface of the Y2 interface are shown in Figure 41.

[0666] The Y2 user plane interface (Y2-U) is defined between cNodes. It is used to transmit task data or UE communication data (e.g., data forwarding when the UE switches between two cNodes).

[0667] Y2 is defined between cNode nodes using a control plane interface (Y2-C). It is used not only for transmitting connection-only signaling but also for transmitting task signaling.

[0668] iii.Y3 Interface

[0669] The user plane interface of the Y3 interface is shown in Figure 42.

[0670] The Y3 User Plane Interface (Y3-U) is defined between sNode nodes. It is used to transmit connection data (UE communication data) or task data (e.g., the context of a task in which an sNode participates is transferred to other sNodes).

[0671] Y3 is defined between sNode nodes using the control plane interface (Y3-C). It is used only for transmitting signaling for tasks or connections.

[0672] iv.T2 Interface

[0673] The user plane interface of the T2 interface is shown in Figure 43.

[0674] The T2 User Plane Interface (T2-U) is defined between the cNode and the TPF. It is used to transmit task data.

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

[0676] v.T3 Interface

[0677] T3 is defined between the cNode node and the NAF using the control plane interface (T3-C), 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 node and the CF-C, as shown in Figure 45. The T4-C is used to transmit connection signaling or transparent task signaling (T-NAS).

[0680] vii.T5 Interface

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

[0682] viii.T6 Interface

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

[0684] ix.T7 Interface

[0685] The T7 uses a control plane interface (T7-U) defined between the sNode and the CF-U, as shown in Figure 48, to transmit connection data or pass through task data.

[0686] xi.T8 Interface

[0687] The control plane interface and user plane interface of the T8 interface are shown in Figure 49.

[0688] The T8 control plane interface (T8-C) is defined between the cNode node and the TEF for transmitting trusted signaling.

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

[0690] xii.T9 Interface

[0691] The control plane interface and user plane interface of the T9 interface are shown in Figure 50.

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

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

[0694] 4.2 SBA Interface

[0695] iS-c Interface

[0696] Depending on the RAN connectivity architecture, the Sc interface provides different functions. For example, for RAN connectivity architecture 1 (i.e., CP / UP separated architecture), the cNode provides connection-related signaling functions; while for RAN connectivity architecture 2 (i.e., CP / UP not separated architecture), the cNode does not provide connection functions.

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

[0698] ii.Ss Interface

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

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

[0701] iii.Se Interface

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

[0703] - Trusted service invocation (including network global trusted policy service, blockchain service, remote proof service, etc.);

[0704] - Trusted information subscription (including capability information, network-wide trusted policies, blockchain capability information, etc.);

[0705] - Trusted Function Management (engine layer management).

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

[0707] iiii.Sg Interface

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

[0709] - Trusted service invocation (security capability information, authentication, authorization, blockchain, situational awareness, remote proof, 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 end-to-end protocol stack under the RAN architecture provided in this application is described below.

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

[0715] 5.1 Option 1: Shared Function Interface

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

[0717] 5.1.1 Task

[0718] The task interface involves four types of interfaces: UE and RAN task interface, UE and TCF task interface, RAN and CN task interface, and RAN and RAN task interface, which will be described below.

[0719] 1) Type 1: UE and RAN task interface

[0720] Different task architectures can be used for different connection architectures.

[0721] ●RAN Connectivity Architecture 1 - (Air Interface) CP / UP Separation

[0722] For the RAN connection architecture with 1-CP / UP separation, the task signaling and data between the UE and cNode (RAN acts as TA to control the UE to perform tasks) can be handled by two schemes: non-SBA and SBA for the end-to-end control plane protocol stack and user plane protocol stack.

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

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

[0725] ■ Data: UE<->sNode<->cNode, data communication between UE and cNode needs to be relayed through sNode.

[0726] If the SBA interface is used:

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

[0728] ●RAN Connectivity Architecture 2 - (Air Interface) CP / UP Not Separated

[0729] For RAN connection architecture 2-CP / UP not separated, UE and cNode task signaling and data (RAN as TA to control UE to perform tasks), there are two schemes for end-to-end control plane protocol stack and user plane protocol stack: 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 inter-task are shown in Figures 57 and 58, respectively:

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

[0732] ■ Data: UE<->sNode<->cNode, data communication between UE and cNode needs to be relayed through sNode.

[0733] If the SBA interface is used:

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

[0735] 2) Type 2: UE and TCF task interface

[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 execute tasks), for task architecture 1a / 1b (distributed T-NAS), there are two schemes for end-to-end control plane protocol stack and user plane protocol stack: non-SBA and SBA.

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

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

[0741] ■ Data: UE<->sNode<->cNode<->TCF. Communication between UE and TCF requires multiple nodes to be relayed through sNode and cNode.

[0742] If the SBA interface is used:

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

[0744] ●Task 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 schemes for end-to-end control plane protocol stack and user plane protocol stack: non-SBA and SBA.

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

[0747] ■ Signaling: UE<->cNode / (sNode+cNode)<->NAF / CF-C<->TCF. Signaling communication between UE and TCF needs to go through multiple nodes, including cNode / (sNode+cNode) and NAF / CF-C.

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

[0749] If the SBA interface is used:

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

[0751] 3) Type 3: RAN and TCF task interface

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

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

[0754] ■ Signaling: sNode<->cNode<->TCF. Signaling communication between sNode and TCF must be relayed through cNode. Signaling and data interaction between CN and RAN for Tasks can only be carried out between TCF and cNode (as peer TA / TS).

[0755] ■Data: sNode<->cNode<->TCF, data communication between sNode and TCF needs to be relayed through cNode;

[0756] The cNode further decomposes the TCF tasks to the sNode for execution (or to the UE for execution).

[0757] If the SBA interface is used:

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

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

[0760] cNode2, acting as a TA, requests nearby cNode1 (TA) to execute tasks. There are two schemes: non-SBA and SBA.

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

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

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

[0764] If the SBA interface is used:

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

[0766] 5.1.2 Connection

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

[0768] If a non-SBA interface is used:

[0769] ■ Signaling: UE<->cNode<->NAF / CF-C, signaling communication between UE and NAF / CF-C needs to be relayed through cNode;

[0770] ■Data: UE<->sNode<->CF-U, data communication between UE and CF-U needs to be relayed through sNode;

[0771] If the SBA interface is used:

[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 plane has been added.

[0778] Optionally, the connection control plane and the mission control plane can be merged, such as the merged control plane protocol stack in option 1.

[0779] 5.3, Option 3: Task Control / Data Surface

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

[0781] Add a new task control plane protocol stack and a task data plane protocol stack.

[0782] 5.4, ​​Option 4: Independent Functional Surface

[0783] Specifically, an independent functional plane refers to adding one or more of the following to the first function: a computational plane, a data plane, and an intelligent plane, 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 computation 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 by calling the basic functions of the RRC protocol to support computing connection control; computing execution control is implemented by CRC, which can be independent of RRC or integrated with RRC into xRC, and xRC can be a sub-function of TRC. CRC is used to control the computing resources, amount of computing operations, and computing quality used by the computing execution function.

[0787] The computing connection control between the UE and the core network can be supported by modifying or enhancing the basic functions of the NAS; the computing execution control can be achieved through the TCF (Task Control Function) to maintain computing execution function addresses, computing tasks, computing power map information, etc.

[0788] The following sections will explain the computational connection control function and the computational execution control function respectively.

[0789] ● The computational connection control function can be implemented in TCF or through CF-C enhancement.

[0790] The computing connection control system monitors the status of computing connections in real time, controls connection resources and quality, and supports service continuity guarantees under terminal status awareness and mobility. It 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 the TCF or through a separate CMF function.

[0792] Computation execution control allocates computing resources used by node computing execution functions, controls the amount of computing operations performed, controls computing quality, and supports terminal mobility. Computation resource control monitors the status of computing resources in real time and controls their allocation.

[0793] The computing connection control and computing execution control between the base station and the core network can be achieved through the TCF (Tracking Function), which maintains computing execution function addresses, computing tasks, computing power map information, etc. The interaction of computing execution control functions between the TCF and the base station can be implemented based on the T2-AP (Track Two Access Point) mechanism.

[0794] The protocol stack for compute plane services is as follows:

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

[0796] Figure 70 shows the service plane protocol stack of 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) at the air interface and the computing bearer (CB) at the ground interface. A new radio computing session protocol (RCSP) is introduced at the session layer; in this case, the computing session can also be called an RCSP session. An RCSP session can include only the CRB (computing collaboration between the terminal and the base station) at the air interface; it can include only the CB (computing collaboration between the base station and the core network) at the ground interface; or it can include both the CRB at the air interface and the CB (computing collaboration between the terminal and the core network) at the ground interface.

[0797] 5.4.2 Independent Data Surface

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

[0799] 5.4.3 Independent Intelligent Surface

[0800] Figure 73 illustrates multi-level collaboration in an independent intelligent plane. As shown in Figure 73, HiC supports intelligent collaboration between network elements and terminals at various levels within the network, including scenarios such as terminal and base station, terminal and core network, base station and base station, and base station and core network. At the control level, HiC can be deployed in layers: local collaboration control functions are deployed on cNodes for collaboration among network elements within the cNode range; global collaboration control functions are deployed on the TCF of the core network to coordinate collaboration between cNode regions and between the RAN domain and the core network domain.

[0801] 5.4.4 Independent Trust Surface

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

[0803] The end-to-end trusted service plane protocol stack is shown in Figure 75. Trusted data is transmitted between the UE, access network, and core network through the Trustworthiness Bearer Protocol (TBP) layer; the EIP provides encryption, decryption, and integrity protection functions for trusted data. All TBP functions are executed by TWE and TWG, and the EIP functions are as described above.

[0804] 6. Air Interface - Protocol Layer.

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

[0806] 6.2 Layer 2.

[0807] 6.2.1 Overview.

[0808] For connectivity, Layer 2 of 6G 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 these, Layer 2 provided in this application includes a sublayer supporting a first function, which includes at least one of the following:

[0809] -The physical layer provides the TRS Sublayer with a transport channel;

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

[0811] - The RLC Sublayer provides the T-PDCP Sublayer with an RLC channel;

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

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

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

[0815] -RSCP Sublayer provides encapsulation of computational data (only for independent computational planes);

[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 channels (BCCH and PCCH are not described for clarity).

[0820] Radio bearers are divided into two groups: user plane data for control plane data and data radio bearers (DRB) for signaling radio bearers (SRB).

[0821] 6.2.2, TRS Sublayer

[0822] Regarding connectivity features, TRS reuses existing MAC functionality for connections:

[0823] ● Services and functions provided:

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

[0825] - Multiplex / demultiplex TRS SDUs belonging to one or different logical channels into transport blocks (TBs), and transmit the transport blocks (TBs) to the physical layer on the transport channel / transmit from transport blocks to transport blocks (TBs);

[0826] - Scheduling information report;

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

[0828] - Prioritization is performed among UEs through dynamic scheduling;

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

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

[0831] -filling.

[0832] ●Logical Channel

[0833] The control channel is used only for transmitting control signaling information.

[0834] - Broadcast Control Channel (BCCH): A downlink channel used for broadcasting control information for the system.

[0835] - Paging Control Channel (PCCH): The 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 for transmitting dedicated control information between the UE and the network. Used by UEs with RRC connections.

[0838] The service channel is used only for transmitting user plane information:

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

[0840] ●Mapped to transmission channel

[0841] In the downlink, the following connection exists between the logical channel and the transport channel:

[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 logical channel and the transport channel have the following connection:

[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] The HARQ function ensures delivery between Layer 1 peers. When the physical layer is not configured for downlink / uplink space multiplexing, a single HARQ process supports 1 TB of transmission. When the physical layer is configured for downlink / uplink space multiplexing, a single HARQ process can support one or more TBs.

[0854] In response to new features such as tasks and computation, TRS has added one or more of the following functionalities:

[0855] ● Services and functions provided:

[0856] - The mapping between the logical channel and the transport channel of the task;

[0857] - Multiplex / demultiplex TRS SDUs belonging to one or different logical channels for tasks and connections into transport blocks (TBs), and transport blocks (TBs) are transmitted to the physical layer on the transport channel / transmitted from transport block to transport block (TB);

[0858] - Computational resource scheduling information report;

[0859] - Computing resource status information report;

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

[0861] - Different tasks of a UE are prioritized according to computing resources;

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

[0863] ● Services and functions provided:

[0864] - The mapping between the logical channel and the transmission channel of data;

[0865] - Multiplex / demultiplex TRS SDUs of data and connections belonging to one or different logical channels into transport blocks (TBs), and transmit the transport blocks (TBs) to the physical layer on the transport channel / transmit from transport block to transport block (TB);

[0866] - Data plane carrying and scheduling priority handling of SRB and DRB;

[0867] 6.2.3, RLC Sublayer

[0868] For connectivity features, reuse all functionalities of the connectivity RLC layer:

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

[0870] ●Business and Functions

[0871] - Transmission of upper-layer PDUs;

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

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

[0874] - Segmentation (AM and UM) and resegmentation (AM only) of RLC SDU;

[0875] - Reassemble 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 segments based on the RLC status report;

[0882] - Use polling of RLC status reports when needed;

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

[0884] 6.2.4, T-PDCP Sublayer

[0885] Based on connectivity characteristics, all functionalities of the PDCP layer are reused:

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

[0887] - Maintain PDCP SN;

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

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

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

[0891] - Encryption and decryption;

[0892] - Integrity protection and integrity verification;

[0893] - SDU discarding based on timers;

[0894] - For split bearers, routing;

[0895] -repeat;

[0896] - Reordering and delivery in sequence;

[0897] -Disordered submission;

[0898] -Duplicates are discarded.

[0899] 6.2.5, T-SDAP Sublayer

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

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

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

[0903] In response to new features related to tasks, computing, data, and AI, T-SDAP has added the following functionalities:

[0904] - Mapping of Task ID to Task QFI;

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

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

[0907] 6.2.6, TRD Sublayer

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

[0909] - Added new AI training / inference / model processing features (compression / pruning / quantization / security, etc.)

[0910] 6.2.7 Task PDUs Sublayer

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

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

[0913] 6.2.8, RCSP Sublayer

[0914] If an independent computational surface is used, a new RCSP layer is added to address the new characteristics of the computational surface, providing the following functions:

[0915] -Intrinsic computing 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 adopted, a new DFCP layer is added to address the new characteristics of the data plane. This layer 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] -Starting and stopping data service tasks;

[0920] -Configure data service task routing information;

[0921] - The rollout and updates of data protection technologies;

[0922] - Reporting of statistical information.

[0923] DFCP-U performs the following functions:

[0924] - Mapping of data service task IDs to data plane radio bearers;

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

[0926] - Packet compression;

[0927] -Data routing and forwarding;

[0928] - Data acquisition, data preprocessing, data analysis, data sharing, etc.

[0929] 6.2.10, EIP Sublayer

[0930] If an independent trusted surface is used, an EIP layer is added to handle trusted packet processing, taking into account the new features of the trusted surface. The EIP reuses the functionality of the PDCP layer and adds the following functions:

[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 adopted, a new TBP layer is added to take into account the characteristics of the trusted data plane. This layer is responsible for trusted service data transmission between the UE and the base station / CN, and between the base station and the CN, and has the following functions:

[0936] - Synchronize blockchain transaction / block data;

[0937] - Situational awareness data;

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

[0939] -Trusted Root manages data;

[0940] -Key.

[0941] 6.2.12 Layer 2 data flow

[0942] For data transmission over the connection, no changes are required. An example of the Layer 2 data flow is shown in Figure 76. The TRS generates a transport block by connecting 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 an IP packet (m).

[0943] For data transmission in a task, modifications to the protocol stack are required: compared to connections, a new TRD layer is added for generating task data, such as AI data generation (e.g., gradient information in federated learning) or AI model encoding and decoding. An example of layer-2 data flow is shown in Figure 77, where the TRS generates a transport block by connecting two RLC PDUs from RBx corresponding to different task IDs and one RLC PDU from RBy corresponding to other task IDs. The two RLC PDUs from RBx correspond to a TRD packet (n and n+1), while the RLC PDU from RBy is a fragment of a TRD packet (m).

[0944] Furthermore, since they share the same transmission channel (air interface), the task data bearer and the connection data bearer can also be multiplexed and packetized into a single TRS PDU for transmission.

[0945] If an independent data plane is used, the protocol stack is modified for data transmission. Compared to a connection, the SDAP layer is reduced, and a new DFCP layer is added for the generation of data plane data, which is mapped to the data bearer DDRB through the data service ID. Figure 78 is a schematic diagram of the data flow of an independent data plane.

[0946] If an independent trusted plane is used, the protocol stack is modified for data transmission on the trusted plane. Compared with the connection, the SDAP layer is reduced and a TBP layer is added. The input data is composed into homomorphic computation input, and after homomorphic computation is performed, the homomorphic output data is unpacked and forwarded as data plane packets. See Figure 79.

[0947] 6.3 Layer 3

[0948] In this application, layer 3 of the air interface may include a sublayer supporting the first function. For example, in one implementation, layer 3 includes a TRC layer, which includes the functions already present in the RRC layer as well as the functions related to the aforementioned newly added features (or the first function). A detailed description of the TRC layer can be found in 6.3.1.

[0949] 6.3.1, TRC

[0950] For example, in addition to inheriting the existing functions of the original RRC (e.g., RRC state maintenance (idle / inactive / connected), generation, scheduling and transmission of system broadcast messages (MIB, SIB1~SIBx), access control, UE capability acquisition, NAS signaling transmission, etc.), TRC also adds new feature-related functions such as task, computing, data, and AI, such as one or more functions related to task configuration, modification, deletion, and mobility. System information broadcasting is shown in Figure 80. As shown, MIB messages are sent by the cNode through the BCH cycle, and SIB1 messages are sent through the DL-SCH cycle. Other system information (SI) (including system information not broadcast in the minimum system message) can be broadcast in the RRC idle / inactive state, or sent through RRC dedicated signaling in the RRC connected state, and can be sent periodically or based on UE requests (i.e., on-demand sending).

[0951] Regarding connectivity characteristics, the main services and functions of the RRC sublayer on the Uu interface that are reused include:

[0952] - Broadcast system information related to AS and NAS;

[0953] - Paging initiated by 6GC or 6G-RAN;

[0954] - Establishing, maintaining, and releasing TRC connections between the UE and 6G-RAN, including:

[0955] - Adding, modifying, and releasing carrier aggregation;

[0956] - Add, modify, and publish 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 signaling radio bearers (SRBs) and data radio bearers (DRBs);

[0959] -Mobile functionality includes:

[0960] - Switching and context transfer;

[0961] - UE cell selection and reselection, and control over cell selection and reselection;

[0962] - Mobility between RATs;

[0963] -QoS management functions;

[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] In response to new features such as tasks, computation, and HiC, TRC has added one or more of the following functionalities:

[0968] - The establishment, configuration, maintenance, and release of Task Radio Signaling Bearer (T-SRB) and Task 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] -Configuring, modifying, and deleting model resources;

[0972] -Configuring, modifying, and deleting collaborative patterns;

[0973] - Based on task switching and context transfer;

[0974] - Task-based QoS management functionality.

[0975] If an independent data plane is used, TRC will add one or more of the following features to address the new data characteristics:

[0976] - The establishment, configuration, maintenance, and release of the Data Radio Data Bearer (DDRB);

[0977] - Data-based QoS management functions;

[0978] - Processing of wireless data bearers during handover;

[0979] - Processing of wireless data bearers during call re-establishment;

[0980] -DA registration.

[0981] In response to the new trusted features, TRC has added one or more of the following functionalities:

[0982] - The establishment, configuration, maintenance, and release of Trusted Radio Signaling Bearer (Trust-SRB) and Trusted Radio Data Bearer (Trust-DRB);

[0983] - UE trusted capability perception, registration, and deregistration;

[0984] -Configuration, modification, activation, and deletion of UE trusted capabilities;

[0985] - Handling of trusted wireless bearers during handover;

[0986] - This will involve processing of the wireless trusted bearer during the reconstruction process;

[0987] - Parsing T-NAS (TUCP) T-NAS message transmission to / from the core network and to / from the UE;

[0988] - QoS management functionality based on trusted bearers;

[0989] - Security negotiation between UE and base station: such as security policy negotiation, key negotiation;

[0990] - Trusted information subscription between UE and base station: such as demand tags, capability tags, response tags, and network-wide trusted policies;

[0991] - Authentication and authorization between UE and base station: 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] - UE and base station blockchain: blockchain creation, updating, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, dynamic node joining, and dynamic node leaving;

[0994] - Trust metrics for UE and base station: Device trust metrics, such as trust proof vector and trust proof parameters;

[0995] - Situational awareness of UE and base station: Situational awareness configuration information, such as parameter types, parameter functions, and parameter information extraction;

[0996] - Homomorphic processing between UE and base station: key negotiation and algorithm configuration.

[0997] 6.3.2, TURP

[0998] If an independent trusted surface is adopted, a new TURP layer is added to address the new characteristics of the trusted control surface, possessing one or more of the following functions:

[0999] - The establishment, configuration, maintenance, and release of Trusted Radio Signaling Bearer (Trust-SRB) and Trusted Radio Data Bearer (Trust-DRB);

[1000] - UE trusted capability perception, registration, and deregistration;

[1001] -Configuration, modification, activation, and deletion of UE trusted capabilities;

[1002] - Handling of trusted wireless bearers during handover;

[1003] - This will involve processing of the wireless trusted bearer during the reconstruction process;

[1004] -Analyze 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 functionality based on trusted bearers;

[1006] - Security negotiation between UE and base station: such as security policy negotiation, key negotiation;

[1007] - Trusted information subscription between UE and base station: such as demand tags, capability tags, response tags, and network-wide trusted policies;

[1008] - Authentication and authorization between UE and base station: 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] - UE and base station blockchain: blockchain creation, updating, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, operating parameters, chain node identity management, dynamic node joining, and dynamic node leaving;

[1011] - Trust metrics for UE and base station: Device trust metrics, such as trust proof vector and trust proof parameters;

[1012] - Situational awareness of UE and base station: Situational awareness configuration information, such as parameter types, parameter functions, and parameter information extraction;

[1013] - Homomorphic processing between UE and base station: key negotiation and algorithm configuration.

[1014] The following describes the network element interface - protocol layer under the RAN architecture provided in 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] - The cNode and sNode need to exchange connection context information (for connection architecture 1, the cNode maintains the connection control signaling and context information and needs to inform the sNode; for connection architecture 2, the sNode maintains the connection control signaling and context information and needs to inform the cNode).

[1020] -cNode and sNode need to exchange task context information.

[1021] - When there is no Y3 interface between sNodes, Y3 interface pass-through and forwarding can be performed through Y1-AP of Y1 interface (forwarded via cNode);

[1022] - cNode and sNode need to exchange trusted context information.

[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 interact with each other to exchange task information (such as task request messages, task response messages, task reconfiguration 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-site RRM negotiation, etc.).

[1031] -sNodes interact with each other to exchange task information (such as task data exchange, which can be calculation results, data processing results, intelligent representations of multi-agent collaboration, etc.).

[1032] - cNode and sNode need to exchange trusted context information.

[1033] 4) T2-AP

[1034] The main functions of T1-AP include:

[1035] -cNode interacts with TCF to exchange task information (such as task request messages, task response messages, task reconfiguration 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] -cNode interacts with NAF to 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] -cNode interacts with CF-C to exchange connection information (only for connection architecture 1, such as other signaling messages besides initial access and initial selection signaling messages).

[1042] 7) T5-AP

[1043] The main functions of T5-AP include:

[1044] -sNode interacts with NAF to exchange connection information (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] -sNode interacts with CF-C to exchange connection information (only for Connection Architecture 2, such as other signaling messages besides the initial access and initial selection signaling messages).

[1048] 9)T8-AP

[1049] The T8-AP's main functions include one or more of the following:

[1050] -cNode trusted capability awareness, registration, and deregistration;

[1051] -Configure, modify, activate, and delete cNode trusted capabilities;

[1052] -Security negotiation between cNode and CN: such as security policy negotiation, key negotiation;

[1053] - Trusted information subscription for cNode and CN: such as demand tags, capability tags, response tags, and network-wide trusted policies;

[1054] -cNode and CN authentication and authorization: identity authentication for secure access, such as authentication vectors and authentication parameters;

[1055] - Encryption and integrity protection of signaling between cNode and BN;

[1056] -cNode and CN authorization: including static authorization and token-based authorization;

[1057] -CN's control over cNode's blockchain: blockchain creation, updates, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, runtime parameters, chain node identity management, dynamic node joining, and dynamic node leaving;

[1058] -CN's situational awareness and control over cNodes: parameter types, parameter configuration, and parameter information extraction;

[1059] - Trust metrics for cNode and CN: Device trust metrics, such as trust proof vector and trust proof parameters;

[1060] - Homomorphic processing of cNode and CN: key negotiation and algorithm configuration.

[1061] 10)T9-AP

[1062] The T9-AP's main functions include one or more of the following:

[1063] -sNode trusted capability awareness, registration, and deregistration;

[1064] -sNode trusted capabilities configuration, modification, activation, and deletion;

[1065] -sNode and CN security negotiation: such as security policy negotiation, key negotiation;

[1066] - Trusted information subscription for sNode and CN: such as demand tags, capability tags, response tags, and network-wide trusted policies;

[1067] -sNode and CN authentication and authorization: identity authentication for secure access, such as authentication vectors and authentication parameters;

[1068] - Encryption and integrity protection of signaling between sNode and CN;

[1069] -sNode and CN authorization: including static authorization and token-based authorization;

[1070] -CN's control over sNode's blockchain: blockchain creation, updates, blockchain / chain node management. Blockchain capability deployment, capability discovery, capability activation, runtime parameters, chain node identity management, dynamic node joining, and dynamic node leaving;

[1071] -CN's situational awareness and control over sNodes includes parameter types, parameter configuration, and parameter information extraction;

[1072] Trust metrics for -sNode and CN: Device trust metrics, such as trust proof vector and trust proof parameters;

[1073] Homomorphic processing of -sNode and CN: key negotiation and algorithm configuration.

[1074] 7.2 RAN Ground Interface - Data

[1075] Used for transmitting user data or task data (including computational 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 has been added, responsible for trusted service data transmission between the UE and the base station / CN, and has the following functions:

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

[1079] 7.2.2, TBP Layer

[1080] If an independent trusted surface is adopted, a new TBP layer is added to address the new characteristics of the trusted data surface, possessing one or more of the following functions:

[1081] - Synchronize blockchain transaction / block data;

[1082] - Situational awareness data;

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

[1084] -Trusted Root manages data;

[1085] -Key.

[1086] 8. 6G Identification.

[1087] 8.1 UE Identification

[1088] 8.2 Network Identities

[1089] As an example, the following identifier is used in 6G-RAN to identify specific network entities:

[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 identifier is used in 6G-RAN to identify a specific service entity:

[1101] ●Task ID: When a UE supports multiple tasks at the same time, it is used to distinguish different tasks and their signaling or data.

[1102] 8.4 TWE / TWG Recognition

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

[1105] 9.1 Task Mobility

[1106] As mentioned above, 6G networks introduce new task features, including computation, AI training, and AI inference. To ensure the QoS of connections and tasks separately, connections and tasks may not migrate simultaneously during handover. For example, if the target base station lacks sufficient computing resources, only the connection may be migrated, not the task. Therefore, 6G networks may face situations where connection anchors and task anchors are separated. In scenarios where a user requests a base station or a base station requests a user to perform a task, the communication between the task anchor and the user needs to be considered when the user moves outside the coverage area of ​​the task anchor. The solutions provided in this application are described below for user-requested task performance and base station-requested task performance, respectively. Here, the base station can be either a cNode or an sNode as mentioned above.

[1107] (1) The user requests the base station to perform a task

[1108] A user initiates a computational or AI task to the base station. The base station, considering the task size, its own resources, and the resources of surrounding nodes, can break down the task and distribute it to devices in neighboring stations or within the cell for execution. The base station, acting as the task anchor, collects the results from each executor after the task is completed and sends them back to the user. If a user moves to a new base station's cell after initiating a task, the connection anchor will switch to the new base station to ensure uninterrupted connection service. However, the task anchor may remain unchanged. In this case, how the task anchor sends the results to the user needs to be considered.

[1109] Since the user is no longer within the coverage area of ​​the task anchor point, it cannot send data directly over the air interface. The task anchor point needs to route the result to the user's current connection anchor point first, and then the connection anchor point sends the result to the user over the air interface. Therefore, the key to solving this problem is how the task anchor point finds the user's connection anchor point. The following three optional solutions provided by this application are given with reference to Figure 81, as shown in Solution 1 to Solution 3.

[1110] Option 1

[1111] As shown in the attached diagram, during handover, the handover request message sent by the source base station to the target base station includes the user's task anchor identifier, i.e., the base station ID / IP of the task anchor, 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 a task anchor point identifier to the target base station, including the base station ID / IP of the task anchor point and the UE ID, such as TMSI. Then, the target base station sends a connection anchor point identifier to the task anchor point, which is the target base station ID / IP and the corresponding UE ID.

[1114] Option 3

[1115] Before sending the result, the task anchor first requests the CF-C of the core network to query the user's connection anchor. After the core network finds the user's current connection anchor based on the UE ID, it sends the identifier of the connection anchor to the task anchor.

[1116] (2) The base station requests the user to perform a task.

[1117] A base station assigns a subtask to a user within its coverage area for execution. Upon completion, the user sends the result back 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 point. They need to send the task result to the connecting base station first, and then the connecting base station forwards it to the task anchor point. Therefore, in this scenario, the key lies in how to find the task anchor point—the connecting base station, i.e., the user's connection anchor point. Two alternative solutions are presented below with reference to Figure 82, namely Solution 1 and Solution 2.

[1118] Option 1

[1119] When a base station configures a task for a user, it includes information such as the task ID and task anchor identifier (e.g., base station ID / IP). Therefore, when the user reports the task result, they can encapsulate the task anchor identifier in the header of the task result packet. When the connection anchor receives this data packet, it can determine the task anchor identifier by parsing the header.

[1120] Option 2

[1121] During handover, the handover request message sent by the source base station to the target base station includes a task anchor point identifier, including the base station ID / IP of the task anchor point and the corresponding UE ID. Compared to Scheme 1, this scheme can reduce the transmission of air interface information.

[1122] 9.2 Calculate Mobility

[1123] Mobility management is a fundamental function of wireless networks, ensuring uninterrupted service for users while they are mobile. Connected-state mobility management, often simply referred to as handover, refers to ensuring that connected users can continue to receive network connectivity services while moving. The handover process includes a handover preparation phase, a handover execution phase, and a handover completion phase. In the traditional handover preparation phase, the source base station sends a handover request including the UE's connection context information. The target site determines whether to accept the source base station's handover request for that user based on the UE's connection context information and its own load information. In this application, the source base station (source-sNode, S-sNode) of the converged computing and communication network sends a handover request that includes 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 perform a connection handover and computing migration based on the UE's connection and computing contexts 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 UE's radio resource management (RRM) configuration during inactive periods, the UE's antenna information, the mapping rules from QoS flow to data radio bearer (DRB), UE capability information, and measurement results reported by the UE. The UE's computation context information includes: the source station's computation resource status, the overhead of computation migration (including communication overhead, communication latency, QoS guarantees, etc.), and the execution status of computation tasks on the S-sNode.

[1124] The following describes the scheduling under the RAN architecture provided in this application.

[1125] 10. Scheduling.

[1126] In the RAN architecture provided in this application, the TRS layer, in addition to the functions of the original medium access control (MAC) layer, also has task-related functions. Since the connection-related functions remain unchanged, this paper focuses on the new functions of the TRS layer brought about by the introduction of new features such as tasks. For details regarding connection scheduling, such as basic scheduling operations, uplink scheduling, downlink scheduling, and connection-related measurement mechanisms, uplink and downlink rate control, please refer to the description in protocol 38.300; this paper will not elaborate further.

[1127] 10.1 Task Scheduling

[1128] Taking a task deployment as an example, the computing power scheduling of TS to TE includes three methods, as shown in Figure 83:

[1129] ●Opt1-TS has no control, TE has full control: no differentiated QoS;

[1130] ●Opt2-TS weak control, TE strong control (cloud AI mode): TE can autonomously decide the allocation of each time slot based on a percentage, but TS cannot precisely control the CPU time slot.

[1131] ●Opt3-TS strong control, TE weak control (communication mode): Controls TE CPU time slot allocation in real-time or near real-time.

[1132] The QoS mechanism under the RAN architecture provided in this application is described below. 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 a QoS mechanism for the first function (e.g., 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) AI Service Quality (QoAIS).

[1139] Both network-side and terminal-side QoS mechanisms need to be enhanced based on existing QoS mechanisms. For example, the network-side QoS mechanism needs the following enhancements: designing new QoS metrics; designing a new mechanism that does not involve CN and does not generate QoS flows based on IP 5-tuples. Considering 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, the terminal-side QoS mechanism can be enhanced as follows: as an example, communication is always prioritized; or, as another example, designing a unified strategy for computing QoS and communication QoS.

[1140] The following section will focus on QoAIS.

[1141] It should be understood that, given the diverse AI needs of various industries for 6G networks, translating user demands into network-understandable requirements for AI service capabilities is a pressing issue. 6G networks will no longer be merely conduits for traditional communication services; different intelligent application scenarios will have varying demands for AI service quality. A set of indicators is needed to quantify or categorize user needs and the overall effectiveness of network orchestration in controlling various AI elements (including connectivity, computation, data, and algorithms). Therefore, this paper proposes the concept of QoAIS, a set of indicators and process mechanisms for evaluating and ensuring the quality of AI services.

[1142] AI services in 6G networks can be categorized into AI data, AI training, AI inference, and AI verification, each requiring a QoAIS (Quality of Access) system. In designing the specific indicator system, traditional communication networks primarily consider connection-related performance metrics such as latency and throughput. However, 6G networks, in addition to traditional communication resources, will introduce various resource elements for AI service orchestration, including distributed heterogeneous computing resources, storage resources, data resources, and AI algorithms. Therefore, it is necessary to comprehensively evaluate the service quality of network-inherent AI from multiple dimensions, including connectivity, computing power, algorithms, and data. Consequently, the QoAIS indicator system design in this application considers multiple aspects such as performance, overhead, security, privacy, and autonomy.

[1143] Table 1 provides a design method for QoAIS metrics for AI training services.

[1144] Table 1: QoAIS Index System for AI Training Services

[1145] QoAIS is a crucial input for the network-native 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. It then maps these task QoS requirements to QoS requirements for multi-dimensional resources such as connectivity, computation, data, and algorithms, ensuring continuous support through the design of management plane, control plane, and user plane mechanisms. Figure 84 illustrates the logical relationship between AI use cases, AI services, and AI tasks provided in this application. It is important to note that an AI use case is a user's AI service request to the network in an intelligent application scenario. An AI use case may involve invoking one or more types of network-native AI services (such as AI training, validation, and inference services).

[1146] As mentioned earlier, QoAIS is a crucial input for the 6G network AI management and orchestration (NAMO) system and its control functions. The network AI management and orchestration system needs to decompose the top-level QoAIS and then map it to QoS requirements for various aspects such as connectivity, computation, data, and algorithms. The logical relationship between this process and the three-layer management and control functional entities is shown in Figure 85. As shown in Figure 85, from the perspective of the entire end-to-end process, after receiving an external service request, NAMO submits the corresponding AI service to the TA for execution. The entire end-to-end process of the real-time AI service 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, validation 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 (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 the task QoS into resource QoS requirements, and clarify the resource requirements of the four elements required by AIT, including connectivity, computing, data and algorithm / model;

[1152] ⑥ Determine and configure the four essential resources required for the task, including node selection (selecting nodes to participate in the computation, nodes to provide data, and nodes to provide algorithms / models), establishing connections between nodes, or updating the above configurations;

[1153] ⑦ Within the selected participating nodes, determine and adjust the allocation of computation, optimize the quality of communication connections, determine and collect the data required for processing, and determine and change or optimize the algorithm model in real time to ensure the achievement of task QoS, thereby ensuring the achievement of QoAIS.

[1154] As mentioned above, the management layer has poor real-time performance, acquires a wide range of network information but with coarse granularity, while the control layer has strong real-time performance and can acquire more accurate information but has a limited data range. Furthermore, the management layer cannot obtain real-time information on the status of air interface links and terminal-side resources. Therefore, some functions are suitable for implementation at the management or control layer, while other functions can achieve better results through collaboration between the management and control layers.

[1155] Another scenario involves network AI capability requests generated at the control plane, such as AI service requests submitted by users 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 (Technical Expertise Center) to first determine whether the request is an AI service request or an AI task request. If it's the former, it's handled by NAMO (Network Assistant); if it's the latter, it's processed by the TA.

[1156] After the task triggering source passes the service workflow to the TA, the TA maps it to a task instance and deploys it to a specific network element with computing power for execution.

[1157] There are two types of triggering sources for tasks: one is from within the network, such as network optimization tasks initiated by the RAN itself; the other is from third parties. The network receives service requests from third parties through capability exposure, orchestrates the received services to form a workflow and the required QoS guarantees, and passes it to the Task Provider (TA). The TA then maps it into specific task instances for execution. The workflow includes the resources required by the task and the dependencies between tasks. The TA first creates an instance for each task, assigns a task ID, and resolves the QoS of each task from the service QoS, completing the mapping from service QoS to task QoS.

[1158] To ensure the achievement of QoAIS, the aforementioned layered management and control logic architecture is implemented through a "three-layer closed loop." The TS layer monitors and optimizes the four key resources in real time to guarantee the achievement of task QoS within the resource configuration scope of the TA layer. When the TS layer cannot provide task QoS guarantees, the TA layer modifies the overall resource configuration, such as adjusting the network nodes participating in the task, or changing the model warehouse or data warehouse. When the TA layer cannot provide task QoS guarantees, optimization is handled by NAMO. NAMO can change the anchor point of the AI ​​task or re-decompose the mapping between AI services and AI tasks.

[1159] Figure 86 illustrates the mapping relationship between QoAIS metrics and QoS across resource dimensions. As shown in Figure 86, the QoAIS metrics of AI services are broken down into QoAIS metrics for tasks and various metric dimensions, and then further mapped to QoS metrics for each resource dimension. This mapping is ensured by management plane, control plane for each resource dimension, and user plane mechanisms. The QoS metrics for each resource dimension in Figure 86 can be divided into metrics suitable for quantitative evaluation (such as various resource overheads) and metrics suitable for hierarchical evaluation (such as security level, privacy level, and autonomy level). For the former type of metrics, this application proposes quantification schemes for some metrics, such as training time, algorithm performance bounds, computational accuracy, and various resource overheads.

[1160] Table 2: Mapping of AI Training Service Performance QoAIS to Various Resource Dimensions

[1161] In the preceding description of the RAN architecture provided in this application, a general overview of the new features offered, such as tasks, computation, trust, and intelligence, was provided. To gain a clearer and more comprehensive understanding of these new features and their impact on the RAN architecture, each of these new features will be elaborated upon below.

[1162] 12. 6G New Feature - Tasks.

[1163] 12.1 Driving force.

[1164] This section aims to explain why we need web AI, and the relationship between web AI, cloud AI, and mobile edge computing (MEC AI).

[1165] 1) Network AI

[1166] In the 5G era, cloud AI architecture has been widely adopted to provide centralized computing, big data analytics, and AI training and inference services. The traditional "end-to-end" architecture is a decoupled design: the terminal 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 provide flexible, smooth, and stable services while ensuring QoE is extremely challenging. Furthermore, for latency-sensitive ultra-reliable low-latency communication (URLLC) services, MEC (Multi-access Edge Computing) deploys application servers closer to the base station, achieving lower latency and proximity to the end user compared to cloud AI. However, it 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, failing to avoid the aforementioned problems of cloud AI.

[1167] To address the issues of low speed, high latency, low privacy, and high carbon emissions associated with deploying AI capabilities at the application layer in cloud and MEC (Multi-access Edge Computing), 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 "edge-cloud" architecture is more effective in supporting compute-intensive, latency-sensitive, security-assured, and privacy-sensitive applications (such as interactive virtual reality / augmented reality games, autonomous driving, and smart manufacturing).

[1168] Therefore, this application considers providing a complete AI environment and service-oriented AI services within the network, i.e., AIaaS; thus, it introduces the concept of network AI to clearly distinguish it from existing cloud AI. Network AI mainly addresses scenarios requiring high real-time performance, high security and privacy, or those that choose to perform data processing within the network (i.e., bringing computation to the data, rather than the traditional method of bringing data to computation) to reduce overall energy consumption. Furthermore, network AI can be a beneficial supplement to cloud AI.

[1169] 2) Application scenarios of network AI.

[1170] In 6G, AI functionality is no longer limited to the application layer but is deeply integrated with the network. From the perspective of the relationship between AI and the network, it can be mainly divided into three application scenarios: network element intelligence, network intelligence, and service intelligence. Network element intelligence refers to the native intelligence of network element devices; network intelligence refers to the network-level collective intelligence generated by the collaboration of multiple intelligent network elements; and service intelligence refers to the intelligent services provided by the entire wireless communication system for services, generally triggered by external services and executed by the wireless network, especially for scenarios involving terminal participation, where the business logic can be transparent to the wireless communication system. Through network element intelligence and network intelligence, AI services are provided internally to the network; and through service intelligence, corresponding AI services are provided externally.

[1171] 3) Why should we natively support AI from the network architecture, and what challenges do we face?

[1172] To simultaneously support the three major application scenarios mentioned above, the native AI architecture of 6G networks must be based on a unified architectural framework. This means building a complete distributed AI environment within the 6G network to support different types of AI training / inference. Specifically, this includes: 1) Network AI can utilize the various basic AI capabilities inherent in 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; 3) It can provide AI QoS guarantee services in complex environments such as heterogeneous wireless, dynamic, and fully distributed environments.

[1173] Compared to the centralized, homogeneous, and stable AI environment provided by the cloud, network AI architecture faces the following technical challenges: 1) Distributed AI needs to be deployed on a massive number of core network elements, base stations, and UEs, requiring efficient management of these massive nodes from the architectural design perspective to avoid centralized node management becoming a bottleneck; 2) Significant differences exist in computing power, memory, data, and algorithm capabilities among different nodes, necessitating efficient management of heterogeneous nodes from the architectural design perspective; 3) Real-time changes in the wireless environment and dynamic changes in computing load require timely updates to dynamically changing states from the architectural design perspective. Therefore, this application shifts the architecture design from a session-centric to a task-centric approach to address these challenges.

[1174] 4) Typical characteristics of native AI network architecture.

[1175] Traditional wireless networks are session-centric, managing and controlling at the session level and implementing QoS guarantees for sessions.

[1176] Figure 87 illustrates the core features of a task-centric architecture. As shown, the network AI proposed in this application, from an architectural perspective, requires a natively intelligent architecture design that natively supports the deep integration of connectivity, computation, data, and algorithms at the architectural level. Therefore, the key to a natively intelligent architecture design is essentially to support real-time management based on the deep integration of these four elements, i.e., task-level management, and to support a task QoS guarantee mechanism. This application refers to an architecture that supports these two fundamental capabilities as a task-centric architecture.

[1177] 12.2 Task Overview.

[1178] Task: To collaboratively utilize computing, algorithms, connectivity, and data to accomplish a specific goal derived from AI use cases, which can be one or more AI training or AI inference processes. The mapping process from AI use cases to tasks can be flexible. As described above, AI use cases can be first decomposed into one or more AI services, AI services can be further decomposed into one or more AI workflows, and AI workflows can be further decomposed into one or more tasks.

[1179] Task-centric approach: This refers to managing tasks as the central control object, supporting task lifecycle management, and ensuring task QoS and smooth execution through the collaboration and allocation of computation, algorithms, connectivity, and data. Specifically, task QoS originates from the AI ​​QoS decomposition and mapping of AI services, and is related to the specific mapping from 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: The controlled object has shifted from "sessions" to "tasks"

[1182] Compared to traditional "conversations," the technical objectives and methods of AI-related tasks differ from those of conversations.

[1183] From a technical perspective, traditional communication systems provide conversational services, typically for communication between specific terminals or between a terminal and an application server, with the ultimate goal of transmitting user data (including voice). However, the purpose of network AI differs from conversational AI. For example, network element intelligence and network intelligence, as mentioned above, aim to provide intelligent services to the network and improve communication network efficiency, while business intelligence aims to provide intelligent services at the application level for third parties.

[1184] From a technical perspective, traditional communication services require maintaining user-level connection pipelines (such as end-to-end tunnels from UE to base station and from base station to core network) and lifecycle management and QoS guarantee mechanisms for these connection pipelines to provide QoS-guaranteed data transmission services in order to transmit user data. AI, however, is a data- and computationally intensive service, exhibiting the following distinct characteristics compared to session communication: Firstly, AI introduces new resource dimensions, including computing power (such as CPU, GPU, and NPU), data (such as data used and generated by AI), and algorithms (such as neural network models and reinforcement learning). Therefore, 6G networks need to introduce new resource management mechanisms. Secondly, factors such as single-point computing bottlenecks, data privacy protection, and large model storage bottlenecks make it difficult for a single node to efficiently implement AI services. It can only be accomplished through the collaboration of computing power, algorithms, and data among multiple nodes. Therefore, 6G networks need to introduce new inter-node collaboration mechanisms.

[1185] Based on the two differences mentioned above, it can be seen that the "conversation" system cannot support native AI. Therefore, a new "task" system needs to be designed to support the aforementioned new mechanisms (including new resource management mechanisms and new inter-node collaboration mechanisms). This paper will use the collaboration of multiple nodes and multi-dimensional resources at the 6G network level to accomplish a specific goal, which is defined as a "task".

[1186] ●Change 2: Resource management has shifted from connecting resources to managing the four elements of resources.

[1187] The "conversation" system establishes channels for data transmission and allocates corresponding connections and air interface resources for users, while the "task" system allocates the four essential resources to complete AI tasks. Taking AI inference tasks as an example, the executor needs to first acquire resource information such as computing power, data, and algorithms before executing the relevant tasks. For example, computing information includes the computing resource slots or proportions corresponding to a certain task; data information includes 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 train the AI ​​model, and during the training process, they need to use the allocated connection resources to transmit gradient information. In summary, due to the introduction of tasks, the management resources change from connections to the four essential resources of connections, computing power, data, and algorithms.

[1188] ● Change 3: From "Conversation Control" to "Task Control"

[1189] Unlike traditional session management, task management systems in network AI primarily offer the following functions: 1) decomposition / mapping of external services to internal tasks; 2) decomposition / mapping of service QoS to task QoS; and 3) providing mechanisms for four-element collaboration and multi-node collaboration, orchestrating and controlling the four-element resources of multiple nodes at the infrastructure layer in real time, ultimately achieving distributed serial / parallel processing at the task granularity and real-time QoS assurance. Specifically, for simple service requests, one service can correspond to / map to one task; while for complex services (such as the integration of multiple service flows or service requests with only one service flow and extremely high computational load), they can be mapped to multiple nodes for system execution.

[1190] The following section will elaborate on function 3) mentioned above. Generally speaking, the execution of a specific AI task requires coordination in two dimensions:

[1191] 1) Coordination of the four elements of resources

[1192] The execution of a task may require some or all of the four essential resources: connectivity, computation, data, and algorithms. For example, this involves configuring these four resources during the task deployment phase and scheduling them in real time during task execution.

[1193] 2) Multi-node collaboration

[1194] In traditional communication networks, most connection-related computational processing is implemented within a single network element, generally without the need for computing power sharing or collaboration between network elements. However, with the increasing prevalence of AI scenarios involving large-scale AI training, large-model AI inference, and massive perceptual image processing, the demand for computing power far exceeds that of traditional communication networks. Simply expanding the computing power of individual network elements would lead to excessively high deployment costs for the entire network. 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 collaboration at the computing power level between nodes. 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 addresses this issue to some extent through collaborative learning and gradient transfer, requiring data-level collaboration between multiple nodes for collaborative tasks. Finally, to support intrinsic AI, model training consumes significant computing and storage resources, and a good model needs to be shared within the network to improve overall network efficiency. Therefore, collaborative tasks require AI model-level collaboration between multiple nodes.

[1195] ●Change 4: From Session QoS to Task QoS

[1196] 6G networks will no longer be merely conduits for traditional communication services. Different intelligent application scenarios will have varying demands for the quality of AI services, requiring a set of indicators to quantify or categorize user needs and the overall effectiveness of network orchestration in controlling various AI elements (including connectivity, computation, data, and algorithms). Therefore, this paper proposes the aforementioned concept of QoAIS.

[1197] Traditional communication network QoS primarily considers connection-related performance metrics such as latency and throughput of communication services. 6G networks, in addition to traditional communication resources, will introduce new resource dimensions such as computing power, algorithms, and data, necessitating the expansion of corresponding evaluation metrics. Simultaneously, with the increasing emphasis on data security and privacy in the global smart application industry, and the growing demand from users for network autonomy, performance-related metrics will no longer be the sole focus for users. The demands for overhead, security, privacy, and autonomy will gradually deepen, thus becoming new dimensions for evaluating service quality. Therefore, the QoAIS indicator system proposed in this application needs to be expanded in terms of the above two aspects.

[1198] For example, the dimensions and content of the QoAIS metric evaluation 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, computing 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: complete autonomy, partial human control, and complete human control.

[1204] The management orchestration system achieves continuous QoAIS assurance through the design of relevant mechanisms at the management, control, and user levels.

[1205] 12.3 Key Technologies

[1206] Figure 88 is a schematic diagram of the key technologies of mission-centric computing. Compared with 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 added: Task Control Plane Protocol Stack and Task User Plane Protocol Stack;

[1212] Control plane: Enhanced T-NAS layer, TRC layer, TRS layer, etc.;

[1213] User-side: Added TRD layer and enhanced T-SDAP layer.

[1214] Figure 89 presents a comprehensive overview of key technologies centered on task granularity. As shown in Figure 89, task-level control offers the following advantages:

[1215] Unified state maintenance: Maintenance of the state database of the four key resources (such as connection database, computing power database, model database, and database) (near real-time);

[1216] Unified task management: This includes task-level deployment, execution, and QoS assurance, encompassing near real-time coordination of the four key elements (algorithm / data and connection / computing power) and TE adjustments. Algorithm and data coordination occurs at the TRC layer, while connection and computing power coordination occurs at the TRS layer.

[1217] Unified general computing scheduling: real-time general computing scheduling for different tasks;

[1218] Unified multi-task scheduling: different tasks share resources (connectivity, computing, etc.), and differentiated QoS guarantees are provided between multiple tasks;

[1219] Unified bearer maintenance: used for transmitting task information.

[1220] Furthermore, the mission-centric framework will impact the interfaces. As shown in Figure 90, since the TE may be deployed at the UE and various network element nodes, the mission interface will involve various 3GPP interfaces, such as:

[1221] ●Uu interface;

[1222] ●RAN ground interface;

[1223] ●Inter-CN interface.

[1224] In other words, task-related signaling needs to be transmitted on these interfaces. The specific content of the task-related signaling is explained in other sections of this document and will not be repeated here.

[1225] To achieve the aforementioned task-centric architecture requirements and goals, the following section will focus on the task management logic architecture and its deployment method.

[1226] ● Logical architecture for task management

[1227] Existing communication systems include management and control domains. The network management equipment deployed in the management domain operates and manages network elements through non-real-time management-level signaling (typically at the minute level). The control domain includes core network equipment, base station equipment, and terminal equipment, where control-level signaling is more real-time (typically at the millisecond level). For example, the end-to-end tunnel established when a user makes a voice call is typically completed within tens of milliseconds.

[1228] Figure 91 is a schematic diagram of the task management logic architecture and functions centered on tasks.

[1229] As shown in Figure 91, task management includes two main logical functions: network AI management and orchestration, and task control. Considering the different real-time requirements and scope of task management at each stage, this application introduces NAMO to complete the decomposition, mapping, and orchestration of AI service flows from AI business to tasks. NAMO is typically non-real-time and is generally deployed in the management domain; task management, on the other hand, introduces task anchor (TA), task scheduler (TS), and task executer (TE) functions at the control layer to perform hierarchical control of tasks, seeking a balance between task scope and real-time task scheduling.

[1230] If tasks are managed solely through the NAMO of the management domain, the following problems will arise:

[1231] 1) NAMO cannot directly manage UEs. Tasks involving UEs need to be deployed through the application layer, which the network cannot perceive. Therefore, it is also impossible to achieve the coordination of the four elements to control and guarantee task QoS.

[1232] 2) The NAMO signaling latency is relatively large (usually on the order of minutes), which leads to untimely task management and makes it difficult to meet the strict task QoS guarantee requirements;

[1233] 3) NAMO manages many nodes, and if highly centralized task control is implemented, the signaling consumption will be large.

[1234] Therefore, the RAN architecture provided in this application introduces a Task Anchor (TA) to manage the lifecycle of tasks. This node is deployed at the control plane, which can ensure real-time and fast signaling transmission (millisecond level), making task control more real-time and efficient. In scenarios with a large task scope, the TA may be deployed at a higher position (e.g., in the core network). If there is a real-time requirement for the control of the four elements of resources, the TS can be deployed close to the TE to perceive the status of connection resources in 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 will be described below.

[1236] Task Anchor Point (TA) function: Primarily responsible for task lifecycle management, completing task deployment, startup, deletion, modification, and monitoring based on task QoS requirements, including regulating the four key resources to provide coarse-grained QoS assurance during the initial deployment phase of the task.

[1237] The Task Scheduling (TS) function is primarily responsible for the control and scheduling of the task execution phase, comprising two main modules: information gathering and resource management. Information gathering refers to the TS's real-time awareness of the computing load, data processing capabilities, currently used algorithm models, and communication channel conditions of multiple nodes. Based on this information gathering, the TS possesses more real-time resource management capabilities compared to the Task Controller (TA). For example, as the network environment changes, it can perform more real-time QoS monitoring and assurance through real-time adjustments to models and data, or real-time scheduling of connections and computing power.

[1238] Task Execution Function (TE): Primarily responsible for the specific execution of tasks, as well as potential information and data interactions related to business logic. A single service request may be mapped / decomposed into multiple tasks and deployed across multiple TEs for execution. Furthermore, data and information may interact between different TEs during task execution; for example, federated learning across multiple nodes requires the transfer 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 inference.

[1239] ●Deployment architecture for task management

[1240] The management of TEs by the TA requires real-time and flexible capabilities. Deploying a RAN TA within the RAN domain to manage RAN TEs is more reasonable. Similarly, the CN TA within the core network (CN) domain manages CN TEs in a similar manner. This is because the status of TEs changes in real time (e.g., CPU load, memory, battery level, UE channel status, etc.), and deploying TA / TS nearby can reduce management latency. Furthermore, according to the design logic of wireless networks, CN and RAN need to be decoupled as much as possible. For example, RAN RRM and radio transmission technology (RTT) optimizations should not be aware of CN; conversely, if CN TA manages RAN TEs and executes RAN tasks, it will lead to strong coupling of service logic. Therefore, this application proposes to deploy TA / TS independently in both the CN and RAN domains to achieve real-time management and service decoupling. The necessity and rationality of CN TA and RAN TA are briefly illustrated below through four use cases. It should be noted that the use cases here are for illustrative purposes only; there may be other deployment scenarios and architectures, which are not fully listed here.

[1241] Taking federated learning with base stations and terminals as an example, the following details how TA, TS, and TE are deployed. It should be noted that the embodiments using federated learning as an example below primarily illustrate the deployment methods of TA, TE, and TS, and do not focus on the specific division of cNode and sNode functions of the base station. Therefore, the following example uses the base station as a whole.

[1242] Figure 92 illustrates the deployment of task-centric network AI. Here, gNB corresponds to a base station in a 5G network. As an example of a base station, gNB can also be flexibly deployed in a way that separates centralized units (CUs) and distributed units (DUs). For example, CUs can be deployed in the cloud to handle non-real-time signaling control and data transmission; DUs can be deployed closer to the UE to handle real-time resource allocation and data transmission / retransmission.

[1243] Scenario 1: Base station (e.g., gNB) + UE scenario

[1244] In this scenario, the gNB acts as both the TA and TS, while the UE acts as the TE. At this time, the UE is both the computing power provider and the task executor, and accepts the task management and task scheduling of the gNB (such as the establishment of connection 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 both the computing power provider and the task executor.

[1247] Scenario 3: Base station CU + base station DU + UE scenario

[1248] In this scenario, the CU acts as the TA, the DU as the TS, and the UE as the TE. The UE is both the computing power provider and the task executor, while the CU acts as the task manager. The DU is aware of the tasks assigned to the UE by the CU and performs four-element resource scheduling and real-time QoS assurance for the tasks. Furthermore, the TA and TS are deployed separately, with the TS deployed at a lower position than the TA. This allows the TS to be more aware of the TE's connection, computing power, and algorithm status in real time, enabling more real-time monitoring of task QoS and rapid adjustment of four-element resources.

[1249] Scenario 4: CN + base station (e.g., gNB) + UE scenario

[1250] In this scenario, CN is TA, gNB is TS, and UE is TE; at this time, UE is both the computing power provider and the task executor.

[1251] As can be seen from the examples of the four scenarios above, TA, TS, and TE are only logical functions. These functions can be deployed on the same logical node or different logical nodes depending on the scenario. From the perspective of logical nodes, a single node can have multiple logical functions at the same time (such as any combination of TA, TS, and TE).

[1252] The following section describes how to ensure task QoS based on the above task management logic architecture.

[1253] ●Task QoS Guarantee

[1254] As mentioned above, to ensure the achievement of QoAIS, the layered management 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 startup, task execution, task update, and task termination.

[1255] Figure 93 is a schematic diagram of the task deployment and execution process. After the task triggering source passes the service workflow to the Task Provider (TA), the TA maps it to a task instance and deploys it to a specific network element with computing power for execution. Task deployment includes the following two aspects.

[1256] (1) Creation and allocation of task instances

[1257] The TA ingress receives service workflows, 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 then need to be assigned to specific network elements for execution.

[1258] Task allocation requires knowledge of the distribution of computing / connectivity resources in the network. This information is managed by the TS (Transaction Service) and reported to the TA (Targeting Service). TSs can be deployed in the core network or at base stations, managing resources within their respective domains. Taking a base station as an example, a TS deployed there maintains the computing power of each node and the computing power of connected terminals. Computing / connectivity information can be reported periodically by the TS to the TA, or the TA can proactively query its assigned TS.

[1259] The TA allocates resources reasonably based on the computing power requirements of each task and the current computing power resources of the network. For example:

[1260] The workflow is instantiated into three tasks. TS1 reports enough computing power to support two tasks, and TS2 reports enough computing power to support the third task. Therefore, the task allocation scheme is as follows: tasks 1 and 2 are deployed to resources managed by TS1 for execution, and task 3 is deployed to resources managed by TS2 for execution. The specific allocation scheme depends on the algorithm implementation and needs to consider multiple aspects such as QoS guarantees, resource capacity, and energy consumption.

[1261] In addition, there is a situation in network AI where certain tasks have specified network elements that must participate, such as specifying certain terminals to participate (data is on the terminals). In this case, the mandatory elements need to be treated as constraints in the task allocation algorithm.

[1262] When a task instance is assigned to a resource under a TS, the TA sends a signaling message 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 resource is no longer available when the TS receives the TE creation signaling message, it will reply with a rejection, and the TA needs to reallocate the resource to another TS; otherwise, it will accept the signaling message, create the TE, and send a receipt to the TA, which carries relevant information about the TE.

[1263] (2) Task parameter configuration

[1264] After creating the execution body (TE) for the task, you can deploy the task to the corresponding TE and distribute the necessary execution parameter configurations. The configurations include:

[1265] ●Basic execution information of the task, such as input, output, and model;

[1266] ● The QoS of the task, such as convergence time, accuracy, and energy consumption;

[1267] ●Workflow relationships between multiple tasks: After configuration, business interactions between TEs do not require command control by TA.

[1268] There are two options for sending task parameter configurations to the TE:

[1269] Option 1: Relay via TS. TS establishes the task context based on the task configuration, thereby enabling real-time scheduling and control of the task.

[1270] Option 2: Send configurations to TS and TE separately. The two configurations can differ. The configuration sent to TS is used to establish the task context, and the configuration sent to TE is used for task execution.

[1271] ●Task Execution Control

[1272] Task execution takes place on the TE and is handled automatically according to business logic. Data interaction between TEs does not require additional control from the TA; it is defined within the business logic. The TA only needs to configure the dependencies between TEs when configuring task parameters.

[1273] For example, in federated training among multiple Training Entities (TEs), a client TE, after completing its local training, will automatically push the gradients to the server TE without notifying the Training Entity (TA), which will then instruct on subsequent actions. This is crucial to prevent the TA from being overburdened by interfering with business logic.

[1274] It's important to note that in task deployment, the computing / connectivity resources managed by the TS can deploy multiple tasks. For example, if the TS is deployed at 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, when multiple UEs under the base station TS are performing tasks, the parameter adjustment instructions issued by the TS need to be scheduled by the task-signaling radio bearer (T-SRB);

[1277] b) Data scheduling for service interaction between TEs. For example, if a base station deploys a federated parameter server, and 10 UEs act as federated clients to upload gradients to the parameter server (PS), the TS needs to schedule the task-data ratio bearer (T-DRB).

[1278] 2) Scheduling in computing power sharing scenarios: scheduling computing power based on the computing power requirements of multiple tasks and the QoS of the tasks.

[1279] A task is a process in which the demand for computing power changes continuously, requiring real-time scheduling. For example, in the training of a neural network, the computing power required varies greatly depending on the layer. Furthermore, changes in the environment can affect the achievement of QoS during task execution, necessitating real-time control by the Task Manager (TS). This part will be discussed in the third stage, task updates.

[1280] ●Task Update

[1281] Wireless network environments are unstable and subject to real-time dynamic changes, such as user movement, interference variations, and sudden service disruptions, which can affect ongoing tasks. Therefore, task management and control functions need to be aware of these changes in the task execution environment in real time, adjusting task parameter configurations to ensure smooth task execution and guarantee QoS.

[1282] Figure 94 is a schematic diagram of task deployment.

[1283] In a three-layer task management architecture, the Task Manager (TS) is responsible for sensing changes in the network environment. Changes in the network environment can be divided into two categories based on whether the task topology has changed. Here, the topology refers to the network relationship between the Task Manager (TA), Task Manager (TS), and Task Equipment (TE) after a task is deployed.

[1284] Category 1: No change in topology. For example, changes in link QoS (users moved further away, increased interference) or changes in computing power (terminals running new apps) do not alter the topology.

[1285] The second category is changes in topology, such as changes in user state (entering inactive / idle), handover, lost UE, and the terminal having extremely low battery and needing to terminate tasks.

[1286] After TS detects a change in the task execution environment, its handling strategy is as follows:

[1287] (1) In scenarios where the topology remains unchanged, the TS updates the configuration directly in real time to ensure the smooth execution of tasks and QoS guarantees. For example, in a task involving base station terminals, if a link QoS change occurs, the base station TS can ensure the inference task continues to execute by configuring a new inference model split point.

[1288] (2) In scenarios where the topology changes, since the TS can only see subordinate tasks, it cannot assess the impact on the overall workflow when the topology changes, and therefore cannot make reasonable configuration adjustments. It is necessary to notify the TA so that the TA can make adjustments and reorganize the topology of the overall tasks.

[1289] ●Mission complete

[1290] After the task is completed, two aspects need to be processed: one is to provide feedback on the task execution results, and the other is to delete the task instance.

[1291] (1) Feedback on task execution results

[1292] After the task is completed, the execution result may be reported in two ways:

[1293] One approach is to directly output the execution result to the triggering source, such as the model trained by the network or the result of inference.

[1294] Another approach is to use the execution results directly in the network, only feeding back the address of the obtained results to the triggering source, such as AI models like the RRM algorithm within the RAN.

[1295] The TE can determine the triggering method and the address of the triggering source for the task execution result. This can be either passed down as a parameter during task deployment and actively pushed by the TE, or the TA can be notified that the task has ended and then issued a push command with the push method and the address of the triggering source.

[1296] (2) Delete task instance

[1297] After a task completes, the task instance needs to be deleted. This is part of the task's lifecycle management and is handled by the Task Agent (TA). After the task is completed, the Task Provider (TE) sends a message to the TA notifying them of the task's end, carrying the task ID. The TA then sends a command to the Task Manager (TS) associated with that task to delete the task context and the TE. Upon receiving the command, the TS deletes the task context, issues a command to delete the corresponding TE, reclaims computing power, and updates its own computing power status.

[1298] 12.3.1 Task Deployment

[1299] 1. Single-point task deployment

[1300] Regarding the configuration of single-point AI tasks, taking AI inference tasks as an example, the following aspects will be elaborated in detail:

[1301] The first aspect: Real-time management of tasks requires the execution of operations and corresponding messages.

[1302] Figure 95 is a schematic diagram of the task deployment method for connected UEs. As shown in the figure, for real-time control messages of a task, the task anchor point (which can be a network-side device or a UE) can achieve the following for the executor (which can be a network-side device or a UE):

[1303] - Method 1: Request / response mode, for task configuration of the device or UE at the task anchor point, each task configuration information, the execution body has a corresponding reply response message to inform of the result of this configuration (success, failure, partial success, etc.).

[1304] - Method 2: config mode (no response message), for AI task configuration (idle / inactive) of UE for task anchor point, the configuration message of each task is configured successfully 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 their associated configuration parameters:

[1306] Table 4: Task Deployment Message Table

[1307] The second aspect: Through which interfaces is real-time task management implemented?

[1308] Figure 96 is a schematic diagram of task deployment methods for idle UEs. As shown in the figure, for a scenario where the task anchor point is the RAN device and the task executor is the UE, the RAN configures the task signaling for the UE in the following three ways, depending on the different TRC states of the UE:

[1309] 1) Method 1: For idle UEs, the task is configured / reconfigured by broadcasting signaling through the system information block (SIB);

[1310] 2) Method 2: For inactive UEs, the task is configured / reconfigured via TRCReconfig message or TRCRelease message; the TRCReconfig message is sent by the base station when the inactive UE was previously in the connected state, and the UE does not enter the inactive state after receiving this message; while the TRCRelease message is also sent by the base station when the inactive UE was previously in the connected state, but the UE immediately enters the inactive state after receiving this message;

[1311] 3) Method 3: For connected UEs, configure / reconfigure tasks via TRCReconfig messages.

[1312] Furthermore, for scenarios where the task anchor point is a network-side device (CN network element or RAN network element) and the task executor is also a network device, task configuration is achieved through the following interface. Taking the 5G interface as an example, the AI ​​task configuration of the RAN device by the task anchor point (assuming it is CU) is achieved through the following interface:

[1313] ●CU->DU: Newly defined F1 message;

[1314] ●CP->UP: Newly defined E1 message;

[1315] ●gNB->gNB: Newly defined Xn message;

[1316] ●CN->gNB: New definition of Ng message;

[1317] Figure 97 concisely illustrates the interfaces and definitions for the device interfaces and the newly defined messages mentioned above.

[1318] Having discussed the configuration message above, the following describes what information is carried in the configuration message to complete the specific parameter configuration of the task, as in aspect 3.

[1319] The third aspect: What parameters are involved in the real-time management of the task?

[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 more of the 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, no additional definition is required or they should be included in the configuration message).

[1323] ■ Independent Inference: Algorithm ID (optional, configured only for independent inference)

[1324] ◆Input parameters: Input can be specific parameters, such as parameters defined by 3GPP, or data collected by the UE itself or provided by the network (in this case, CPU offloading);

[1325] Figure 98 illustrates the segmented inference process. The input and output parameters are the model's input and output parameters, respectively. In many cases, placing the entire AI / ML model inference process on the terminal or network side can lead to imbalances in computing and wireless communication resources between the terminal and network, as well as security and privacy issues. Therefore, it is advisable to rationally segment the AI / ML inference task, enabling joint inference on both the terminal and network sides. This reduces the pressure on the device's computing power, memory, storage, power consumption, and network transmission, lowers AI / ML inference latency and energy consumption, and improves inference accuracy and efficiency. The principle of AI / ML model segmentation is to transfer computations that consume more computing power and energy to network-side nodes, while keeping latency-sensitive computations and those required to remain on the terminal under certain privacy protection rules on the terminal. As an example, the terminal executes AI / ML operations to a specific part or executes the AI / ML model to a specific layer, sending the generated intermediate data to the network. The network-side nodes are responsible for executing the remaining parts of the AI / ML operations or the remaining layers of the AI / ML model and feeding back the inference results to the terminal. The selection of model split points should be based on factors such as the computing power consumed by each layer and the amount of data. 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 metric corresponding to this task; for example, for a single AI inference task, it can 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, AI task attributes include parameters such as geographic area, timer, number of executions of the AI ​​inference task, and application granularity of the AI ​​model. For example, the application granularity of the AI ​​model includes cell-level AI models, which are applicable to all UEs within the cell; and user-level AI models, which are only applicable to some UEs.

[1329] ■Geographical scope:

[1330] 1) Idle / inactive UEs are outside the geographic range, automatically delete old AI tasks, and notify the base station (optional);

[1331] 2) Automatically delete old AI tasks and base station delete tasks when connected UEs are outside the geographical range (optional);

[1332] ■Timeliness: When the timer expires, the task is deleted by idle / inactive / connected UEs; the configuration can be retained / deleted (it can be pre-configured by the base station or predefined by the protocol).

[1333] 1) Real-time type: adopts 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: Only for non-algorithm-based AI inference tasks, it supports one-shot, periodic, or event-based configurations, as well as periodic task management based on 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, area granularity (e.g., tracking area code (TAC), RAN-based notification area code (RANAC)), etc.

[1337] Regarding the specific parameters of the above tasks, the UE-side behavior is as follows:

[1338] ■Geographical scope:

[1339] Assume that each cell broadcasts its area ID, along with task configuration information (optional);

[1340] Figure 100 is a schematic diagram of task mobility. As shown, two cells are used as an example, denoted as 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. For example, the broadcast message can be a system information block (SIB).

[1341] 1) If an idle / inactive UE is outside the geographic range, automatically delete old AI tasks and notify the base station (optional);

[1342] 2) Automatically delete old AI tasks and base station delete tasks when connected UEs are outside the geographical range (optional);

[1343] 3) When an idle / inactive / connected UE accesses a new cell, it first uses the area id in the cell's SIB to determine whether it needs to reacquire the task configuration (and AI model configuration).

[1344] If it's 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 not a new area:

[1348] There is no need to retrieve the task configuration information for this cell again.

[1349] ■Timeliness: When the timer expires, the task is deleted by idle / inactive / connected UEs; the configuration can be retained / deleted (it can be pre-configured 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 immediately starts the timer;

[1351] ●Stop / delete the task after the UE-side timer expires.

[1352] ■Task execution count: Only for non-algorithm-based AI inference tasks, it supports configurations of one shot, periodic, or event, as well as periodic task management based on timer+number.

[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, incremented by 1 for each execution; or initial value = N (total number of times), decremented by 1 for each execution);

[1354] ●After the UE side executes the pre-configured number of times (N times), stop / delete the task.

[1355] 2. Collaborative task configuration

[1356] The main differences between configuring 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 multi-point collaboration is greater than or equal to 2;

[1358] 2) Simultaneous successful configuration: In a single-point task, if the configuration of a single executor is successful, the task is successful; however, in multi-point collaboration, since multiple executors need to be configured at the same time, there will be scenarios where some executors are configured successfully and some are not. How to roll back or restore the configuration in this case is the main problem to be solved in this scenario.

[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, the task can also be reconfigured by executor 1 to executor 2.

[1360] 4) Path configuration: There are multiple paths for collaborative information exchange between multiple executors in a collaborative task. The specific path to report needs to be pre-configured for 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 disconnection, configuration between executors, and multi-path reporting.

[1362] 1) Question 1: Configuring Associations

[1363] In configuring collaborative AI tasks, compared to configuring single-point AI tasks, configuring collaborative AI tasks involves the coordinated configuration of two or more executors. Therefore, it is necessary to additionally consider the configuration rollback issue in case the configuration of one or more executors fails. To address this, this application provides two solutions, as shown in Solution 1 and Solution 2 below.

[1364] Option 1: Configure simultaneously (no specific order)

[1365] Figure 102 is a schematic diagram of a collaborative AI task configuration scheme. As shown, in single-point AI task configuration, the task anchor only configures the task for one executor. However, in collaborative AI task configuration, the task anchor can configure the task for multiple executors simultaneously. Taking two executors, such as executor 1 and executor 2, as an example, the configuration of executor 2 does not depend on whether the configuration of executor 1 is successful.

[1366] One problem with this approach is that if the configuration of Executor 1 fails while the configuration of Executor 2 succeeds, the tasks cannot be executed collaboratively because the configurations of Executor 1 and Executor 2 are out of sync. In this case, additional signaling is needed to roll back the configuration, for example, to roll back the configuration of the collaborative task that was previously successfully configured in Executor 2 to the state before it was configured.

[1367] Option 2: Configure simultaneously (in a specific order)

[1368] Figure 103 is a schematic diagram of another collaborative AI task configuration scheme. In this scheme, the configuration of the collaborative task of the task anchor for the executor 2 depends on whether the configuration of the task anchor for the executor 1 has been successful. For example, if the task anchor successfully configures the executor 1, it will continue to configure the executor 2; otherwise, if the configuration of the executor 1 fails, the task anchor will not configure the collaborative task for the executor 2.

[1369] 2) Question 2: Inter-executive configuration

[1370] Taking two executors as an example, configuration between executors means that the task anchor point is not directly configured for executor 2, but rather executor 1 configures executor 2.

[1371] Figure 104 is a schematic diagram of the configuration between execution entities. The specific steps are as follows:

[1372] Step 1: The configuration of the task anchor point for executor 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 executor 2, such as Node id / UE id, Node type / UE type, etc.

[1373] Step 2: The configuration for executing Execution Body 2 includes 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: Multi-path reporting

[1378] For CU / DU separation and CP / UP separation scenarios, the collaborating parties can be CP, UP, and DU, which collaborate with the UE respectively. The reporting path is also configured by the task anchor point for the UE, such as configuring the layer name and node name to be reported.

[1379] ● When the task anchor is configured with a task for executor 1 / 2, the path for reporting task results can be specified:

[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 for 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 report directly to Executor 1. Instead, it may report to other network elements (such as task anchors). In this case, it needs to be transparently / non-transparently forwarded to Executor 1, carrying 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 a configuration of the task anchor point to the executor, or a configuration of the executor to other executors (e.g., the configuration of executor 1 to executor 2).

[1387] For scenarios requiring forwarding (e.g., in the scenario described above, the UE has different collaborative tasks with CU-CP, CU-UP, and DU simultaneously, and needs to report different collaborative information to these different nodes; and the reporting channel configured by task anchor point / executor 1 for executer 2 (UE in this example) is path 2 (e.g., carrying collaborative information at the TRC layer), it can also be other paths, with similar solutions). After parses the TRC signaling and obtains the corresponding collaborative information, if the CU-CP determines that it was not sent to itself and needs to further forward (through or without pass-through) to other entities (such as DU, CU-UP, etc.), then the CU-CP needs to perform the following additional operations:

[1388] Step 1: Determine if this message is for yourself.

[1389] Explicit method: For example, each cooperation information reported by the UE includes the identifiers 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 identifier (e.g., TRS / PHY needs to be forwarded to DU, T-SDAP needs to be forwarded to CU-UP; TRC needs to be processed by CU-CP);

[1392] Implicit method (task id): For example, if a task is configured to have only one reporting path, then 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 subsequent collaborative task information reported by the UE.

[1393] Step 2: If it needs to be forwarded to other entities:

[1394] Transparent forwarding: forwarding the entire content of the collaborative information to the destination network element through transparent transmission without parsing the specific content of the collaborative information;

[1395] Non-transparent forwarding: First, parse the specific content, then reorganize the message and send it to the destination network element.

[1396] The following section introduces task carrying, specifically involving signaling carrying and data carrying.

[1397] 12.3.2 Task Bearing

[1398] 12.3.2.1 Data Bearer

[1399] Figure 106 shows an example of an interactive scenario for task information, such as:

[1400] ●Scenario 1: Computation / data (serial) tasks, centralized business flow processing;

[1401] ●Scenario 2: Computation / data (serial) tasks, distributed business flow processing;

[1402] ●Scenario 3: AI training task (FL), gradient reporting, model update distribution;

[1403] ●Scenario 4: AI inference task (joint inference), interactive intermediate output.

[1404] To transmit task data in a wireless communication network, the following problems need to be solved:

[1405] 1) Question 1: Is TRB carried via signaling or data?

[1406] Figure 107 illustrates some possible methods for carrying task data. As shown in Figure 107, one possible method (Opt1 in the figure) is to carry task data using an SRB (represented as T-SRB in the figure). However, this method may have the following problems:

[1407] 1) Limited quantity (3 units, excluding NSA and QoE);

[1408] 2) Undifferentiated QoS;

[1409] 3) Maximum limit (16*9k), unable to support extremely large models / data.

[1410] Another method (as shown in Opt2 in the figure) is to carry task data through DRB (the figure shows the task data being carried).

[1411] DRB (represented as T-DRB) may have the following problems:

[1412] ■ Problem 1 - Non-transparent transmission: The current mode is base station transparent transmission mode. A non-transparent transmission mode needs to be added (i.e., the base station needs to parse and terminate it).

[1413] ■Question 2 - QoS-related issues:

[1414] For example, QoS metrics differ between computing, AI, and sensing tasks and communication tasks; the QoS metrics used for task QoS differ from those used for communication QoS.

[1415] For example, QoS mechanisms (RAN AI4NET scenario): without CN participation, the mechanism of CN generating QoS and passing it to RAN cannot be reused; without carrying IP information, the IP QoS flow mapping mechanism cannot be reused.

[1416] ■Question 3 - Protocol Stack:

[1417] New TRD (task resource data) - native AI layer;

[1418] Large models / data: PDCP SDUs (limited to 9k) cannot support large models;

[1419] (Uu)SDAP+: QoS flow DRB mapping mechanism cannot be reused;

[1420] ■Question 4 - Load-bearing capacity:

[1421] Different protocol stacks require dedicated transport for tasks.

[1422] The solutions to problems 1 to 4 mentioned above regarding DRB-borne task data are as follows:

[1423] (1) Solution 1 for Problem 1:

[1424] Add a new logical channel (LCH) type, such as "DRB type";

[1425] ◆ "Task type" or "Data type" (traditional session data). That is, data is divided into session data and task data, which are identified by datatype and task type, respectively.

[1426] (2) Solution 2 for problem 2

[1427] The current situation and solutions for Problem 2 are shown in Figure 108.

[1428] Scenario 1: How to transmit gradient information when the UE and DU are performing FL (Flexible Interaction)? One solution is to use T-SRB (Transmitter-Surveyed Module) for transmission and CU (Columbus Module) for forwarding: the UE and CU interact, and the CU forwards the information to the DU, resulting in excessive latency. Another solution is to use DCI / UCI / MAC CE (Digital Interface Code) to carry task information, with the DU parsing and processing the DCI / UCI / MAC CE. The disadvantages are small data volume and inflexible data format.

[1429] Scenario 2: How to transmit gradient information when the UE and CU-CP are performing FL? One solution is to use T-SRB as the bearer. The UE and CU-CP interact, and the DU discovers that it is a T-SRB bearer, so it directly forwards it to the CU-CP. The disadvantages are similar to those of SRB: size limitation and no QoS level.

[1430] Scenario 3: When the UE and CU-UP are performing computation offloading, how can the intermediate computation results be transmitted? One solution is to use T-DRB as a bearer, which can reuse the existing mechanism (the UE interacts with the DU, and the DU discovers that it is a T-DRB bearer, so it directly forwards it to the CU-CP). However, the CU-UP can currently only pass through T-DRB and cannot parse and terminate it.

[1431] The second solution to the above problem 2 provided in this application is as follows:

[1432] Full-stack T-DRB

[1433] 1) DU Protocol Stack

[1434] Originally: Only PHY and TRS were used;

[1435] Currently: PHY, TRS, and T-DRB (PHY / MAC / RLC / PDCP / SDAP / TRD).

[1436] 2) CU-CP protocol stack

[1437] Originally: T-SRB;

[1438] Currently: T-SRB and T-DRB.

[1439] 3) CU-UP protocol stack

[1440] Originally: Only T-DRB was available;

[1441] Currently: No new additions.

[1442] DU forwarding strategy:

[1443] Originally: DCI / UCI / MAC CE is given to itself, SRB to CU-CP, and DRB to CU-UP;

[1444] Now: Based on the different T-DRB numbers, decide whether to use it for self-use (path 1), transfer it to CU-CP, or CU-UP.

[1445] CU-CP forwarding strategy:

[1446] Originally: T-DRB reception was not supported;

[1447] Now: Receive T-DRB and terminate unconditionally (path 2);

[1448] CU-UP forwarding strategy:

[1449] Originally: Receive DRB and pass it through to UPF;

[1450] Now: Identify which ones are for themselves (path 3) and which ones are for UPF based on the T-DRB ID (path 4).

[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 needs to be added.

[1453] ■AI Layer:

[1454] ◆Due to the PDCP SDU size limitation (9k), in order to support the transmission of larger models, a segmentation / concatenation function needs to be added to the TRD layer;

[1455] ◆TRD Features: Added AI training / inference / model processing functions (compression / pruning / quantization / security, etc.);

[1456] ◆Data Layer / Computation Layer / Perception Layer: Supports the data plane / computation plane, etc.

[1457] (4) Solution 4 for problem 4

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

[1459] ● The cNode / sNode configures the UE to establish different DRBs and maps task data to DRB1,2; and data data to DRB3,4.

[1460] ●After receiving uplink DRB data, cNode / sNode distinguishes between DRB IDs 1 and 2, processing and terminating them themselves; DRB IDs 3 and 4 need to be forwarded to 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 create multi-point collaboration channels and provide a complete operating environment for AI tasks. Unlike the session-connection-centric architecture of traditional networks, 6G endogenous AI is task-centric, managing, scheduling, controlling, and executing tasks throughout their lifecycle.

[1464] Because wireless network environments are unstable and subject to real-time dynamic changes, such as user movement, interference variations, and sudden service disruptions, ongoing tasks can be affected. Therefore, task management and control functions need to be aware of these changes in the task execution environment in real time, adjusting task parameter configurations to ensure smooth task execution and guarantee QoS.

[1465] Changes in the network environment can be categorized into two types based on whether the task topology changes.

[1466] Category 1: No change in topology. For example, changes in link QoS (users moved further away, increased interference), changes in computing power (terminals running new apps), etc., do not alter the topology. Category 2: Changes in topology, such as changes in terminal state (e.g., terminals entering inactive / idle state), terminal handover, TE Dropout, etc.

[1467] The procedures for handling these two types of environmental changes differ, and they will be described separately below.

[1468] ● Changes in topological relationships

[1469] Since the TS can only see subordinate tasks, it cannot assess the impact on the overall workflow when the topology changes, and therefore cannot make reasonable configuration adjustments. The TA needs to be notified so that it can adjust and reorganize the overall task topology. For example, if a user switches to another station, and the TS simply migrates the task context to the new station, it will increase the data interaction latency between the TE and UE on the source station, and the overall service QoS cannot be guaranteed. In this case, the TA should assess the impact of the UE handover latency on the overall workflow and adjust the relevant task configurations to ensure the overall service QoS.

[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 the Task Controller (TS) detects a change in the task execution environment that will affect the task topology, it needs to notify the Task Agent (TA) so that the TA can make a decision, 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, reason for change, etc. The reason for change can include information elements (IEs) such as category, object, and magnitude.

[1473] Step 3: After receiving the change notification, the Task Agent (TA) makes an adjustment decision, modifies the task configuration, and reorganizes the topology. The decision-making scheme depends on the algorithm implementation, and the final configuration modifications can be roughly divided into the following levels:

[1474] (1) TS changes. The task execution body remains unchanged, but the relevant task context is established on the new TS, and the new TS is updated in the task topology. For example, after a user switches to a new base station, the task context is established on the new base station TS;

[1475] (2) TE change. Abandon the previous execution body of the task and switch to the new execution body. All intermediate execution processes such as data / model / configuration need to be moved to the new TE. It may also be necessary to select the corresponding new TS based on the new TE. If there is business interaction between multiple TEs of the task, the topology relationship between TEs also needs to be updated.

[1476] (3) If the topology changes beyond the current TA's management domain and enters a new TA's management domain, a complete task execution environment needs to be re-established under the new TA, which is equivalent to creating a new task.

[1477] Step 4: After the decision-making plan is formulated, the new configuration is distributed to the relevant network elements.

[1478] Here are a few specific examples (cases) to illustrate this:

[1479] ●Case 1: Adjustment when the terminal enters idle mode

[1480] Figure 111 illustrates task data transmission for an idle UE. As shown in Figure 111, when the UE enters idle mode, tasks previously deployed on the UE cannot be scheduled or controlled, nor can they interact with the TS and TE. Task QoS cannot be guaranteed, necessitating adjustments to the task execution environment. The process is as follows:

[1481] Step 1: The TS (Transmission Service) where xNB1 is located, based on the previously established task context, identifies that the UE has a related task being executed, triggering the task environment change handling procedure. The UE enters idle mode, determines that this situation involves a change in task topology, and needs to notify the TA (Task Controller).

[1482] Step 2: xNB1 sends a mission environment change notification to TA, including the mission ID, reason for change, etc. For example, the reason for change includes: Category = UE IDLE, Object = UE ID.

[1483] Step 3: After receiving the notification, the TA identifies the UE's role in the overall task based on its UE ID and decides on the adjustment plan. As mentioned above, the decision plan is a specific algorithm implementation; here is an example: paging the corresponding UE, establishing the UE task context at the new base station xNB2, and updating the topology.

[1484] Step 4: The TA triggers the core network to page the UE and confirm that the UE has newly connected to base station xNB2.

[1485] Step 5: Configuration distribution. Create a UE task context on TS@xNB2 and update the topology. Here, TS@xNB2 represents the task scheduler on xNB2. This will not be repeated in the following examples.

[1486] In one example of the TA decision-making process described above, step 4 requires adding interaction messages between the TA and the CN, as well as adding Task awareness functionality to the CN. Figure 112 illustrates the task data transmission upon task completion.

[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 paging process of the core network can reuse the existing paging process, but after paging is successful, a task awareness function needs to be added. After the UE accesses the new base station, the CN informs the TA of the new base station's information.

[1488] ●Case 2: Adjustments after terminal switching

[1489] During task execution, the UE switches to another base station, causing the original base station to be unable to continue task scheduling and control for the UE, and the task QoS cannot be guaranteed. Therefore, adjustments to the task execution environment are required. The process is shown in Figure 113, which illustrates the task adjustment process during terminal handover.

[1490] Step 1: After a UE handover, the TS on xNB1 identifies that the UE has related tasks being executed by it through the previously created task context, triggering the task processing flow. UE handover determines that the task topology relationship has changed and requires notification to the TA.

[1491] Step 2: xNB1 sends a mission environment change notification to TA, including the mission ID, reason for change, etc. As an example, the reason for change includes: Category = UE HO, Object = UE ID.

[1492] Step 3: After receiving the notification, the TA identifies the UE's role in the overall task based on the UE ID and decides on the adjustment plan. As an example, the adjustment plan could be: keep the base station TE unchanged, establish the UE task context on the new base station xNB2, and update the topology.

[1493] Step 4: Configuration distribution. Create a UE task context in TS@xNB2 and update the topology.

[1494] 2. Real-time coordination of the four elements.

[1495] Figure 114 is a schematic diagram of the real-time coordination 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 in response to changes in the environment or the state of a particular element, or for reasons such as achieving better performance or energy conservation. For example:

[1497] ●Connection → Algorithm (i.e., adjusting the algorithm based on changes in connection state): The UE and base station perform joint inference, and the base station adjusts the model on the UE side:

[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] ■ Connectivity status, for example, when bandwidth is low, adjust the split point to a position with less output in the middle;

[1500] ●Model → Connection (i.e., adjusting connection resources based on model changes): Federated learning between UE and base station:

[1501] ■ After the base station adjusts the model of the UE, the gradient information of different models or segmentation points is different, and thus different air interface resources (SPS or GF) are allocated.

[1502] ●Data → Nodes (i.e., adjusting nodes based on data)

[1503] ■Base stations select UEs to report based on the principle of non-independent identically distributed (non-IID).

[1504] 12.3.4 Mobility

[1505] Due to the mobility of terminals, updating the state of tasks becomes more complex, requiring consideration of the following issues:

[1506] ●Question 1: For old tasks of the UE in the source cell, after the UE moves and switches / camps to the target (new) cell, how is the computation context of the old task migrated, and is the TA / TS migrated, so as to enable the continued execution of the old task.

[1507] ●Question 2: After a UE moves / reselects to a target (new) cell, the configuration of new tasks in the target (new) cell takes time. How can the UE obtain the configuration of new tasks as early as possible and use them in advance?

[1508] To address the above issues, this application proposes corresponding solutions, as shown in Solution 1 and Solution 2 below.

[1509] ● Solution 1 for the aforementioned problem 1 is shown in Figure 115, which is a schematic diagram of task context transition during scenario switching. Specifically, Solution 1 is as follows:

[1510] ■The executor of the old task (from the source community) switches / does not switch as the task anchor point changes:

[1511] ◆Negotiation: Requires the exchange of task progress information in order to decide whether to migrate the executor / task anchor point, etc.

[1512] ◆The source transmits the remaining computing power to the target, such as computing power (task completion rate / remaining computing power) and algorithms (AI models, data, etc.);

[1513] ■ Should the execution entity be switched during the target decision-making process?

[1514] If a handover is performed: the UE's computational context is migrated from the source base station to the target base station:

[1515] ◆Training tasks: Algorithm (learned model, unupdated gradient information), data (unlearned data), etc.;

[1516] ◆Inference tasks: data (remaining inputs), algorithms (remaining models), etc.

[1517] ●Solution 2 to the above problem 2 is shown in Figure 116. Figure 116 is a schematic diagram of the advance acquisition of neighboring cell task configuration in a UE mobile scenario. Specifically, Solution 2 is as follows:

[1518] ■ (Target cell) New task configuration: In order to reduce configuration signaling overhead, new / old task configurations (such as computing power, algorithm, data, connection, etc.) need to be transferred between stations; for connected UEs: perform handover; for idle UEs: perform reselection.

[1519] Optionally, for connected UEs, there are two schemes, which will be explained below with reference to Figure 117.

[1520] Opt1: To reduce the configuration overhead of AI tasks assigned to the UE by the target cell, the following process can be included:

[1521] Step 1: The source cell transmits its task configuration information to the target cell (existing handover (HO) procedures can be reused, but the task configuration is carried).

[1522] Step 2: The target cell performs delta configuration based on the configuration of the old task obtained (for example, if there are 10 parameters in total for the task, and the configuration of 9 parameters is the same in the configuration of the source cell and the target cell, then the target cell only needs to send the one 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 transmits the target cell's configuration to the UE in the HO CMD (carrying the task configuration).

[1525] Opt2: To avoid carrying the task configuration in step 3 of the above Opt1 scheme, only the task configuration index can be carried in this step, thereby reducing the configuration overhead of the ground interface and air interface; however, at this time, the enhancement needs to add 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 starts up, as shown in scheme 2 in Figure 125.

[1526] For idle UEs, the following three schemes are provided (e.g., 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 read the target cell's SIB to obtain the task configuration of that cell; this solution can save the UE the time of reading the target cell's SIB), the following process is available:

[1528] Step 1: Initiate messages and obtain task configuration information from neighboring cells via the inter-station interface;

[1529] Step 2: This cell broadcasts the task configuration information of neighboring cells via SIB;

[1530] Option 2a: As shown in Figure 119, each cell will broadcast its own area ID, and the UE can assume that cells within the same area ID have the same task configuration;

[1531] Step 1: Obtain the task configuration information (including area ID) of neighboring cells through the inter-station interface;

[1532] Step 2: This cell broadcasts the task configuration information (including area ID) of neighboring cells via SIB;

[1533] Optionally, if the area ID of this cell is different from that of a neighboring cell, more task configuration information can be requested from the neighboring cell.

[1534] Step 3: This cell requests AI models from neighboring cells;

[1535] Step 4: Neighboring cell feedback;

[1536] Step 5: This cell broadcasts the neighbor cell model in SIB.

[1537] Option 2b: As shown in Figure 120, interact with the area ID and task configuration parameters via Xn setup (regardless of whether the area IDs of the two cells are the same).

[1538] Step 1: Obtain the task configuration information (including area id + task configuration parameters) of neighboring cells through the inter-station interface;

[1539] Step 2: This cell broadcasts the task configuration information of neighboring cells via SIB (including area id + task configuration parameters (optional)); when the area id of this cell is different from the area id 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 needs to be broadcast (because it is the same as the task configuration parameters of this cell).

[1540] 13. New feature in 6G - Connectivity+ (i.e., the feature of hyperconnectivity).

[1541] A fully decoupled network architecture that supports:

[1542] ● Separation of control and data nodes

[1543] Applicable scenarios: Simplified carrier (carrier is only used for data transmission), extreme energy saving (dynamically turn sNode on / off), extreme aggregation of radio access technology (RAT) (cNode centrally controls LTE, NR, 6G);

[1544] ● Separation of uplink and downlink nodes

[1545] Applicable scenarios: UL-only Node (increases uplink coverage / throughput, enables TDD heterogeneous ratio, enables full-duplex), heterogeneous networks;

[1546] ● Uplink and downlink spectrum separation

[1547] Applicable scenarios: spectrum cloudification, separate management of uplink and downlink carriers;

[1548] ●Separation of uplink and downlink RF

[1549] Applicable scenarios: Unified independent radio frequency (RF) management (optimized RF scheduling).

[1550] ●Separation of perception / AI control and execution

[1551] Applicable scenarios: centralized AI management and control using cNode.

[1552] 13.1 Separation of Control and Data Nodes

[1553] Figure 121 is a schematic diagram of the separation of control and data. As shown in the figure, the cNode provides the control function of the connection and is responsible for the CP function, 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 data connectivity. Specifically, the sNode provides data transmission capabilities. 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 achieving a simplified data carrier.

[1555] Separating control and data nodes enables high-frequency, high-efficiency transmission. Figure 122 illustrates a low-frequency-assisted high-frequency transmission under this separation. As shown in Figure 122, the low-frequency cNode assists the high-frequency sNode, enabling fast high-frequency beam alignment and reducing beam scanning overhead and access latency.

[1556] Separating control and data nodes can enable network energy saving. The cNode can dynamically turn sNodes on and off based on the number of access users and user service needs, thereby reducing network energy consumption while ensuring data services.

[1557] Separating control and data nodes enables extreme aggregation of multiple RATs, such as aggregating 5G and 6G, as shown in Figure 123. Figure 123 is a schematic diagram of multi-RAT aggregation under the separation of control and data nodes. The cNode can provide seamless dynamic switching and aggregation of physical layers. A terminal may only connect to a single type of TRC connection, but the cNode can enable the terminal to seamlessly support switching or aggregation of two different air interface standards.

[1558] The protocol stack for multi-RAT extreme aggregation is shown in Figure 124, which illustrates the separation of control and data nodes in multi-RAT aggregation (TRS layer traffic offloading). The multi-RAT protocol stack shares a single PDCP, RLC, and TRS layer. Unlike dual-connectivity DC which offloads traffic at the PDCP layer and carrier aggregation CA which offloads traffic at the TRS layer, extreme aggregation offloads traffic from multiple RATs at the physical layer, enabling joint physical layer processing and thus enabling fast / efficient multi-RAT collaboration.

[1559] Figure 125 is a schematic diagram of a network topology where control and data nodes are separated. As shown in Figure 125, control always originates from the cNode, with independent RRUs providing extremely wide coverage, and the cNode performing centralized connection control, unified functions such as interference coordination and resource allocation.

[1560] 13.2 Separation of Uplink and Downlink Nodes

[1561] The uplink and downlink access nodes can be different. UL-only nodes can be deployed in the network; these nodes only have a receive module and no transmit module, for example, no power amplifier. UL-only nodes are characterized by low cost and ease of deployment. Dense deployment of UL-only nodes can significantly improve network performance, including one or more of the following:

[1562] Improve uplink SNR, and enhance UL coverage and throughput;

[1563] Uplink and downlink physical isolation enables heterogeneous TDD;

[1564] Uplink and downlink physical isolation enables full-duplex operation.

[1565] Traditional solutions for improving uplink coverage include heterogeneous TDD, where macro and small cell TDD ratios differ, or full-duplex technology. However, self-interference and cross-interference are the main problems faced by full-duplex and heterogeneous TDD. Deploying UL-only nodes can increase the distance between the DL RRH and UL RRH, reducing self-interference power and thus lowering the implementation complexity of advanced receivers; it also shortens the distance between the UL RRH and the UE, thereby improving UL reception power and reducing cross-interference from neighboring DL RRHs. Through spatially separated DL and UL RRHs, full-duplex or heterogeneous TDD becomes possible.

[1566] The separation of uplink and downlink nodes can also be applied to heterogeneous networks like HetNet, as shown in Figure 126, including the following scenarios:

[1567] 1) Low-frequency + high-frequency TRP, downlink access to high-frequency TRP, uplink access to 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 area, it accesses the Pico cell for uplink and the macro cell for downlink.

[1569] The uplink and downlink nodes are separated, and 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, which is cell-based management. A cell can be paired uplink and downlink FDD spectrum, TDD spectrum, or TDD spectrum plus SUL spectrum. 6G adopts independent uplink and downlink spectrum management, which is UE-centric uplink and downlink carrier resource pool management. It flexibly selects the optimal carrier from the downlink and uplink carrier resource pools for the UE, ensuring that the UE always has the primary carrier, the best link, zero handover waiting time, and resource sharing between carrier pools, providing the best capacity balance and the best edge coverage performance.

[1572] Uplink and downlink spectrum separation, including:

[1573] ●Flexible carrier switching: As shown in Figure 127, multi-carrier cooperative TDD configuration, 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 carried out at a high frequency. If there is a retransmission, for example, if the initial transmission fails and a NACK is returned, the retransmission is carried out at a low frequency. Semi-static / dynamic switching between multiple carriers increases uplink transmission opportunities and improves coverage; low-frequency assistance for high-frequency retransmission improves high-frequency robustness.

[1575] ●Cooperative carrier: As shown in Figure 129, dynamic data switching between multiple carriers allows large data packets to be transmitted at high frequencies, while small data packets or UEs that cannot be paired are transmitted at low frequencies, thereby improving the efficiency of the high-frequency spectrum.

[1576] 13.4. Separation of Uplink and Downlink RF

[1577] Uplink and downlink RF are managed independently. RF includes antennas, radio frequency channels, etc. 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 the UE transmits data on a single carrier, the base station can instruct the UE how many antennas to use for transmission, enabling Super Uplink. It supports switching all transmit antennas to a single carrier.

[1579] ● Flexible indication of the number of antennas used for channel sensing: For SRS antenna selection, the base station instructs the UE on how many antennas and how many ports to use for SRS transmission on a single carrier. It supports using all transmit antennas for SRS transmission on a single carrier, enabling fast antenna selection.

[1580] ● Flexible RF handover instruction for carrier pool management: The base station instructs the UE to switch the RF for measurement of another carrier, thereby maintaining the channel quality information of each carrier in the carrier pool.

[1581] ● Flexible instruction and cooperation RF group: Utilize RF cooperation between UEs to form multiple transceiver antennas and transceiver channels.

[1582] 13.5 Separation of Perception / AI Control and Execution

[1583] An AI control unit is an 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 communication or AI services. It is deployed on a cNode. The AI ​​control unit can operate without sensing operations, or it can use sensing to assist AI. For example, the AI ​​control unit can use sensing information as part or all of its AI training input dataset, thereby realizing a sensing-based AI framework.

[1584] AI agents are used to assist AI control units in AI operations. AI agents can focus on AI model execution and related transmission functions. AI agents are deployed on sNodes.

[1585] A sensing control unit (SCU) is a sensing management and control unit for one or more RANs or UEs. It serves as the sensing computing and processing center, using collected sensor data as input to provide the necessary measurement information for communication or sensing services. Sensing can include positioning and other sensing functions, such as IoT and environmental sensing features.

[1586] A sensing agent can perform sensing operations to provide sensing and AI services. For example, it can perform measurements to collect data and provide sensing information as part or all of its AI training input dataset.

[1587] The AI ​​control unit and perception control unit on the cNode realize centralized AI and perception management, solving the problems of complex interaction and difficult coordination among multiple agents in the distributed AI / perception architecture.

[1588] 14. New features in 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 placing more urgent demands on communication and computing. Communication networks, as conduits connecting users and transmitting data, are capable of sensing computing and supporting the efficient use of diverse distributed computing resources. For example, edge computing deployed within communication networks to reduce end-to-end latency and improve service experience has become a hot topic in the industry. Diverse computing resources and the convergence of communication and computing have become important technological trends in the industry.

[1591] In 6G networks, computing resources will be distributed across various infrastructures, including central cloud, edge cloud, network equipment, and even terminal devices. 6G CaaS (Communication as a Service) provides on-demand, endogenous computing services to users based on various distributed computing resources within the network, particularly offering high-performance computing services for terminals with limited computing resources or power, and for intelligent services with extreme performance or high data security and privacy requirements. 6G CaaS will enable the on-demand "flow" of various distributed computing resources in 6G, breaking through the limitations of single-point computing performance and improving the overall efficiency of computing applications.

[1592] To achieve 6G CaaS and better provide users with inclusive computing services, the 6G architecture needs to natively support the convergence of communication and computing, enabling intelligent scheduling of ubiquitous network computing resources and deep collaboration with connectivity resources. This will allow the 6G network to become a dual infrastructure for both connectivity and computing. The goal of the convergence of communication and computing in 6G networks is to meet AI QoS requirements in dynamic and complex wireless environments while achieving optimal efficiency for both network and computing resources. Currently, the industry generally uses two forms of convergence: external computing resources and intrinsic computing resources. External computing resources, such as edge computing, involve joint optimization of the communication resources of network nodes and the computing resources of computing nodes through management plane functions. Intrinsic computing resources utilize the network's inherent computing resources, where network nodes not only possess control and forwarding capabilities but also have computing power.

[1593] The deep integration of communication and computing is a key technological feature of AI inherent in 6G networks. AI services provided through traditional cloud AI require more effective fundamental safeguards for data security and privacy, and more efficient sharing mechanisms for distributed computing resources and AI models are needed to support providing users with the necessary AI services at a relatively low cost while ensuring service quality. The AI ​​capabilities inherent in 6G networks—that is, providing AI services via network AI (artificial-intelligence-as-a-service, AIaaS)—are expected to address these challenges and become a valuable supplement to cloud AI in business scenarios requiring extreme performance and high security and privacy. In network AI scenarios, how to provide users with lower latency jitter, higher overall efficiency computing services, and ensure AI QoS services based on the efficient collaboration of communication and distributed computing resources remains an unsolved problem. One important technical challenge is the integration of communication and computing, namely, achieving deeper and real-time collaboration between communication and computing to ensure ultra-low latency, high data security and privacy, and sustainable energy saving for future new services in dynamic and complex wireless network environments.

[1594] 14.2 Overview of Calculation Surfaces

[1595] Figure 130 is a schematic diagram of the computation plane. As shown in Figure 130, the computation plane includes a computation control section, a computation execution section, and a computation data transmission section (referred to as the computation transmission section). The computation control section includes computation execution control and computation connection control. The computation execution section refers to the process by which the computation execution functions of nodes (such as RAN nodes and UE nodes) use the computation resources allocated by the computation control to execute computation tasks. The computation transmission section refers to the interaction of computation data between the computation execution functions of different nodes using computation connections, thereby enabling different nodes to collaborate in completing computation tasks.

[1596] The computing connection control system monitors the status of computing connections in real time, controls connection resources and quality, and supports service continuity guarantees under terminal status awareness and mobility. It 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] Computation execution control allocates computing resources used by node computing execution functions, controls the amount of computing operations performed, controls computing quality, and supports terminal mobility. Computation resource control monitors the status of computing resources in real time and controls their allocation, such as adding, modifying, deleting, and releasing resources. Computation quality control orchestrates computing operations and configures relevant parameters (such as computing precision, quantization precision, and sparsity) based on resource quantity, accuracy, and latency requirements. Computation execution control also supports terminal mobility, computing resource address management, access control for computing services, control of terminal computing resources, and computing resource management control when multiple computing resources are aggregated.

[1598] Based on the different technical domains to which the computing control functions belong, they are divided into core network domain xCN computing control and RAN domain computing control. Among them, RAN domain computing control includes the implementation of TRC+ function to compute radio bearers, the management and control of computing bearers; the implementation of computing resource control (CRC) function, the management and control of computing atomic tasks, including requesting, creating, updating, and deleting, real-time scheduling of computing resources, and real-time perception of computing power status, reporting overall computing power information to the xCN domain computing execution control function to facilitate its maintenance of global computing power map information.

[1599] On the one hand, in scenarios where multiple nodes collaborate to complete computing tasks, the quality of computing connections and the quality of computing execution jointly determine the overall quality of the computing task, thus creating the possibility of joint optimization. On the other hand, the sharing of connection resources between computing and communication connections exacerbates the dynamic nature of connection resource states. These dynamically changing resource states have a real-time impact on computing quality, requiring joint consideration. Furthermore, for terminals executing computing tasks while in motion, the control of computing connections and computing execution will be performed synchronously, and the state and quality objectives of computing connections and computing resources will influence their switching decisions. Therefore, it is evident that there is a need and possibility for the integration of computing execution control and computing connection control on the computing plane, i.e., "integrated computing control."

[1600] The convergence of computing and communication technologies supports mutual awareness and coordination, enabling the rational allocation of computing resources and computing connection resources. For example, the convergence control can use the computing resource control section to sense changes in the computing resources required by the radio bearer due to user mobility and dynamic environmental changes, thereby adjusting computing resources in real time; or it can use the computing connection control section to sense the computing resource status in real time and dynamically adjust the user's connection bandwidth, thereby continuously ensuring the QoS of computing services. For example, the 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] Computational power awareness specifically refers to the need for 6G-native AI networks to perceive information about computing resources, such as the type, quantity, and usage status of computing power. This awareness enables the perception of heterogeneous physical resources such as GPUs, CPUs, and field-programmable gate arrays (FPGAs). Furthermore, 6G-native AI networks need to perceive the types and amounts of computing power required by different algorithms, such as artificial intelligence (AI), machine learning, and neural networks, thereby enabling the rational allocation of computing resources.

[1604] Optionally, the UE needs to report its computing power capability and computing power status to the base station.

[1605] ● Capability Reporting

[1606] Step 1: The base station transmits information such as the mode / method for instructing the terminal to report computing power via SIB / TRC, which includes information such as the reporting type, reporting granularity, and reporting path.

[1607] 1) Reporting type: CPU, GPU, NPU, FPGA, etc.; or storage, memory, power, etc. This can prevent terminals whose computing power does not meet the base station's requirements from reporting their computing power, resulting in invalid reporting and wasted bandwidth resources.

[1608] 2) Reporting granularity: such as 1 / 10 / 100 CPU scheduling granularity, 1 / 10 / 100MB storage and memory scheduling granularity, 1% / 5% / 10% power scheduling granularity, or combinations of the above resource scheduling granularities, etc., can prevent terminals with computing power less than the base station scheduling granularity from reporting terminal computing power, and reduce computing power reporting overhead.

[1609] 3) Reporting methods: L1, L2, L3 signaling; the reporting method can also be a predefined method of the protocol, such as one or more of the L1, L2, or L3 signaling methods.

[1610] Step 2: The terminal reports its computing power capability based on the reporting mode / method. The terminal uses L1 / L2 / L3 signaling to report its computing power capability according to the configured reporting granularity, reporting type, etc.

[1611] 1) For example, L1 signaling, such as random access preamble indicating whether the terminal includes computing resources greater than the reporting type and reporting granularity of the network side broadcast (the network side broadcasts random access preamble packets; the computing power included by the terminal using group 0 preamble is less than the reporting type and reporting granularity of the network side broadcast; the computing power included by the terminal using group 1 preamble is greater than or equal to the reporting type and reporting granularity of the network side broadcast).

[1612] 2) For example, in L2 signaling, the computing power capability TRS CE includes the maximum number of computing resource combinations supported by the terminal;

[1613] 3) For example, L3 signaling, UECapabilityInformation signaling includes: UE logical computing, parallel computing, neural network computing, dedicated computing capabilities, and other types of computing power capabilities. UE storage c...

Claims

1. A radio access network (RAN) architecture, characterized by, The RAN is deployed, including a cluster control node and a service node; The cluster control node is configured to provide regional-level centralized coordination functions of a plurality of service nodes and coordination functions between the cluster control nodes across regions; The service node is configured to provide scheduling and execution functions of tasks.

2. The RAN architecture of claim 1, wherein, The cluster control node provides a control plane function of a connection over an air interface, and the service node provides a user plane function of the connection over the air interface; or The cluster control node does not provide a connection function over the air interface, and the service node provides a control plane function and a user plane function of the connection over the air interface.

3. The RAN architecture of claim 1 or 2, wherein, The RAN architecture is a non-service-based architecture (SBA) architecture; The non-SBA-based architecture includes: The cluster control node and the service node are connected to each other through a Y1 interface; The cluster control node and other cluster control nodes are connected to each other through a Y2 interface; The service nodes are connected to each other through a Y3 interface.

4. The RAN architecture of any one of claims 1 to 3, wherein, The cluster control node is connected to a core network through one or more of the following interfaces: connected to a task control function (TCF) and a task processing function (TPF) of the core network through a T2 interface; connected to a network access function (NAF) of the core network through a T3 interface; connected to a connection function control plane (CF-C) of the core network through a T4 interface.

5. The RAN architecture of any one of claims 1 to 4, wherein, The service node is connected to the core network through one or more of the following interfaces: connected to a network access function (NAF) of the core network through a T5 interface; connected to a connection function control plane (CF-C) of the core network through a T6 interface; connected to a connection function user plane (CF-U) of the core network through a T7 interface.

6. The RAN architecture of claim 1 or 2, wherein, The RAN architecture is an SBA-based architecture; The SBA-based architecture includes: The cluster control node provides a first service interface (S-c); The service node provides a second service interface (S-s); The first service interface and the second service interface are connected to a service bus of the RAN.

7. The RAN architecture of any one of claims 3 to 5, wherein, The RAN architecture includes one of the following connection architectures: In a first connection architecture, a control plane (CP) and a user plane (UP) of an air interface are separated, the cluster control node has a CP function of a connection, and the service node has a UP function of the connection; or In a second connection architecture, the CP and the UP of the air interface are not separated, the cluster control node does not provide a connection function, and the service node provides a CP function and a UP function of the connection. The RAN architecture includes a third connection architecture in which the CP and the UP of the air interface are separated; 8. The RAN architecture of claim 6, wherein, The cluster control node provides the first service interface, which is used for invocation of a core network element to transmit a control plane signaling of a connection and is also used for invocation of other cluster control nodes to provide a mobility signaling function; ​ The service service node provides the second service interface, and the second service interface is used for calling of a core network element to transmit user plane data, and the second service interface is also used for calling of other service service nodes to provide a mobility data forwarding function, wherein data forwarding between the service service nodes is controlled by the cluster control node.

9. The RAN architecture of claim 6, wherein, 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; The service service node provides the second service interface, and the second service interface is used for calling of a core network element to transmit control plane signaling and user plane data of a connection; The second service interface is also used for calling of other service service nodes to provide mobility signaling interaction and data forwarding functions.

10. The RAN architecture of any one of claims 3 to 5, wherein, The RAN architecture is a task architecture for a first function, and the first function includes one or more of computing, data, intelligence and trust; The task architecture includes: The cluster control node is configured to provide a control plane function and a data processing function of the first function; The service service node is configured to provide a partial control plane function and a user plane function of the first function, and the user plane function includes task scheduling (TS) and task execution (TE); The cluster control node and the service service node manage tasks through the Y1 interface, the cluster control nodes negotiate tasks through the Y2 interface, the cluster control node and a core network element negotiate tasks between network domains through a T2 interface, and the service service nodes negotiate tasks between the TEs through the Y3 interface.

11. The RAN architecture of claim 6, wherein, The RAN architecture is a task architecture for a first function, and 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 interface, which is used for transmission of task negotiation signaling and task data across network domains; the first service interface is also used for calling of other cluster control nodes to transmit task negotiation signaling and task data across regions; The service service node provides the second service interface, which is used for task control signaling interaction and task data transmission of the cluster control node to the service service node; the second service interface is also used for calling of other service service nodes to transmit task data between the service service nodes.

12. The RAN architecture of any one of claims 3 to 5, wherein, 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 service service node includes the TWG, The TWE is configured to provide global decision and management information of a trusted plane for a network, and provide a trusted policy input for the TWG, activate and manage a trusted service; The TWG is configured to receive configuration and management of the TWE to perform a trusted capability. 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, respectively; 13. The RAN architecture of claim 6, wherein, ​ The TEF is configured to provide global decision and management information for a trusted face of a network, and to provide a trusted policy input, activate and manage a trusted service for the TGF; the TGF receives configuration and management of the TEF to perform trusted capability; The TEF provides a third service interface (S-e); The TGF provides a fourth service interface (S-g); The third service interface and the fourth service interface each provide one or more of the following functions: trusted service invocation, trusted information subscription, trusted function management.

14. The RAN architecture of any of claims 1-13, wherein, The RAN supports a first function in connection and out of connection, the first function including one or more of computing, data and intelligence; For the relationship between the connection and the first function, the design of the air interface protocol stack adopts one of the following options: Option one: the first function is integrated into the control plane of the connection and the user plane of the connection; Option two: the first function is integrated into the control plane of the connection to form a converged control plane, the user plane of the connection remains unchanged, and an independent task data plane for the first function is added; Option three: a task control plane and a task data plane are added for the first function, and the control plane and the user plane of the connection remain unchanged; Option four: an independent computing plane, data plane and intelligence plane are added for the first function, and the control plane and the user plane of the connection remain unchanged.

15. The RAN architecture of any one of claims 3 to 5, wherein, 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, the T2-U is an interface between the task processing function TPF of the cluster control node and the core network, used for transmission of task data, and the T2-C is an interface between the task control function TCF of the cluster control node and the core network, used for transmission of task signaling; The T3 interface between the cluster control node and the core network includes a T3 control plane interface T3-C, the T3-C is an interface between the network access function NAF of the cluster control node and the core network, used for transmission of connection signaling; The T4 interface between the cluster control node and the core network further includes a T4 control plane interface T4-C, used for transmission of connection signaling or transparent task signaling; The T5 interface between the service service node and the core network further includes a T5 control plane interface T5-C, used for transmission of connection signaling or transparent task signaling; The T6 interface between the service service node and the core network further includes a T6 control plane interface T6-C, used for transmission of connection signaling or transparent task signaling; The T7 interface between the service service node and the core network further includes a T7 user plane interface T7-U, used for transmission of connection data or transparent task data.

16. The RAN architecture of any one of claims 1 to 13, wherein, The RAN supports a first function in addition to the connection, the first function including one or more of computing, data, and intelligence; The end-to-end protocol stack adopts one of the following options: Option one: the first function is fused into the control plane of the connection and the user plane of the connection; Option two: the first function is fused into the control plane of the connection to form a fused control plane, the user plane of the connection remains unchanged, and a separate task data plane for the first function is added; Option three: a task control plane and a task data plane are added for the first function, and the control plane and the user plane of the connection remain unchanged; Option four: a separate computing plane, data plane, and intelligence plane are added for the first function, and the control plane and the user plane of the connection remain unchanged.

17. The RAN architecture of any one of claims 1 to 16, wherein, The protocol layers of the air interface include layer 2, which includes a sublayer that supports the first function.

18. The RAN architecture of claim 17, wherein, The layer 2 includes at least one of the following sublayers: 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 logical channels of the RLC sublayer, the T-PDCP sublayer provides radio bearers of the T-SDAP sublayer, and the T-SDAP provides tasks of the core network and quality of service (QoS) flows of the connection; Task resource data (TRD) sublayer, which includes one or more of the following functions: artificial intelligence (AI) training, AI inference and AI model processing, protocol mode analysis and local collaboration parameters, collaboration mode process execution, and collaboration interaction information transmission and processing; Task PDU sublayer for the task data plane, which is used for data transmission of trusted services between the terminal and the RAN and the core network; RCSP sublayer for the computing plane, the functions of which include endogenous computing resource addressing, computing data routing and forwarding, computing session identification, and computing session priority; DFCP sublayer for the independent data plane, which is used for control signaling and service data processing of the independent data plane; ETP sublayer for the independent trusted plane, which is used for processing of trusted data packets, and the functions of the EIP sublayer further include encryption and decoding, and integrity protection and integrity verification; TBP layer for the independent trusted data plane, which is used for trusted service data transmission between the terminal and the RAN and the core network, or between the RAN and the core network.

19. The RAN architecture of claim 17 or 18, characterized by, The protocol layers of the air interface further include layer 3, which also includes sublayers that support the first function.

20. The RAN architecture of any one of claims 1 to 19, wherein, The RAN architecture also provides a trusted function, which is decoupled from other functions of the RAN.

21. The RAN architecture of any one of claims 1 to 20, wherein, 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 network-side QoS mechanism and a terminal-side QoS mechanism, and the first function includes one or more of computing, data, intelligence, and trust.

22. A terminal device, comprising: The control plane protocol stack and the data plane protocol stack, The control plane protocol stack includes one of the following: The control plane protocol stack includes a first sub-layer that supports transmission of control signaling of a first function, the first function including one or more of compute, data, intelligence, and trust; or The control plane protocol stack includes a first sub-layer that supports transmission of control signaling of a first function and a routing function, the first function including one or more of compute, data, intelligence, and trust; And the data plane protocol stack of the first function supports a mechanism of arbitrary routing.

23. A communications device, characterized by A communication device comprising at least one processor coupled to at least one memory, the at least one processor configured to execute a computer program or instructions stored in the at least one memory to cause the communication device to have the functionality of the RAN architecture of any one of claims 1 to 21, or the terminal device of claim 22.

24. A chip, characterized by A chip comprising a processor and a communication interface, the communication interface configured to receive information and / or data to be processed and send the information and / or data to be processed to the processor, the processor configured to process the information and / or data to be processed, so that a communication device in which the chip is installed has the functionality of the RAN architecture of any one of claims 1 to 21, or the terminal device of claim 22.

25. A computer-readable storage medium, characterized in that, A computer readable storage medium having stored therein computer instructions that, when executed on a computer, cause the functionality of the RAN architecture of any one of claims 1 to 21, or the terminal device of claim 22 to be implemented.

26. A computer program product, characterised in that, A computer program product comprising computer program code that, when executed on a computer, causes the functionality of the RAN architecture of any one of claims 1 to 21, or the terminal device of claim 22 to be implemented.

27. A wireless communication system, characterized by A wireless access network RAN architecture as claimed in any one of claims 1 to 21 and / or a terminal device as claimed in claim 22.

Images