A method of network coordination

Abstract

This disclosure relates generally to a method, device, and system for UE and network coordination. One method performed by a wireless device is disclosed. The method may include: transmitting, to a network node, a message carrying UE capability information, the UE capability information comprising an information container corresponding to a target entity in a plurality of entities of the wireless device and carrying capability information for the target entity, wherein the information container is encoded by the target entity and is to be decoded by a peer entity in the network node that is peer to the target entity.

Description

A METHOD OF NETWORK COORDINATIONTECHNICAL FIELD

[0001] This disclosure is generally directed to wireless communications, and particularly to a method, device, and system for UE and network coordination in a wireless network, such as a 4G LTE, 5G, or a 6G network.BACKGROUND

[0002] With the rapid evolution of wireless communication technology, more and more wireless devices are introduced to provide various services that need to meet various requirements. The wireless device may include a User Equipment (UE) , an Internet of Things (IoT) device, a Machine-to-Machine (M2M) device, a Machine Type Communications (MTC) device, etc. Different wireless devices may have different capabilities. To provide optimal service to a wireless device based on its capability, it is critical to coordinate wireless device and wireless network in an accurate and efficient manner.SUMMARY

[0003] This disclosure is directed to a method, device, and system for UE and network coordination in a wireless network.

[0004] In some embodiments, a method performed by a wireless device is disclosed. The method may include: transmitting, to a network node, a message carrying UE capability information, the UE capability information comprising an information container corresponding to a target feature in a plurality of features of the wireless device and carrying capability information for the target feature, wherein the target feature is associated with a target entity of the wireless device. The method may further include: where the information container is encoded by the target entity and is to be decoded by a peer entity in the network node that is peer to the target entity.

[0005] In some embodiments, a method performed by a wireless device is disclosed. The method may include: receiving, from a network node, a configuration message comprising a configuration container corresponding to a target feature in a plurality of features of the wireless device and carrying configuration information indicated by a peer entity in the network node that is peer to a target entity in the wireless device,  the target entity being associated with the target feature. The method may further include: wherein the configuration container is encoded by the peer entity and is to be decoded by the target feature.

[0006] In some embodiments, a method performed by a network node or wireless node is disclosed. The method may include: transmitting, to a wireless device, a request message comprising a request container corresponding to a target feature in a plurality of features of the network node, wherein the target feature is associated with a target entity of the network node, and wherein the request container carries capability items that are requested to be reported by a peer entity in the wireless device that is peer to the target entity. The method may further include: wherein the request container is encoded by the target entity and is to be decoded by the peer entity.

[0007] In some embodiments, a method performed by a network node or wireless node is disclosed. The method may include: transmitting, to a wireless device, a message comprising a configuration container corresponding to a target feature in a plurality of features of the network node and carrying configuration information indicated by a target entity of the network node that is associated with the target feature, wherein there is a peer entity in the wireless device that is peer to the target entity. The method may further include: wherein the configuration container is encoded by the target entity and is to be decoded by the peer entity.

[0008] In some embodiments, a method performed by a wireless device is disclosed. The method may include: receiving, from a network node, a control element (CE) message comprising a CE container, the CE container being corresponding to a target feature in a plurality of features of the wireless device and comprising control instruction for the target feature, wherein the target feature is associated with a target entity of the wireless device. The method may further include: where the CE container is encoded by a peer entity in the network node that is peer to the target entity and is to be decoded by the target entity.

[0009] In some embodiments, there is a wireless device, a network element, or a network node comprising a processor and a memory, wherein the processor is configured to read code from the memory and implement any methods recited in any of the embodiments.

[0010] In some embodiments, a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement any method recited in any of the embodiments.

[0011] The above embodiments and other aspects and alternatives of their implementations are described in greater detail in the drawings, the descriptions, and the claims below.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1 shows an example wireless communication network.

[0013] FIG. 2 shows an example wireless network node.

[0014] FIG. 3 shows an example user equipment.

[0015] FIGs. 4A-4C show exemplary entities and containers for UE capability.

[0016] FIGs. 5A-5C show various example for sending and receiving UE capability containers.

[0017] FIGs. 6A-6C show various example for sending and receiving UE capability containers using capability set index.

[0018] FIGs. 7A-7C show various example for sending and receiving UE capability request containers.

[0019] FIGs. 8A-8C show exemplary entities and containers for UE configuration.

[0020] FIGs. 9A-9C show various example for sending and receiving UE configuration containers.

[0021] FIGs. 10A-10C show various example for sending and receiving UE configuration containers using configuration set index.

[0022] FIG. 11A show example MAC ME in a tightly coupled architecture.

[0023] FIG. 11B show example MAC ME in a loose coupled or un-coupled architecture.

[0024] FIGs. 12A-12B show various example Configuration Element (CE) containers.

[0025] FIG. 13 shows an example for sending and receiving CE containers.

[0026] FIGs. 14A-14C show various example MAC CE carrying CE container and header.DETAILED DESCRIPTION

[0027] Wireless Communication Network

[0028] FIG. 1 shows an exemplary wireless communication network 100 that includes a core network 110 and a radio access network (RAN) 120. The core network 110 further includes at least one Mobility Management Entity (MME) 112 and / or at least one Access and Mobility Management Function (AMF) . Other functions that may be included in the core network 110 are not shown in FIG. 1. The RAN 120 further includes multiple base stations, for example, base stations 122 and 124. The base stations may include at least one  evolved NodeB (eNB) for 4G LTE, an enhanced LTE eNB (ng-eNB) , or a Next generation NodeB (gNB) for 5G New Radio (NR) , or any other type of signal transmitting / receiving device such as a UMTS NodeB. The eNB 122 communicates with the MME 112 via an S1 interface. Both the eNB 122 and gNB 124 may connect to the AMF 114 via an Ng interface. Each base station manages and supports at least one cell. For example, the base station gNB 124 may be configured to manage and support cell 1, cell 2, and cell 3.

[0029] The gNB 124 may include a central unit (CU) and at least one distributed unit (DU) . The CU and the DU may be co-located in a same location, or they may be split in different locations. The CU and the DU may be connected via an F1 interface. Alternatively, for an eNB which is capable of connecting to the 5G network, it may also be similarly divided into a CU and at least one DU, referred to as ng-eNB-CU and ng-eNB-DU, respectively. The ng-eNB-CU and the ng-eNB-DU may be connected via a W1 interface.

[0030] The wireless communication network 100 may include one or more tracking areas. A tracking area may include a set of cells managed by at least one base station. For example, tracking area 1 labeled as 140 includes cell 1, cell 2, and cell 3, and may further include more cells that may be managed by other base stations and not shown in FIG. 1. The wireless communication network 100 may also include at least one UE 160. The UE may select a cell among multiple cells supported by a base station to communication with the base station through Over the Air (OTA) radio communication interfaces and resources, and when the UE 160 travels in the wireless communication network 100, it may reselect a cell for communications. For example, the UE 160 may initially select cell 1 to communicate with base station 124, and it may then reselect cell 2 at certain later time point. The cell selection or reselection by the UE 160 may be based on wireless signal strength / quality in the various cells and other factors.

[0031] The wireless communication network 100 may be implemented as, for example, a 2G, 3G, 4G / LTE, or 5G cellular communication network. Correspondingly, the base stations 122 and 124 may be implemented as a 2G base station, a 3G NodeB, an LTE eNB, or a 5G NR gNB. The UE 160 may be implemented as mobile or fixed communication devices which are capable of accessing the wireless communication network 100. The UE 160 may include but is not limited to mobile phones, laptop computers, tablets, personal digital assistants, wearable devices, Internet of Things (IoT) devices, MTC / eMTC devices, distributed remote sensor devices, roadside assistant equipment, XR devices, and desktop computers. The UE 160 may also be generally referred to as a wireless communication device, or a wireless terminal. The UE 160 may support sidelink communication to another UE via a PC5 interface.

[0032] While the description below focuses on cellular wireless communication systems as shown in FIG.  1, the underlying principles are applicable to other types of wireless communication systems for paging wireless devices. These other wireless systems may include but are not limited to Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

[0033] FIG. 2 shows an example of electronic device 200 to implement a network base station (e.g., a radio access network node) , a core network (CN) , and / or an operation and maintenance (OAM) . Optionally in one implementation, the example electronic device 200 may include radio transmitting / receiving (Tx / Rx) circuitry 208 to transmit / receive communication with UEs and / or other base stations. Optionally in one implementation, the electronic device 200 may also include network interface circuitry 209 to communicate the base station with other base stations and / or a core network, e.g., optical or wireline interconnects, Ethernet, and / or other data transmission mediums / protocols. The electronic device 200 may optionally include an input / output (I / O) interface 206 to communicate with an operator or the like.

[0034] The electronic device 200 may also include system circuitry 204. System circuitry 204 may include processor (s) 221 and / or memory 222. Memory 222 may include an operating system 224, instructions 226, and parameters 228. Instructions 226 may be configured for the one or more of the processors 221 to perform the functions of the network node. The parameters 228 may include parameters to support execution of the instructions 226. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and / or other parameters.

[0035] FIG. 3 shows an example of an electronic device to implement a terminal device 300 (for example, a user equipment (UE) ) . The UE 300 may be a mobile device, for example, a smart phone or a mobile communication module disposed in a vehicle. The UE 300 may include a portion or all of the following: communication interfaces 302, a system circuitry 304, an input / output interfaces (I / O) 306, a display circuitry 308, and a storage 309. The display circuitry may include a user interface 310. The system circuitry 304 may include any combination of hardware, software, firmware, or other logic / circuitry. The system circuitry 304 may be implemented, for example, with one or more systems on a chip (SoC) , application specific integrated circuits (ASIC) , discrete analog and digital circuits, and other circuitry. The system circuitry 304 may be a part of the implementation of any desired functionality in the UE 300. In that regard, the system circuitry 304 may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, internet connectivity; establishing, maintaining, and terminating wireless network connections,  Bluetooth connections, or other connections; and displaying relevant information on the user interface 310. The user interface 310 and the inputs / output (I / O) interfaces 306 may include a graphical user interface, touch sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I / O interfaces 306 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input  / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors) , and other types of inputs.

[0036] Referring to FIG. 3, the communication interfaces 302 may include a Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 316 which handles transmission and reception of signals through one or more antennas 314. The communication interface 302 may include one or more transceivers. The transceivers may be wireless transceivers that include modulation  / demodulation circuitry, digital to analog converters (DACs) , shaping tables, analog to digital converters (ADCs) , filters, waveform shapers, filters, pre-amplifiers, power amplifiers and / or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium. The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM) , frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 302 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) +, 4G  / Long Term Evolution (LTE) , 5G, and 6G standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP) , GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

[0037] Referring to FIG. 3, the system circuitry 304 may include one or more processors 321 and memories 322. The memory 322 stores, for example, an operating system 324, instructions 326, and parameters 328. The processor 321 is configured to execute the instructions 326 to carry out desired functionality for the UE 300. The parameters 328 may provide and specify configuration and operating options for the instructions 326. The memory 322 may also store any BT, WiFi, 3G, 4G, 5G or other data that the UE 300 will send, or has received, through the communication interfaces 302. In various implementations, a system power for the UE 300 may be supplied by a power storage device, such as a battery or a transformer.

[0038] Cloud Native Radio Access Network (RAN)

[0039] Cloud native is an approach of building, deploying, and managing applications in cloud computing  environments. Cloud native provides the possibility to build highly scalable, flexible, and resilient applications which can be updated quickly to meet ever changing service requirements. With the development of the cloud-native technologies, the Cloud-native RAN technology is adopted in the wireless network. Cloud-native RAN is designed to take advantage of cloud-native technologies and principles, such as automation, microservices, containerization, and hybrid cloud environments. Cloud-native RAN leads to the transformation of traditional mobile network infrastructure into a more agile, scalable, and virtualized architecture using cloud-native principles. This approach leverages cloud computing, software-defined networking (SDN) , and network functions virtualization (NFV) to improve the flexibility and efficiency of RANs. The key aspects of the Cloud-native RAN include:

[0040] ● Virtualization: In a cloud-native RAN, various network functions, such as baseband processing, can be virtualized and run on standard off-the-shelf hardware. This virtualization allows for better resource utilization and scalability.

[0041] ● Microservices: Cloud-native RAN uses microservices architecture, breaking down network functions into smaller, independent services that can be deployed and scaled independently. This enhances the agility of the network.

[0042] ● Containerization: Container technology, such as Docker and Kubernetes, is often used to package and manage network functions. Containers make it easier to deploy and manage applications in a cloud-native environment.

[0043] ● Orchestration: Network functions and services can be orchestrated dynamically to respond to changing network demands. This enables efficient resource allocation and load balancing.

[0044] ● Automation: Automation plays a crucial role in cloud-native RANs. Network management tasks are automated to reduce human intervention, minimize errors, and ensure rapid response to network changes.

[0045] ● Edge Computing: Cloud-native RAN can support edge computing, bringing computational capabilities closer to the end-users. This is particularly important for latency-sensitive applications like 5G, 6G, and IoT.

[0046] ● Open Standards: Many cloud-native RAN initiatives aim to adhere to open standards to promote interoperability and prevent vendor lock-in.

[0047] ● Scalability and Elasticity: Cloud-native RANs are designed to scale horizontally and vertically to handle varying traffic loads efficiently.

[0048] ● Security: Security is a crucial consideration in cloud-native RANs. Network segments are isolated, and security measures are implemented at various layers to protect against threats.

[0049] In this disclosure, from a RAN perspective, the following concepts are considered as key components for cloud native friendly design.

[0050] Loosely coupled architectures

[0051] A key characteristic of cloud native development is using loosely coupled architectures. A loosely coupled architecture is an application design strategy in which the various parts of an application are developed, deployed and operated independently of each other.

[0052] API-first design

[0053] API-first design is the principle that APIs (Application Program Interfaces) are treated as “first-class citizens” when developing applications. For example, instead of writing application source code and only later implementing an API, APIs should be designed first and other source code may be later developed based on the APIs.

[0054] Scalable state management (stateless)

[0055] Traditional applications typically manage state –meaning the data that they need to operate, by storing the data in, for example, the memory and / or file systems of whichever server hosts them. With cloud native applications, it is preferable to design applications that are “stateless, ” meaning that the applications themselves don’ t directly store any data at all. Instead, the applications may choose to use APIs to manage access to the data on demand, therefore, the burden for storing data is removed from the applications.

[0056] In modern wireless network, such as 4G LTE, 5G, and 6G wireless network based on 3GPP standards, interoperability is a critical factor to be considered for product development and deployment. One critical task for 3GPP is to clearly define the interfaces between various network nodes, modules, entities, etc., so there is no ambiguity in term of interoperability. This way, the implementation details may be left to each individual vendors of these products.

[0057] One important factor in cloud-native design is “loosely coupled architecture” . Loosely coupled architecture is an architectural style where the individual components of an application are built independently from one another (compared with tightly coupled architectures) . Each component, sometimes referred to as a microservice, is built to perform a specific function in a way that can be used by any number of other services.  This architecture has a number of benefits, particularly when vendors for applications are different and when scalability is desired.

[0058] In this disclosure, to achieve a loosely coupled architecture, the following aspects are considered, with details being describe in below sectors. Specifically, mechanisms for UE capability reporting, updating, as well as UE configuration driven by the network are described under loosely coupled architecture.

[0059] ● Self-contained signaling coding / decoding.

[0060] ● In-band signaling through user plane for the configuration of UP entities.

[0061] ● Container based control element (e.g., MAC CE) for the control of lower layer (also referred to as low layer, e.g., physical layer) functions.

[0062] Self-contained Signaling Coding / Decoding

[0063] In current network structure, the UE capabilities for all of the functions / modules are encoded and reported together. At the network side, one network entity is in charge of decoding this message and forwarding / sending the decoded message to destined functions / modules. Therefore, a centralized mechanism is utilized and functions / modules are tightly coupled.

[0064] This centralized framework does not fit well in a cloud native network. A loosely coupled UE capability reporting method is described herein to meet the requirement of the cloud native network architecture.

[0065] In a wireless device such as a UE, or a network work node such as a base station, there exist multiple layers, modules, functions, unit, and / or domains. In this disclosure, the term entity is used to generally represent a layer, a module, a function, a unit, a domain, or a separate capability set that may be predefined, or preconfigured by, for example, a standard specification.

[0066] In some embodiments, the UE capability for each layer / module / function / domain / unit / set can be encoded separately by the corresponding module / function / domain / unit / set entity. The UE capability may be classified using various criteria.

[0067] In this disclosure, a feature may be implemented by an entity of, for example, a network node, such as a base station, or a UE. That is, a feature may be an implantation of an entity.

[0068] In this disclosure, an entity may also implicitly imply or mean one or more features that the entity implements.

[0069] In some example implementations, the module / function / domain / unit / set may be classified according to the different protocol layers. The protocol layers may include: a Mobility Management (MM) layer; a Session Management (SM) layer; a Radio Resource Management (RRM) layer; a Radio Resource Control (RRC) layer; a Service data adaptation protocol (SDAP) layer; a Packet Data Convergence Protocol (PDCP) layer; a Radio link control (RLC) layer; a Medium Access Control (MAC) layer; or a physical (PHY) layer. FIG. 4A shows example classification based on layer.

[0070] In some example implementations, the module / function / domain / unit / set may be classified according to the different planes, such as control plane, or user plane. FIG. 4B shows example classification based on plane.

[0071] In some example implementations, the module / function / domain / unit / set may be classified according to the different functions / domains, such as Perception Domain, Trust Domain, Resource Domain, Intelligence Domain, Data Domain, Management Domain, Operations Domain, Communication Domain, and so on. FIG. 4C shows example classification based on domain.

[0072] In some example implementations, the module / function / domain / unit / set may be classified according to the different capability sets specified by, for example, a technical standard. The capability set may include measurement sets, band combination sets, Multiple Input Multiple Output (MIMO) sets, and so on.

[0073] The UE capability for each entity (module / function / domain / unit / set) can be encoded as a separate container. As shown in FIGs. 4A-4C, for each type of UE capability, there is a corresponding container, which may serve as a wrapper to encapsulate the corresponding UE capability. For example, an RLC layer capability container may be used to encapsulate RLC layer capability; a user plane capability container may be used to encapsulate user plane capability.

[0074] The container concept is not limited to UE capability reporting and may also apply to other network and UE communications. For example, container (s) may be used when the network sends inquiry to the UE to request UE reporting UE capabilities; or when the network configures the UE (e.g., based on acquired UE capability) by sending configuration items and / or configuration requirements; or when the network instructs the UE to execute commands / instructions. In these cases, the payload of such communication may be encapsulated into one or more containers (e.g., one container for each entity) and sent to a peer entity. Note that container (or content of the container) is encoded / decoded at entity level.

[0075] UE Capability Reporting

[0076] In some embodiment, when reporting UE capability to the network (e.g., a base station, a radio access network (RAN) ) , the UE may include one or more or all of the containers in one message. FIG. 5A shows an example in which UE capability is classified or categorized by layer. From UE side, there are following entities: RRC entity, PDCP entity, RLC entity, MAC entity, PHY entity, and Radio Frequency (RF) entity. Each entity may encode its capability information, and the encoded capability information may be encapsulated in a corresponding container.

[0077] In some example implementations, UE has a central unit which is in charge of collecting the UE capability containers from each entity. In the example demonstrated in FIG. 5A, after the UE capability containers are collected, UE may combine them together, to form a UE capability message 510, and send the message to the network side (e.g., a base station) . The network side may also be configured with a central unit that is in charge of handling message from the UE. Once receives the message, the central unit may distribute each UE capability container to its corresponding entity, which is a peer to the source entity on UE side. Note that the message processing at central unit is lightweight –as the message is not decoded in the central unit. Message decoding, on the other hand, is performed by the entity corresponding to the UE capability container. For example, the RLC layer capability container will be decoded by the RLC entity.

[0078] Note that each entity in the UE side may have a peer entity found in the network side. For example, the RRC entity in the UE side has a peer entity in the network side with a same name and defined using a similar manner.

[0079] In some example implementations, instead of using a central unit for sending / receiving UE capability message which encapsulates one or more UE capability containers, a more agile mechanism may be chosen, in which a UE entity may send UE capability container to its peer entity in network side directly (without using a central unit) . FIG. 5B shows an example in which the entity is classified by layer. Each layer entity in the UE may send its UE capability via a container to its peer in the network side directly. FIG. 5C shows an example in which the entity is classified by domain, and each domain entity in the UE may send its UE capability via a container to its peer in the network side directly.

[0080] In some example implementations, to reduce signaling overhead (e.g., size of each UE capability container) , the UE may report UE capability via a container carrying a predefined index, with each index indicating a set of predefined / preconfigured capabilities. FIG. 6A shows 2 example RRC capability sets 610 and 612, and 2 example PDCP capability sets 614 and 616, with their corresponding set index. As shown in FIG. 6A, each set includes a list of capability items.

[0081] FIG. 6B shows an example that UE entities send UE capability containers to their peer entities. In this example, the UE RRC entity indicates that it supports RRC capability set 1, and the UE PDCP entity indicates that it supports PDCP capability set 2.

[0082] FIG. 6C shows an example that UE sends a message which carries multiple UE capability containers. In this example, there are two containers in the message: an RRC layer capability container specifying the RRC capability set index 1, and a PDCP layer capability container specifying the PDCP capability set index 2.

[0083] In some example implementations, the same mechanism may be used by the UE to send updated capability.

[0084] UE Capability Inquiry

[0085] In some embodiments, the network may initiate a UE capability inquiry by sending a capability inquiry request to the UE. Similar to UE capability reporting, the capability inquiry request may also be designed to be adapted to a cloud-native architecture. That is, capability request container may be implemented for each entity, and entities may be classified by one of: protocol layer; plane; or module / function / domain / unit / set. Exemplarily, same set of entities as illustrated in FIGs. 4A-4C may be used. Capability request container may be implemented by each entity.

[0086] For example, when the entity is classified by a protocol layer, the capability request container may include: MM layer capability request container; SM layer capability request container; RRM layer capability request container; RRC layer capability request container; SDAP layer capability request container; PDCP layer capability request container; RLC layer capability request container; MAC layer capability request container; PHY layer capability request container; and RF layer capability request container.

[0087] For another example, when the entity is classified by a plane, the capability request container may include: user plane capability request container; and control plane capability request container.

[0088] For yet another example, when the entity is classified by a module / function / domain / unit / set, the capability request container may include: perception domain capability request container; trust domain capability request container; resource domain capability request container; intelligence domain capability request container; and data domain capability request container.

[0089] In some example implementations, as shown in FIG. 7A, the network may first collect capability request from one or more entities. Each entity may reply back a corresponding capability request container  which is encoded by the entity. The network then combines these containers and send them to the UE in one message. From the UE side, each container will be distributed to a peer container for decoding. Note that encoding / decoding of the container occurs at entities.

[0090] In some example implementations, as shown in FIGs. 7B and 7C, from network side, each entity may directly encode and send its capability request container to the peer entity in the UE side.

[0091] In some example implementations, the capability request container may be replaced by a corresponding capability request indicator. The capability request indicator is used to indicate whether the UE is required to report the corresponding capability, sometimes the capability request indicator maybe only 1 bit. The specific capability item (s) that needs to be reported may be indicated by the indicator, or may be predefined or preconfigured via signaling.

[0092] After receiving the capability inquiry from the network, the UE may response using UE capability container (s) , as described in UE capability reporting section above.

[0093] Network Configuring UE

[0094] In current network structure, when the network attempts to configure a UE, all of the configurations are encoded and sent to the UE together. For example, on UE side, configurations for all entities are decoded by a module / unit, and the single module / unit may then configure each entity based on decoded configuration corresponding to the entity. This may be considered as a centralized mechanism, and functions / modules / units are tightly coupled. This centralized framework does not fit well in a cloud native network. A loosely coupled network configuration method is described herein to meet the requirement of the cloud native network architecture.

[0095] In some embodiments, each entity in the network side (NW) may determine a UE configuration for its peer entity in the UE side and encode / encapsulate the desired UE configuration into a container. As shown in FIGs. 8A-8C show example configurations, including: Mobility Management (MM) layer configuration, Session Management layer configuration, RRC layer configuration, SDAP layer configuration, PDCP layer configuration, RCL layer configuration, MAC layer configuration, PHY layer configuration, RF layer configuration, etc. For each type of configuration, there is a corresponding container, which may serve as a wrapper to encapsulate the corresponding configuration. For example, an RLC layer configuration container may be used to encapsulate RLC layer configuration; a user plane configuration container may be used to encapsulate user plane configuration. Note that from the network side, each entity may determine its desired  or optimized configuration based on received UE capability reporting (from a peer entity) .

[0096] In some embodiments, when network configuring UE capability to the UE, the network may include one or more or all of the configuration containers (i.e., for all entities) in one message. FIG. 9A shows an example in which UE configuration is classified or categorized by layer. From network side, there are following entities: RRM entity, RRC entity, PDCP entity, RLC entity, MAC entity, PHY entity, and Radio Frequency (RF) entity. Each entity may encode its desired UE configuration, and the encoded configuration may be encapsulated in a corresponding container.

[0097] In some example implementations, network has a central unit which is in charge of collecting the configuration containers from each entity. In the example demonstrated in FIG. 9A, after the configuration containers are collected, the central unit may combine them together, to form a configuration message 910, and send the message to the UE side. The UE side may also be configured with a central unit that is in charge of handling message from the network. Once receives the message, the central unit may distribute each configuration container to its corresponding entity, which is a peer to the source entity on network side. Note that the message processing at central unit is lightweight –as the message is not decoded in the central unit. Message decoding, on the other hand, is performed by the entity corresponding to the configuration container. For example, the RLC layer configuration container will be decoded by the RLC entity.

[0098] Note that each entity in the network side may have a peer entity found in the UE side. For example, the RRC entity in the network side has a peer entity with same name in the UE side.

[0099] In some example implementations, instead of using a central unit for sending / receiving UE configuration message which encapsulates one or more configuration containers, a more agile mechanism may be chosen, in which a network entity may send configuration container to its peer entity in UE side directly (without using a central unit) . FIG. 9B shows an example in which the entity is classified by layer. Each layer entity in the network may send its desired UE configuration via a container to its peer in the UE side directly. FIG. 9C shows an example in which the entity is classified by domain, and each domain entity in the network may send its desired UE configuration via a container to its peer in the UE side directly.

[0100] In some example implementations, to reduce signaling overhead (e.g., size of each configuration container) , the network may send configuration information via a container carrying a predefined index, with each index indicating a set of predefined / preconfigured configurations. FIG. 10A shows 2 example RRC configuration sets 1010 and 1012, and 2 example PDCP configuration sets 1014 and 1016, with their  corresponding set index. As shown in FIG. 10A, each set includes a list of configuration items.

[0101] FIG. 10B shows an example that network entities send configuration containers to their peer entities. In this example, the network RRC entity indicates UE RRC entity (i.e., peer entity) to use RRC configuration set 1 for RRC entity configuration, and the network PDCP entity indicates UE PDCP entity to use PDCP configuration set 2 for PDCP entity configuration.

[0102] FIG. 10C shows an example that network sends a message which carries multiple configuration containers. In this example, there are two configuration containers in the message: an RRC layer configuration container specifying the RRC configuration set index 1, and a PDCP layer configuration container specifying the PDCP configuration set index 2.

[0103] UE Action upon Receiving Configuration

[0104] Upon receiving the configuration sent from the network (e.g., configuration message 910 as shown in FIG. 9A) , the UE entity (e.g., central unit) that receives the configuration message would distributes each container to the corresponding module / function / domain / unit / set entity.

[0105] The module / function / domain / unit / set entity (e.g., entities as shown in FIGs. 4A-4C) at the UE side would decoding the corresponding container separately.

[0106] In some example implementations, the UE can feedback the configuration result (e.g. whether the receiving entity can comply the network configuration or not) to the network, and the configuration result may be sent separately by each receiving entity to the network. For example, the RLC entity may response back indicating the configuration is successful, and the PDCP may response back indicating a configuration failure. The response may also be encoded and sent via a container corresponding to the entity. The response containers may be combined into one message as a combined configuration result, or sent separately via each individual entity directly to a peer entity.

[0107] Control Element for Controlling Lower Layer

[0108] In current network structure, to achieve the fast configuration effect with lower delay, the Medium Access Element –Control Element (MAC CE) was adopted. For different functions, different MAC CEs need to be designed. For example, under current technology, the MAC layer is responsible for MAC CE decoding then executing the related configuration as specified in the MAC CE by coordinating with other layers, functions, and / or entities. The current CE mechanism may be seen as a MAC layer based centralized mechanism, as an  upper layer (e.g., MAC layer) is tightly couple with a lower layer (e.g., PHY layer) and is directly involved with decoding / executing the control element for lower layer.

[0109] FIG. 11A shows an example for a PHY layer function and its corresponding MAC CE. For each physical layer command, one MAC CE with separate logical channel ID is allocated in MAC layer to carry the command, for example, MAC CE 1 is allocated for carrying PHY command 1. The tight coupling of different layers prevents the independent evolution of these layers (e.g., MAC and PHY) . For example, when adding a new PHY function 2, a corresponding new MAC CE 2 needs to be added as well, therefore, both MAC layer and PHY layer are impacted by the addition of a new PHY command. That is, an update in PHY layer may have to be propagated to the MAC layer.

[0110] To avoid the aforementioned tightly coupled relationship between an upper layer and a lower layer (e.g., MAC and PHY) , and to better support the cloud-native architecture, various embodiments are described below.

[0111] In some embodiments, a Control Element (CE) container is introduced. The CE container may be generally considered as an encapsulation of the corresponding CE. From transmitting end (e.g., a base station, which transmits the CE) , a lower layer will provide the CE container to an upper layer. For example, there may be a PHY (physical, or physical layer) CE container, which carries physical layer command and is provided by the PHY layer to the MAC layer. From receiving end (e.g., a UE receives the CE) , an upper layer is responsible for passing the CE container to a lower layer. For example, the MAC layer may pass the PHY CE container to the PHY layer. Note that the CE container is transparent to the upper layer. That is, the CE container is encode / decoded by the lower layer, and the upper layer is not required to understand the content of each particular CE container. For example, the physical layer may provide to the MAC layer the CE container (encoded with physical layer command) , and the container (with encoded payload) will be pass to the MAC CE directly. Optionally, a length indication may be added to the MAC CE.

[0112] An example for using CE container is illustrated in FIG. 11B. In the PHY layer, CE containers 1 and 2 are provided to MAC layer, specifically, these CE containers are added to a MAC CE which is a general place holder for CE container (s) . When a MAC CE carrying CE container is received, the MAC layer may simply pass the encapsulated CE container (s) to the lower layer (s) (e.g., physical layer) , and the lower layer is responsible for decoding the CE container and execute the command / function as instructed in the CE container.

[0113] In some example implementations, CEs be categorized by layers and may reside at various layers.  For example, there may be RRC CE, MAC CE, PHY CE. Each CE may carry one or more CE containers from one or more lower layers. For example, the MAC CE may carry CE containers from PHY layer, and RF layer; an RRC CE may carry CE containers from MAC layer, PHY layer, and RF layer. FIG. 12A shows example CE containers classified by layer.

[0114] In some example implementations, there may be one or more function / domain CEs, which carry CE containers from various functions / domains. For example, CE containers may include: Perception Domain CE container, Trust Domain CE container, Resource Domain CE container, Intelligence Domain CE container, Data Domain CE container, Management Domain CE container, Operations Domain CE container, Communication Domain CE container, and so on. FIG. 12B shows example CE containers classified by functions / domains.

[0115] In some example implementations, the CEs may be classified by physical layer functions, such as Phy measurement function, Phy Multiple Input Multiple Output (MIMO) function and so on.

[0116] Each CE container may be encoded separately by a layer, a domain, a function, a module, and the like. CE containers may have variable length.

[0117] FIG. 13 shows an example CE that carrying multiple CE containers. In this example, the network (e.g., a base station) has a central unit which is in charge of collecting the CE containers from various entities, for example, RRC entity, MAC entity, PHY entity, and RF entity. After these CE containers (i.e., RRC entity CE container, MAC entity CE container, PHY entity CE container, and RF entity CE container) are collected, the network may combine them together, to form a CE 1310, and send the CE 1310 to the UE side. The UE side may also be configured with a central unit that is in charge of handling CE from the network. Once receives the CE 1310, the central unit may distribute each CE container to its corresponding entity, which is a peer to the source entity on network side. Note that the CE processing at central unit is lightweight –as the CE containers are not decoded in the central unit. CE container decoding, on the other hand, is performed by the entity corresponding to the CE container. For example, the RRC entity CE container will be decoded by the RRC entity, the PHY entity CE container will be decoded by the PHY entity, and so on.

[0118] In some example implementations, there is no need to for central unit to handle the CE containers. Instead, an entity may send a CE directly to its peer entity. Using MAC entity as an example. The MAC entity may receive CE container from lower layer (e.g., a PHY layer) . The lower layer is in charge of encoding control command or bit string to a CE container. The MAC entity may then encapsulate the lower layer CE  container into a MAC CE. Note that the MAC layer does not need to know the content of the CE container. The content of the CE container is defined in the lower layer (e.g., PHY layer) instead of MAC.

[0119] In some example implementations, a logical channel ID (LCID) or MAC control element ID is allocated to the MAC CE which carries the CE container from lower layer.

[0120] In some example implementations, there is be a length indication in the header of the MAC CE which carries the CE container from lower layer.

[0121] FIG. 14A shows an example MAC CE, which includes a MAC CE header and a MAC CE container. Optionally, the MAC CE header may include an identifier, such as a LCID, and a length indicator indicating the length of the MAC CE container. There may be one or more MAC CE container in a MAC CE, and each MAC CE container may have a corresponding length indicator.

[0122] FIG. 14B shows another example MAC CE. In this example MAC CE, a MAC CE identifier is used to identify the MAC CE.

[0123] FIG. 14C shows another example MAC CE. There may be a lower layer command type field in the header of this example MAC CE to indicate the type of the command or content of the CE container from lower layer. Alternatively, the lower layer command type itself is encoded as part of the CE container by the lower layer directly (i.e., the lower layer command type is not part of the header of the MAC CE, but is the payload of the MAC CE that is part of each CE container) . The lower layer command type may be used indicate the function associated with each MAC container. For example, the command type may include: Timing Advance Command, Discontinuous Reception (DRX) Command, Buffer Status Report, Transmission Configuration Indicator (TCI) States Activation / Deactivation for UE-specific PDSCH (Physical Downlink Shared Channel) , and the like.

[0124] FIGs. 14A-14C are example CEs in MAC layer. The same concept may also apply to a CE in other layers, such as RRC layer, PHY layer.

[0125] From UE perspective, whenever UE receives the MAC CE, and determine the MAC CE contains CE containers from lower layer (e.g., via the LCID or CE ID assigned to the MAC CE) , UE MAC layer (or UE MAC entity) delivers the received CE container to lower layer (s) (e.g., physical layer, RF layer, etc. ) . The UE MAC entity is not required to decode the content of each CE container.

[0126] In this disclosure, a container may correspond to, or is associated with one or more features, or  entities. A container may simultaneously carry information / instruction / command, and the like, for one or more features.

[0127] In this disclosure, there may exist various Radio Access Technologies (RATs) . Each of the RAT may be associated with one or more containers. For example, based on various features of a 5G RAT, each feature, or combinations of features, may have a corresponding container. For example, a single message may include multiple containers all corresponding to a same RAT; or different messages may each include a different container associated with a same RAT (e.g., message 1 includes a container 1 for a first feature of the 5G RAT, whereas message 2 includes a container 2 for a second feature of the 5G RAT) .

[0128] In this disclosure, a single container may carry information / instruction / command for one or more features.

[0129] In this disclosure, central unit as mentioned in various embodiment may be a same unit, that handle all the containers; or they may be different units each corresponding to a type of container.

[0130] In this disclosure, various embodiments are described for: UE capability reporting; network UE capability inquiry; network configuring UE; and control element with CE containers. Note that these embodiments are described focusing on a specific function, but these embodiments may be combined to form another embodiment. For example, a combined embodiment may include: network requesting UE to report capability; UE reporting capability based on the request from network; network configuring the UE based received UE capability; and network may at any time use a control element to control a lay / entity of the UE. On the other hand, an embodiment may include all or just partial steps of the embodiment described, if there is no conflict.

[0131] The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0132] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

[0133] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0134] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0135] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method for wireless communication, performed by a wireless device, the method comprising:transmitting, to a network node, a message carrying UE capability information, the UE capability information comprising an information container corresponding to a target feature in a plurality of features of the wireless device and carrying capability information for the target feature, wherein the target feature is associated with a target entity of the wireless device.2.The method of claim 1, where the information container is encoded by the target entity and is to be decoded by a peer entity in the network node that is peer to the target entity.3.The method of claim 1, wherein the message further comprises another information container that is associated with a same Radio Access Technology (RAT) as the information container.4.The method of claim 1, wherein the plurality of features of the wireless device is predefined or preconfigured.5.The method of claim 1, wherein the plurality of features of the wireless device is defined according to a protocol layer of each of the plurality of features, the plurality of features comprising at least one of:a Mobility Management (MM) entity corresponding to an MM layer;a Session Management (SM) entity corresponding to an SM layer;a Radio Resource Management (RRM) entity corresponding to an RRM layer;a Radio Resource Control (RRC) entity corresponding to an RRC layer;a Packet Data Convergence Protocol (PDCP) entity corresponding to a PDCP layer;a Radio link control (RLC) layer;a Medium Access Control (MAC) layer; ora physical (PHY) layer.6.The method of claim 1, wherein the plurality of features of the wireless device is defined according to a plane associated with each of the plurality of features, the plurality of features comprising at least one of:a User Plane (UP) entity associated with a user plane; ora Control Plane (CP) entity associated with a control plane.7.The method of claim 1, wherein the plurality of features of the wireless device is defined according to a function of each of the plurality of features, the plurality of features comprising at least one of:a perception domain entity corresponding to a perception domain;a trust domain entity corresponding to a trust domain;a resource domain entity corresponding to a resource domain;an intelligence domain entity corresponding to an intelligence domain;a data domain entity corresponding to a data domain;a management domain entity corresponding to a management domain;an operations domain entity corresponding to an operation domain; ora communication domain entity corresponding to a communication domain.8.The method of claim 1, wherein:before transmitting the message carrying the UE capability information, the method further comprises receiving, by a module in the wireless device, the information container that is encoded by the target entity; andtransmitting the message carrying the UE capability information comprises:transmitting, to the network node by the module in the wireless device, the message carrying the UE capability information, the UE capability information comprising the information container.9.The method of claim 1, wherein transmitting the message carrying the UE capability information comprises:encoding, by the target entity, the capability information for the target entity into the information container; andtransmitting, to the network node by the target entity, the message comprising the information container.10.The method of any one of claims 1 to 9, wherein transmitting, to the network node, the message comprising the UE capability information comprises transmitting, to the network node, the message comprising the UE capability information via at least one of: a user plane; or a control plane.11.The method of any one of claims 1 to 9, further comprising:receiving, from the network node, a request soliciting capability information for the target entity, wherein the message is a response to the request and carries the capability information for the target entity.12.The method of claim 11, wherein the request carries a request container corresponding the target entity  and carrying capability items that are need to be reported by the target entity.13.The method of claim 12, wherein the request container is encoded by a network node entity which is a peer of the target entity, and wherein the request container is decoded by the target entity.14.The method of claim 1, wherein the information container carries a capability index indicating a predetermined capability information.15.The method of claim 14, wherein the capability index is in a scope of an entity level.16.A method for wireless communication, performed by a wireless device, the method comprising:receiving, from a network node, a configuration message comprising a configuration container corresponding to a target feature in a plurality of features of the wireless device and carrying configuration information indicated by a peer entity in the network node that is peer to a target entity in the wireless device, the target entity being associated with the target feature.17.The method of claim 16, wherein the configuration container is encoded by the peer entity and is to be decoded by the target feature.18.The method of claim 16, wherein the configuration message further comprises another configuration container that is associated with a same Radio Access Technology (RAT) as the configuration container.19.The method of claim 16, wherein the plurality of features of the wireless device is defined according to a protocol layer of each of the plurality of features, the plurality of features comprising at least one of:a Mobility Management (MM) entity corresponding to an MM layer;a Session Management (SM) entity corresponding to an SM layer;a Radio Resource Management (RRM) entity corresponding to an RRM layer;a Radio Resource Control (RRC) entity corresponding to an RRC layer;a Packet Data Convergence Protocol (PDCP) entity corresponding to a PDCP layer;a Radio link control (RLC) layer;a Medium Access Control (MAC) layer; ora physical (PHY) layer.20.The method of claim 16, wherein the plurality of features of the wireless device is defined according to  a plane associated with each of the plurality of features, the plurality of features comprising at least one of:a User Plane (UP) entity associated with a user plane; ora Control Plane (CP) entity associated with a control plane.21.The method of claim 16, wherein the plurality of features of the wireless device is defined according to a function of each of the plurality of features, the plurality of features comprising at least one of:a perception domain entity corresponding to a perception domain;a trust domain entity corresponding to a trust domain;a resource domain entity corresponding to a resource domain;an intelligence domain entity corresponding to an intelligence domain;a data domain entity corresponding to a data domain;a management domain entity corresponding to a management domain;an operations domain entity corresponding to an operation domain; ora communication domain entity corresponding to a communication domain.22.The method of claim 16, wherein receiving the configuration message comprises:receiving, from the network node via a central unit of the wireless device, the configuration message.23.The method of claim 16, wherein receiving the configuration message comprises:receiving, from the network node, the configuration message which is sent by the peer entity directly to the target entity.24.The method of claim 16, further comprising:decoding, by the target entity, the configuration information from the configuration container;configuring the target entity according to the configuration information; andtransmitting, by the target entity, a result of the configuring.25.A method for wireless communication, performed by a network node, the method comprising:transmitting, to a wireless device, a request message comprising a request container corresponding to a target feature in a plurality of features of the wireless device, wherein the target feature is associated with a target entity of the network node, and wherein the request container carries capability items that are requested to be reported by a peer entity in the wireless device that is peer to the target entity.26.The method of claim 25, wherein the request container is encoded by the target entity and is to be decoded by the peer entity.27.The method of claim 25, wherein the request message further comprises another request container that is associated with a same Radio Access Technology (RAT) as the request container.28.The method of claim 25, wherein the plurality of features of the wireless device is defined according to a protocol layer of each of the plurality of features, the plurality of features comprising at least one of:a Mobility Management (MM) entity corresponding to an MM layer;a Session Management (SM) entity corresponding to an SM layer;a Radio Resource Management (RRM) entity corresponding to an RRM layer;a Radio Resource Control (RRC) entity corresponding to an RRC layer;a Packet Data Convergence Protocol (PDCP) entity corresponding to a PDCP layer;a Radio Link Control (RLC) layer;a Medium Access Control (MAC) layer; ora physical (PHY) layer.29.The method of claim 25, wherein the plurality of features of the wireless device is defined according to a plane associated with each of the plurality of features, the plurality of features comprising at least one of:a User Plane (UP) entity associated with a user plane; ora Control Plane (CP) entity associated with a control plane.30.The method of claim 25, wherein the plurality of features of the wireless device is defined according to a function of each of the plurality of features, the plurality of features comprising at least one of:a perception domain entity corresponding to a perception domain;a trust domain entity corresponding to a trust domain;a resource domain entity corresponding to a resource domain;an intelligence domain entity corresponding to an intelligence domain;a data domain entity corresponding to a data domain;a management domain entity corresponding to a management domain;an operations domain entity corresponding to an operation domain; ora communication domain entity corresponding to a communication domain.31.The method of claim 25, wherein before transmitting the request message comprising the request container, the method further comprises:receiving, by a central unit in the network node, the request container that is encoded by the target entity.32.The method of claim 25, wherein transmitting the request message comprising the request container comprises:encoding, by the target entity, the capability items requested by the target entity into the request container; andtransmitting, to the wireless device by the target entity, the request message comprising the request container.33.The method of any one of claims 25 to 32, wherein transmitting, to the wireless device, the request message comprising the request container comprises transmitting, to the wireless device, the request message comprising the request container via at least one of: a user plane; or a control plane.34.The method of any one of claims 25 to 32, further comprising:receiving, from the wireless device, a response message to the request message, the response message comprising an information container which carries capability information as requested in the request container, wherein the information container is encoded by the peer entity and is to be decoded by the target entity.35.A method for wireless communication, performed by a network node, the method comprising:transmitting, to a wireless device, a message comprising a configuration container corresponding to a target feature in a plurality of features of the wireless device e and carrying configuration information indicated by a target entity of the network node that is associated with the target feature, wherein there is a peer entity in the wireless device that is peer to the target entity.36.The method of claim 35, wherein the configuration container is encoded by the target entity and is to be decoded by the peer entity.37.The method of claim 35, wherein the message further comprises another configuration container that is associated with a same Radio Access Technology (RAT) as the configuration container.38.The method of claim 35, wherein the plurality of features of the wireless device is defined according to  a protocol layer of each of the plurality of features, the plurality of features comprising at least one of:a Mobility Management (MM) entity corresponding to an MM layer;a Session Management (SM) entity corresponding to an SM layer;a Radio Resource Management (RRM) entity corresponding to an RRM layer;a Radio Resource Control (RRC) entity corresponding to an RRC layer;a Packet Data Convergence Protocol (PDCP) entity corresponding to a PDCP layer;a Radio link control (RLC) layer;a Medium Access Control (MAC) layer; ora physical (PHY) layer.39.The method of claim 35, wherein the plurality of features of the wireless device is defined according to a plane associated with each of the plurality of features, the plurality of features comprising at least one of:a User Plane (UP) entity associated with a user plane; ora Control Plane (CP) entity associated with a control plane.40.The method of claim 35, wherein the plurality of features of the wireless device is defined according to a function of each of the plurality of features, the plurality of features comprising at least one of:a perception domain entity corresponding to a perception domain;a trust domain entity corresponding to a trust domain;a resource domain entity corresponding to a resource domain;an intelligence domain entity corresponding to an intelligence domain;a data domain entity corresponding to a data domain;a management domain entity corresponding to a management domain;an operations domain entity corresponding to an operation domain; ora communication domain entity corresponding to a communication domain.41.The method of claim 35, wherein:before transmitting the message carrying the configuration information, the method further comprises receiving, by a central unit in the network node, the configuration container that is encoded by the target entity; andtransmitting the message carrying the configuration information comprises:transmitting, to the wireless device by the central unit in the network node, the message carrying the configuration information, the configuration information comprising the configuration container.42.The method of claim 35, wherein transmitting the message carrying the configuration information comprises:encoding, by the target entity, the configuration information indicated by the target entity into the configuration container; andtransmitting, to the wireless device by the target entity, the message comprising the configuration container.43.The method of claim 35, wherein the configuration container carries a configuration index indicating a predetermined configuration information.44.The method of claim 43, wherein the configuration index is in a scope of an entity level.45.The method of any one of claims 35 to 44, wherein transmitting, to the wireless device, the message comprising the configuration information comprises transmitting, to the wireless device, the message comprising the configuration information via at least one of: a user plane; or a control plane.46.The method of any one of claims 35 to 44, further comprising:receiving, from the wireless device, a response to the message, the response indicating whether the peer entity in the wireless device applies the configuration information successfully.47.The method of claim 46, wherein the response comprises a response container encoded by the peer entity and is sent by a central unit in the wireless device.48.The method of claim 46, wherein the response comprises a response container encoded by the peer entity and is sent by the peer entity directly to the target entity.49.A method for wireless communication, performed by a wireless device, the method comprising:receiving, from a network node, a control element (CE) message comprising a CE container, the CE container being corresponding to a target feature in a plurality of features of the wireless device and comprising control instruction for the target feature, wherein the target feature is associated with a target entity of the wireless device.50.The method of claim 49, where the CE container is encoded by a peer entity in the network node that is peer to the target entity and is to be decoded by the target entity.51.The method of claim 1, wherein the message further comprises another CE container that is associated with a same Radio Access Technology (RAT) as the CE container.52.The method of claim 49, wherein the plurality of features of the wireless device is defined according to a protocol layer of each of the plurality of features, the plurality of features comprising at least one of:a Mobility Management (MM) entity corresponding to an MM layer;a Session Management (SM) entity corresponding to an SM layer;a Radio Resource Management (RRM) entity corresponding to an RRM layer;a Radio Resource Control (RRC) entity corresponding to an RRC layer;a Packet Data Convergence Protocol (PDCP) entity corresponding to a PDCP layer;a Radio link control (RLC) layer;a Medium Access Control (MAC) layer; ora physical (PHY) layer.53.The method of claim 49, wherein the plurality of features of the wireless device is defined according to a function of each of the plurality of features, the plurality of features comprising at least one of:a perception domain entity corresponding to a perception domain;a trust domain entity corresponding to a trust domain;a resource domain entity corresponding to a resource domain;an intelligence domain entity corresponding to an intelligence domain;a data domain entity corresponding to a data domain;a management domain entity corresponding to a management domain;an operations domain entity corresponding to an operation domain; ora communication domain entity corresponding to a communication domain.54.The method of claim 49, wherein:receiving the CE message comprises receiving, by a central unit in the wireless device, the CE message; andthe method further comprises:distributing the CE container to the target entity;decoding, by the target entity, the CE container, to obtain the control instruction for the target entity; andexecuting, by the target entity, the control instruction.55.The method of claim 49, wherein:the plurality of features of the wireless device is defined according to a protocol layer of each of the plurality of features;receiving the CE message comprises receiving, by a receiving entity belonging to the plurality of features of the wireless device, the CE message, wherein the receiving entity corresponds to a receiving layer that is higher than a target layer corresponding to the target entity; andthe method further comprises:distributing the CE container, by the receiving entity to the target entity;decoding, by the target entity, the CE container, to obtain the control instruction for the target entity; andexecuting, by the target entity, the control instruction.56.The method of claim 55, wherein the receiving layer comprises a MAC layer, the target layer comprises a layer lower than the MAC layer.57.The method of claim 56, wherein the CE message is identified by an identifier, the identifier indicating the CE message being a message comprising a CE container.58.The method of claim 57, wherein the identifier comprises one of:a Logical Channel ID; ora CE ID.59.The method of claim 49, wherein the CE container comprises a type indicator indicating a type of the control instruction encoded in the CE container.60.The method of claim 49, wherein the CE message comprises a length indicator indicating a length of the CE container.61.The method of claim 49, wherein the CE message comprises a command type field indicating a command type of a command encoded in the CE container.62.A device for wireless communication comprising a memory for storing computer instructions and a processor in communication with the memory, wherein, when the processor executes the computer instructions, the processor is configured to implement a method in any one of claims 1-61.63.A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of any one of claims 1-61.

Images