wordpress页眉导航栏位置/湖南优化推广

@[TOC](ORU 的 Open RAN 管理平面 (M 平面))

ORU 的 Open RAN 管理平面 (M 平面)

https://www.techplayon.com/open-ran-management-plane-m-plane-for-open-radio-unit/

ORU M 平面

在 ORAN 中，设置参数的 O-RU 管理功能是通过 M-Plane 完成的。管理功能包括 O-RU 软件管理、故障管理等。在这方面，O-RAN 前传规范规定了各种参数作为数据模型，以实现所需的管理操作。这消除了对不同 O-RU 供应商实施的依赖，并使多供应商 RAN 成为可能。

M-Plane 架构

在M-Plane中，O-DU和NMS用于管理O-RU。O-DU和NMS使用NETCONF来管理O-RU。O-DU，NMS对应于NETCONF客户端，而O-RU对应于NETCONF服务器。ORAN规范为O-RU管理定义了两种配置模型，即分层模型 和混合模型。

• 分层模型：在此配置中，O-RU 由 O-DU 管理。O-DU 终止对下属 O-RU 的监控/控制，这使得 NMS 无需处理所有 O-RU 的监控/控制，并有助于减少 NMS 的处理负载。此外，如果现有 NMS 不支持 NETCONF，此模型的优点是可以在不影响现有系统的情况下实现网络构建，因为 O-DU 在此 M-Plane 中支持 NETCONF。O-DU 作为NETCONF 客户端工作，O-RU 作为NETCONF 服务器工作。
• 混合模型： 在此配置中，除了 O-DU 之外，O-RU 还由一个或多个 NMS 管理。此模型的优点是，NMS 可以监控/控制除 O-RU 之外的其他网络设备，从而实现所有设备的统一维护、监控和控制。O-DU 和 NMS 作为 NETCONF 客户端，O-RU 作为 NETCONF 服务器。

在任一架构模型中，都可以限制每个管理 O-RU 的 NETCONF 客户端的管理功能，从而实现灵活操作，例如，操作可以分为执行 SW 管理的 NETCONF 客户端和执行故障管理的 NETCONF 客户端。

ORAN M-Plane 功能

• O-RU启动程序
• O-RU软件管理
• O-RU 参数设置/获取（配置管理）
• O-RU 测量（绩效管理）
• O-RU故障管理（Fault Management）
• O-RU数据文件发送/接收管理（文件管理）

O-RU 启动程序

O-RU“启动”程序指定在 O-RU 和 O-DU 及 NMS 可用的 NETCONF 客户端之间建立 M-Plane。建立 M-Plane 连接需要相互交换传输层地址信息。对于此功能，O-RAN 前传规范规定了以下三个选项。

• 手动设置传输层地址
• DHCP 服务器分配传输层地址
• IPv6 寻址时通过无状态地址自动配置分配传输层地址

O-RU 软件管理

O-RU 软件可通过带有 M-Plane 的 NETCONF 客户端的 O-DU/NMS 进行管理。在多供应商 RAN 环境中，某个供应商的 NETCONF 客户端必须管理严重依赖于另一个供应商实现的 O-RU 软件文件，因此独立于 O-RU 实现或供应商的 SW 管理机制非常重要。主要软件管理流程如下：

• 软件清单
• 软件下载
• 软件安装/升级
• 软件激活

O-RU 配置管理

在此功能中，O-DU/NMS NETCONF 客户端设置 C/U 平面和 S 平面上所需的 O-RU 参数，并通过 M 平面获取设备状态信息。此功能使用 NETCONF 中指定的标准消息实现。所需参数的设置以YANG 模块的形式指定，并通过以下方式实现。在 NETCONF 中，建立会话 伴随着消息的交换。这些消息中的每一个都包含该设备支持的 NETCONF 功能以及有关支持的 YANG 模块的信息。这使 O-DU/NMS NETCONF 客户端能够确定 O-RU 支持哪些 YANG 模块。NETCONF 分别指定和作为设置参数和获取参数值的标准消息。将这些消息发送到 O-RU 可以设置各种类型的参数并获取有关存储在 O-RU 上的参数和该设备状态的信息。

O-RU 故障管理

NETCONF 客户端通过 M-Plane 管理 O-RU 故障。在此功能中，O-RU 使用NETCONF 中指定为标准消息的向 O-DU/NMS NETCONF 客户端发送通知。如果 O-RU 端出现某种问题（例如设备故障），O-RU 会将故障连同以下详细信息一起通知 NETCONF 客户端。

• 故障编号
• 故障发生位置
• 受故障影响的地点
• 过错严重程度
• 发生新的故障或已解决的故障

https://www.techplayon.com/open-ran-management-plane-m-plane-for-open-radio-unit/

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 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 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 and 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 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