Validating rApp Instructions in SMO

Abstract

This wireless access network control device comprises at least one processor that: verifies, by using an indication verification unit provided to the service management and orchestration (SMO) of an open radio access network (O-RAN), an indication to outside of the SMO, the indication being generated by a rApp that is executed by a non-real time RAN intelligent controller (Non-RT RIC) in the SMO; and issues the verified indication to outside of the SMO by using an indication issuance unit provided to the SMO. The indication verification unit verifies an operation guideline relating to operation of a wireless access network node generated by the rApp, and the indication issuance unit issues the verified operation guideline to at least one of the wireless access network node, a virtualization infrastructure that virtually manages the wireless access network node, and a near-real time RAN intelligent controller (Near-RT RIC) (fig. 4).

Description

[Technical Field]

[0001] The present disclosure relates to the verification of rApp instructions in the SMO of O-RAN. [Background technology]

[0002] With the aim of opening up radio access networks (RANs) in mobile communication systems, studies are underway on "Open RAN," "O-RAN," "vRAN," and other concepts. In this specification, "O-RAN" is used as a comprehensive term to refer to such 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 formulated by the O-RAN Alliance.

[0003] The control unit of O-RAN is equipped with a Non-RT RIC (Non-Real Time RAN Intelligent Controller) that has a relatively long control cycle (for example, one second or more) for executing application software called rApp, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller) that has a relatively short control cycle (for example, less than one second) for executing application software called xApp. In addition, 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]

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

[0005] The Non-RT RIC is located in the Service Management and Orchestration (SMO) and generates various instructions to external RAN nodes, O-Cloud, Near-RT RICs, etc. through the execution of rApps. These instructions are issued to external SMOs via various interfaces, such as the O1 interface, O2 interface, and A1 interface. In conventional SMOs, instructions generated by rApps are issued to external SMOs almost as is, regardless of the target (RAN node, O-Cloud, Near-RT RIC, etc.) or interface (O1 interface, O2 interface, A1 interface, etc.). This means that rApps executing different tasks or jobs may issue conflicting instructions to external SMOs, resulting in the waste of resources within and outside the SMO for their execution, resolution, and coordination.

[0006] The present disclosure has been made in consideration of these circumstances, and aims to provide a radio access network control device and the like that can efficiently issue instructions generated by an rApp to outside the SMO. [Means for solving the problem]

[0007] In order to solve the above problem, a radio access network control device according to an embodiment of the present disclosure includes at least one processor that performs the following: an instruction verification unit provided in an SMO (Service Management and Orchestration) of an O-RAN verifies an instruction to be sent outside the SMO that is generated by an rApp executed by a Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO; and an instruction issuance unit provided in the SMO issues the verified instruction to be sent outside the SMO.

[0008] In this embodiment, an instruction verification unit provided in the SMO verifies an instruction of the rApp before the instruction issuance unit provided in the SMO issues the instruction to the outside of the SMO. Therefore, instructions generated by the rApp that have been verified by the instruction verification unit are efficiently issued to the outside of the SMO by the instruction issuance unit.

[0009] Another aspect of the present disclosure is a radio access network control method, comprising: verifying, in a Service Management and Orchestration (SMO) of an O-RAN, an instruction to an outside of the SMO, the instruction being generated by an rApp executed by a Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; and issuing, in the SMO, the verified instruction to an outside of the SMO.

[0010] Yet another aspect of the present disclosure is a storage medium storing a radio access network control program that causes a computer to execute the following operations: in a Service Management and Orchestration (SMO) of an O-RAN, verifying an instruction to an outside of the SMO that is generated by an rApp executed by a Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; and issuing, in the SMO, the verified instruction to an outside of the SMO.

[0011] 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]

[0012] According to the present disclosure, instructions generated by an rApp can be efficiently issued outside of the SMO. [Brief explanation of the drawings]

[0013] [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] FIG. 2 is a functional block diagram illustrating a radio access network control device. DETAILED DESCRIPTION OF THE INVENTION

[0014] 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.

[0015] 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. SMO (Service Management and Orchestration) controls the entire RAN control device or the entire O-RAN and coordinates the operations of each unit. 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 has a relatively long control period (e.g., one second or longer) and issues guidelines, policies, and guidance regarding the operation of each RAN node (O-CU and / or O-DU, described below), as well as configuration change instructions regarding configuration changes outside the SMO for each RAN node, O-Cloud, Near-RT RIC (Near-Real Time RAN Intelligent Controller), etc. Specifically, the Non-RT RIC executes application software called rApp to issue operation guidelines for each RAN node to the Near-RT RIC via the A1 interface and to issue configuration change instructions outside the SMO via the O1 interface, O2 interface, etc. 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.

[0016] 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).

[0017] 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 acquired 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 and configuration change instructions outside the SMO issued by the Non-RT RIC via the O1 interface, O2 interface, etc. Note that the O-RU may be connected to the SMO for FCAPS via the O1 interface or another interface (such as the Open Fronthaul M-Plane).

[0018] 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.

[0019] 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).

[0020] 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.

[0021] 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.

[0022] 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. The other SMO framework functions provide functions other than the O1-related functions and the O2-related functions. The other SMO framework functions are connected to the A2 terminal (not shown) in the Non-RT RIC via an A2 interface (not shown). 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.

[0023] The Non-RT Framework, which is the area of ​​the Non-RT RIC excluding rApp, includes an A1 Termination, A1 Related Functions, an A2 Termination (not shown), A2 Related Functions (not shown), an R1 Termination, R1 Service Exposure Functions, external terminations, data management / disclosure functions, artificial intelligence / machine learning workflow functions, policy / conflict management functions, and other Non-RT RIC Framework Functions.

[0024] The A1 terminal is the terminal of the A1 interface in the Non-RT framework. As shown in FIG. 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 (not shown) is the terminal of the A2 interface (not shown) 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 (not shown) directly connected to the A2 terminal provide various functions related to the A2 interface, other SMO framework functions, etc.

[0025] 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.

[0026] The data management / disclosure function manages various data on the main bus MB and provides the function of disclosing it in a manner according to the access permissions of each functional block. The artificial intelligence / machine learning workflow function provides the function of managing 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 policy / conflict management function, as described below, constitutes an instruction verification unit that verifies instructions (operation guidelines and configuration change instructions) generated by rApps to outside the SMO.

[0027] Other Non-RT RIC framework functions provide functions other than the above-mentioned various Non-RT framework functions. 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, policy / conflict management function, and other Non-RT RIC framework functions, are connected to the main bus MB that extends to the outside of the Non-RT RIC. Each of these function blocks can exchange data with other function blocks inside and outside the Non-RT RIC through the main bus MB.

[0028] Fig. 4 is a functional block diagram 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 the Non-RT framework in Fig. 3. Note that some of the functional blocks in Fig. 3 (specifically, the R1 service disclosure function, external termination, data management / disclosure function, artificial intelligence / machine learning workflow function, and other Non-RT RIC framework functions) are omitted from the diagram.

[0029] The radio access network control device 1 includes an O1 / O2 information acquisition unit 11, an O1 / O2 information provision unit 12, an operation guideline generation unit 13, a configuration change instruction generation unit 14, an instruction verification unit 15, and an instruction issuance unit 16. These functional blocks are realized by the cooperation of hardware resources such as a processor (e.g., 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 its 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 processor provided in the SMO and / or Non-RT RIC, or may be realized in a distributed or centralized manner by computers or processors provided outside the SMO and / or Non-RT RIC.

[0030] The O1 information acquisition unit included in the O1 / O2 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 is provided in the SMO and / or Non-RT RIC and acquires O1 information from the Near-RT RIC and / or E2 node via the O1 interface. Examples of O1 information include various control information indicating the control state of the Near-RT RIC and operational data measured individually for each E2 node. The operational 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 status of the hardware of the E2 node and the O-RU. In this way, the O1 information acquisition unit constitutes an operational data acquisition unit that acquires operational data measured from the RAN node.

[0031] The O1 information acquisition unit in FIG. 4 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 may be provided entirely or partially within the SMO framework outside the Non-RT framework. Furthermore, the O1 information acquisition unit only needs to be able to access related functional blocks within the SMO, specifically, the O1 termination, O1-related functions, the O1 / O2 information provider 12 (particularly the O1 information provider), the policy / conflict management function (particularly the instruction verification unit 15), the R1 termination, the rApp (the operation guideline generator 13 and / or the configuration change instruction generator 14), 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 in the O1-related function within the SMO framework (outside the Non-RT framework) that is most closely related among these related functional blocks.

[0032] The O2 information acquisition unit included in the O1 / O2 information acquisition unit 11 constitutes a virtualization infrastructure information acquisition unit that acquires O2 information as virtualization infrastructure information related to the O-Cloud from the O2 interface. Specifically, the O2 information acquisition unit 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 O-Cloud configuration and telemetry, and / or faults and operational statuses of each E2 node (each RAN node) virtually managed by the O-Cloud. Examples of the operational status of each E2 node include resource usage and communication load statuses in each E2 node. For example, the FOCOM in the SMO may acquire this O2 information from the IMS in the O-Cloud through the O2ims interface, or the OAM Function in the SMO may acquire it from the O-Cloud through the O2 interface. In this way, the O2 information acquisition unit constitutes an operational status acquisition unit that acquires the operational status of a RAN node from the O-Cloud that virtually manages the RAN node.

[0033] The O2 information acquisition unit in FIG. 4 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 may be provided entirely or partially within the SMO framework outside the Non-RT framework. Furthermore, the O2 information acquisition unit only needs to be able to access related functional blocks within the SMO, specifically, the O2 termination, O2-related functions, the O1 / O2 information provider 12 (particularly the O2 information provider), the policy / conflict management function (particularly the instruction verification unit 15), the R1 termination, and the rApp (the operation guideline generator 13 and / or the configuration change instruction generator 14), 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 O2 information acquisition unit in the O2-related functions within the SMO framework (outside the Non-RT framework) that are most closely related among these related functional blocks.

[0034] The O1 / O2 information provider 12 provides the O1 information and / or O2 information acquired by the O1 / O2 information acquirer 11 to the rApp through the R1 interface in the Non-RT RIC. The O2 information provider included in the O1 / O2 information provider 12 constitutes a virtualization infrastructure information provider that provides virtualization infrastructure information (O2 information) to the rApp through the R1 interface, which is the interface with the rApp. The O1 / O2 information provider 12 in FIG. 4 is shown schematically on the main bus MB within the Non-RT framework. However, the O1 / O2 information provider 12 may be provided in whole or in part within the Non-RT framework. Furthermore, the O1 / O2 information provider 12 only needs to be able to access related functional blocks within the SMO, specifically, the O1 / O2 information acquisition unit 11, policy / conflict management function (particularly the instruction verification unit 15), R1 termination, R1 service disclosure function (not shown), rApp (operation guideline generator 13 and / or configuration change instruction generator 14), etc., and does not necessarily have to be directly connected to the main bus MB. Of these related functional blocks, it is preferable to realize some or all of the functions of the O1 / O2 information provider 12 in the R1 service disclosure function (not shown) within the Non-RT framework, which is the most related.

[0035] The operation guideline generation unit 13, which is realized by rApp, generates operation guidelines for the operation of each RAN node based on the operation status and operation data of each RAN node acquired by the O1 / O2 information acquisition unit 11 and provided by the O1 / O2 information provision unit 12. Among the operation guidelines generated by the operation guideline generation unit 13, examples of those issued to the O-Cloud via the O2 interface by the instruction issuing unit 16 described later include resource allocation guidelines and / or load management guidelines related to resource allocation and / or load management of multiple RAN nodes. Furthermore, among the operation guidelines generated by the operation guideline generation unit 13, examples of those issued to the Near-RT RIC and each RAN node via the A1 interface or O1 interface by the instruction issuing unit 16 described later include traffic control guidelines related to traffic control of each RAN node.

[0036] The Near-RT RIC, which receives operation guidelines and / or traffic control guidelines via the A1 interface, controls each RAN node based on the guidelines via the E2 interface (Figure 1). For example, if the traffic control guidelines are to reduce traffic at a specific RAN node, the Near-RT RIC performs traffic restriction processing on UEs within the communication cell provided by the RAN node itself or the O-RU connected to it, such as directing UEs connected to the RAN node to other available RAN nodes, restricting the communication speed and communication volume of UEs connected to the RAN node, and restricting the connection of new UEs to the RAN node.

[0037] The operation guideline generation unit 13 may generate operation guidelines including the resource allocation guideline, load management guideline, and traffic control guideline by using a machine learning model provided by an artificial intelligence / machine learning workflow function (not shown). This machine learning model can derive a set of operation guidelines from a set of faults and operation statuses of multiple RAN nodes acquired from the O-Cloud via the O2 interface by an O2 information acquisition unit (O1 / O2 information acquisition unit 11) constituting the operation status acquisition unit, and individual operation data for each RAN node acquired via the O1 interface or the like by an O1 information acquisition unit (O1 / O2 information acquisition unit 11) constituting the operation data acquisition unit. Specifically, the machine learning model to which the set of operation statuses from the O2 information acquisition unit (operation status acquisition unit) and operation data from the O1 information acquisition unit (operation data acquisition unit) are input outputs a set of operation guidelines, such as a resource allocation guideline and a load management guideline to be issued to the O-Cloud via the O2 interface, and a traffic control guideline to be issued to each RAN node via the A1 interface or the O1 interface, based on machine learning previously performed using comprehensive training data or teacher data that associates input and output.

[0038] In this way, the machine learning model of this embodiment associates a set of input (operational status) from O-Cloud and input (operational data) from each RAN node with a set of output to O-Cloud (resource allocation guidelines, load management guidelines, etc.) and output to each RAN node (traffic control guidelines, etc.). Compared to a simple case in which input from O-Cloud is individually associated with output to O-Cloud and input from each RAN node is individually associated with output to each RAN node, the machine learning model of this embodiment can comprehensively or comprehensively consider correlations between inputs and outputs of O-Cloud and each RAN node, and therefore can effectively manage operation guidelines for efficiently operating each RAN node from both the O-Cloud and each RAN node's perspective.

[0039] The configuration change instruction generation unit 14 realized by rApp generates a configuration change instruction for a configuration change outside the SMO based on various O1 information and / or O2 information (including the operating status and operating data of each RAN node described above) acquired by the O1 / O2 information acquisition unit 11 and provided by the O1 / O2 information provision unit 12. The configuration change instruction generated by the configuration change instruction generation unit 14 instructs changing at least a portion of the configuration outside the SMO in the O-RAN, for example, software and / or hardware in the O-RU, RAN node, O-Cloud, and Near-RT RIC.

[0040] A configuration change instruction for hardware such as an O-RU or a RAN node may include an instruction to execute (or stop) so-called hardware acceleration. Hardware acceleration is a technology that supports general-purpose processors such as CPUs (Central Processing Units) using hardware 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.

[0041] The configuration change instruction generator 14 may generate configuration change instructions using a machine learning model provided by an artificial intelligence / machine learning workflow function (not shown). This machine learning model can derive a set of configuration change instructions from a set of various O1 information and / or O2 information acquired by the O1 / O2 information acquirer 11 through the O1 interface and / or the O2 interface. Specifically, the machine learning model to which the sets of various O1 information and O2 information from the O1 / O2 information acquirer 11 are input outputs a set of configuration change instructions to be issued outside the SMO via the O1 interface, the O2 interface, the A1 interface, etc., based on machine learning previously performed using comprehensive training data or teacher data that associates inputs and outputs. This machine learning model associates a set of inputs (O1 information and O2 information) from outside the SMO with a set of outputs (configuration change instructions) to outside the SMO.

[0042] As described above, the Non-RT RIC provided in the SMO generates various instructions (particularly, operation guidelines and configuration change instructions) for RAN nodes, O-Cloud, Near-RT RICs, etc. outside the SMO through the execution of rApps. These instructions are issued to the outside of the SMO through various interfaces, such as the O1 interface, O2 interface, and A1 interface. In conventional SMOs, instructions generated by rApps are issued to the outside of the SMO almost as is, regardless of the target (RAN node, O-Cloud, Near-RT RIC, etc.) or interface (O1 interface, O2 interface, A1 interface, etc.). As a result, there is a risk that rApps executing different tasks or jobs may issue conflicting instructions to the outside of the SMO, resulting in the waste of resources in the SMO itself and outside the SMO for the execution, resolution, adjustment, etc. of these conflicts. According to the radio access network control device 1 (particularly, the instruction verification unit 15 and the instruction issuing unit 16) of this embodiment described below, instructions generated by rApps can be issued to the outside of the SMO efficiently.

[0043] The instruction verification unit 15 provided in the SMO verifies instructions to outside the SMO generated by an rApp executed by a Non-RT RIC in the SMO. Specifically, the instruction verification unit 15 verifies both the operation guidelines for RAN node operation generated by the operation guidelines generation unit 13 in the rApp and the configuration change instructions for configuration changes outside the SMO generated by the configuration change instruction generation unit 14 in the rApp. For example, the instruction verification unit 15 performs at least one of a prioritization process, an issuance scheduling process, a cancellation process, and a change process on each instruction (each operation guidelines and each configuration change instruction) generated by the rApp. The prioritization process assigns priorities to multiple instructions generated by the rApp. The issuance scheduling process specifies the issuance timing by the instruction issuing unit 16 for each instruction generated by the rApp. The cancellation process cancels instructions generated by the rApp that are inconsistent or conflict with other instructions or that may degrade the performance or efficiency of the O-RAN. The modification process is a process of making various modifications to instructions generated by the rApp that would otherwise be subject to cancellation. Note that the rApp may perform modification processes on behalf of the instruction verification unit 15 for instructions that the instruction verification unit 15 has identified as subject to cancellation.

[0044] The instruction verification unit 15 is provided anywhere within the SMO so that it can access the instructions (operation guidelines and configuration change instructions) generated by the rApp. However, for efficient access to substantially all instructions generated by the rApp, it is preferable that at least a portion of the instruction verification unit 15 is provided in the Non-RT RIC, and it is even more preferable that it is provided alongside the R1 interface that interfaces with the rApp. For example, it is preferable that at least a portion of the instruction verification unit 15 is provided in the R1 terminal, which is the terminal of the R1 interface that constitutes the API of the rApp, or in the R1 service disclosure function (not shown) provided accompanying it.

[0045] The instruction issuing unit 16 provided in the SMO issues, to the outside of the SMO, the instructions of the rApp verified by the instruction verifying unit 15. Specifically, the instruction issuing unit 16 issues, to the outside of the SMO, the operation guidelines relating to the operation of the RAN node generated by the operation guideline generating unit 13 in the rApp and the configuration change instructions relating to the configuration change outside of the SMO generated by the configuration change instruction generating unit 14 in the rApp that have been verified by the instruction verifying unit 15.

[0046] The instruction issuing unit 16 issues operation guidelines verified by the instruction verifying unit 15 to at least one of the RAN node, the O-Cloud that virtually manages the RAN node, and the Near-RT RIC. Specifically, the instruction issuing unit 16 issues the operation guidelines verified by the instruction verifying unit 15 to the Near-RT RIC via the A1 interface, issues the operation guidelines verified by the instruction verifying unit 15 to the O-Cloud via the O2 interface, and issues the operation guidelines verified by the instruction verifying unit 15 to the RAN node and the O-RU via the O1 interface or the Open Fronthaul M-Plane. In addition, the instruction issuing unit 16 issues a configuration change instruction verified by the instruction verifying unit 15 to at least one of the RAN node, the O-Cloud that virtually manages the RAN node, and the Near-RT RIC. Specifically, the instruction issuing unit 16 issues a configuration change instruction verified by the instruction verifying unit 15 to the O-Cloud via the O2 interface, and issues a configuration change instruction verified by the instruction verifying unit 15 to the RAN node, O-RU, Near-RT RIC, etc. via the O1 interface, Open Fronthaul M-Plane, A1 interface, etc.

[0047] The instruction issuing unit 16 issues instructions that have been prioritized by the instruction verification unit 15 outside the SMO according to the assigned priorities. Therefore, important instructions with high priority, urgency, application frequency, impact, etc. are preferentially issued outside the SMO (note that instructions with high application frequency or impact may be lowered in priority because they require careful verification). Furthermore, the instruction issuing unit 16 issues instructions that have been scheduled for issuance by the instruction verification unit 15 outside the SMO according to a specified schedule and / or issuance timing. In this way, by appropriately determining the issuance order and issuance timing of rApp instructions according to the situation in the O-RAN (particularly outside the SMO), it is possible to improve the performance and efficiency of the O-RAN.

[0048] The instruction issuing unit 16 does not issue outside the SMO an instruction that has been cancelled by the instruction verifying unit 15. Furthermore, for instructions that have been changed by the instruction verifying unit 15 and / or rApp, the instruction issuing unit 16 issues the changed instructions outside the SMO according to the priority and schedule. This effectively prevents instructions generated by an rApp that are inconsistent or conflict with other instructions or that may degrade the performance or efficiency of O-RAN from being issued outside the SMO as is.

[0049] The instruction issuing unit 16 is provided at any location within the SMO so as to have access to the instruction verification unit 15, which obtains verification results of rApp instructions, and the A1 interface, O1 interface, and O2 interface, which are locations for issuing instructions to outside the SMO. However, for rapid issuance of instructions to outside the SMO, it is preferable that at least a portion of the instruction issuing unit 16 be provided alongside at least one of the A1 interface, O1 interface, and O2 interface, which are interfaces with outside the SMO. For example, the function of the instruction issuing unit 16 related to issuing operation guidelines and the like via the A1 interface is preferably provided in the A1 terminal, which is the end of the A1 interface, or in an A1-related function provided therewith; the function of the instruction issuing unit 16 related to issuing configuration change instructions and the like via the O1 interface is preferably provided in the O1 terminal, which is the end of the O1 interface, or in an O1-related function provided therewith; and the function of the instruction issuing unit 16 related to issuing configuration change instructions and the like via the O2 interface is preferably provided in the O2 terminal, which is the end of the O2 interface, or in an O2-related function provided therewith.

[0050] As described above, the instruction issuing unit 16 issues various instructions (operation guidelines, configuration change instructions, etc.) generated by the rApp to various configurations outside the SMO (O-RU, RAN node, O-Cloud, Near-RT RIC, etc.) via various interfaces (A1 interface, O1 interface, O2 interface, etc.). Therefore, it is efficient to distribute and implement the relevant functions of the instruction issuing unit 16 in each interface that is a location where instructions are issued to outside the SMO. Similarly, by distributing and implementing the relevant functions of the instruction verification unit 15 in each interface (A1 interface, O1 interface, O2 interface, etc.), the policy / conflict management function configured by the instruction verification unit 15 and the instruction issuing unit 16 can be optimized for each interface that is a location where instructions are issued to outside the SMO.

[0051] For example, for the A1 interface, which is mainly responsible for issuing operation guidelines to Near-RT RICs, a function of the instruction verification unit 15 for verifying the operation guidelines for Near-RT RICs generated by the operation guideline generation unit 13 is provided in the A1 terminal or A1-related functions, and a function of the instruction issue unit 16 for issuing the verified operation guidelines to Near-RT RICs through the A1 interface is provided in the A1 terminal or A1-related functions. Similarly, for the O1 interface, which is mainly responsible for issuing configuration change instructions to RAN nodes, a function of the instruction verification unit 15 for verifying the configuration change instructions for RAN nodes generated by the configuration change instruction generation unit 14 is provided in the O1 terminal or O1-related functions, and a function of the instruction issue unit 16 for issuing the verified configuration change instructions to RAN nodes through the O1 interface is provided in the O1 terminal or O1-related functions. In addition, with regard to the O2 interface, which is mainly responsible for issuing configuration change instructions to O-Cloud, a function of the instruction verification unit 15 to verify the configuration change instructions to O-Cloud generated by the configuration change instruction generation unit 14 is provided in the O2 terminal and O2-related functions, and a function of the instruction issuance unit 16 to issue the verified configuration change instructions to O-Cloud through the O2 interface is provided in the O2 terminal and O2-related functions.

[0052] Note that, like the operation guideline generation unit 13 and / or the configuration change instruction generation unit 14, the instruction verification unit 15 and / or the instruction issuance unit 16 may verify and / or issue rApp instructions using a machine learning model provided by the artificial intelligence / machine learning workflow function (FIG. 3) in the SMO. Furthermore, if the Near-RT RIC is also provided with a function similar to the artificial intelligence / machine learning workflow function, by providing some of the functions of the instruction verification unit 15 and / or the instruction issuance unit 16 in the Near-RT RIC, the verification and / or issuance of rApp instructions can be more efficiently performed based on information available there (e.g., actions initiated by the Near-RT RIC for each RAN node) and the machine learning model. Alternatively, various data generated by the machine learning model in the Near-RT RIC may be provided or aggregated to the instruction verification unit 15 and / or the instruction issuance unit 16 in the SMO via the O1 interface or the A1 interface, so that the verification and / or issuance of rApp instructions can be centralized in the SMO.

[0053] According to the present embodiment, before the instruction issuing unit 16 provided in the SMO issues an instruction of an rApp to an outside SMO, the instruction verifying unit 15 provided in the SMO verifies the instruction in a unified manner. Therefore, among the instructions generated by the rApp, those verified by the instruction verifying unit 15 are efficiently issued to an outside SMO by the instruction issuing unit 16.

[0054] 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.

[0055] 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.

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

[0057] Item 1: An instruction verification unit provided in an SMO (Service Management and Orchestration) of the O-RAN verifies an instruction to an outside of the SMO generated by an rApp executed by a Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO; issuing the verified instruction to an outside of the SMO by an instruction issuing unit provided in the SMO; A radio access network controller comprising at least one processor executing: Item 2: The instruction verification unit verifies an operation guideline regarding the operation of a radio access network node generated by the rApp; The instruction issuing unit issues the verified operation guideline to at least one of the radio access network node, a virtualization platform that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). Item 1. The radio access network controller according to item 1. Item 3: The instruction verification unit verifies a configuration change instruction generated by the rApp regarding a configuration change outside the SMO; the instruction issuing unit issues the verified configuration change instruction to at least one of a radio access network node, a virtualization platform that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller); Item 3. The radio access network controller according to item 1 or 2. Item 4: The instruction verification unit verifies a configuration change instruction regarding a configuration change outside the SMO generated by the rApp together with the operation guidelines; The instruction issuing unit issues the verified operation guideline and / or the configuration change instruction to at least one of the radio access network node, the virtualization platform, and the Near-RT RIC. Item 2. A radio access network controller. Item 5: The radio access network control device according to any one of items 1 to 4, wherein the instruction verification unit performs at least one of prioritization processing, issuance scheduling processing, cancellation processing, and change processing on the instruction generated by the rApp. Item 6: 6. The radio access network control device according to any one of items 1 to 5, wherein at least a part of the instruction verification unit is provided in the Non-RT RIC. Item 7: Item 7. The radio access network control device according to item 6, wherein at least a part of the instruction verification unit is provided in an R1 interface, which is an interface with the rApp. Item 8: 8. The radio access network control device according to any one of items 1 to 7, wherein at least a part of the instruction issuing unit is provided in at least one of an A1 interface, an O1 interface, and an O2 interface, which are interfaces with the outside of the SMO. Item 9: The at least one processor: acquiring, by a virtualization infrastructure information acquisition unit, virtualization infrastructure information from a virtualization infrastructure that virtually manages wireless access network nodes; A virtualization infrastructure information providing unit provides the virtualization infrastructure information to the rApp through an R1 interface, which is an interface with the rApp; Run The instruction verification unit verifies the instruction generated by the rApp based on the virtualization infrastructure information. 9. A radio access network controller according to any one of items 1 to 8. Item 10: The at least one processor: acquiring, by an operation status acquisition unit, an operation status of the radio access network node from a virtualization platform that virtually manages the radio access network node; acquiring, by an operation data acquisition unit, operation data measured from the radio access network node; generating an operation guideline for the operation of the radio access network node based on the operation status and the operation data by an operation guideline generating unit of the rApp; Run The instruction verification unit verifies the operation guideline. 10. A radio access network controller according to any one of items 1 to 9. Item 11: In an O-RAN Service Management and Orchestration (SMO), verifying instructions to an external SMO generated by an rApp executed by a Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; issuing, at the SMO, the verified instruction out of the SMO; A radio access network control method comprising: Item 12: In an O-RAN Service Management and Orchestration (SMO), verifying instructions to an external SMO generated by an rApp executed by a Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; issuing, at the SMO, the verified instruction out of the SMO; A storage medium storing a radio access network control program that causes a computer to execute the above. [Industrial Applicability]

[0058] The present disclosure relates to the verification of rApp instructions in the SMO of O-RAN. [Explanation of symbols]

[0059] 1 Radio access network control device, 11 O1 / O2 information acquisition unit, 12 O1 / O2 information provision unit, 13 Operation guideline generation unit, 14 Configuration change instruction generation unit, 15 Instruction verification unit, 16 Instruction issuance unit.

Claims

1. An instruction verification unit provided in an O-RAN SMO (Service Management and Orchestration) verifies instructions to an instruction target outside the SMO, which are generated by multiple rApps executed by a Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO; issuing the verified instruction to the instruction target outside the SMO by an instruction issuing unit provided in the SMO; at least one processor executing the instruction verification unit verifies one instruction to be verified based on another instruction to be verified or a previously verified instruction; Radio Access Network Controller.

2. The instruction verification unit verifies operation guidelines regarding operation of radio access network nodes generated by the plurality of rApps; The instruction issuing unit issues the verified operation guideline to at least one of the radio access network node, a virtualization platform that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). The radio access network controller according to claim 1 .

3. The instruction verification unit verifies configuration change instructions regarding configuration changes outside the SMO generated by the plurality of rApps; the instruction issuing unit issues the verified configuration change instruction to at least one of a radio access network node, a virtualization platform that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller); The radio access network controller according to claim 1 .

4. The instruction verification unit verifies configuration change instructions related to configuration changes outside the SMO generated by the plurality of rApps together with the operation guidelines; The instruction issuing unit issues the verified operation guideline and / or the configuration change instruction to at least one of the radio access network node, the virtualization platform, and the Near-RT RIC. The radio access network controller according to claim 2 .

5. The radio access network controller according to claim 1 , wherein the instruction verification unit performs at least one of a prioritization process, an issuance scheduling process, a cancellation process, and a change process on the instructions generated by the plurality of rApps.

6. The radio access network controller according to claim 1 , wherein at least a part of the instruction verification unit is provided in the Non-RT RIC.

7. The radio access network controller according to claim 6 , wherein at least a part of the instruction verification unit is provided in an R1 interface that is an interface with the plurality of rApps.

8. 2. The radio access network control device according to claim 1, wherein at least a part of the instruction issuing unit is provided in at least one of an A1 interface, an O1 interface, and an O2 interface which are interfaces with the outside of the SMO.

9. The at least one processor: acquiring, by a virtualization infrastructure information acquisition unit, virtualization infrastructure information from a virtualization infrastructure that virtually manages wireless access network nodes; A virtualization infrastructure information providing unit provides the virtualization infrastructure information to the rApp through an R1 interface, which is an interface with the rApp; Run The instruction verification unit verifies the instruction generated by the rApp based on the virtualization infrastructure information. The radio access network controller according to claim 1 .

10. The at least one processor: acquiring, by an operation status acquisition unit, an operation status of the radio access network node from a virtualization platform that virtually manages the radio access network node; acquiring, by an operation data acquisition unit, operation data measured from the radio access network node; generating an operation guideline for the operation of the radio access network node based on the operation status and the operation data by an operation guideline generating unit of the rApp; Run The instruction verification unit verifies the operation guideline. The radio access network controller according to claim 1 .

11. In an O-RAN Service Management and Orchestration (SMO), verifying instructions to target devices outside the SMO generated by multiple rApps executed by a Non-RT Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; issuing, at the SMO, the verified instruction to the instruction target outside the SMO; A radio access network control method comprising:

12. In an O-RAN Service Management and Orchestration (SMO), verifying instructions to target devices outside the SMO generated by multiple rApps executed by a Non-RT Non-Real Time RAN Intelligent Controller (Non-RT RIC) in the SMO; issuing, at the SMO, the verified instruction to the instruction target outside the SMO; A radio access network control program that causes a computer to execute the above.

Images