O-RAN专题系列-31：5G基站如何升级到O-RAN基站 - O-RU - 管理面MPlane的升级

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客

本文网址：https://blog.csdn.net/HiWangWenBing/article/details/120323472

---

目录

第1章 协议栈

1.1 eCPRI协议栈

1.2 5G基站 eCPRI接口的协议栈

1.2. O-RAN基站eCPRI接口的协议栈

1.3. NetConf的协议栈

1.4 多厂家M面互联互通测试架构

第2章  总体架构的变化

2.1 遵循的协议标准

2.2 协议栈接口的变化

2.3 O-RU启动过程的变化

2.4 完整的启动流程

2.5 M面消息内容的变化：O-RAN IoT profile

2.6 O-RAN模式与传统模式的选择

第3章 对O-RU进行操作维护管理OAM的变化

3.1 软件包管理

3.2 配置管理CM

3.3 故障管理FM

3.4 性能统计管理PM

3.5 设备管理

3.6 状态管理

3.7 安全性管理

3.8 客户文档管理

---

---

第1章 协议栈

1.1 eCPRI协议栈

1.2 5G基站 eCPRI接口的协议栈

 从协议栈的角度看：

• M面：即使到了5G, 采用了eCPRI接口，但M面的接口还是厂家的私有协议，并没有开放。
• C面：eCPRI协议对AxC的格式进行了定义
• U面：eCPRI协议对fast control进行了定义
• S面：采用标准的PTP协议。

1.2. O-RAN基站eCPRI接口的协议栈

1.3. NetConf的协议栈

备注：

netconf只是M面数据的数据结构描述协议，并不是M面消息的内容。

1.4 多厂家M面互联互通测试架构

备注：作图的O-DU应该纠正为O-RU

• 网管中心NMS可以通过nectconf协议对O-RU进行管理（新增）
• 网管中心NMS可以借助O-DU，通过nectconf协议对O-RU进行管理（新增）
• 第三方O-DU可以通过nectconf协议对O-RU进行管理（新增）

第2章  总体架构的变化

2.1 遵循的协议标准

 O-RAN.WG4.MP.0-v02.00 & O-RAN.WG4.MP-YANGs-v02.00 

 O-RAN.WG4.IOT.0-v02.00 (scope limited to M-Plane IOT tests & M-Plane IOT profile).

DCM ecosystem "TP 3D.975 V4.0.0" 

New interface is based on:

RFC 6241 Network Configuration Protocol (NETCONF)

RFC 7950 The YANG 1.1 Data Modeling Language

RFC 6021 Common YANG Data Types

RFC 7895 YANG Model Library

RFC 5277 NETCONF Event Notifications

RFC 6242 Using the Netconf Protocol over Secure Shell (SSH)

The scope of the feature from the O-RAN M-Plane specification perspective:

M-Plane architecture: hierarchical model

M-Plane security (SSH) – chapter 2.4 and 3.3.1

Start up” installation – chapter 3

O-RU to O-DU Interface Management – chapter 4

Delay Management – chapter 4.7

Software Management – chapter 5

Configuration Management – chapter 6

Performance Management – chapter 7

Fault Management – chapter 8

File Management - chapter 9

Synchronization aspects – chapter 10

Supervision, Troubleshooting – chapters 11.1 and 11.2.1

Antenna Line Devices management – chapter 11.3

External Input and Output – 11.4

Retrieval of O-RU information – chapter 12.1

U-Plane message routing – chapter 12.2

Carrier configuration – chapter 12.3

Pre-Defined Beamforming Configuration- chapter 12.4.1

2.2 协议栈接口的变化

（1）M面消息的承载协议：由厂家自行选择，如UDPCP/SOAP协议转为标准的SOAP/HTPP/TLS协议

无论是UDPCP/SOAP还是SOAP/HTPP/TLS，都是标准协议，并非厂家自定义协议。

差别在于不同厂家，选择的标准协议不同，O-RAN对这个标准的选择进行了规定，即SOAP/HTPP/TLS. 

TLS是承载在TCP之上的安全传输协议，确保M面消息传输的安全性。

SOAP/HTTP协议，确保M面消息的可读性、文本性、易修改性和可维护性。

（2）M面消息格式的描述协议：由厂家自定义协议，转为标准的Netconf协议。

Netconf也是标准协议，不过他是数据描述协议，并非数据本身。

（3）M面消息的内容：由厂家自定义转为O-RAN IoT profile

IoT profile定义了不同厂家M面数据的互联互通，这是O-RAN M面变化最大的地方。

需要重新定义O-RU的每个可管理参数的名称和格式。

2.3 O-RU启动过程的变化

（1）新增：通过DHCP获取IP地址的同时，获取自举服务器的域名。

（2）新增：通过DNS把自举服务器的域名转换成IP地址

（3）新增：通过自举服务器的IP地址，下载O-RU的以netconf承载的配置文件。

（4）使用远程下载的配置文件对O-RU进行配置管理

备注：如果本地已经有配置文件，就不需要从远程自举服务器上下载配置文件。

（5）当网络中有多个DU提供DHCP offser时，O-RU选择其中一个DHCP offer，通常会选择第一个DHCP offer。

（6）M面VLAN的自动扫描

按照O-RAN的要求，O-RU需要能够对M面的VLAN id进行自动扫描。

对于不支持VLAN id自动扫描的设备，可以设置固定的VLAN ID

（7）DHCP IP地址动态续租

传统RU的IP地址是通过DU获取的，IP地址可以是永久性的，或静态分配的，但O-RU从DU中剥离出来，成为一个独立的网元，因此其IP地址需要支持动态续租。

2.4 完整的启动流程

（1）O-RU通过DHCP从O-DU的DHCP server中获取IP地址和自举服务器的域名。

（2）O-RU从1588 server获取时钟同步

（3）O-RU 呼叫O-DU上的自举服务器（也就是说，O-RU是通过DHCP获得O-DU的信息的）

（4）O-DU与O-RU建立SSH连接

（5）O-DU与O-RU交换Netconf的能力

（6）O-DU从O-RU获取Yang模型以及支持的特征信息。

（7）如果需要，在O-RU上建立特定的用户

（8）O-DU通过netconf向O-RU注册。

（9）O-DU与O-RU监控M-Plane的Netconf连接

（10）O-DU获取O-RU的信息

（11）O-DU获取O-RU上的所有alarm信息

（12）O-DU对O-RU执行软件软件，如果需要，升级O-RU的软件

（13）O-DU恢复O-RU的delay profile 

（14）O-DU对O-RU执行业务面的载波配置

（15）O-DU配置性管理

（16）O-DU获取O-RU最新状态

（17）使能O-RU的工作状态

（18）O-RU处于可工作状态，O-DU可以发送和接收U面的数据

（19）O-DU收到O-RU的状态更新信息

2.5 M面消息内容的变化：O-RAN IoT profile

参考O-RAN IoT profile规范

这个改动是最大的，需要对原先的所有O-RU的配置参数进行重新定义。
 

2.6 O-RAN模式与传统模式的选择

（1）dual mode：双模式

由传统的RU升级到O-RU, 从工程的角度来看，完全废弃原有的接口是不经济的，因此升级后的O-RU需要支持两种模式: 传统的私有接口模式和O-RAN的开放接口模式。

这两种模式可以通过配置进行切换，默认模式取决于厂家自己。

（2）dual interface：双接口

也可以同时提供双接口的支持，这两个接口同时工作。

（3）双M面协议栈

传统的私有接口模式和O-RAN的共有接口模式，M面有不同的协议栈。

因此需要支持两个不同的M面的协议栈。

• 消息格式不一样
• 消息时序不一样

第3章 对O-RU进行操作维护管理OAM的变化

3.1 软件包管理

（1）软件包的发布和管理

        O-RU的软件包，可以独立发布和管理，不需要与BBU的软件包打包在一起。

（2）网管NMS直接对O-RU的软件包进行独立更新，可以不需要通过O-DU

        NMS通过netconf协议下载、安装和激活O-RU的软件。

3.2 配置管理CM

（1）可以借助O-DU对O-RU进行管理，也可以直接通过O-RAN的NMS直接对O-RU进行网管（新增）。

（2）把厂家私有的配置格式转换成O-RAN格式的配置项。

3.3 故障管理FM

（1）把厂家私有的故障转换成O-RAN定义的故障

（2）通过netconf接口上报

3.4 性能统计管理PM

（1）把厂家私有的性能统计转换成O-RAN定义的性能统计

（2）通过netconf接口上报

3.5 设备管理

（1）需要通过O-RAN接口对挂接在O-RU上的ALD智能天线设备进行管理。

（2）通过netconf接口上报

3.6 状态管理

（1）增加：对O-RAN TLS管理面连接状态的监控和管理

（2）增加：对O-RAN同步面同步状态进行监控和管理

（3）增加： 根据IOT Profile 1，对eCPRI用户面连接状态进行监控和管理

（4）增加： 根据IOT Profile 1，对eCPRI控制面连接状态进行监控和管理

（5）增加：  根据IOT Profile 1，对O-RU与O-DU之间的delay进行管理

3.7 安全性管理

由于O-RU是直接暴露给网管中心，Fronthaul接口由私有接口转为公共接口，TLS协议提供公共接口的安全性保障。

（1）O-RU提供TLS连接所需的公钥

（2）O-RU提供TLS连接所需的安全证书（可选，非 IOT profile 1的要求）

（3）提供不同安全级别的用户管理

（4）用户名和 密码管理

（5）IPsec: O-RAN的安全是通过TLS完成的，因此，O-RU需要放弃传统的IPSec

3.8 客户文档管理

O-RU与O-DU的分离，导致相关的手册和客户文档，也需要与O-DU分离

---

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客

本文网址：https://blog.csdn.net/HiWangWenBing/article/details/120323472