WO2024057544A1

WO2024057544A1 - Verification of rapp indication in smo

Info

Publication number: WO2024057544A1
Application number: PCT/JP2022/034814
Authority: WO
Inventors: パンケージシェト; アウンムハンマド
Original assignee: 楽天モバイル株式会社
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2024-03-21

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

Verification of rApp instructions in SMO

This disclosure relates to verification of rApp instructions in SMO of O-RAN.

"Open RAN," "O-RAN," "vRAN," etc. are being considered with the aim of making the radio access network (RAN: Radio Access Network) open in mobile communication systems or mobile communication systems. In this specification, the term "O-RAN" is used to comprehensively represent various such "open radio access networks." Therefore, "O-RAN" in this specification is not interpreted to be limited to the standards and specifications of the same name developed by the O-RAN Alliance.

The O-RAN control unit uses a Non-RT RIC (Non-Real Time RAN Intelligent Controller) that executes application software called rApp, which has a relatively long control cycle (for example, 1 second or more), and application software called xApp. Equipped with a Near-RT RIC (Near-Real Time RAN Intelligent Controller) that executes a relatively short control cycle (for example, less than 1 second). Additionally, O-RAN provides a virtualization platform also called O-Cloud (hereinafter also referred to as O-Cloud for convenience) that virtually manages a collection of multiple radio access network nodes (RAN nodes).

JP 2021-83058 Publication

Non-RT RIC is installed in SMO (Service Management and Orchestration) and generates various instructions to RAN nodes outside SMO, O-Cloud, Near-RT RIC, etc. through the execution of rApp. These instructions are issued outside the SMO through various interfaces such as the O1 interface, O2 interface, and A1 interface. In traditional SMO, instructions generated by rApp are issued outside SMO almost unchanged, regardless of the target (RAN node, O-Cloud, Near-RT RIC, etc.) or interface (O1 interface, O2 interface, A1 interface, etc.) be done. As a result, rApps that execute different tasks or jobs may issue mutually contradictory instructions outside of SMO, and the resources of SMO itself and outside of SMO will be wasted for execution, resolution, coordination, etc. .

The present disclosure has been made in view of these circumstances, and aims to provide a radio access network control device, etc. that can efficiently issue instructions generated by an rApp outside of SMO.

In order to solve the above problems, a radio access network control device according to an embodiment of the present disclosure uses an instruction verification unit provided in an SMO (Service Management and Orchestration) of O-RAN to perform non-RT RIC (Non-RT Verifying the instructions to outside the SMO generated by the rApp executed by the Real Time RAN Intelligent Controller) and issuing the verified instructions to the outside of the SMO by the instruction issuing unit provided in the SMO. at least one processor for executing.

In this aspect, before the instruction issuing unit provided in the SMO issues an rApp instruction outside of the SMO, the instruction verification unit provided in the SMO verifies the instruction. Therefore, among the instructions generated by the rApp, those verified by the instruction verification section are efficiently issued outside the SMO by the instruction issuing section.

Another aspect of the present disclosure is a radio access network control method. This method verifies, in the O-RAN SMO (Service Management and Orchestration), the instructions generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO to outside the SMO. and issuing the verified instructions in the SMO to outside the SMO.

Yet another aspect of the present disclosure is a storage medium. This storage medium verifies instructions outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO in the O-RAN SMO (Service Management and Orchestration). The wireless access network control program stores a radio access network control program that causes the computer to perform the following steps: and in an SMO, issue a verified instruction outside the SMO.

Note that the present disclosure also includes any combination of the above constituent elements and the conversion of these expressions into methods, devices, systems, recording media, computer programs, etc.

According to the present disclosure, instructions generated by an rApp can be efficiently issued outside of SMO.

An overview of a radio access network control device is schematically shown. Schematically shows various functions realized by SMO and/or Non-RT RIC and O-Cloud. Schematically shows the internal configuration and/or functions of SMO and/or Non-RT RIC. FIG. 2 is a functional block diagram schematically showing a radio access network control device.

In the following, this embodiment will be described in accordance with "O-RAN", which is the standard and specification established by O-RAN Alliance. Therefore, in this embodiment, the well-known term defined by "O-RAN" is used for convenience, but the technology related to this disclosure is applicable to other existing radio access networks such as "Open RAN" and "vRAN". , it can also be applied to similar types of radio access networks that may be developed in the future.

FIG. 1 schematically shows an 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 O-RAN and causes each part to work together. SMO is equipped with a Non-RT RIC (Non-Real Time RAN Intelligent Controller) that functions as an overall control processor responsible for overall control. Non-RT RIC, which has a relatively long control cycle (for example, 1 second or more), provides guidelines, policies, and guidance regarding the operation of each RAN node (O-CU and/or O-DU, described later), and - Issue configuration change instructions regarding configuration changes outside of SMO, such as Cloud and Near-RT RIC (Near-Real Time RAN Intelligent Controller). Specifically, the Non-RT RIC runs an application software called rApp to issue operational guidelines for each RAN node to the Near-RT RIC through the A1 interface, and to issue configurations outside of SMO through the O1 interface, O2 interface, etc. Issue change orders. Near-RT RIC, which has a relatively short control cycle (for example, less than 1 second), runs application software called xApp and controls each RAN node (O-CU/O-DU) itself and each RAN node through the E2 interface. Controls general-purpose hardware, etc. in the wireless unit (O-RU) connected to the

The illustrated RAN nodes include O-CU, which is an O-RAN-compliant central unit (CU), and/or O-DU, which is an O-RAN-compliant distributed unit (DU). Be prepared. Both O-CU and O-DU are responsible for baseband processing in O-RAN, but O-CU is provided on the core network side (not shown), and O-DU is an O-RAN-compliant radio unit (RU : Radio Unit) is installed on the O-RU side. The O-CU may be divided into O-CU-CP, which constitutes a control plane (CP), and O-CU-UP, which constitutes a user plane (UP). Note that the O-CU and O-DU may be integrally configured as one baseband processing unit. Further, as a RAN node, an O-eNB as a base station compliant with O-RAN and a fourth generation mobile communication system (4G) may be provided. One or more O-RUs are connected to each RAN node (O-CU/O-DU), and are controlled by the Near-RT RIC via each RAN node. Communication equipment (UE: User Equipment) in the communication cell provided by each O-RU can be connected to each O-RU, and a core (not shown) can be connected via each RAN node (O-CU/O-DU). Can perform network and mobile communication.

Each RAN node (O-CU/O-DU) and Near-RT RIC transmits the operating data of each RAN node, each O-RU, and each UE through the O1 interface, so-called FCAPS (Fault, Configuration, Accounting, Performance, Security) provided to SMO. Based on the operation data obtained through the O1 interface, the SMO provides operational guidelines for each RAN node that the Non-RT RIC issues to the Near-RT RIC through the A1 interface, and the Non-RT RIC issues information on the O1 interface, O2 interface, etc. Update configuration change instructions outside of SMO issued through SMO as necessary. Note that the O-RU may be connected for SMO and FCAPS through the O1 interface or other interfaces (such as Open Fronthaul M-Plane).

O-Cloud, which serves as 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 through the O2 interface, SMO provides resource allocation guidelines and workload management for resource allocation of the multiple RAN nodes. ) and publish it to O-Cloud through the O2 interface.

Figure 2 schematically shows various functions realized by SMO and/or Non-RT RIC and O-Cloud. SMO mainly implements 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).

FOCOM manages resources in O-Cloud while receiving services from O-Cloud's IMS through the O2 interface (O2ims). NFO receives services from O-Cloud's DMS through the O2 interface (O2dms), and realizes the cooperative operation of a set of network functions (NFs) through multiple NF Deployments in O-Cloud. NFOs may utilize OAM Functions 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. The OAM Function in this embodiment monitors O2ims and/or O2dms procedures and provides callbacks to receive data regarding failures and operational status of multiple RAN nodes virtually managed by O-Cloud. It can be a provided functional block. IMS is responsible for managing O-Cloud resources (hardware) and the software used to manage them, and primarily provides services to SMO's FOCOM. One or more DMSs are responsible for managing multiple NF Deployments in O-Cloud, specifically starting, monitoring, terminating, etc., and mainly provide services to NFOs in SMO.

FIG. 3 schematically shows the internal configuration and/or functions of SMO and/or Non-RT RIC. SMO or SMO Framework includes Non-RT RIC. 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. Further, the broken lines in this figure represent functional blocks and connections that can be implemented in this embodiment.

The areas of the SMO framework excluding Non-RT RIC include O1 Termination, O1 Related Functions, O2 Termination, and O2 Related Functions. , Other SMO Framework Functions are provided. The O1 termination is the termination of the O1 interface in the SMO framework. As shown in Figure 1, Near-RT RIC and/or E2 nodes (RAN nodes such as O-CU/O-DU, O-RU, etc.) are connected to the O1 terminal via the O1 interface. . O1-related functions that are directly connected to the O1 termination provide various functions related to the O1 interface, Near-RT RIC, E2 node, etc. The O2 termination is the termination of the O2 interface in the SMO framework. As shown in Figure 1, O-Cloud is connected to the O2 terminal via the O2 interface. O2-related functions that are directly connected to the O2 terminal provide various functions related to the O2 interface, O-Cloud, etc. Other SMO framework functions provide other functions other than O1-related functions and O2-related functions. Other SMO framework functions are connected via the A2 termination (not shown) and A2 interface (not shown) in the Non-RT RIC. Various functions of the SMO framework, such as 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 functional blocks can exchange data with other functional blocks inside and outside the SMO framework (or inside and outside the Non-RT RIC) via the main bus MB.

The Non-RT Framework, which is the area of Non-RT RIC excluding rApp, includes A1 Termination, A1 Related Functions, and A2 Termination (not shown). A2 Termination), A2 Related Functions (not shown), R1 Termination, R1 Service Exposure Functions, External Terminations, and data management/disclosure functions (Data Management & Exposure Functions), artificial intelligence/machine learning workflow functions (AI/ML Workflow Functions), policy/conflict management functions (Policy & Conflict Manager), and other Non-RT RIC framework functions (Other Non -RT RIC Framework Functions).

A1 termination is the termination of the A1 interface in the Non-RT framework. As shown in Figure 1, Near-RT RIC is connected to the A1 terminal via the A1 interface. A1-related functions that are directly connected to the A1 termination 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. The A2 terminal is connected to the SMO framework and other SMO framework functions via the A2 interface. A2-related functions (not shown) that are directly connected to the A2 termination provide various functions related to the A2 interface and other SMO framework functions.

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

The data management/disclosure function provides a function of managing various data on the main bus MB and disclosing it in a manner according to the access authority of each functional block. Artificial intelligence/machine learning workflow functionality is performed using artificial intelligence (AI) and/or machine learning (ML) capabilities implemented in Non-RT RIC and/or Near RT RIC. Provides functionality to manage workflows. As described later, the policy/conflict management function constitutes an instruction verification unit that verifies instructions (operation guidelines and configuration change instructions) generated by the rApp to outside the SMO.

Other Non-RT RIC framework functions provide other functions in addition to the functions of the various Non-RT frameworks described above. 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, etc. - Various functions of the RT framework are connected to the main bus MB, which also 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.

FIG. 4 is a functional block diagram schematically showing the radio access network control device 1 according to the present embodiment. The radio access network control device 1 is provided in the SMO framework and/or the Non-RT framework in FIG. 3. This diagram shows some functional blocks in Figure 3 (specifically, R1 service disclosure function, external termination, data management/disclosure function, artificial intelligence/machine learning workflow function, and other Non-RT RIC framework functions). illustration is omitted.

The radio access network control device 1 includes an O1/O2 information acquisition section 11, an O1/O2 information provision section 12, an operation guideline generation section 13, a configuration change instruction generation section 14, an instruction verification section 15, and an instruction issuing section. 16. These functional blocks are realized through the cooperation of hardware resources such as the computer's central processing unit (central processing unit), memory, input devices, output devices, and peripheral devices connected to the computer, and the software that is executed using them. Realized. Regardless of the type of computer or installation location, each of the above functional blocks may be realized using the hardware resources of a single computer, or may be realized by combining hardware resources distributed across multiple computers. . In particular, in this embodiment, part 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 by a processor provided in the SMO and/or Non-RT RIC. It may also be implemented in a distributed or centralized manner using external computers and processors.

The O1 information acquisition unit included in the O1/O2 information acquisition unit 11 acquires O1 information regarding at least one of the Near-RT RIC and the E2 node (RAN node) from 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 through the O1 interface. Examples of the O1 information include various types of control information representing the control status of the Near-RT RIC and operational data measured individually for each E2 node. The operation data of each E2 node is a variety of data that can be detected by a general mobile communication base station, such as communication volume per hour, communication speed, number and type of connected UEs (communication devices), The strength and mode 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, the performance of the E2 node and O-RU hardware, etc. The state etc. are exemplified. In this way, the O1 information acquisition section constitutes an operation data acquisition section that acquires operation data measured from RAN nodes.

The O1 information acquisition unit in FIG. 4 is schematically shown so as to straddle the inside and outside of the Non-RT framework on the main bus MB. However, the O1 information acquisition unit may be provided in whole or in part within the SMO framework outside the Non-RT framework. In addition, the O1 information acquisition unit is responsible for related functional blocks within SMO, specifically O1 termination, O1 related functions, O1/O2 information provision unit 12 (especially O1 information provision unit), policy/conflict management function (especially It is only necessary to be able to access the instruction verification unit 15), R1 termination, rApp (operation guideline generation unit 13 and/or configuration change instruction generation unit 14), etc., and it does not necessarily need to be directly connected to the main bus MB. Among these related functional blocks, it is preferable to realize some or all of the functions of the O1 information acquisition unit in the most relevant O1-related functions within the SMO framework (outside the Non-RT framework).

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 regarding O-Cloud from the O2 interface. Specifically, the O2 information acquisition unit is provided in SMO and/or Non-RT RIC, and acquires O2 information from O-Cloud through the O2 interface. Examples of O2 information include information regarding the O-Cloud configuration and telemetry, and/or failures and operating status of each E2 node (each RAN node) virtually managed by O-Cloud. Examples of the operating status of each E2 node include resource usage and communication load status at each E2 node. For example, FOCOM in SMO may obtain this O2 information from IMS in O-Cloud through the O2ims interface, or OAM Function in SMO may obtain it from O-Cloud through the O2 interface. In this way, the O2 information acquisition unit constitutes an operation status acquisition unit that acquires the operation status of the RAN node from O-Cloud, which virtually manages the RAN node.

The O2 information acquisition unit in FIG. 4 is schematically shown on the main bus MB so as to straddle the inside and outside of the Non-RT framework. However, the O2 information acquisition unit may be provided in whole or in part within the SMO framework outside the Non-RT framework. In addition, the O2 information acquisition unit is responsible for related functional blocks within SMO, specifically O2 termination, O2 related functions, O1/O2 information provision unit 12 (especially O2 information provision unit), policy/conflict management function (especially It is only necessary to be able to access the instruction verification unit 15), R1 termination, rApp (operation guideline generation unit 13 and/or configuration change instruction generation unit 14), etc., and it does not necessarily need to be directly connected to the main bus MB. Among these related functional blocks, it is preferable to realize some or all of the functions of the O2 information acquisition unit in the most relevant O2-related functions within the SMO framework (outside the Non-RT framework).

The O1/O2 information providing unit 12 provides the rApp with O1 information and/or O2 information acquired by the O1/O2 information acquiring unit 11 through the R1 interface in the Non-RT RIC. The O2 information providing unit included in the O1/O2 information providing unit 12 constitutes a virtualization infrastructure information providing unit that provides virtualization infrastructure information (O2 information) to the rApp through the R1 interface, which is an interface with the rApp. The O1/O2 information providing unit 12 in FIG. 4 is schematically shown on the main bus MB within the Non-RT framework. However, the O1/O2 information providing unit 12 may be provided entirely or partially within the Non-RT framework. In addition, the O1/O2 information providing unit 12 includes related functional blocks within the SMO, specifically, the O1/O2 information acquisition unit 11, the policy/conflict management function (in particular, the instruction verification unit 15), the R1 termination, and the R1 service. It is only necessary to be able to access the disclosure function (not shown), rApp (operation guideline generation unit 13 and/or configuration change instruction generation unit 14), etc., and it does not necessarily need to be directly connected to the main bus MB. Among these related functional blocks, the most relevant R1 service disclosure function (not shown) in the Non-RT framework realizes some or all of the functions of the O1/O2 information providing unit 12. preferable.

The operation guideline generation unit 13 realized by rApp generates information for 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. Generate operational guidelines for RAN node operation. Among the operation guidelines generated by the operation guideline generation unit 13, those issued to O-Cloud through the O2 interface by the instruction issuing unit 16 (described later) include resources related to resource allocation and/or load management of multiple RAN nodes. Distribution guidelines and/or load management guidelines are illustrated. In addition, among the operation guidelines generated by the operation guideline generation unit 13, those issued to the Near-RT RIC and each RAN node through the A1 interface and O1 interface by the instruction issuing unit 16, which will be described later, are as follows: Traffic control guidelines regarding traffic control are illustrated.

The Near-RT RIC that receives the operation guidelines and/or traffic control guidelines through the A1 interface controls each RAN node through the E2 interface (Figure 1) based on the guidelines. For example, if the aforementioned traffic control guidelines are to reduce traffic at a particular RAN node, the Near-RT RIC may direct the UE connected to that RAN node to other available RAN nodes. The RAN node itself and the O-RU connected to it provide traffic restriction processing, such as limiting the communication speed and amount of communication of UEs connected to the RAN node, and restricting new UE connections to the RAN node. Performed for the UE within the communication cell.

The operation guideline generation unit 13 generates operation guidelines including the resource allocation guideline, load management guideline, and traffic control guideline described above by using a machine learning model provided by an artificial intelligence/machine learning workflow function (not shown). good. This machine learning model uses the faults, operating statuses, and operating data of multiple RAN nodes that the O2 information acquisition unit (O1/O2 information acquisition unit 11) that constitutes the operating status acquisition unit acquires from O-Cloud through the O2 interface. The O1 information acquisition unit (O1/O2 information acquisition unit 11) constituting the acquisition unit can derive a set of operation guidelines from a set of individual operation data for each RAN node acquired through the O1 interface or the like. Specifically, a machine learning model that is input with a set of operating status from the O2 information acquisition unit (operation status acquisition unit) and operation data from the O1 information acquisition unit (operation data acquisition unit) associates input and output. Based on machine learning performed in advance using comprehensive training data or teacher data, resource allocation guidelines and load management guidelines are issued to O-Cloud through the O2 interface, and each RAN node is issued through the A1 interface and O1 interface. Outputs a set of operational guidelines such as traffic control guidelines issued to

In this way, the machine learning model of this embodiment uses a set of input (operation status) from O-Cloud and input (operation data) from each RAN node to output to O-Cloud (resource allocation guidelines, load management guidelines, etc.) and output to each RAN node (traffic control guidelines, etc.). Compared to the simple case where inputs from O-Cloud are individually matched to outputs to O-Cloud, and inputs from each RAN node are individually matched to outputs to each RAN node, the machine learning of this embodiment According to the model, the correlation between input and output of O-Cloud and each RAN node can be considered comprehensively or exhaustively, so operation guidelines for efficiently operating each RAN node can be set for O-Cloud and each RAN node. It can be operated effectively from both sides.

The configuration change instruction generation unit 14 realized by rApp generates various O1 information and/or O2 information (for each RAN node mentioned above) acquired by the O1/O2 information acquisition unit 11 and provided by the O1/O2 information provision unit 12. generation of configuration change instructions for configuration changes outside of SMO The configuration change instruction generated by the configuration change instruction generation unit 14 changes the configuration outside of SMO in O-RAN, for example, at least one of the software and/or hardware in O-RU, RAN node, O-Cloud, and Near-RT RIC. This is an instruction to change the section.

A configuration change instruction regarding 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 specialized or customized for specific processing or applications such as FPGA (Field-Programmable Gate Array), GPU (Graphics Processing Unit), ASIC (Application Specific Integrated Circuit), DSP (Digital Signal Processor), etc. This is a technology that supports general-purpose processors such as CPUs (Central Processing Units) using hardware equipped with circuits. Even complex processing that requires a lot of time and power to be processed by software using a general-purpose processor can be executed quickly and efficiently by a dedicated processor implemented in hardware.

The configuration change instruction generation unit 14 may generate the configuration change instruction 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 that the O1/O2 information acquisition unit 11 has acquired through the O1 interface and/or the O2 interface. Specifically, a machine learning model into which various sets of O1 information and O2 information from the O1/O2 information acquisition unit 11 are input is trained in advance using exhaustive training data or teacher data that associates inputs and outputs. Based on the learned machine learning, it outputs a set of configuration change instructions that are issued outside the SMO through the O1 interface, O2 interface, A1 interface, etc. This machine learning model associates a set of inputs from outside SMO (O1 information and O2 information) with a set of outputs from outside SMO (configuration change instructions).

As mentioned above, the Non-RT RIC installed in SMO generates various instructions (especially operation guidelines and configuration change instructions) to RAN nodes outside SMO, O-Cloud, Near-RT RIC, etc. through the execution of rApp. do. These instructions are issued outside the SMO through various interfaces such as the O1 interface, O2 interface, and A1 interface. In traditional SMO, instructions generated by rApp are issued outside SMO almost unchanged, regardless of the target (RAN node, O-Cloud, Near-RT RIC, etc.) or interface (O1 interface, O2 interface, A1 interface, etc.) be done. As a result, rApps that execute different tasks or jobs may issue mutually contradictory instructions outside of SMO, and the resources of SMO itself and outside of SMO will be wasted for execution, resolution, coordination, etc. . According to the radio access network control device 1 (particularly the instruction verification unit 15 and instruction issuing unit 16) according to the present embodiment described below, instructions generated by an rApp can be efficiently issued outside of SMO.

The instruction verification unit 15 provided in the SMO verifies the instruction to outside the SMO generated by the rApp executed by the Non-RT RIC in the SMO. Specifically, the instruction verification unit 15 uses the operation guidelines related to the operation of RAN nodes generated by the operation guideline generation unit 13 in rApp, and the configuration change instructions regarding configuration changes outside of SMO generated by the configuration change instruction generation unit 14 in rApp. We will also verify this. 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 guideline and each configuration change instruction) generated by the rApp. The prioritization process is a process of assigning priorities to multiple instructions generated by the rApp. The issuance scheduling process is a process of specifying the issuance timing by the instruction issuing unit 16 for each instruction generated by the rApp. Cancellation processing is the process of canceling instructions generated by an rApp that contradict or conflict with other instructions, or instructions that may deteriorate O-RAN performance or efficiency. The modification process is a process of making various changes to the instructions generated by the rApp, which would otherwise be subject to cancellation. Note that the rApp may perform change processing on behalf of the instruction verification section 15 with respect to an instruction that the instruction verification section 15 has identified as subject to cancellation processing.

The instruction verification unit 15 is provided at any location within the SMO so that it can access instructions (operation guidelines and configuration change instructions) generated by the rApp. However, in order to efficiently access substantially all instructions generated by the rApp, it is preferable that at least a part of the instruction verification unit 15 be provided in the Non-RT RIC, and the R1 interface that is the interface with the rApp. It is even more preferable that it be attached to the For example, it is preferable to provide at least a part of the instruction verification unit 15 at the R1 terminal, which is the terminal of the R1 interface that constitutes the API of the rApp, or at the R1 service disclosure function (not shown) provided in conjunction therewith.

The instruction issuing unit 16 provided in the SMO issues the rApp instruction verified by the instruction verification unit 15 to outside the SMO. Specifically, the instruction issuing unit 16 issues operational guidelines related to the operation of RAN nodes generated by the operational guidelines generating unit 13 in the rApp, and configuration change instructions regarding configuration changes outside of SMO generated by the configuration change instruction generating unit 14 in the rApp. Among them, those verified by the instruction verification unit 15 are issued outside the SMO.

The instruction issuing unit 16 issues the operation guidelines verified by the instruction verification unit 15 to at least one of the RAN node, O-Cloud, and Near-RT RIC that virtually manage the RAN node. Specifically, the instruction issuing unit 16 issues operational guidelines that have been verified by the instruction verification unit 15 through the A1 interface to Near-RT RIC, and issues the operation guidelines verified by the instruction verification unit 15 through the O2 interface to O-Cloud. The instruction verification unit 15 issues the operation guidelines verified by the instruction verification unit 15 through the O1 interface or Open Fronthaul M-Plane to the RAN nodes and O-RU. In addition, the instruction issuing unit 16 issues a configuration change instruction verified by the instruction verification unit 15 to at least one of the RAN node, O-Cloud that virtually manages the RAN node, and Near-RT RIC. . Specifically, the instruction issuing unit 16 issues a configuration change instruction verified by the instruction verification unit 15 to the O-Cloud through the O2 interface, and sends the configuration change instruction to the RAN node, O-RU, Near-RT RIC, etc. A configuration change instruction verified by the instruction verification unit 15 is issued through the O1 interface, Open Fronthaul M-Plane, A1 interface, etc.

The instruction issuing unit 16 issues the instructions to outside the SMO according to the assigned priority for the instructions that have been subjected to the prioritization process by the instruction verification unit 15. For this reason, important instructions with high priority, urgency, frequency of application, degree of impact, etc. are issued to outside SMO on a priority basis (note that instructions with high frequency of application and degree of impact require careful verification). (The priority may be lowered conversely.) Further, the instruction issuing unit 16 issues the instruction outside the SMO according to the specified schedule and/or issuance timing for the instruction that has been subjected to the issue scheduling process by the instruction verification unit 15. In this way, the performance and efficiency of O-RAN can be improved by appropriately determining the order and timing of issuing rApp instructions according to the O-RAN situation (especially outside of SMO).

Note that the instruction issuing unit 16 does not issue the instruction that has been canceled by the instruction verification unit 15 to outside the SMO. In addition, the instruction issuing unit 16 issues the changed instruction to outside the SMO according to the priority and schedule for the instruction that has undergone the modification process by the instruction verification unit 15 and/or rApp. For this reason, among the instructions generated by rApp, instructions that contradict or conflict with other instructions, or instructions that may deteriorate O-RAN performance or efficiency, are effectively prevented from being issued outside of SMO. can be prevented.

The instruction issuing unit 16 is installed at any location within the SMO so that it can access the instruction verification unit 15 from which the verification results of rApp instructions can be obtained, and the A1 interface, O1 interface, and O2 interface, which are the locations for issuing instructions outside of the SMO. established in However, in order to quickly issue instructions to outside of SMO, it is recommended that at least a part of the instruction issuing unit 16 be attached to at least one of the A1 interface, O1 interface, and O2 interface, which are interfaces with outside of SMO. preferable. For example, in the instruction issuing section 16, it is preferable to provide a function related to issuing operation guidelines etc. through the A1 interface at the A1 terminal, which is the terminal of the A1 interface, or at an A1-related function provided therein. It is preferable that the function related to issuing configuration change instructions etc. through the O1 interface is provided in the O1 terminal, which is the terminal of the O1 interface, or in the O1-related functions provided in conjunction therewith. It is preferable that a function related to issuing configuration change instructions, etc., be provided at the O2 terminal, which is the terminal of the O2 interface, or an O2-related function provided incidentally thereto.

As described above, the instruction issuing unit 16 provides various interfaces (A1 interface, O1 interface, O2 issue various instructions (operation guidelines, configuration change instructions, etc.) generated by rApp. Therefore, it is efficient to distribute and implement the related functions of the instruction issuing unit 16 in each interface that is a place for issuing instructions outside the SMO. Similarly, the related functions of the instruction verification unit 15 can be distributed and implemented in each interface (A1 interface, O1 interface, O2 interface, etc.), so that the policy / Conflict management functions can be optimized for each interface where instructions are issued outside of SMO.

For example, for the A1 interface, which is mainly responsible for issuing operating guidelines for Near-RT RIC, the function of verifying operating guidelines for Near-RT RIC generated by the operating guideline generation unit 13 of the instruction verification unit 15 is applied to the A1 terminal or A1 interface. A function is provided in the A1 terminal and A1 related functions to issue an operation guideline verified through the A1 interface to the Near-RT RIC of the instruction issuing unit 16. Similarly, regarding the O1 interface, which is mainly responsible for issuing configuration change instructions to RAN nodes, the function of verifying the configuration change instructions for RAN nodes generated by the configuration change instruction generation section 14 of the instruction verification section 15 is applied to the O1 terminal or O1 interface. A function of issuing a configuration change instruction verified through the O1 interface to the RAN node of the instruction issuing unit 16 is provided in the O1 terminal and O1 related functions. Regarding the O2 interface, which is mainly responsible for issuing configuration change instructions to O-Cloud, the function of verifying the configuration change instruction to O-Cloud generated by the configuration change instruction generation unit 14 of the instruction verification unit 15 is added to the O2 terminal and A function of issuing a configuration change instruction verified through the O2 interface to O-Cloud in the instruction issuing unit 16 is provided in the O2 terminal and O2 related functions.

Note that the above instruction verification unit 15 and/or instruction issuing unit 16 are provided by the artificial intelligence/machine learning workflow function (Fig. 3) in SMO, similar to the operation guideline generation unit 13 and/or configuration change instruction generation unit 14. Machine learning models may be utilized to verify and/or publish instructions for the rApp. In addition, if Near-RT RIC is also provided with a function similar to the artificial intelligence/machine learning workflow function, some functions of the instruction verification unit 15 and/or instruction issuing unit 16 may be provided in Near-RT RIC. rApp instructions can be verified and/or issued more efficiently based on the information available there (e.g., actions initiated by the Near-RT RIC for each RAN node) and machine learning models. Alternatively, the various data generated by the machine learning model in Near-RT RIC can be provided or aggregated to the instruction verification unit 15 and/or instruction issuing unit 16 in the SMO through the O1 interface or A1 interface. The rApp instructions may be verified and/or issued automatically.

According to the present embodiment described above, before the instruction issuing unit 16 provided in the SMO issues an rApp instruction outside the SMO, the instruction verification unit 15 provided in the SMO centrally verifies the instruction. Therefore, among the instructions generated by the rApp, those verified by the instruction verification unit 15 are efficiently issued outside the SMO by the instruction issuing unit 16.

The present disclosure has been described above based on the embodiments. It will be obvious to those skilled in the art that various modifications can be made to the combinations of components and processes in the exemplary embodiments, and such modifications are within the scope of the present disclosure.

Note that the configuration, operation, and function of each device and each method described in the embodiments can be realized by hardware resources or software resources, or by cooperation of hardware resources and software resources. As hardware resources, for example, a processor, ROM, RAM, and various integrated circuits can be used. As software resources, for example, programs such as operating systems and applications can be used.

The present disclosure may be expressed as the following items.

Item 1:
The instruction verification unit provided in the SMO (Service Management and Orchestration) of O-RAN verifies the instructions outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO. to verify and
issuing the verified instruction outside 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 operation guidelines regarding the operation of a radio access network node generated by the rApp,
The instruction issuing unit is verified against at least one of the radio access network node, a virtualization infrastructure that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). issue the said operating guidelines;
The radio access network control device according to item 1.
Item 3:
The instruction verification unit verifies a configuration change instruction regarding a configuration change outside of the SMO generated by the rApp,
The instruction issuing unit has been verified against at least one of a radio access network node, a virtualization infrastructure that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). issuing the configuration change instruction;
The radio access network control device according to item 1 or 2.
Item 4:
The instruction verification unit verifies a configuration change instruction related to a configuration change outside of the SMO generated by the rApp together with the operation guideline,
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 infrastructure, and the Near-RT RIC.
The radio access network control device according to item 2.
Item 5:
The wireless access according to any one of items 1 to 4, 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 instruction generated by the rApp. Network control equipment.
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:
7. The radio access network control device according to item 6, wherein at least a part of the instruction verification unit is attached to an R1 interface that is an interface with the rApp.
Item 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 attached to 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 includes:
acquiring virtualization infrastructure information from a virtualization infrastructure that virtually manages radio access network nodes by a virtualization infrastructure information acquisition unit;
providing the virtualization infrastructure information to the rApp by a virtualization infrastructure information providing unit through an R1 interface that is an interface with the rApp;
Run
The instruction verification unit verifies the instructions generated by the rApp based on the virtualization infrastructure information.
The radio access network control device according to any one of items 1 to 8.
Item 10:
The at least one processor includes:
obtaining the operating status of the radio access network node from a virtualization platform that virtually manages the radio access network node by the operating status acquisition unit;
acquiring operational data measured from the radio access network node by an operational data acquisition unit;
Generating an operation guideline regarding the operation of the radio access network node based on the operation status and the operation data by the operation guideline generation unit by the rApp;
Run
The instruction verification unit verifies the operation guideline.
The radio access network control device according to any one of items 1 to 9.
Item 11:
In the O-RAN SMO (Service Management and Orchestration), verifying instructions to outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO,
In the SMO, issuing the verified instruction outside the SMO;
A wireless access network control method comprising:
Item 12:
In the O-RAN SMO (Service Management and Orchestration), verifying instructions to outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO,
In the SMO, issuing the verified instruction outside the SMO;
A storage medium that stores a radio access network control program that causes a computer to execute.

This disclosure relates to verification of rApp instructions in SMO of O-RAN.

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 issuing unit.

Claims

The instruction verification unit provided in the SMO (Service Management and Orchestration) of O-RAN verifies the instructions outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO. to verify and
issuing the verified instruction outside the SMO by an instruction issuing unit provided in the SMO;
A radio access network controller comprising at least one processor executing.
The instruction verification unit verifies operation guidelines regarding the operation of a radio access network node generated by the rApp,
The instruction issuing unit is verified against at least one of the radio access network node, a virtualization infrastructure that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). issue the said operating guidelines;
The radio access network control device according to claim 1.
The instruction verification unit verifies a configuration change instruction regarding a configuration change outside of the SMO generated by the rApp,
The instruction issuing unit has been verified against at least one of a radio access network node, a virtualization infrastructure that virtually manages the radio access network node, and a Near-RT RIC (Near-Real Time RAN Intelligent Controller). issuing the configuration change instruction;
The radio access network control device according to claim 1.
The instruction verification unit verifies a configuration change instruction related to a configuration change outside of the SMO generated by the rApp together with the operation guideline,
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 infrastructure, and the Near-RT RIC.
The radio access network control device according to claim 2.
The radio access network control device according to claim 1, wherein the instruction verification unit performs at least one of a prioritization process, an issue scheduling process, a cancellation process, and a change process on the instruction generated by the rApp.
The radio access network control device according to claim 1, wherein at least a part of the instruction verification unit is provided in the Non-RT RIC.
The radio access network control device according to claim 6, wherein at least a part of the instruction verification unit is installed in an R1 interface that is an interface with the rApp.
The radio access network control device according to claim 1, wherein at least a part of the instruction issuing unit is installed in at least one of an A1 interface, an O1 interface, and an O2 interface, which are interfaces with the outside of the SMO.
The at least one processor includes:
acquiring virtualization infrastructure information from a virtualization infrastructure that virtually manages radio access network nodes by a virtualization infrastructure information acquisition unit;
providing the virtualization infrastructure information to the rApp by a virtualization infrastructure information providing unit through an R1 interface that is an interface with the rApp;
Run
The instruction verification unit verifies the instructions generated by the rApp based on the virtualization infrastructure information.
The radio access network control device according to claim 1.
The at least one processor includes:
obtaining the operating status of the radio access network node from a virtualization platform that virtually manages the radio access network node by the operating status acquisition unit;
acquiring operational data measured from the radio access network node by an operational data acquisition unit;
Generating an operation guideline regarding the operation of the radio access network node based on the operation status and the operation data by the operation guideline generation unit by the rApp;
Run
The instruction verification unit verifies the operation guideline.
The radio access network control device according to claim 1.
In the O-RAN SMO (Service Management and Orchestration), verifying instructions to outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO,
In the SMO, issuing the verified instruction outside the SMO;
A wireless access network control method comprising:
In the O-RAN SMO (Service Management and Orchestration), verifying instructions to outside the SMO generated by the rApp executed by the Non-RT RIC (Non-Real Time RAN Intelligent Controller) in the SMO,
In the SMO, issuing the verified instruction outside the SMO;
A storage medium that stores a radio access network control program that causes a computer to execute.