Functional architecture and interfaces for non-real-time ran intelligent controller

Abstract

The present disclosure relates to a 5G communication system or a 6G communication system for supporting higher data rates beyond a 4G communication system such as long term evolution (LTE). A service management and orchestration (SMO) entity implementing functional separation between a non-real-time (RT) radio access network (RAN) intelligent controller (RIC) and an external artificial intelligence (AI) / machine learning (ML) server will: collect and process RAN data and non-RAN data using the SMO entity and the non-RT RIC during a data collection phase, and transfer the processed RAN data and non-RAN data from the SMO entity to the external AI / ML server via an interface during a data transfer phase. During a trained model input phase, the SMO entity receives a trained AI / ML model, metadata, and training results from the external AI / ML server via the interface at the SMO entity, and during a configuration phase, the SMO entity uses the trained AI / ML model within the SMO entity and the non-RT RIC to transfer configuration parameters to a near-RT RIC.

Description

TECHNICAL FIELD

[0001] The disclosure relates generally to a functional architecture of a non-real-time (RT) radio access network (RAN) intelligent controller (RIC), and more particularly, to enhancing an artificial intelligence (AI) / machine learning (ML) life cycle management. BACKGROUND

[0002] Considering the development of wireless communication for generation after generation, technologies have been developed mainly targeting services positioned for humans such as voice phone, multimedia services, and data services. After the commercialization of 5G (5th generation) communication systems, it is expected that the number of connected devices will exponentially increase. More and more of these devices will be connected to communication networks. Examples of connected things can include vehicles, robots, drones, home appliances, displays, smart sensors connected with various infrastructures, construction machines, and factory equipment. It is expected that mobile devices will evolve in various forms such as augmented reality glasses, virtual reality headsets, and hologram devices. In order to provide various services by connecting hundreds of billions of devices and things in the 6G (6th generation) era, there have been ongoing efforts to develop improved 6G communication systems. For these reasons, 6G communication systems are referred to as beyond 5G systems.

[0003] It is expected that 6G communication systems, which are commercialized around 2030, will have a peak data rate of terabit (1,000 gigabit) level bps and a wireless latency of less than 100 microseconds, thus being 50 times faster than 5G communication systems and having 1 / 10 of the wireless latency thereof.

[0004] In order to achieve such a high data rate and ultra-low latency, it has been considered to implement 6G communication systems in a terahertz band (for example, 95 GHz to 3 THz bands). It is expected that, due to more severe path loss and atmospheric absorption in the terahertz band than in the millimeter wave band introduced in 5G, technologies capable of securing signal transmission distance, that is, coverage, will become more crucial. As major technologies to secure coverage, it is necessary to develop radio frequency (RF) elements, antennas, new waveforms having better coverage than orthogonal frequency division multiplexing (OFDM), beamforming, and massive multiple input multiple output (MIMO), full dimensional MIMO (FD-MIMO), array antennas, and multi-antenna transmission technologies (for example, massive antennas). In addition, new technologies for improving coverage of terahertz band signals, such as metamaterial-based lenses and antennas, orbital angular momentum (OAM), and reconfigurable intelligent surfaces (RISs), have been discussed.

[0005] Moreover, in order to improve the spectral efficiency and overall network performance, the following technologies have been developed for 6G communication systems: a full-duplex technology for enabling uplink transmission and downlink transmission to use the same frequency resource at the same time; a network technology for using satellites, high-altitude platform stations (HAPS), etc. in an integrated manner; an improved network structure for supporting mobile base stations, etc. and implementing network operation optimization and automation, etc.; a dynamic spectrum sharing technology through conflict avoidance based on prediction of spectrum usage; application of artificial intelligence (AI) in wireless communications by developing 6G with the use of AI from the design stage and internalizing end-to-end AI support functions to improve the overall network operation; and a next-generation distributed computing technology for overcoming the limitations of UE computing capability through network-accessible super-high-performance communication and computing resources such as mobile edge computing (MEC), the cloud, etc. In addition, attempts to strengthen connectivity between devices, optimize networks, improve the software of network entities, and increase the openness of wireless communications are continuing by designing new communication protocols to be used in 6G communication systems, developing mechanisms for implementing a hardware-based secure environment and secure use of data, and developing technologies for maintaining privacy.

[0006] It is expected that research and development of 6G communication systems including hyper-connectivity of people-to-machine (P2M) and machine-to-machine (M2M) will allow the experience of the next hyper-connectivity. Specifically, it is expected that services such as hyper-immersive extended reality (XR), high-fidelity mobile hologram display, and digital replication, etc. can be provided through 6G communication systems. In addition, services such as remote surgery for security and reliability enhancement, industrial automation, and emergency response, etc. will be provided through 6G communication systems, so that technologies can be applied in various fields such as industry, medical care, automobiles, and home appliances, etc. SUMMARY

[0007] TECHNICAL PROBLEM

[0008] In order to facilitate the AI / ML lifecycle management, the possibility of functional separation of the non-RT RIC should be considered. Without such functional separation, the AI / ML lifecycle management will be more difficult because the non-RT RIC will be more ML-specific, and it will be difficult to adjust the ML-specific non-RT RIC to support a wide range of future applications.

[0009] SOLUTION TO THE PROBLEM

[0010] In one embodiment, a method of implementing a service management and orchestration (SMO) entity for functional separation between a non-real-time (RT) radio access network (RAN) intelligent controller (RIC) and an external artificial intelligence (AI) / machine learning (ML) server, includes: using the SMO entity and the non-RT RIC to collect and process RAN data and non-RAN data during a data collection phase; transferring the processed RAN data and non-RAN data from the SMO entity to the external AI / ML server via an interface during a data transfer phase; receiving a trained AI / ML model, metadata, and training results from the external AI / ML server at the SMO entity via the interface during a trained model input phase; and using the trained AI / ML model within the SMO entity and the non-RT RIC to transfer configuration parameters to a near-RT RIC during a configuration phase.

[0011] Optionally, within the method, transferring the processed RAN data and non-RAN data includes transferring a pointer to the processed RAN data and non-RAN data in a data store, wherein the pointer is configured for use in the external AI / ML server to retrieve the processed RAN data and non-RAN data.

[0012] Within the method, the external AI / ML server can be a general-purpose AI / ML entity, the functional separation can be implemented between the non-RT RIC and the general-purpose AI / ML entity, and the general-purpose AI / ML entity can train the AI / ML model.

[0013] The method can further include collecting the RAN data and non-RAN data using defined control signaling, wherein the trained AI / ML model and the configuration parameters enable an intelligent beam management procedure.

[0014] In a second embodiment, a method of arbitrating the transfer of enriched information (EI) to a near-RT RIC at a non-real-time (RT) radio access network (RAN) intelligent controller (RIC), includes: establishing a connection between the non-RT RIC and the near-RT RIC for communicating the EI; determining, by the non-RT RIC, whether the EI satisfies a defined boundary; and in the event that the defined boundary is not satisfied, transferring, by the non-RT RIC, an error notification and removing access to the EI by the near-RT RIC.

[0015] Within the method, the EIs for which it is determined that the EIs do not satisfy the defined boundaries are generated by a non-RT RIC application (rApp) or are received from an external source, and in the case that the EIs are received from an external source, the method can further comprise transmitting an error notification to the external source, and in the case that the EIs are generated by the rApp, the method can further comprise pausing and undeploying the rApp prior to sending a command to the external AI / ML server to retrain the rApp.

[0016] Within the method, establishing a connection between the non-RT RIC and the near-RT RIC for communicating the EIs can comprise establishing a connection for continuous communication of the EIs, and the method can further comprise determining, by the non-RT RIC, a target set of key performance indicators (KPIs) for the EIs, continuously transmitting the EIs from the non-RT RIC to the near-RT RIC, monitoring, by the non-RT RIC, the target KPIs, and determining whether there is a KPI in the target set of KPIs that does not satisfy a predefined boundary associated with the KPI.

[0017] In a third embodiment, a service management and orchestration (SMO) entity capable of enabling functional separation between a non-real-time (RT) radio access network (RAN) intelligent controller (RIC) and an external artificial intelligence (AI) / machine learning (ML) server, comprises a transceiver, and a processor connected to the transceiver, the processor configured to: run with the non-RT RIC during a data collection phase to collect and process RAN data and non-RAN data; transmit, via an interface, the processed RAN data and non-RAN data from the SMO entity to the external AI / ML server during a data transfer phase; receive, via the interface, a trained AI / ML model, metadata, and training results at the SMO entity from the external AI / ML server during a trained model input phase; and use the trained AI / ML model within the SMO entity and the non-RT RIC to transmit configuration parameters to a near-RT RIC during a configuration phase.

[0018] Within the SMO entity, transmitting the processed RAN data and non-RAN data can comprise transmitting a pointer to the processed RAN data and non-RAN data in a data storage, wherein the pointer is configured for use in the external AI / ML server to retrieve the processed RAN data and non-RAN data.

[0019] Within the SMO entity, the external AI / ML server can be a general-purpose AI / ML entity, the functional separation can be implemented between the non-RT RIC and the general-purpose AI / ML entity, and the general-purpose AI / ML entity can train the AI / ML model.

[0020] Within the SMO entity, the processor can be further configured to collect the RAN data and the non-RAN data using the defined control signaling, wherein the trained AI / ML model and the configuration parameters enable the intelligent beam management procedure.

[0021] In a fourth embodiment, a non-real-time (RT) radio access network (RAN) intelligent controller (RIC) mediating the transfer of enrichment information (EI) to a near-RT RIC, comprises a transceiver and a processor connected to the transceiver, the processor being configured to: establish a connection between the non-RT RIC and the near-RT RIC for transferring the EI; determine, by the non-RT RIC, whether the EI satisfies a defined boundary; and, in case the defined boundary is not satisfied, transfer, by the non-RT RIC, an error notification and remove access of the near-RT RIC to the EI.

[0022] Within the non-RT RIC, the EI for which it is determined that the EI does not satisfy the defined boundary can be generated by a radio application (rApp) of the non-RT RIC or received from an external source, and the processor can be further configured to: in case the EI is received from an external source, transfer the error notification to the external source; and, in case the EI is generated by the rApp, suspend and undeploy the rApp before sending a command to a external AI / ML server to retrain the rApp.

[0023] Within the non-RT RIC, establishing the connection between the non-RT RIC and the near-RT RIC for transferring the EI can comprise establishing the connection for continuous transfer of the EI, and the processor can be further configured to: determine, by the non-RT RIC, a target set of key performance indicators (KPIs) of the EI; continuously transfer, from the non-RT RIC to the near-RT RIC, the EI; monitor, by the non-RT RIC, the target KPIs; and determine whether there is a KPI of the target set of KPIs that does not satisfy a predefined boundary associated with the KPI.

[0024] Other technical features can be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0025] Advantages of the Invention

[0026] According to embodiments of the present disclosure, several options for functional separation between the non-RT RIC, a service management and orchestration (SMO) entity and a non-SMO entity as well as the functionality of an external AI / ML server are provided.

[0027] Furthermore, details are provided regarding the interface between the non-RT RIC and the AI / ML server, including the information element(s) to be exchanged over the interface. BRIEF DESCRIPTION OF DRAWINGS

[0028] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings in which:

[0029] Figure 1 An example wireless network within which a functional architecture and interfaces for a non-RT RIC can be implemented is shown in accordance with an embodiment of the present disclosure;

[0030] Figure 2 An example base station of an example wireless network within which a functional architecture and interfaces for a non-RT RIC can be implemented is shown in accordance with an embodiment of the present disclosure;

[0031] Figure 3 An example user equipment of an example wireless network within which a functional architecture and interfaces for a non-RT RIC can be implemented is shown in accordance with an embodiment of the present disclosure;

[0032] Figure 4A A selection of non-RT RIC functional split is depicted in accordance with an embodiment of the present disclosure;

[0033] Figure 4B Another selection of non-RT RIC functional split is depicted in accordance with an embodiment of the present disclosure;

[0034] Figure 5 is an example flow diagram of AI / ML assisted configuration of a near-RT RIC and a centralized unit (CU) / distributed unit (DU) with assistance of an AI / ML server in accordance with an embodiment of the present disclosure;

[0035] Figure 6 is an example flow diagram of an SMO initiated fallback procedure for an AI / ML server to enable the SMO to initiate a fallback procedure for the AI / ML server in accordance with an embodiment of the present disclosure;

[0036] Figure 7 An additional example selection of non-RT RIC functional split is presented in accordance with an embodiment of the present disclosure;

[0037] Figure 8 An additional example selection of non-RT RIC functional split is presented in accordance with an embodiment of the present disclosure;

[0038] Figure 9 is an example flow diagram of AI / ML assisted configuration of a near-RT RIC and a CU / DU with assistance of an AI / ML server in accordance with an embodiment of the present disclosure;

[0039] Figure 10is an example flow diagram for SMO initiated fallback procedure for near RT RIC and CU / DU that enables SMO to initiate fallback procedure for near RT RIC and CU / DU, according to embodiments of the disclosure;

[0040] Figure 11 Additional example choices for non-RT RIC functional split are presented. The figures and example choices should not be interpreted as limiting factors of the scope of the disclosure;

[0041] Figure 12 is an example flow diagram for AI / ML assisted configuration for near RT RIC and CU / DU with the assistance of AI / ML entity, according to embodiments of the disclosure;

[0042] Figure 13 is an example flow diagram for AI / ML assisted configuration for near RT RIC and CU / DU that enables SMO to initiate fallback procedure for near RT RIC and CU / DU, according to embodiments of the disclosure;

[0043] Figure 14 depicts non-RT RIC functional architecture support for EI, according to embodiments of the disclosure;

[0044] Figure 15 is an example flow diagram for non-RT RIC error handling for EI, according to embodiments of the disclosure;

[0045] Figure 16 is an example flow diagram for non-RT RIC error handling when EI does not meet associated guardrails, according to embodiments of the disclosure;

[0046] Figure 17 is an example flow diagram for non-RT RIC error handling for continuous passing for EI when target KPIs do not meet their guardrails, according to embodiments of the disclosure;

[0047] Figure 18 different procedures involved in beam management are shown;

[0048] Figure 19 a framework of architecture that can support AI / ML assisted beam management with additional E2 functional enhancements is shown, according to embodiments of the disclosure;

[0049] Figure 20 an example flow diagram showing near RT RIC implementing policies for efficient beam management, according to embodiments of the disclosure;

[0050] Figure 21An example flow diagram of SMO training of an AI / ML model for beam management is shown in accordance with embodiments of the present disclosure. DETAILED DESCRIPTION

[0051] Before undertaking the detailed description below, it can be advantageous to set forth definitions of certain words and phrases used throughout this patent document: The term “connect” and its derivatives refer to any connection between two or more elements, which is direct or indirect, whether mechanical, electrical, or otherwise. The term “transmit” and its derivatives mean to convey or move from one point to another. The term “receive” and its derivatives mean to accept or handle an incoming communication. The term “communication” and its derivatives mean the transmission of information over some medium. The term “determine” and its derivatives mean to find or to judge with certainty. The term “application” and its derivatives mean an application program running on a mobile device, and / or a program that causes another program to perform an action. The term “associated with” and its derivatives mean to belong to, to have a relationship with, or to be in the same environment, as, to be related by some manner that may be seen by a reasonable person, or to be associated with an object, action, or event that happens around the same time or place. The term “controller” means any device, system or part thereof that controls at least one operation. A controller can be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may

[0052] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof. The phrase "computer readable medium" includes any medium that can be accessed by a computer including volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media can comprise memory (RAM, ROM, PROM, EPROM, EEPROM, or Flash memory), magnetic or optical disks, or other storage media. The term computer readable program code includes any expression of instructions in any language capable of being executed by a computer including assemblies, instructions, scripts, object code, machine code, or either source or object code combinations thereof. The phrase "computer readable medium" excludes signals per se.

[0053] Definitions for other certain words and phrases are provided throughout this patent document. Those of ordinary skill in the art will understand that such

[0054] The drawings included herewith are illustrative only and are not intended to limit the scope of the disclosure in any way. Furthermore, the principles of the disclosure can be implemented in any appropriate arrangement for any suitable communication system.

[0055] The following Figures 1 to 3 Various embodiments of the disclosure implemented in a wireless communication system are described. Figures 1 to 3 The description of the various embodiments of the disclosure is not meant to imply physical or architectural limitations to the manner in which different embodiments of the disclosure can be implemented. Different embodiments of the disclosure can be implemented in any suitably-arranged communication system.

[0056] Figure 1 An example wireless network within which a functional architecture and interfaces for non-RT RICs can be implemented in accordance with embodiments of the disclosure is shown. Figure 1 The embodiments of wireless networks shown in the

[0057] As Figure 1As shown, the wireless network includes a base station (gNB or gNodeB) 101, a gNB 102, and a gNB 103. The gNB 101 communicates with the gNB 102 and the gNB 103. The gNB 101 also communicates with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network.

[0058] The gNB 102 provides wireless broadband access to the network 130 for a first plurality of user equipment units (UEs) within a coverage area 120 of the gNB 102. The first plurality of UEs includes a UE 111, which can be located in a small business (SB); a UE 112, which can be located in an enterprise (E); a UE 113, which can be located in a WiFi hotspot (HS); a UE 114, which can be located in a first residence (Rl); a UE 115, which can be located in a second residence (R2); and a UE 116, which can be a mobile device (M), such as a cell phone, a wireless laptop, a wireless personal digital assistant (PDA), and so on. The gNB 103 provides wireless broadband access to the network 130 for a second plurality of UEs within a coverage area 125 of the gNB 103. The second plurality of UEs includes the UE 115 and the UE 116, as well as user equipment (UE) 117, 118, and 119. In some embodiments, one or more of the gNBs 101-103 can communicate with each other and with the UEs 111-116 using existing radio technologies such as, for example, Global System for Mobile Communications (GSM), Universal Mobile

[0059] Depending on the network type, the term "base station" or "BS" can refer to any component (or collection of components) configured to provide wireless access to a network, such as a transmit point (TP), a transmit-receive point (TRP), a base transceiver station (BTS), a base station (BS), an evolved (or "e") node B (eNB), a 5G base station (gNB), a macrocell, a femtocell, a wireless fidelity (Wi-Fi) access point (AP), or other wirelessly enabled devices. Base stations can provide wireless access to a PLMN, a 5G core (5GC), or other networks using one or more radio access technologies, such as a 5G 3GPP New Radio (NR) interface / access, Long Term Evolution (LTE) / LTE-Advanced (LTE-A), High Speed Packet Access (HSPA), Wi-Fi 802.11a / b / g / n / ac, etc. For the sake of convenience, the various names for devices and functions of devices are used interchangeably in this patent document to refer to the components of a network that provide wireless access to remote terminals. Also, depending on the network type, the term "user equipment" (UE) can refer to any component such as mobile station (MS), subscriber station (SS), remote terminal, wireless terminal, receive point, or user device, etc. For the sake of convenience, the various names for devices and functions of devices are used interchangeably in this patent document to refer to remote wireless equipment that wirelessly accesses a BS whether the UE is mobile (such as a mobile phone or smartphone) or generally considered fixed (such as a desktop computer or vending machine).

[0060] Dotted lines show the approximate extents of the coverage areas 120 and 125 as

[0061] As described in more detail below, one or more of the UEs 111-119 include circuitry, programming or a combination thereof for efficient signaling for control messages of a forwardhaul interface. In certain embodiments, one or more of the gNBs 101-103 include circuitry, programming or a combination thereof for spatial frequency compressed CSI acquisition in advanced wireless communication systems.

[0062] Although Figure 1 One example of a wireless network is illustrated, but Figure 1Various changes can be made. For example, wireless network 100 could include any number of gNBs and any number of UEs in any suitable arrangement. Also, gNB 101 could communicate directly with any number of UEs and provide those UEs access to network 130 by providing wireless broadband access to the network 130. Similarly, each gNB 102-103 could communicate directly with network 130 and provide UEs access to network 130 by providing wireless broadband access to the network 130. In addition, gNBs 101, 102, and / or 103 could provide access to other or additional external networks, such as external telephone networks or other types of data networks.

[0063] Figure 2 An example base station of an example wireless network within which a functional architecture and interfaces for a non-RT RIC can be implemented in accordance with embodiments of the disclosure is shown. Figure 2 The embodiment of the gNB 102 illustrated in Figure 1 The gNBs 101 and 103 of Figure 2 The scope of the disclosure is not limited to any particular implementation of a gNB.

[0064] As Figure 2 As shown in FIG. 1C, the gNB 102 includes multiple antennas 200a-200n, multiple radio frequency (RF) transceivers 201a-201n, transmit (TX) processing circuitry 203, and receive (RX) processing circuitry 204. The gNB 102 also includes a controller / processor 205, a memory 206, and a backhaul or network interface 207.

[0065] The RF transceivers 201a-201n receive, from the antennas 200a-200n, incoming RF signals such as signals transmitted by UEs in the network 100. The RF transceivers 201a-201n down-convert the incoming RF signals to generate intermediate frequency (IF) or baseband signals. The IF or baseband signals are sent to the RX processing circuitry 204, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry 204 transmits the processed baseband signals to the controller / processor 205 for further processing.

[0066] The TX processing circuitry 203 receives analog or digital data (such as voice data, web data, e-mail, or interactive video game data) from the controller / processor 205. The TX processing circuitry 203 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceivers 201a-201 n receive the outgoing processed baseband or IF signals from the TX processing circuitry 203 and up-convert the signals to RF signals that are transmitted via the antennas 201a-201 n.

[0067] The controller / processor 205 can include one or more processors or other processing devices to manage the overall operation of the gNB 102. For example, the controller / processor 205 can control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 201a-201 n, the RX processing circuitry 204, and the TX processing circuitry 203 in accordance with well-known principles. The controller / processor 205 can support additional functions as well, such as more advanced wireless communication functions.

[0068] For instance, the controller / processor 205 can support beamforming or directional routing operations in which outgoing signals from multiple antennas 200a-200n are weighted differently to effectively "steer" the outgoing signals in a desired direction. Any of a plurality of other functions can be supported in the gNB 102 by the controller / processor 205 as well.

[0069] The controller / processor 205 is also capable of executing programs and other processes located in the memory 206, such as an operating system (OS). The controller / processor 205 can move data into or out of memory 206 as

[0070] The controller / processor 205 is also connected to the backhaul or network interface 207. The backhaul or network interface 207 allows the gNB 102 to communicate with other devices or systems over a backhaul connection or over a network. The interface 207 can support communications over any suitable wired or wireless connection. For example, when the gNB 102 is implemented as part of a cellular communication system (such as one supporting 5G, LTE, or LTE-A), the interface 207 can allow the gNB 102 to communicate with other gNBs over a wired or wireless backhaul connection. When the gNB 102 is implemented as an access point, the interface 207 can allow the gNB 102 to communicate with other devices, such as wireless communication devices, over a wired or wireless local area network or through a wired or wireless connection to a larger network, such as the Internet. The interface 207 includes any suitable structure supporting communications over transmission media to other devices computing or storage systems. When the gNB 102 is implemented as part of a cellular communication system (such as one supporting 5G, LTE, or LTE-A), the interface 207 can allow the gNB 102 to communicate with other gNBs over a wired or wireless backhaul connection. When the gNB 102 is implemented as an access point, the interface 207 can allow the gNB 102 to communicate with other devices, such as wireless communication devices, over a wired or wireless local area network or through a wired or wireless connection to a larger network, such as the Internet. The interface 207 includes any suitable structure supporting communications over transmission media to other devices computing or storage systems.

[0071] Memory 206 is connected to controller / processor 205. A portion of memory 206 may include random access memory (RAM), and another portion of memory 206 may include flash memory or other read-only memory (ROM).

[0072] although Figure 2 An example of gNB 102 is shown, but it is possible to see more. Figure 2 Various changes can be made. For example, gNB 102 can include any number of Figure 2 Each component is shown in the diagram. As a specific example, an access point may include multiple interfaces 207, and the controller / processor 205 may support routing functionality to route data between different network addresses. As another specific example, although shown as a single instance of TX processing circuitry 203 and a single instance of RX processing circuitry 204, gNB102 may include multiple instances of each (such as one per RF transceiver). For example, Figure 2 The various components can be combined, further subdivided, or omitted, and additional components can be added as needed.

[0073] Figure 3 An example user equipment is shown that can implement a functional architecture and interface for a non-RT RIC within an example wireless network according to an embodiment of the present disclosure. Figure 3 The embodiment of UE 116 shown is for illustrative purposes only, and Figure 1 UEs 111-115 and 117-119 can have the same or similar configurations. However, UEs appear in multiple configurations, and Figure 3 This disclosure is not intended to limit the scope to any particular implementation of the UE.

[0074] like Figure 3 As shown, UE 116 includes an antenna 301, a radio frequency (RF) transceiver 302, a TX processing circuit 303, a microphone 304, and a receive (RX) processing circuit 305. UE 116 also includes a speaker 306, a controller or processor 307, an input / output (I / O) interface (IF) 308, a touchscreen display 310, and memory 311. Memory 311 includes an OS 312 and one or more applications 313.

[0075] The RF transceiver 302 receives, from the antenna 301, an incoming RF signal transmitted by a gNB of the network 100. The RF transceiver 302 down-converts the incoming RF signal to generate an IF or baseband signal. The IF or baseband signal is sent to the RX processing circuitry 305, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. The RX processing circuitry 305 transmits the processed baseband signal to the speaker 306 (such as for voice data) or to the processor 307 for further processing (such as for web browsing data).

[0076] The TX processing circuitry 303 receives analog or digital voice data from the microphone 304 or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the processor 307. The TX processing circuitry 303 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 302 receives the outgoing processed baseband or IF signal from the TX processing circuitry 303 and up-converts it into an RF signal for transmission via the antenna 301.

[0077] The processor 307 can include one or more processors or other processing devices and execute the OS 312 stored in the memory 311 in order to control the overall operation of the UE 116. For example, the processor 307 can control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 302, the RX processing circuitry 305, and the TX processing circuitry 303 in accordance with well-known principles. In some embodiments, the processor 307 includes at least one microprocessor or microcontroller.

[0078] The processor 307 is also capable of executing other processes and programs stored in memory 311, such as a process for CSI reporting on an uplink channel. The processor 307 can move data into or out of memory 311 as required by the processes executing on the processor 307. In some embodiments, the processor 307 is configured to execute the applications 313 based on the OS 312 or in response to signals received from gNBs or an operator. The processor 307 is also coupled to the I / O interface 309, which provides the UE 116 with the ability to connect to other devices such as laptop computers and portable computers. The I / O interface 309 is the communication path between these accessories and the processor 307.

[0079] The processor 307 is also connected to the touch screen display 310. The user of the UE 116 can use the touch screen display 310 to enter data into the UE 116. The touch screen display 310 can be a liquid crystal display, a light emitting diode display, or other display capable of rendering text and / or at least limited graphics, such as from web sites.

[0080] The memory 311 is connected to the processor 307. A portion of the memory 311 can include a volatile RAM, and another portion, a non-volatile memory, for example, flash memory or other ROM.

[0081] Although Figure 3 One example of a UE 116 is shown, but various changes can be made Figure 3 For example, Figure 3 Various components in the UE 116 can be combined, further subdivided, or omitted and additional components can be added according to particular needs. As a particular example, the processor 307 can be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while Figure 3 Although the UE 116 is shown configured as a mobile, or cellular, telephone or smartphone, the UE can be configured to operate as other types of mobile or stationary devices.

[0082] Figure 4A And Figure 4B Two options for non-RT RIC functional split are depicted in accordance with embodiments of the present disclosure. The figures and example options should not be interpreted as limiting factors of the scope of the present disclosure.

[0083] For Figure 4A And Figure 4B Both architectures 400, 450 include a service management and orchestration (SMO) 401, 451, respectively, that includes a corresponding non-RT RIC 402, 452 that further includes: an SMO mediator 403, 453; a messaging infrastructure 404, 454; a subscription management 405, 455; a management service 406, 456; an Al policy and RAN parameter data store 407, 457; a data store of “queryable” ML models 408, 458; and, an Al mediator 409, 459 that provides an interface to a corresponding near-RT RIC 410, 460.

[0084] In Figure 4AIn the first embodiment shown in

[0085] In Figure 4B In the second embodiment shown in

[0086] The external AI / ML server (in the case of the first option) can partially or wholly possess the following capabilities to support a generic non-RT RIC 402 as exemplified in Figure 4A

[0087] • Data preparation

[0088] • Including data selection, fusion, cleansing, etc.

[0089] • AI / ML modeling

[0090] • Including feature extraction, model selection, etc.

[0091] • AI / ML model training

[0092] • AI / ML model validation

[0093] • AI / ML model inference

[0094] • AI / ML model feedback

[0095] • AI / ML model training feedback for A1 policies

[0096] • AI / ML model training feedback for near-RT RIC parameters

[0097] • AI / ML model training feedback for RAN parameters

[0098] • Maintenance of the auxiliary non-RT RIC with AI / ML model

[0099] • Including metadata with AI / ML model feedback

[0100] • Including metadata with AI / ML model training feedback

[0101] ​The interface between the non-RT RIC 402 and the AI / ML server can convey, in part or in whole:

[0102] • SMO data from non-RT RIC to AI / ML server

[0103] • The following from AI / ML server to non-RT RIC:

[0104] • Trained AI / ML model

[0105] • Training results for Al policies

[0106] • Training results for RAN / near-RT RIC parameters

[0107] In addition, the interface between the non-RT RIC 402 and the AI / ML server can support the following functions and necessary information exchange:

[0108] • Support for AI / ML life cycle management in AI / ML server

[0109] • Monitoring and analytics can be handled in SMO

[0110] • Support for transferring mediation SMO data to AI / ML server to enable data prep

[0111] • Data prep is necessary for retraining of currently deployed ML models

[0112] • Support for transferring trained ML model / metadata to non-RT RIC for addition to catalog of "queryable" ML models

[0113] • Metadata includes model ID, textual description, training error, etc.

[0114] • Support for transferring training results for generating / optimizing Al policies to database of Al policies

[0115] • Training results include training error, training dataset ID, timestamp, etc.

[0116] • Support for transferring training results for configuring RAN / near-RT RIC parameters to database of RAN / near-RT RIC parameters

[0117] • Training results include training error, training dataset ID, timestamp, etc.

[0118] • Support for transferring "retrain" command to AI / ML server based on pre-configured trigger events

[0119] • The following principles apply only if AI / ML server is inference host

[0120] o Support transfer of mediation SMO data to AI / ML server to enable inference on currently deployed ML model

[0121] o Support retrieval of performance data of currently deployed ML model for addition to catalog of “queryable” ML models

[0122] ■Performance data includes test error, test dataset ID, timestamp, etc.

[0123] o Should support transfer of “fallback” command to AI / ML server based on pre-configured trigger event

[0124] Figure 5 is an example flowchart of AI / ML assisted configuration of near-RT RIC and centralized unit (CU) / distributed unit (DU) with assistance of an AI / ML server according to embodiments of the present disclosure. At operation 501 of method 500, the SMO and non-RT RIC process data from the RAN, including management information. At operation 502, the SMO transfers the processed data to an external AI / ML server over an interface. The AI / ML server uses the processed data to train an ML model, which is then transferred to the SMO over the interface, as will be described at operation 503, along with metadata and training results. At operation 504, the SMO and non-RT RIC use the trained ML model to communicate with the near-RT RIC in order to configure it and the CU / DU.

[0125] Figure 6 is an example flowchart of SMO-initiated fallback procedure for an AI / ML server to enable the SMO to initiate a fallback procedure with the AI / ML server according to embodiments of the present disclosure. At operation 601 of method 600, the SMO and non-RT RIC process data from the RAN, including management information. At operation 602, the SMO transfers the processed data to an external AI / ML server over an interface. The AI / ML server uses the processed data to train an ML model; which is then transferred to the SMO over the interface, as will be described at operation 603, along with metadata and training results. At operation 604, the SMO and non-RT RIC use the trained ML model to communicate with the near-RT RIC in order to configure it and the CU / DU. At operation 605, the SMO responds to a pre-configured trigger event by transferring a fallback command to the AI / ML server. At operation 606, the SMO and non-RT RIC communicate with the near-RT RIC in order to configure it and the CU / DU with the fallback configuration.

[0126] Figure 7 and Figure 8Two additional example choices of non-RT RIC function separation are presented according to embodiments of the present disclosure. The figures and example choices should not be interpreted as limiting factors of the scope of the present disclosure.

[0127] In Figure 7 In the third embodiment shown, the architecture 700 includes an SMO 701 that includes a corresponding non-RT RIC 702 that in turn includes: an SMO mediator 703; a messaging infrastructure 704; subscription management 705; management services 706; Al policy and RAN parameter data stores 707; data stores of "queryable" ML models 708; and an Al mediator 709 that provides an interface to a corresponding near-RT RIC 710. The architecture 700 also includes an evaluation module 713 external to the non-RT RIC 702, a data collector 720 external to the non-RT RIC 702, and data stores 721 external to the SMO 701. The architecture 700 requires that the data prep and / or training modules be placed as Al / ML servers 712 external to the SMO 701, and that the evaluation module be placed external to the non-RT RIC 702. Again, it is necessary to define an interface 714 between the non-RT RIC 702 and the external Al / ML servers 712, which is discussed further below.

[0128] In Figure 8 In the fourth embodiment shown, the architecture 800 includes an SMO 801 that includes a corresponding non-RT RIC 802 that in turn includes: an SMO mediator 803; a messaging infrastructure 804; subscription management 805; management services 806; Al policy and RAN parameter data stores 807; data stores of "queryable" ML models 808; and an Al mediator 809 that provides an interface to a corresponding near-RT RIC 810. The architecture 800 also includes a data collector 820 external to the non-RT RIC 802, and data stores 821 external to the SMO 801. The architecture 800 requires that the data prep module 815 be placed internal to the non-RT RIC 802, that the training module 816 be placed internal to the non-RT RIC 802, and that the evaluation module 813 be placed internal to the non-RT RIC 802.

[0129] The external Al / ML servers 712 (in the case of the third choice) can partially or fully possess the following capabilities to support a generic non-RT RIC 702 as exemplified in Figure 7

[0130] • Data preparation

[0131] ​○Including data selection, fusion, cleaning, etc.

[0132] ●AI / ML Modeling

[0133] ○ Including feature extraction, model selection, etc.

[0134] ●AI / ML model training

[0135] ●AI / ML model validation

[0136] ●AI / ML model inference

[0137] This includes running the trained model on test data to generate outputs including the A1 policy, near-RT RIC parameter configuration, and RAN parameter configuration.

[0138] ●AI / ML model feedback

[0139] ●Feedback on AI / ML model training for A1 strategy

[0140] ●Feedback for training AI / ML models with near-RT RIC parameters

[0141] ●Feedback on AI / ML model training for RAN parameters

[0142] ● Utilize AI / ML models to maintain auxiliary non-RT RICs

[0143] ○ Includes metadata with AI / ML model feedback

[0144] ○ Includes metadata with AI / ML model training feedback

[0145] The interface between the non-RT RIC and the AI / ML server can be communicated partially or completely:

[0146] ● Pointers to SMO data from non-RT RIC to AI / ML servers

[0147] AI / ML servers use these pointers to retrieve SMO data from the data storage device.

[0148] ●The following is from AI / ML servers to non-RT RIC:

[0149] ○ Trained AI / ML model

[0150] Training results of strategy A1

[0151] Training results of RAN / near RT RIC parameters

[0152] In addition, the interface between the non-RT RIC and the AI / ML server can support the following functions and the necessary information exchange:

[0153] • AI / ML lifecycle management in the AI / ML server

[0154] o Repeatable processes including data prep, training and evaluation

[0155] o Monitoring and analytics can be handled in the SMO

[0156] • Pointers to SMO data are transferred to the AI / ML server to enable data prep

[0157] o The AI / ML server uses these pointers to fetch SMO data from data storage

[0158] o Data prep is necessary for retraining of currently deployed ML models

[0159] • Trained ML models / metadata are transferred to the non-RT RIC for addition to a catalog of "queryable" ML models

[0160] o Metadata includes model ID, textual description, training error, etc.

[0161] • Training results for generating / optimizing Al policies are transferred to a database of Al policies

[0162] o Training results include training error, training dataset ID, timestamp, etc.

[0163] • Training results for configuring RAN / near-RT RIC parameters are transferred to a database of RAN / near-RT RIC parameters

[0164] o Training results include training error, training dataset ID, timestamp, etc.

[0165] • "Retrain" commands are transferred to the AI / ML server based on pre-configured trigger events

[0166] Figure 9is an example flowchart of AI / ML assistance configuration for near-RT RIC and CU / DU with assistance of an AI / ML server according to embodiments of the present disclosure. At operation 901 of method 900, the SMO and non-RT RIC process data from the RAN, including management information. At operation 902, the SMO transmits a pointer to the processed data to an external AI / ML server over an interface. At operation 903, the AI / ML server uses the pointer to retrieve the processed data from a data store over an interface. The AI / ML server uses the processed data to train an ML model; the AI / ML server then transmits the trained ML model, metadata, and training results to the SMO over an interface, which will be described at operation 904. At operation 905, the SMO and non-RT RIC use the trained ML model to communicate with the near-RT RIC in order to configure the near-RT RIC and CU / DU.

[0167] Figure 10 is an example flowchart of SMO-initiated fallback procedure for near-RT RIC and CU / DU that enables the SMO to initiate a fallback procedure for the near-RT RIC and CU / DU according to embodiments of the present disclosure. At operation 1001 of method 1000, the SMO and non-RT RIC process data from the RAN, including management information. At operation 1002, the SMO transmits a pointer to the processed data to an external AI / ML server over an interface. At operation 1003, the AI / ML server uses the pointer to retrieve the processed data from a data store over an interface. The AI / ML server uses the processed data to train an ML model; the AI / ML server then transmits the trained ML model, metadata, and training results to the SMO over an interface, which will be described at operation 1004. At operation 1005, the SMO and non-RT RIC use the trained ML model to communicate with the near-RT RIC in order to configure the near-RT RIC and CU / DU. At operation 1006, the SMO and non-RT RIC respond to a preconfigured trigger event by communicating with the near-RT RIC in order to configure the near-RT RIC and CU / DU with a fallback configuration. At operation 1007, the SMO transmits a retraining command to the AI / ML server.

[0168] Figure 11 Additional example choices for non-RT RIC functional split are presented. The figures and example choices should not be interpreted as limiting factors of the scope of the present disclosure.

[0169] In Figure 11In a fifth embodiment shown in FIG. 11, the architecture 1100 includes an SMO 1101 that includes a corresponding non-RT RIC 1102 that in turn includes: an SMO mediator 1103; a messaging infrastructure 1104; a subscription management 1105; a management service 1106; an Al policy and RAN parameter data store 1107; and an Al mediator 1109 that provides an interface to a corresponding near-RT RIC 1110. The architecture 1100 also includes a data collector 1120 that is external to the non-RT RIC 1102. The architecture 1100 requires that the data prep module and / or the training module (not shown) be placed outside the SMO and that the evaluation module (also not shown) be placed outside the SMO.

[0170] The Al / ML entity (in the case of the fifth option) can partially or fully possess the following capabilities to support the general non-RT RIC as exemplified in Figure 11

[0171] • Data preparation

[0172] o Including data selection, fusion, cleansing, etc.

[0173] • Data storage

[0174] o Including storage of data sets for model training and model validation

[0175] • Al / ML modeling

[0176] o Including feature extraction, model selection, etc.

[0177] • Al / ML model training

[0178] • Al / ML model validation

[0179] • Al / ML model compilation

[0180] o Including conversion of file format of Al / ML model to file format compatible with Al / ML model inference host

[0181] • Al / ML model optimization

[0182] o Including optimization of the computational graph of the Al / ML model for improvements including: reduction in model size, increase in model inference speed, etc.

[0183] • Al / ML model inference

[0184] o Including running the trained model on test data to generate output including Al policy, near-RT RIC parameter configuration, and RAN parameter configuration

[0185] • Al / ML model feedback​

[0186] • AI / ML model training feedback for A1 policies

[0187] • AI / ML model training feedback for near-RT RIC parameters

[0188] • AI / ML model training feedback for RAN parameters

[0189] • Maintenance of the assisted non-RT RIC with AI / ML models

[0190] o Including metadata with AI / ML model feedback

[0191] o Including metadata with AI / ML model training feedback

[0192] • AI / ML model catalog

[0193] • Including storing trained AI / ML models with metadata

[0194] The interface between the non-RT RIC and the AI / ML entity can convey, partially or fully:

[0195] • Pointers from the non-RT RIC to the AI / ML entity pointing to SMO data

[0196] o The AI / ML entity uses these pointers to fetch SMO data from internal data storage

[0197] • The following from the AI / ML entity to the non-RT RIC:

[0198] o Trained AI / ML models

[0199] o Training results for A1 policies

[0200] o Training results for RAN / near-RT RIC parameters

[0201] In addition, the interface between the non-RT RIC and the AI / ML entity can support the following functions and necessary information exchange:

[0202] • AI / ML life cycle management in the AI / ML entity

[0203] o Including repeatable processes for data prep, training, and evaluation

[0204] o Monitoring and analytics can be handled in the SMO

[0205] • Transfer of pointers to SMO data to the AI / ML entity for data prep

[0206] o The AI / ML entity uses these pointers to retrieve SMO data from internal data storage

[0207] o The data prep is necessary for retraining of the currently deployed ML model

[0208] • Transfer of trained ML model / metadata to non-RT RIC for addition to catalog of "queryable" ML models

[0209] o Metadata includes model ID, textual description, training error, etc.

[0210] • Transfer of training results for generating / optimizing Al policies to database of Al policies

[0211] o Training results include training error, training dataset ID, timestamp, etc.

[0212] • Transfer of training results for configuring RAN / near-RT RIC parameters to database of RAN / near-RT RIC parameters

[0213] o Training results include training error, training dataset ID, timestamp, etc.

[0214] • Transfer of "retrain" command to AI / ML entity based on pre-configured trigger events

[0215] Figure 12 is an example of a flowchart of configuration of AI / ML assistance for near-RT RIC and CU / DU with assistance of AI / ML entity according to embodiments of the present disclosure. At operation 1201 of method 1200, SMO and non-RT RIC process data from RAN, including management information. At operation 1202, SMO transfers pointers to the processed data to AI / ML entity through an interface. At operation 1203, AI / ML entity uses the pointers to retrieve the processed data from internal data storage. AI / ML entity uses the processed data to train ML model; AI / ML entity then transfers trained ML model, metadata, and training results to SMO through an interface, which will be described at operation 1204. At operation 1205, SMO and non-RT RIC use the trained ML model to communicate with near-RT RIC in order to configure near-RT RIC and CU / DU.

[0216] Figure 13is an example flowchart of AI / ML-assisted configuration of near-RT RIC and CU / DU by SMO according to embodiments of the disclosure, which enables SMO to initiate fallback procedures for near-RT RIC and CU / DU. At operation 1301 of method 1300, SMO and non-RT RIC process data from RAN, including management information. At operation 1302, SMO transmits a pointer to the processed data to an AI / ML entity through an interface. At operation 1303, the AI / ML entity uses the pointer to retrieve the processed data from internal data storage. The AI / ML entity uses the processed data to train an ML model; the AI / ML entity then transmits the trained ML model, metadata, and training results to the SMO through an interface, which will be described at operation 1304. At operation 1305, the SMO and non-RT RIC use the trained ML model to communicate with near-RT RIC in order to configure the near-RT RIC and CU / DU. At operation 1306, the SMO and non-RT RIC respond to preconfigured trigger events by communicating with the near-RT RIC in order to configure the near-RT RIC and CU / DU with fallback configuration. At operation 1307, the SMO transmits a retraining command to the AI / ML entity.

[0217] There is a need to determine how the functional architecture of non-RT RIC can support enriched information (EI), which can be used to enhance the operation of RAN. Several non-RT RIC functional blocks that can support EI are disclosed, as well as the functionality of external EI sources. Furthermore, the details of the interface between non-RT RIC and external EI sources are disclosed, including the information elements exchanged over the interface.

[0218] Figure 14 The non-RT RIC functional architecture support for EI according to embodiments of the disclosure is depicted. Several non-RT RIC functional blocks that can support EI are presented. The figure should not be interpreted as a limiting factor of the scope of the disclosure.

[0219] Architecture 1400 includes SMO 1401, which includes non-RT RIC 1402. The non-RT RIC functional blocks that can support EI are Al EI function 1403, external El terminal 1404, and associated external El interface of external El source 1405. Architecture 1400 also includes Al terminal 1406 interfacing with near-RT RIC 1410. Non-RT RIC 1402 includes external Al / ML terminal 1407 and associated external Al / ML interface of external Al / ML server 1408. It is necessary to define the interface between non-RT RIC 1402 and external El source 1405, which will be further discussed below.

[0220] The aforementioned non-RT RIC functional blocks can own, in part or in whole, the following capabilities in support of Figure 14

[0221] • A1 EI database

[0222] • Includes EI ID

[0223] • Includes current value of EI

[0224] • For example, (latitude, longitude, altitude) of UE can be an EI for vehicle-to- everything (V2X) handover management use case

[0225] • Includes target KPI

[0226] • For example, number of ping-pong handovers can be a target key performance indicator (KPI) for V2X handover management use case

[0227] • Includes current and a priori values of target KPI

[0228] • For example, number of ping-pong handovers can be reduced after using the EI for V2X handover management use case

[0229] • Includes requesting rApps (software application(s) hosted by non-RT RIC - i.e., non-RT RIC is a platform that includes rApps developed by different vendors)

[0230] • Includes requesting xApps (software application(s) hosted by near-RT RIC)

[0231] • A1 EI data sharing component

[0232] • Includes handling of EI subscription requests from rApps

[0233] • For example, rApps can be deployed in non-RT RIC to address V2X handover management use case; the rApps can subscribe to EIs from V2X application server

[0234] • Includes handling of EI subscription requests from xApps

[0235] • Includes routing of EIs to requesting rApps

[0236] • For example, cooperative awareness messages (CAMs) from V2X application server can be routed to rApps that requested the CAMs

[0237] • Includes routing of EIs to requesting xApps

[0238] • External EI termination

[0239] ​o includes guaranteeing the external EI interface

[0240] o includes decoding incoming messages from external sources of the EI

[0241] ■For example, the V2X application server can send ASN.1 encoded messages to the non-RT RIC

[0242] o includes routing of handshake messages from the non-RT RIC to external sources of the EI

[0243] o includes translating external data models

[0244] o For example, the V2X application server can send messages compliant with the 5GAA (5G Automotive Association) standard, which can be translated into a suitable format for SMO / non-RT RIC internal messaging

[0245] The interface between the non-RT RIC 1402 and external sources of the EI 1405 can convey, in part or in full:

[0246] • EI request messages

[0247] o For example, an rApp that has been deployed in the non-RT RIC for resolving UAV dynamic resource allocation use cases can request flight path information for a UAV; the non-RT RIC can convey this request to the UTM application server

[0248] • EI response messages

[0249] o For example, the UTM application server can convey flight path information for a UAV to the non-RT RIC; the non-RT RIC can convey this information to the rApp that has requested the flight path information

[0250] In addition, the interface between the non-RT RIC 1402 and external sources of the EI 1405 can support the following functions and necessary information exchange:

[0251] • Support for registration of external sources of the EI

[0252] • Support for transmission of external EIs from their sources to the rApps that requested them

[0253] • Support for transmission of external EIs from their sources to the xApps that requested them

[0254] • Support for transmission of handshake messages from the non-RT RIC to external sources of the EI

[0255] In addition to requesting EIs, rApps can also create EIs. For example, a rApp can use RAN measurement data to generate a radio fingerprint. As another example, a rApp can use video application data to generate statistics such as average bitrate and bitrate per segment.

[0256] Figure 15 is an example flowchart for non-RT RIC error handling for EIs according to embodiments of the disclosure. The method 1500 is for a non-RT RIC to handle errors in EIs. At operation 1501, the non-RT RIC establishes a connection with a near-RT RIC to pass an EI to the near-RT RIC. At operation 1502, the non-RT RIC determines whether a guardrail associated with the EI is satisfied.

[0257] Any item of EI should satisfy the associated guardrail; if an item of EI does not satisfy its associated guardrail, the non-RT RIC determines that an error has occurred. For example, if a radio fingerprint is mapped to a UE that is not known from the perspective of the non-RT RIC, the radio fingerprint has not satisfied the associated guardrail. As another example, assume that a V2X application server has sent a location of a UE to the non-RT RIC; if the location corresponds to a location outside of the domain of the network operator, the location has not satisfied the associated guardrail.

[0258] At operation 1503, if the guardrail associated with the EI is not satisfied, the non-RT RIC notifies the near-RT RIC that an error has occurred and removes access to the EI.

[0259] Figure 16 is an example flowchart for non-RT RIC error handling when an EI does not satisfy an associated guardrail according to embodiments of the disclosure. The method 1600 is for a non-RT RIC to handle errors in EIs when an EI does not satisfy its own guardrail. At operation 1601, the non-RT RIC establishes a connection with a near-RT RIC to pass an EI to the near-RT RIC. At operation 1602, the non-RT RIC checks whether the EI to be passed satisfies the associated guardrail; if not, the non-RT RIC notifies the near-RT RIC that an error has occurred and removes access to the EI. At operation 1603, the non-RT RIC then checks whether the rApp created the EI. If the rApp has not created the EI, the EI is created by an external source, so at operation 1604, the non-RT RIC notifies the external source. If the rApp did create the EI, at operation 1605, the non-RT RIC suspends and undeploys the rApp. At operation 1606, the non-RT RIC sends a retraining command to the external AI / ML server for the rApp.

[0260] Figure 17is an example flowchart of non-RT RIC error handling for continuous transfer of EIs when target KPIs do not meet their guardrails, according to embodiments of the present disclosure. The method 1700 is for non-RT RIC to handle errors in continuous transfer of EIs when target KPIs of the EIs do not meet their own guardrails. At operation 1701, the non-RT RIC establishes a connection with the near-RT RIC to transfer EIs to the near-RT RIC. At operation 1702, the non-RT RIC determines a set K of target KPIs of the EIs. At operation 1703, the non-RT RIC continuously transfers the EIs. At operation 1704, the non-RT RIC monitors all KPIs within a time window T. At operation 1705, the non-RT RIC checks whether the KPIs in K meet their guardrails; if not, the non-RT RIC performs the same or similar steps as in operation 1603 in FIG. 16B, where the EIs do not meet their guardrails. Figure 16

[0261] Beam management is defined as a set of Layer 1 (i.e., physical layer) / Layer 2 (i.e., medium access control) procedures to acquire and maintain a set of beam pair links, i.e., cases where beams used at the transmission-reception point(s) (TRP(s)) at the BS side are paired with beams used at the UE. The beam pair links can be used for downlink (DL) and uplink (UL) transmission / reception.

[0262] The beam management procedures include at least the following six aspects:

[0263] Beam sweeping: an operation that covers a spatial region, where beams are transmitted and / or received during a time interval in a predetermined manner.

[0264] Beam measurement: an operation that causes the TRP(s) or the UE to measure characteristics of received beamformed (BF) signals

[0265] Beam reporting: an operation that causes the UE to report information of the BF signal(s) based on the beam measurement

[0266] Beam determination: an operation that causes the TRP(s) or the UE to select its own Tx / Rx beam(s).

[0267] Beam maintenance: an operation that causes the TRP(s) or the UE to maintain candidate beams by beam tracking or correction to adapt to channel changes due to UE movement or obstacles.

[0268] Beam recovery: an operation that causes the UE to identify new candidate beam(s) after detecting beam failure and subsequently inform the TRP of a beam recovery request along with information indicating the new candidate beam(s)

[0269] ​For beam management, the motivation for beyond 5G is to extend wider use cases and scenarios, such as ultra-reliable & low latency communications (URLLC), millimeter wavelength (mmWave) multi-user multiple-input multiple-output (MU-MIMO) enhancements, and UE power saving, etc. To support these use cases, technical improvements for 5G beam management become indispensable.

[0270] The application of AI algorithms including machine learning (ML) in beam management for communication networks has attracted much interest in recent research. AI algorithms are described for deployment for 5G networks, and it is expected that AI applications are used more widely in network or even UE implementations. In general, AI is a tool that helps the network to make faster and wiser decisions based on past training data. The potential benefits of standardization support are reduced feedback / control signaling overhead, more accurate feedback, and implementing better AI algorithms, which require coordination between base stations and UEs. These potential benefits will then translate into better system performance in terms of, for example, throughput and reliability. AI can be applied in the following two aspects of beam management

[0271] - Beamforming

[0272] - Beam tracking

[0273] The requirements defining AI-based beam management fall into the range of use case requirements for quality of service (QoS) optimization use cases. Different procedures involved in beam management are depicted in Figure 18 and include beam determination, which receives updates from beam maintenance and provides UE mobility information to beam maintenance and also signals beam link failure and receives beam failure recovery requests. Beam sweeping feeds information to beam measurement and reporting, which provides information to beam determination to select a transmit (Tx) beam from a pool of candidate beams using beam indication.

[0274] Figure 19 Entities of an architecture that can support AI / ML assisted beam management with additional E2 function enhancements are shown in accordance with embodiments of the present disclosure.

[0275] The different entities involved are as follows:

[0276] 1. SMO entity 1901: Collects necessary measurement metrics (can get data from applications) from network level measurement reports and enriched data for constructing / training relevant AI / ML models

[0277] 2. Non-RT RIC 1902: Sends A1 policies to near-RT RIC to drive resource optimization at RAN level.

[0278] 3. Near-RT RIC 1903:

[0279] • Support for using AI / ML model inference from non-RT RIC based on network data (e.g., measurement reports from E2 nodes), such as QoS prediction.

[0280] • Support for interpretation and enforcement of AI policies from non-RT RIC.

[0281] • Sending of QoS resource optimization related policies and commands to E2 nodes to influence RRM behavior.

[0282] 4. E2 nodes (e.g., joint O-eNB 1904, O-CU-CP 1905, O-CU-UP 1906, and O-DU 1907):

[0283] • Support for reporting UE context, network measurements, and UE measurements to near-RT RIC over E2 interface.

[0284] • Enforcement of policies and commands received from near-RT RIC over E2 interface.

[0285] • Support for network and UE performance reporting to SMO entity over O1 interface.

[0286] • Provide services called RIC services to provide access to messages and measurements and / or to implement control from near-RT RIC to E2 nodes. Such as REPORT, INSERT, CONTROL, and POLICY.

[0287] CU control plane (CP) 1905, CU user plane (UP) 1906, DU 1907, radio unit (RU) 1908, and cloud 1909 are also depicted.

[0288] Figure 20 An example flow diagram of a near-RT RIC implementing policies for efficient beam management is shown in accordance with embodiments of the present disclosure. The method 2000 is used by the near-RT RIC to effectively change RAN behavior in order to implement an efficient beam management procedure. At operation 2001, the near-RT RIC receives policies from a non-RT RIC over an Al interface or from an SMO entity over an O1 interface. The policy targets are to implement optimal beam management procedures, which include but are not limited to beam tracking, beam failure recovery.

[0289] At operation 2002, the near-RT RIC uses the RIC service REPORT to subscribe to beam management related measurements exposed by E2 nodes, including but not limited to:

[0290] 1) Beam level RSRP, RSRQ, SINR (TS 36.331, TS 38.331) including periodic and / or event triggered measurement reports (A1-A6, B1-B2) from serving cells available at CU-CP

[0291] 2) Beam level RSRP, RSRQ, SINR (TS 36.331, TS 38.331) including periodic and / or event triggered measurement reports (A1-A6, B1-B2) from neighboring cells available at CU-CP

[0292] 3) Serving beam indicator

[0293] The near-RT RIC monitors the measurement values and decides to intervene to update / modify RAN behavior when deemed necessary by the policy.

[0294] At operation 2003, the near-RT RIC uses the RIC service CONTROL and POLICY to modify beam management related procedures including but not limited to beam tracking, beam failure recovery, beam reporting. This is achieved by updating the Remote Radio Control (RRC) control information elements (IEs) exposed by the E2 node including but not limited to the following:

[0295] 1) CSI-MeasConfig (TS 38.331): Configure / update candidate beam set.

[0296] The IE CSI-MeasConfig is used to configure CSI-RS (Reference Signal) belonging to the serving cell including CSI-MeasConfig, channel state information reports to be transmitted on PUCCH on the serving cell including CSI-MeasConfig, and channel state information reports on PUSCH triggered by DCI received on the serving cell including CSI-MeasConfig.

[0297] • csi-ReportConfigToAddModList

[0298] • csi-ResourceConfigToAddModList

[0299] • csi-SSB-ResourceSetToAddModList

[0300] 2) CSI-Report Config (TS 38.331): IE CSI-ReportConfig is used to configure periodic or semi-persistent reporting on PUCCH on the cell including CSI-ReportConfig, or to configure semi-persistent or aperiodic reporting on PUSCH triggered by DCI received on the cell including CSI-ReportConfig.

[0301] • reportQuantity - cri-RSRP or ssb-Index-RSRP

[0302] • nrofReportedRS

[0303] 3) CSI-ResourceConfig (TS 38.331): IE CSI-ResourceConfig defines a set of one or more NZP-CSI-RS-ResourceSet, CSI-IM-ResourceSet and / or CSI-SSB-ResourceSet.

[0304] • Resource - NZP CSI-RS or SSB or CSI-IM

[0305] 4) BeamFailureRecoveryConfig (TS 38.331): IE BeamFailureRecoveryConfig is used to configure RACH resources for the UE in case of beam failure detection and candidate beams for beam failure recovery.

[0306] • Rsrp-TresholdSSB

[0307] • Rsrp-ThresholdCSI RS

[0308] • CandidateBeamRSList

[0309] Figure 21An example flowchart of SMO training an AI / ML model for beam management is shown in accordance with embodiments of the present disclosure. The method 2100 is for causing an SMO entity to perform data collection and train an AI / ML model for efficient beam management. At operation 2101, the SMO entity subscribes to measurements related to beam management, which include but are not limited to those mentioned earlier. The non-RT-RIC can access enriched information (EI) from external EI sources through an external EI interface. The non-RT RIC functions that can support EI are Al EI function, external EI terminal, and external EI interface. At operation 2102, the SMO entity checks the available enriched information, including but not limited to the user’s location, velocity.

[0310] At operations 2103 and 2104, the SMO entity trains an AI / ML model based on the available information. Various neural networks such as reinforcement learning can be used. The goal of the ML model is to improve the beam management process, i.e., to make beam management efficient by reducing the required latency, increase the connection to idle beams, connect to the best beam all the time, reduce the frequency of beam failure, so that the UE always meets the specified QoS metric (such as throughput) requirements.

[0311] Some possible approaches can involve predicting UE motion to set a list of candidate beams for the UE, which reduces the latency involved in the beam tracking process. Another approach can be used for the case of beam failure, where an ML model can also be used to predict a set of candidate beams to consider to speed up the recovery process.

[0312] While the present disclosure has been described with respect to exemplary embodiments, various changes and modifications can suggest themselves to those skilled in the art. It is therefore intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1. A method for service management and orchestration (SMO) entities capable of functional separation between a non-real-time, non-RT radio access network (RAN) intelligent controller (RIC) and an external artificial intelligence (AI) / machine learning (ML) server, the method comprising: During the data collection phase, the SMO framework and non-RT RIC are used to collect and process RAN and non-RAN data; During the data transmission phase, processed RAN data and non-RAN data are transmitted from the SMO entity to an external AI / ML server via an interface; During the training model input phase, the SMO entity receives the trained AI / ML model, metadata, and training results from the external AI / ML server via an interface. as well as During the configuration phase, the trained AI / ML model within the SMO entity and the non-RT RIC are used to transmit configuration parameters to the near-RT RIC.

2. The method according to claim 1, wherein, Transmitting processed RAN data and non-RAN data includes: A pointer to processed RAN data and non-RAN data in a data storage device is transmitted, wherein the pointer is configured to retrieve the processed RAN data and non-RAN data in the external AI / ML server.

3. The method according to claim 1, wherein, The external AI / ML server is a generic AI / ML entity, the functional separation can be achieved between the non-RT RIC and the generic AI / ML entity, and the generic AI / ML entity trains the AI / ML model.

4. The method according to claim 1, further comprising: The defined control signaling is used to collect the RAN data and non-RAN data. Among them, the trained AI / ML model and configuration parameters enable the intelligent beam management process.

5. A Service Management and Orchestration (SMO) entity capable of separating functions between a non-real-time (non-RT) radio access network (RAN) intelligent controller (RIC) and an external artificial intelligence (AI) / machine learning (ML) server, wherein the SMO entity comprises: transceiver; as well as A processor, connected to the transceiver and configured to: During the data collection phase, it operates in conjunction with the non-RT RIC to collect and process RAN and non-RAN data. During the data transmission phase, processed RAN data and non-RAN data are transmitted from the SMO entity to an external AI / ML server via an interface. During the model training input phase, the SMO entity receives the trained AI / ML model, metadata, and training results from the external AI / ML server via an interface. During the configuration phase, the trained AI / ML model within the SMO entity and the non-RT RIC are used to transmit configuration parameters to the near-RT RIC.

6. The SMO entity according to claim 5, wherein, The processor is configured to: A pointer to processed RAN data and non-RAN data in a data storage device is transmitted, wherein the pointer is configured to retrieve the processed RAN data and non-RAN data in the external AI / ML server.

7. The SMO entity according to claim 5, wherein, The external AI / ML server is a generic AI / ML entity, the functional separation can be achieved between the non-RT RIC and the generic AI / ML entity, and the generic AI / ML entity trains the AI / ML model.

8. The SMO entity according to claim 5, wherein, The processor is also configured to: The defined control signaling is used to collect the RAN data and non-RAN data. The trained AI / ML model and configuration parameters enable intelligent beam management.

Images