Issue of guidelines for hardware acceleration in O-RAN

Abstract

This wireless access network control device 1 is equipped with one or more processors which issue a hardware acceleration guide pertaining to hardware acceleration in a wireless access network node which is virtually managed by O-Cloud in a Non-Real Time RAN Intelligent Controller (Non-RT RIC), by using a hardware acceleration guide issuing unit 13. The hardware acceleration guide issuing unit 13 provides a hardware acceleration guide to a destination outside said Non-RT RIC via an A2 interface within Service Management and Orchestration (SMO) which includes said Non-RT RIC. The hardware acceleration guide issuing unit 13 provides a hardware acceleration guide to a hardware acceleration management unit 14 in O-Cloud (fig. 7).

Description

[Technical Field]

[0001] The present disclosure relates to the publication of hardware acceleration guidelines in O-RAN. [Background technology]

[0002] With the aim of opening up radio access networks (RANs) in mobile communication systems, studies are underway on concepts such as "Open RAN," "O-RAN," and "vRAN." In this specification, "O-RAN" is used as a comprehensive term to refer to these various "open radio access networks." Therefore, "O-RAN" in this specification should not be interpreted as being limited to the standards and specifications of the same name established by the O-RAN Alliance. O-RAN provides a virtualization platform known as O-Cloud (hereinafter referred to as O-Cloud for convenience) that virtually manages a collection of multiple radio access network nodes (RAN nodes). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-83058 Summary of the Invention [Problem to be solved by the invention]

[0004] The O-RAN control unit comprises a Non-RT RIC (Non-Real Time RAN Intelligent Controller) with a relatively long control cycle (e.g., one second or more) that executes application software called rApp, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller) with a relatively short control cycle (e.g., less than one second) that executes application software called xApp. Of these, the Non-RT RIC is responsible for overall control of the O-RAN, but in conventional O-RAN, the mechanism for controlling hardware acceleration in RAN nodes was not sufficiently defined.

[0005] The present disclosure has been made in light of these circumstances, and aims to provide a radio access network control device and the like that can effectively control hardware acceleration in RAN nodes. [Means for solving the problem]

[0006] In order to solve the above problem, a radio access network control device according to one embodiment of the present invention includes at least one processor that executes, via a hardware acceleration guideline issuing unit, issuing a hardware acceleration guideline regarding hardware acceleration in a radio access network node that is virtually managed by a virtualization infrastructure in a Non-RT RIC (Non-Real Time RAN Intelligent Controller) of an O-RAN.

[0007] According to this aspect, hardware acceleration in a RAN node can be effectively controlled based on the hardware acceleration guidelines issued by the Non-RT RIC.

[0008] Another aspect of the present invention is a radio access network control method, comprising issuing, in a Non-Real Time RAN Intelligent Controller (Non-RT RIC) of an O-RAN, hardware acceleration guidelines regarding hardware acceleration in radio access network nodes virtually managed by a virtualization infrastructure.

[0009] Yet another aspect of the present invention is a storage medium storing a radio access network control program that causes a computer to execute, in a Non-Real Time RAN Intelligent Controller (Non-RT RIC) of O-RAN, issuing hardware acceleration guidelines regarding hardware acceleration in radio access network nodes that are virtually managed by a virtualization infrastructure.

[0010] Any combination of the above components, or any conversion of these expressions into methods, devices, systems, recording media, computer programs, etc., are also encompassed within the present disclosure. [Effects of the Invention]

[0011] According to the present disclosure, hardware acceleration in a RAN node can be effectively controlled. [Brief explanation of the drawings]

[0012] [Figure 1] 1 shows a schematic overview of a radio access network control device. [Figure 2] Schematic diagram of various functions realized by SMO and / or Non-RT RIC and O-Cloud. [Figure 3] 1 shows a schematic diagram of the internal structure and / or function of the SMO and / or Non-RT RIC. [Figure 4] This shows an example of applying hardware acceleration to a RAN node virtually managed by O-Cloud. [Figure 5] 1 illustrates the concept of hardware acceleration. [Figure 6] FIG. 2 is a functional block diagram illustrating a radio access network control device. [Figure 7] FIG. 2 is a functional block diagram illustrating a radio access network control device. [Figure 8] 10 is a flowchart illustrating an example of control of hardware acceleration by a radio access network controller. DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, this embodiment will be described in accordance with "O-RAN," which is a standard and specification established by the O-RAN Alliance. Therefore, this embodiment will use well-known terms defined by "O-RAN" for convenience, but the technology disclosed herein can also be applied to other existing radio access networks such as "Open RAN" and "vRAN," as well as similar radio access networks that may be developed in the future.

[0014] FIG. 1 shows a schematic overview of a radio access network control device according to this embodiment. This radio access network control device is a RAN control device that controls a radio access network compliant with O-RAN. The SMO (Service Management and Orchestration) controls the entire RAN control device or the entire O-RAN, causing each unit to operate in a coordinated manner. The SMO includes a Non-RT RIC (Non-Real Time RAN Intelligent Controller), which functions as an overall control processor responsible for overall control. The Non-RT RIC, which has a relatively long control period (e.g., one second or longer), issues guidelines, policies, guidance, etc. regarding the operation of each RAN node (O-CU and / or O-DU, described below). Specifically, the Non-RT RIC runs application software called rApp and issues operation guidelines for each RAN node to the Near-RT RIC (Near-Real Time RAN Intelligent Controller) via the A1 interface. The Near-RT RIC, which has a relatively short control period (for example, less than one second), runs application software called xApp to control each RAN node (O-CU / O-DU) itself and general-purpose hardware in the radio unit (O-RU) connected to each RAN node through the E2 interface.

[0015] The illustrated RAN node includes an O-CU, which is an O-RAN-compliant central unit (CU), and / or an O-DU, which is an O-RAN-compliant distributed unit (DU). Both the O-CU and O-DU are responsible for baseband processing in O-RAN, but the O-CU is located on the core network side (not shown), and the O-DU is located on the O-RU side, which is an O-RAN-compliant radio unit (RU). The O-CU may be divided into an O-CU-CP that constitutes the control plane (CP) and an O-CU-UP that constitutes the user plane (UP). The O-CU and O-DU may be integrated into a single baseband processing unit. Alternatively, the RAN node may include an O-eNB, which is a base station compliant with O-RAN and the fourth-generation mobile communication system (4G). One or more O-RUs are connected to each RAN node (O-CU / O-DU), and are controlled by a Near-RT RIC via the RAN node. A communication device (UE: User Equipment) within a communication cell provided by each O-RU can be connected to each O-RU and can perform mobile communication with a core network (not shown) via each RAN node (O-CU / O-DU).

[0016] Each RAN node (O-CU / O-DU) and Near-RT RIC provides operation data of each RAN node, each O-RU, and each UE to the SMO via the O1 interface for so-called FCAPS (Fault, Configuration, Accounting, Performance, Security). Based on the operation data obtained via the O1 interface, the SMO updates the operation guidelines of each RAN node issued by the Non-RT RIC to the Near-RT RIC via the A1 interface as needed. Note that the O-RU may be connected to the SMO for FCAPS via the O1 interface or another interface (such as Open Fronthaul M-Plane).

[0017] O-Cloud, a virtualization platform that virtually manages a collection of multiple RAN nodes (O-CU / O-DU), is connected to SMO via the O2 interface. Based on the operational status of multiple RAN nodes (O-CU / O-DU) obtained from O-Cloud via the O2 interface, SMO generates resource allocation guidelines for resource allocation of the multiple RAN nodes and load management guidelines for workload management, and issues them to O-Cloud via the O2 interface.

[0018] Figure 2 shows a schematic diagram of the various functions realized by SMO and / or Non-RT RIC and O-Cloud. SMO mainly realizes three functions: FOCOM (Federated O-Cloud Orchestration and Management), NFO (Network Function Orchestrator), and OAM Function. O-Cloud mainly realizes two functions: IMS (Infrastructure Management Services) and DMS (Deployment Management Services).

[0019] FOCOM manages resources in the O-Cloud while receiving services from the IMS of the O-Cloud through the O2 interface (O2ims). NFO realizes the coordinated operation of a collection of Network Functions (NFs) through multiple NF deployments in the O-Cloud while receiving services from the DMS of the O-Cloud through the O2 interface (O2dms). The NFO may use an OAM function to access deployed NFs through the O1 interface. The OAM function is responsible for FCAPS management of O-RAN managed entities such as RAN nodes. In this embodiment, the OAM function can be a function block that provides callbacks to receive data on faults and operational status of multiple RAN nodes virtually managed by the O-Cloud by monitoring the procedures or procedures of O2ims and / or O2dms. The IMS is responsible for managing O-Cloud resources (hardware) and the software used to manage them, and provides services mainly to FOCOM in the SMO. One or more DMSs are responsible for managing multiple NF deployments in the O-Cloud, specifically starting, monitoring, terminating, etc., and provide services primarily to the SMO's NFO.

[0020] Figure 3 shows a schematic diagram of the internal configuration and / or functions of the SMO and / or Non-RT RIC. The SMO or SMO Framework includes the Non-RT RIC. The Non-RT RIC is internally divided into the Non-RT Framework or Non-RT RIC Framework and rApp. The solid lines in this diagram represent functional blocks and connections defined in O-RAN. The dashed lines in this diagram represent functional blocks and connections that can be implemented in this embodiment.

[0021] In the SMO framework, the area excluding the Non-RT RIC is provided with an O1 termination, O1 related functions, O2 termination, O2 related functions, and other SMO framework functions. The O1 termination is the termination of the O1 interface in the SMO framework. As shown in FIG. 1, Near-RT RICs and / or E2 nodes (RAN nodes such as O-CU / O-DU, O-RU, etc.) are connected to the O1 termination via the O1 interface. The O1 related functions directly connected to the O1 termination provide various functions related to the O1 interface, Near-RT RIC, E2 nodes, etc. The O2 termination is the termination of the O2 interface in the SMO framework. As shown in FIG. 1, the O-Cloud is connected to the O2 termination via the O2 interface. The O2 related functions directly connected to the O2 termination provide various functions related to the O2 interface, O-Cloud, etc. Other SMO framework functions provide functions other than the O1-related functions and O2-related functions. The other SMO framework functions are connected to the A2 terminal (described later) in the Non-RT RIC via the A2 interface. Various functions of the SMO framework, such as the O1-related functions, O2-related functions, and other SMO framework functions, are connected to the main bus MB, which also extends inside the Non-RT RIC. Each of these function blocks can exchange data with other function blocks inside and outside the SMO framework (or inside and outside the Non-RT RIC) via the main bus MB.

[0022] The Non-RT Framework, which is the area of ​​the Non-RT RIC excluding rApp, includes A1 Termination, A1 Related Functions, A2 Termination, A2 Related Functions, R1 Termination, R1 Service Exposure Functions, External Terminations, Data Management & Exposure Functions, Artificial Intelligence / Machine Learning Workflow Functions, and Other Non-RT RIC Framework Functions.

[0023] The A1 terminal is the terminal of the A1 interface in the Non-RT framework. As shown in Figure 1, the Near-RT RIC is connected to the A1 terminal via the A1 interface. The A1-related functions directly connected to the A1 terminal provide various functions related to the A1 interface, Near-RT RIC, etc. The A2 terminal is the terminal of the A2 interface in the Non-RT framework. Other SMO framework functions of the SMO framework are connected to the A2 terminal via the A2 interface. The A2-related functions directly connected to the A2 terminal provide various functions related to the A2 interface, other SMO framework functions, etc.

[0024] The R1 termination is the termination of the R1 interface in the Non-RT framework. An rApp running on a Non-RT RIC is connected to the R1 termination via the R1 interface. In other words, the R1 interface constitutes the API (Application Programming Interface) of the rApp. The R1 service disclosure function provided in association with the R1 termination provides the function of disclosing data related to services such as the R1 interface and rApp to the main bus MB, etc., and / or the function of disclosing data from the main bus MB, etc. to the R1 termination, etc., for services such as the R1 interface and rApp, etc. The external termination is the termination of various external interfaces (not shown) in the Non-RT framework.

[0025] The data management / disclosure function manages various data on the main bus MB and provides a function to disclose it in a manner according to the access privileges of each functional block. The artificial intelligence / machine learning workflow function provides a function to manage workflows executed using the artificial intelligence (AI) and / or machine learning (ML) capabilities implemented in the Non-RT RIC and / or Near RT RIC. The other Non-RT RIC framework functions provide functions other than the functions of the various Non-RT frameworks described above. Various functions of the Non-RT framework, such as A1-related functions, A2-related functions, R1 termination, R1 service disclosure function, external termination, data management / disclosure function, artificial intelligence / machine learning workflow function, and other Non-RT RIC framework functions, are connected to the main bus MB that extends outside the Non-RT RIC. Each of these functional blocks can exchange data with other functional blocks inside and outside the Non-RT RIC through the main bus MB.

[0026] Figure 4 shows an example of applying hardware acceleration to a RAN node virtually managed by O-Cloud. Hardware acceleration is a technology that supports general-purpose processors such as CPUs (Central Processing Units) with hardware (hereinafter, for convenience, collectively referred to as dedicated processors, hardware accelerators, or HW accelerators) equipped with circuits specialized or customized for specific processes or applications, such as FPGAs (Field-Programmable Gate Arrays), GPUs (Graphics Processing Units), ASICs (Application Specific Integrated Circuits), and DSPs (Digital Signal Processors). Complex processes that require a lot of time and power when processed by software on a general-purpose processor can be executed quickly and efficiently by dedicated processors implemented in hardware.

[0027] Figure 5 illustrates the concept of hardware acceleration. Figure 5A shows an example without hardware acceleration, in which a general-purpose CPU (CPU) serially executes a series of processes or functions, "func1" through "func5." Figure 5B shows an example with hardware acceleration, in which a dedicated FPGA is provided in addition to the general-purpose CPU. The CPU does not execute some of the processes or functions, "func2" through "func4," but instead delegates them to an FPGA with a customized circuit configuration. The FPGA in the illustrated example not only executes "func2" and "func3 / 4" in parallel, but also executes each process or function, "func2" through "func4," faster than the CPU. As a result, the example with hardware acceleration in Figure 5B executes the series of processes or functions, "func1" through "func5," more quickly and efficiently than the example without hardware acceleration in Figure 5A.

[0028] In Figure 4, general-purpose processors are not shown, and only a group of HW accelerators (Hardware Accelerators) is shown as the target of hardware acceleration. The group of HW accelerators includes dedicated processors, hardware accelerators, and multiple (M) processing units (Processing Unit 1 to Processing Unit M) as HW accelerators. These processing units (Processing Unit 1 to Processing Unit M) are any baseband processing units included in the baseband units (BBUs) of one or more RAN nodes virtually managed by the O-Cloud. As mentioned above, the baseband units of a RAN node are broadly divided into an aggregation unit (O-CU) on the core network side and a distributed unit (O-DU) on the O-RU side. Therefore, the processing units (Processing Unit 1 to Processing Unit M) shown in the figure are any baseband processing units included in at least one of the aggregation unit (O-CU) and distributed unit (O-DU) of these baseband units.

[0029] These HW accelerators are managed by the Hardware Accelerator Manager, which serves as the hardware acceleration manager in O-Cloud. The HW Accelerator Manager is responsible for lifecycle management, configuration, updates, upgrades, error handling, etc. of the HW accelerators managed by O-Cloud. In addition, performance and monitoring data from the HW Accelerator Manager is shared with SMO by applications via the O1 interface. The HW Accelerator Manager is connected to the IMS and DMS of O-Cloud, also shown in Figure 2. The IMS provides various information obtained from the SMO's FOCOM through the O2-IMS interface to the HW Accelerator Manager. One or more DMSs provide various information obtained from the SMO's NFO through the O2-DMS interface to the HW Accelerator Manager. The HW accelerator management unit manages the HW accelerators through the AAL-LPUs (Acceleration Abstraction Layer Logical Processing Units) described below, based on various information provided by the IMS and / or DMS.

[0030] The Near-RT RIC and the Aggregation Unit (O-CU), which are connected to the SMO via the O1 interface, are provided with a mechanism to manage the HW accelerators in cooperation with the HW accelerator management unit in the O-Cloud. Specifically, an AAL interface and an AAL logical processing unit (AAL-LPU) are provided. The AAL interface is an application interface between various O-RAN applications executed on the Non-RT RIC, Near-RT RIC, etc., and the AAL (Acceleration Abstraction Layer). For example, each network function (Application) coordinated by the NFO of the SMO can access the AAL logical processing unit and the HW accelerators through the AAL interface.

[0031] The AAL logical processing unit group includes multiple (N) AAL logical processing units, "AAL-LPU 1" to "AAL-LPU N." The AAL logical processing unit group is a logical representation of the resources (especially hardware resources) included in the HW accelerator group. Each AAL logical processing unit included in the AAL logical processing unit group is an arbitrary combination of some or all of the resources of one or more processing units included in the HW accelerator group. An appropriate AAL logical processing unit is selected and activated for each O-RAN application via the AAL interface. Each AAL logical processing unit stores one or more AAL profiles based on the resources included in it. Although not shown in the figure, each AAL profile lists one or more accelerated functions (AFs: Accelerated Functions) realized by the resources included in the AAL logical processing unit. These accelerated functions specify the processing units (at least one of "Processing Unit 1" to "Processing Unit M") and / or their specific resources that should actually be used or operated in the HW accelerator group when the AAL profile is selected by the active AAL logical processing unit. As will be described in detail later, the active AAL logical processing unit works with the HW accelerator management unit in the O-Cloud to select an appropriate AAL profile according to the O-RAN situation.

[0032] 6 and 7 are functional block diagrams schematically showing a radio access network control device 1 according to this embodiment. The radio access network control device 1 is provided in the SMO framework and / or Non-RT framework in FIG. 3, except for the hardware acceleration management unit 14 in the O-Cloud, which corresponds to the "Hardware Accelerator Manager" in FIG. 4. Note that some of the functional blocks in FIG. 3 (specifically, external termination, data management / disclosure function, artificial intelligence / machine learning workflow function, and other Non-RT RIC framework functions) are omitted from the diagrams.

[0033] The radio access network control device 1 includes an O1 information acquisition unit 11, an O2 information acquisition unit 12, a hardware acceleration guideline issuance unit 13, and a hardware acceleration management unit 14. These functional blocks are realized by the cooperation of hardware resources such as a processor, such as a central processing unit of a computer, a memory, an input device, an output device, and peripheral devices connected to the computer, and software executed using these. Regardless of the type of computer or the installation location, each of the above functional blocks may be realized by the hardware resources of a single computer, or may be realized by combining hardware resources distributed across multiple computers. In particular, in this embodiment, some or all of the functional blocks of the radio access network control device 1 may be realized by a computer or processor provided in the Non-RT RIC, SMO, or O-Cloud, or may be realized in a distributed or centralized manner by an external computer or processor capable of communicating with at least one of the Non-RT RIC, SMO, and O-Cloud.

[0034] The O1 information acquisition unit 11 acquires O1 information related to at least one of a Near-RT RIC and an E2 node (RAN node) via the O1 interface. Specifically, the O1 information acquisition unit 11 is provided in an SMO and / or a Non-RT RIC, and acquires O1 information from the Near-RT RIC and / or the E2 node via the O1 interface. Examples of the O1 information include various control information indicating the control state of the Near-RT RIC and operation data measured individually for each E2 node. The operation data of each E2 node is various data that can be detected by a general mobile communication base station, such as the amount of communication traffic and communication speed per hour, the number and type of connected UEs (communication devices), the strength and state of communication radio waves from the UE, the quality of the channel between the UE and the O-RU, the coverage area and available bandwidth of the communication cell provided by the O-RU, and the performance and state of the hardware of the E2 node and the O-RU.

[0035] The O1 information acquisition unit 11 in Figures 6 and 7 is shown schematically as spanning both the inside and outside of the Non-RT framework on the main bus MB. However, the O1 information acquisition unit 11 may be provided entirely or partially within the SMO framework outside the Non-RT framework. Furthermore, the O1 information acquisition unit 11 only needs to be able to access related functional blocks within the SMO, specifically, the O1 termination, O1-related functions, R1 termination, R1 service disclosure function, rApp, hardware acceleration guideline issuer 13, etc., and does not necessarily need to be directly connected to the main bus MB. It is preferable to realize some or all of the functions of the O1 information acquisition unit 11 in the O1-related functions within the SMO framework (outside the Non-RT framework) that are most closely related among these related functional blocks.

[0036] The O2 information acquisition unit 12 acquires O2 information related to the O-Cloud through the O2 interface. Specifically, the O2 information acquisition unit 12 is provided in the SMO and / or the Non-RT RIC, and acquires the O2 information from the O-Cloud through the O2 interface. Examples of the O2 information include information related to the configuration and telemetry of the O-Cloud and / or faults and operating status of each E2 node (each RAN node) virtually managed by the O-Cloud. Examples of the operating status of each E2 node include resource usage and communication load status in each E2 node. For example, the O2 information may be acquired by the FOCOM in the SMO from the IMS in the O-Cloud through the O2ims interface, or by the OAM Function in the SMO from the O-Cloud through the O2 interface.

[0037] The O2 information acquisition unit 12 in Figures 6 and 7 is shown schematically as spanning both the inside and outside of the Non-RT framework on the main bus MB. However, the O2 information acquisition unit 12 may be provided entirely or partially within the SMO framework outside the Non-RT framework. Furthermore, the O2 information acquisition unit 12 need only be able to access related functional blocks within the SMO, specifically, the O2 termination, O2-related functions, R1 termination, R1 service disclosure function, rApp, hardware acceleration guideline issuer 13, etc., and does not necessarily have to be directly connected to the main bus MB. It is preferable to realize some or all of the functions of the O2 information acquisition unit 12 in the O2-related functions within the SMO framework (outside the Non-RT framework) that are most closely related among these related functional blocks.

[0038] The hardware acceleration guideline issuing unit 13 provided in the Non-RT RIC issues a hardware acceleration guideline regarding hardware acceleration in a RAN node or an E2 node virtually managed by the O-Cloud. Specifically, all or a part of the hardware acceleration guideline issuing unit 13 is realized by an rApp executed by the Non-RT RIC. As schematically shown by the arrows in FIG. 6 , the hardware acceleration guideline issuing unit 13 in the rApp and / or the Non-RT RIC acquires the O1 information acquired by the O1 information acquiring unit 11 and / or the O2 information acquired by the O2 information acquiring unit 12 via the main bus MB, the R1 termination, the R1 interface, etc. Based on this O1 information (related to the Near-RT RIC or the E2 node) and / or the O2 information (related to the O-Cloud), the hardware acceleration guideline issuing unit 13 can issue an appropriate hardware acceleration guideline according to the situation of the O-RAN.

[0039] The hardware acceleration guidelines issued by the hardware acceleration guideline issuing unit 13 relate to hardware acceleration in at least one of the aggregation unit (O-CU) and the distributed unit (O-DU) of the baseband unit of the RAN node. As schematically shown by the arrows in Figure 7, the hardware acceleration guideline issuing unit 13 in the rApp and / or Non-RT RIC provides the hardware acceleration guidelines to other SMO framework functions outside the Non-RT RIC via the R1 interface, R1 termination, main bus MB, A2-related functions, A2 termination, A2 interface, etc. The other SMO framework functions provide the hardware acceleration guidelines provided by the hardware acceleration guideline issuing unit 13 to the hardware acceleration management unit 14 in the O-Cloud via the main bus MB, O2-related functions, O2 termination, O2 interface, etc. For example, the hardware acceleration policy issued by the hardware acceleration policy issuing unit 13 is provided from the NFO in the SMO to the DMS in the O-Cloud through the O2-DMS interface of the O2 interface, as shown in Figure 4, and is further provided to the hardware acceleration management unit 14 (Hardware Accelerator Manager). Note that other SMO framework functions may provide the hardware acceleration policy provided by the hardware acceleration policy issuing unit 13 to the Near-RT RIC and / or E2 node through the main bus MB, O1-related function, O1 termination, O1 interface, etc. Also, the hardware acceleration policy issuing unit 13 in the rApp and / or Non-RT RIC may provide the hardware acceleration policy to outside the Non-RT RIC and outside the SMO without going through the A2 interface. Specifically, hardware acceleration guidelines may be provided to a hardware acceleration management unit 14 in the O-Cloud outside the Non-RT RIC and outside the SMO through the R1 interface, R1 termination, main bus MB, O2-related functions, O2 termination, O2 interface, etc.

[0040] As shown in FIG. 4 , the “Hardware Accelerator Manager” serving as the hardware acceleration management unit 14 causes the active AAL logical processing unit (“AAL-LPU 1” in the example of FIG. 4 ) to select an appropriate AAL profile according to the O-RAN situation, in accordance with the hardware acceleration guidelines provided by the hardware acceleration guideline issuing unit 13 via the O2 interface. In this manner, various accelerated functions (Accelerated Functions) listed in the AAL profile selected in accordance with the hardware acceleration guidelines issued by the hardware acceleration guideline issuing unit 13 are realized by various hardware resources of the HW accelerators (Processing Unit 1-M) included in the HW accelerator group (Hardware Accelerators). In this manner, according to this embodiment, hardware acceleration in the RAN node can be effectively controlled based on the hardware acceleration guidelines issued by the Non-RT RIC (Hardware Acceleration Guideline issuing unit 13). Note that some or all of the hardware acceleration guidelines issued by the hardware acceleration guideline issuing unit 13 may be provided to the Near-RT RIC via the A1 interface. In this case, the control of hardware acceleration in the RAN node can be effectively executed from both the O-Cloud (hardware acceleration management unit 14) and the Near-RT RIC.

[0041] 8 is a flowchart showing an example of control of hardware acceleration by the radio access network controller 1. In the flowchart, "S" denotes a step and / or a process.

[0042] In S1, the O1 information acquisition unit 11 acquires O1 information related to at least one of the Near-RT RIC and the E2 node through the O1 interface. For example, a Non-RT RIC in which the hardware acceleration guideline issuing unit 13 is provided transmits a subscription request for performance data of the HW accelerator manager and an AAL profile being deployed in an active AAL logical processing unit from the application layer (user space) through the O1 interface.

[0043] In S2, the O2 information acquisition unit 12 acquires O2 information related to the O-Cloud through the O2 interface. For example, the Non-RT RIC framework in which the hardware acceleration guideline issuing unit 13 is provided sends a discovery request for cloud inventory data (e.g., the number of unused or used hardware processing units, their availability, power consumption, etc.) in the IMS via the OAM. This discovery result is shared with the non-RT RIC by the OAM of the SMO framework. In addition, the Non-RT RIC that recognizes a specific service in the O-Cloud sends a subscription request to the IMS of the O-Cloud through the O2-IMS interface to collect data.

[0044] Note that in S1 and / or S2, the OAM Function of the SMO may enable subscription of the E2 node for data collection.

[0045] In S3, the hardware acceleration guideline issuing unit 13 in the Non-RT RIC issues hardware acceleration guidelines for hardware acceleration in RAN nodes or E2 nodes virtually managed by the O-Cloud. Specifically, the Non-RT RIC inputs various O1 information (application performance, accelerator monitoring data, etc.) and / or O2 information (HW accelerator performance, configuration data, etc.) acquired in S1 and / or S2 to a trained AI / ML model deployed through the AI / ML workflow function (Figure 3). Based on the output from the AI / ML model, the hardware acceleration guideline issuing unit 13 issues hardware acceleration guidelines to realize appropriate mapping of AAL logical processing units and HW accelerators according to the O-RAN situation and to have the active AAL logical processing unit select an appropriate AAL profile according to the O-RAN situation. This hardware acceleration guideline is provided to the NFO of the SMO as an A2 policy via the A2 interface, and further provided to the DMS and hardware acceleration management unit 14 (Hardware Accelerator Manager) in the O-Cloud.

[0046] In S4, the hardware acceleration management unit 14 causes the active AAL logical processing unit to select an appropriate AAL profile according to the O-RAN situation, in accordance with the hardware acceleration policy provided in S3. The hardware acceleration management unit 14 receives feedback, such as the success or failure of the execution results of the hardware acceleration policy, from the AAL logical processing unit group and the HW accelerator group. This feedback is provided to the NFO of the SMO via the DMS, and further provided to the hardware acceleration policy issuer 13 in the Non-RT RIC and / or rApp.

[0047] When applying the above-described embodiment to the existing "O-RAN" established by the O-RAN Alliance, it is preferable to add the following changes to the SMO framework and / or the Non-RT RIC framework.

[0048] Change 1: Non-RT RICs will be able to issue policies and guidance to SMOs (NFOs) regarding the deployment of AAL logical processing units.

[0049] Change 2: The specification of the internal interface (A2 interface) is written in terms of issuing guidelines.

[0050] Change 3: The A2 interface can issue guidelines to SMO for optimizing O-Cloud resources (additional input, reduction, etc.) and maintaining efficient use of hardware resources.

[0051] Change 4: Services from the HW accelerator management unit are added to O1-related services and / or O2-related services so that they can be enjoyed by non-RT RICs as well.

[0052] Change 5: SMO function (NFO) supports triggering of non-RT RIC from the perspective of AAL profile deployment.

[0053] The present disclosure has been described above based on the embodiments. Various modifications are possible to the combinations of the components and processes in the exemplary embodiments, and it will be obvious to those skilled in the art that such modifications are included within the scope of the present disclosure.

[0054] The configuration, operation, and function of each device and method described in the embodiments can be realized by hardware resources, software resources, or a combination of hardware and software resources. Examples of hardware resources include processors, ROMs, RAMs, and various integrated circuits. Examples of software resources include operating systems, applications, and other programs.

[0055] This disclosure may be expressed in the following terms:

[0056] Item 1: The Hardware Acceleration Guidelines Publishing Department issues hardware acceleration guidelines for hardware acceleration in radio access network nodes virtually managed by a virtualization platform in the Non-RT RIC (Non-Real Time RAN Intelligent Controller) of O-RAN; A radio access network controller comprising at least one processor executing: Item 2: The radio access network control device described in item 1, wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to a device outside the Non-RT RIC through an A2 interface within an SMO (Service Management and Orchestration) including the Non-RT RIC. Item 3: 3. The radio access network control device according to item 1 or 2, wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to the virtualization platform through an O2 interface. Item 4: Item 4. The radio access network control device according to item 3, wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to a hardware acceleration management unit in the virtualization infrastructure. Item 5: 5. The radio access network control device according to any one of items 1 to 4, wherein the hardware acceleration guideline issuing unit issues the hardware acceleration guideline by an rApp executed by the Non-RT RIC. Item 6: The at least one processor further executes an O2 information acquisition unit to acquire O2 information related to the virtualization infrastructure through an O2 interface; The hardware acceleration guideline issuing unit issues the hardware acceleration guideline based on the O2 information. 6. A radio access network controller according to any one of items 1 to 5. Item 7: The at least one processor further performs, by an O1 information acquisition unit, acquiring O1 information related to at least one of a Near-RT RIC (Near-Real Time RAN Intelligent Controller) and the radio access network node through an O1 interface; The hardware acceleration guideline issuing unit issues the hardware acceleration guideline based on the O1 information. 7. A radio access network controller according to any one of items 1 to 6. Item 8: 8. The radio access network control device according to any one of items 1 to 7, wherein the hardware acceleration guideline issuing unit issues the hardware acceleration guideline regarding hardware acceleration in a baseband unit of the radio access network node. Item 9: Item 9. The radio access network control device according to item 8, wherein the hardware acceleration guideline issuing unit issues the hardware acceleration guideline regarding hardware acceleration in at least one of an aggregation unit and a distribution unit of the baseband unit. Item 10: 10. The radio access network control device according to any one of items 1 to 9, wherein the virtualization platform is an O-Cloud of an O-RAN. Item 11: Issue hardware acceleration guidelines for O-RAN Non-RT RIC (Non-Real Time RAN Intelligent Controller) regarding hardware acceleration in radio access network nodes that are virtually managed by a virtualization platform; A radio access network control method comprising: Item 12: Issue hardware acceleration guidelines for O-RAN Non-RT RIC (Non-Real Time RAN Intelligent Controller) regarding hardware acceleration in radio access network nodes that are virtually managed by a virtualization platform; A storage medium storing a radio access network control program that causes a computer to execute the above. [Industrial Applicability]

[0057] The present disclosure relates to the publication of hardware acceleration guidelines in O-RAN. [Explanation of symbols]

[0058] 1 Radio access network control device, 11 O1 information acquisition unit, 12 O2 information acquisition unit, 13 Hardware acceleration guideline issuing unit, 14 Hardware acceleration management unit.

Claims

1. A hardware acceleration guideline issuing unit issues, in a Non-Real Time RAN Intelligent Controller (Non-RT RIC) of the O-RAN, a hardware acceleration guideline regarding hardware acceleration in a radio access network node virtually managed by a virtualization platform to a hardware acceleration management unit outside the Non-RT RIC; at least one processor executing The hardware acceleration guideline is for selecting a profile by the hardware acceleration management unit and realizing the hardware acceleration listed in the profile.

2. The radio access network control device according to claim 1, wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to an outside of the Non-RT RIC through an A2 interface in an SMO (Service Management and Orchestration) including the Non-RT RIC.

3. The radio access network controller according to claim 1 , wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to the virtualization platform through an O2 interface.

4. The radio access network control device according to claim 3 , wherein the hardware acceleration guideline issuing unit provides the hardware acceleration guideline to the hardware acceleration management unit in the virtualization infrastructure.

5. The radio access network controller according to claim 1 , wherein the hardware acceleration policy issuing unit issues the hardware acceleration policy by an rApp executed by the Non-RT RIC.

6. The at least one processor further executes an O2 information acquisition unit to acquire O2 information related to the virtualization infrastructure through an O2 interface; The hardware acceleration guideline issuing unit issues the hardware acceleration guideline based on the O2 information. The radio access network controller according to claim 1 .

7. The at least one processor further performs, by an O1 information acquisition unit, acquiring O1 information related to at least one of a Near-RT RIC (Near-Real Time RAN Intelligent Controller) and the radio access network node through an O1 interface; The hardware acceleration guideline issuing unit issues the hardware acceleration guideline based on the O1 information. The radio access network controller according to claim 1 .

8. The radio access network controller according to claim 1 , wherein the hardware acceleration guideline issuing unit issues the hardware acceleration guideline regarding hardware acceleration in a baseband unit of the radio access network node.

9. The radio access network controller according to claim 8 , wherein the hardware acceleration guideline issuing unit issues the hardware acceleration guideline regarding hardware acceleration in at least one of an aggregation unit and a distribution unit of the baseband unit.

10. The radio access network control device according to claim 1 , wherein the virtualization platform is an O-Cloud of an O-RAN.

11. In an O-RAN Non-RT RIC (Non-Real Time RAN Intelligent Controller), hardware acceleration guidelines regarding hardware acceleration in radio access network nodes virtually managed by a virtualization platform are issued to entities outside the Non-RT RIC; Equipped with The hardware acceleration guideline is for selecting a profile outside the Non-RT RIC and realizing the hardware acceleration listed in the profile.

12. In an O-RAN Non-RT RIC (Non-Real Time RAN Intelligent Controller), hardware acceleration guidelines regarding hardware acceleration in radio access network nodes virtually managed by a virtualization platform are issued to entities outside the Non-RT RIC; on the computer, A storage medium that stores a radio access network control program in which the hardware acceleration guidelines are for selecting a profile outside the Non-RT RIC and realizing the hardware acceleration listed in the profile.

Images