Open RAN Management Plane (M-plane) for ORU

ORU M-Plane

In ORAN, the O-RU management functions to set parameters are done over the M-Plane. The management functions includes O-RU software management,  fault management etc. Regarding this, O-RAN fronthaul specifications prescribe various parameters as data models to achieve the required management operation. This eliminates dependency on different O-RU vendorʼs implementation and makes multivendor RAN possible.

M-Plane Architecture

In M-Plane, the O-DU and NMS are used to manage the O-RUs. O-DU and NMS uses NETCONF to manage O-RUs. O-DU, NMS correspond to NETCONF clients while O-RUs correspond to NETCONF servers. ORAN specification has defined two configuration model for O-RU management namely Hierarchical model and Hybrid model.

Hierarchical and Hybrid M-Plane Models for ORU

  • Hierarchical model : In this configuration, an O-RU is managed by O-DUs. O-DUs terminate the monitoring/control of a subordinate O-RU, which makes it unnecessary for NMS to handle the monitoring/control of all O-RUs and helps to reduce the NMS processing load. Furthermore, if existing NMS does not support NETCONF, this model has the advantage of enabling network construction without affecting the existing system since O-DU supports NETCONF in this M-Plane. O-DU works as NETCONF client and O-RUs as NETCONF server.
  • Hybrid model: In this configuration, an O-RU is managed by one or more NMSs in addition to O-DUs. An advantage of this model is that NMSs can monitor/control other network devices in addition to O-RUs enabling uniform maintenance, monitoring, and control of all. O-DU and NMS works as NETCONF client and O-RUs as NETCONF server.

In either architectural model, management functions can be limited for each NETCONF client managing an O-RU making for flexible operation e.g. the operations can be divided into a NETCONF client performing SW management and a NETCONF client performing fault management.

ORAN M-Plane Functions

  • O-RU startup procedure
  • O-RU Software management
  • O-RU parameter set/get (Configuration Management)
  • O-RU measurement (Performance Management)
  • O-RU fault management (Fault Management)
  • O-RU data file send/receive management (File Management)

O-RU startup Procedure: O-RU “Start up” procedure specifies the establishment of M-Plane between O- RU and NETCONF clients available with O-DU and NMS. Establishing M-Plane connection requires mutual exchange of Transport Layer address information. For this function, O-RAN fronthaul specifications prescribe the following three options.

    • Manual setting of Transport Layer addresses
    • Allocation of Transport Layer addresses by DHCP server
    • Allocation of Transport Layer addresses by State Less Address Auto-Configuration in case of  IPv6 addressing

O-RU Software Management: The O-RU software can be managed via An O-DU/NMS with NETCONF client with the M-Plane. In multivendor RAN environment, a NETCONF client of a certain vendor must manage the Software files of an O-RU heavily dependent on another vendorʼs implementation, so a mechanism of SW management that is independent of O-RU implementation or vendor is important. The main  software management procedure is as follows:

    • Software Inventory
    • Software Download
    • Software Installation/Upgrade
    • Software Activation

O-RU Configuration Management: In this function, an O-DU/NMS NETCONF client sets O-RU parameters required on the C/U-Plane and S-Plane and gets equipment status information via the M-Plane. This function is achieved using standard messages specified in NETCONF. The setting of required parameters is specified in the form of YANG modules and achieved in the following way. In NETCONF, establishing a session is accompanied by an exchange of <hello> messages. Each of these messages contains the NETCONF functions supported by that equipment and information on supported YANG modules. This enables the O-DU/NMS NETCONF client to determine what YANG modules are supported by the O-RU. NETCONF specifies <edit-config> and <get-config> as standard messages for setting parameters and getting parameter values, respectively. Sending these messages to an O-RU makes it possible to set various types of parameters and to get information on the parameters stored on the O-RU and the status of that equipment.

O-RU Fault management: An NETCONF client manages O-RU faults via the M-Plane. In this function, the O-RU sends a notification to the O-DU/NMS NETCONF client using <notification> specified as a standard message in NETCONF. In the event of some sort of problem on the O-RU side such as an equipment fault, the O-RU notifies the NETCONF client of the fault together with the following detailed information.

    • Fault ID
    • Location of fault occurrence
    • Locations affected by fault
    • Severity of fault
    • New fault occurrence or a fault that has already been resolved

Related Post

You may also like...