O-RAN专题系列-36：管理面-WG4.MP.V07-规范解读-第3章-启动安装流程：NetConf会话连接前的准备

最新推荐文章于 2023-07-17 17:23:20 发布

文火冰糖的硅基工坊

最新推荐文章于 2023-07-17 17:23:20 发布

阅读量1.5k

点赞数 2

分类专栏：通信-ORAN专题系列文章标签： O-RAN 启动流程 IP地址自动获取

本文链接：https://blog.csdn.net/HiWangWenBing/article/details/122490156

版权

通信-ORAN专题系列专栏收录该内容

61 篇文章 500 订阅

订阅专栏

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

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

第3章 “Start up” installation 启动安装流程

3.1 Management Plane Transport aspects

3.1.3 IP地址的分配

3.1.4 O-RU Controller Discovery

3.1.5 Multi-Vendor Plug-and-Play

3.1.6 Event-Collector Discovery

3.2 NETCONF Call Home to O-RU Controller(s)

3.3 NETCONF Connection Establishment

3.4 NETCONF Access Control

3.5 NETCONF capability discovery

3.6 Monitoring NETCONF connectivity

3.7 Closing a NETCONF Session

3.8 PNF Registration

第3章 “Start up” installation 启动安装流程

启动流程还是比较复杂的，它涉及到O-RU开机重启之后到能够O-RU提供服务的整个流程。

前置条件：

O-RU上电或复位重启
O-RU Controller处于正在工作
pnfRegistration event-collector处于正常工作
O-RU与O-RU Controller/event-collector物理层连接正常

后置结果：

状态：gNB至少有一个小区Cell处于On Air状态
业务面：O-RU与O-DU之间的业务数据通信正常（Tx/Rx)
业务面：O-RU空口与手机之间的业务数据通信正常
管理面：至少有一个网网管系统可以管理O-RU

从上述可以看出，本章节涉及到O-RU整个启动流程，直到能够对外提供业务。

当然，本章只是总体流程，至于某个环节的细节，需要后续章节再继续讨论。

3.1 Management Plane Transport aspects

前置条件：

O-RU物理连接正常

后置条件 (该过程需要获得的信息）

当O-RU有多物理连接端口时，O-RU能够知道通过那个物理口建立M面连接。
当O-RU有多个VLAN时，O-RU能够知道通过那个vlan id建立M面连接。（MAC地址是硬件配置的，不同机器，MAC地址不同）
O-RU获得自身的IP地址
O-RU获得远程控制器Controller的类型与对应的IP地址或名称（FQDN + DNS)
为与O-RU controller建立M面连接最好准备

所以，这个过程，就是O-RU自身重启的过程，也是O-RU自我准备的过程，获得初始传输层参数的过程。有如下几种方式：

（1）静态配置

这种方式的配置，为默认配置，允许被后期的O-RU controller的Netconf/Yang配置信息替代或覆盖。

（2）IPV4 DHCP

通过DHCP过程，O-RU不仅仅要获得自身M面的IP地址，还要通过DHCP option获得O-RU controller的IP地址，同时还需要通过VLAN probing，来检测分配给M面的VLAN id。

（3）IPV6

过程同IP V4, 不同的是，IPV4使用的Stateless Address Auto-Configuration (SLAAC)协议，SLAAC是DHCP在IP V4上的升级版本。

备注：

O-RU controller通过后续的NetConfg能力交换的时候，获取O-RU对IP V4或V6能力支持的程度。

这个过程的关键过程就是DHCP/SLAAC，该过程如下：

这个过程是标准协议，在这里不做详细介绍，这里需要指出，这个过程不仅仅获取O-RU管理面的IP地址，还可以获得：

网关的地址
DNS服务器地址
管理面所在的vlan id
remote controller的地址

3.1.1 O-RU如何在DHCP中标识自己

（1）标识方式

O-RU可以通过三种方式标识自己：DHCP已有的Option60， DHCP为O-RAN新增加的option 124， SLAAC的Option 16。

（2）标识的内容

有了这些标识，DHCP server就知道如何通知O-RU，其对应的远程的O-RU controller的地址。

3.1.2 O-RU管理面VLAN ID的自动发现

在O-RU架构中，O-RU可能会连接多个O-DU和多个Controller，不同的controller，在传输层，可能有不同的VLAN，这就需要O-RU自己主动发现自己的管理面的VLAN id。

VLAN ID discovery的原理比较简单，就是在每个vlan上发起DHCP过程，然后看，哪个VLAN上有DHCP回复，完成DHCP完整过程的VLAN就是管理面的VLAN。

当然，如果O-RU之前没有获得或发行自己M面的VLAN, 则总是先尝试untag VLAN，然后遍历其他的VLAN，如果之前已经获得过管理面的VLAN ID, 则先使用先前的VLAN ID进行尝试。

查询每个VLAN ID采用的是串行的方式，每个VLAN ID查询超时的时间为60s，如果 60s内收不到回应，则切换到下一个VLAN ID上继续查询。

3.1.3 IP地址的分配

IP地址分配是DHCP server的职责，DHCP server的部署，并没有约束，可以部署在O-DU中个，也可以独立部署。DHCP server的地址池，采用静态绑定的方式，确保每个终端的地址在重启后保持不变。

3.1.4 O-RU Controller Discovery

（1）首先，O-RU DHCP client通过IPV4 option43或IPV6的option17告诉DHCP server，自身的类型

o-ran-ru 或
o-ran-ru2

O-RU也可以通过OPTION_V4_SZTP_REDIREC和OPTION_V6_SZTP_REDIRECT主动请求Server提供O-RU controlller的信息。

（2）然后，DHCP server，根据O-RU的类型或DHCP client的主动请求，通过DHCP option向O-RU提供O-RU controller的地址。获得的信息方式和内容依赖于O-RU自身的类型：

其中，比较特殊的是域是：Call Home protocol，用于向O-RU表明，通过O-RU需要通过什么的协议与controller建立连接。

通过上面的机制可以看出，O-RU获取自身地址和远程Controller信息的机制是一种称为”bootstrap“的机制。

bootstrap机制在家庭网关设备的自动化部署中起着关键性的作用。

3.1.5 Multi-Vendor Plug-and-Play

O-RU无论与O-DU controller还是NMS controller的管理面的连接，都是安全连接，或SSH, 或TLS，中间都是普通非安全的传输网络.

而安全连接的验证，可以通过密码，也可以通过证书。如果通过证书验证，这就涉及到一个问题， O-RU如何获得安全访问controller的证书？

（1）一种方式是静态预先安装好证书，这种方式优点流程简单，但适应性差，因为O-RU需要连接第三方的O-DU和第三方的NMS，很难通过预习安装厂家特有的证书在不同厂家之间相互认证。

（2) 另一种方式，就是向证书服务器动态申请证书，通过获得的证书再与controller建立连接。

这是推荐的、非强制性性、可选性方式，O-RU通过CMP证书管理协议，向证书服务器申请新的证书。

其实，这里也有问题：

O-RU如何获取证书服务器的IP地址呢？

这个问题的解决，通过DHCP过程, 有DHCP server提供给O-RU.

证书服务器如何验证O-RU的合法性呢？

这个问题的解决，可以通过厂家预安装的证书来解决，预安装证书，仅仅用于从证书服务器获取新的证书之用。

O-RU在获取了证书服务器CA的IP地址后，就发起CMP证书管理流程，从CA服务器上获得后续安全连接所需要的证书的。

当然，证书管理是一个大的体系，证书不是单一层级的一张证书，有一个称为证书链概念，用于管理不同层级证书之间的相互认可。关于证书链和证书管理CMP的内容，不是本文的范围。

3.1.6 Event-Collector Discovery

至此，DHCP完成，获取了O-RU controller的地址，安全传输层协议类型，也获取的安全访问O-RU controller所需要的证书。

此时是乎可以与O-RU controller建立NetConf/Yang连接了。

然后，此时还无法与O-RAN controller建立O-RAN的NetConf/Yang连接，这是因为O-RU是服务端，O-RU controller是客户端，Netcong/Yang的连接应该由客户端发起，而不是O-RU。

这里出现一个新的问题：

O-RU controller如何知道O-RU什么时候ready？O-RU controller如何知道O-RU的动态获取的IP地址呢？

解决上述问题的办法：就是增加一个新的功能：Event-Collector ，它通常是O-RU Controller(s) 的一部分，当然，也可以是分离的、独立的网元。

到这里，又出现一个新的问题：

O-RU如何获取Event-Collector服务器的信息呢? 即如何发现O-RU如何发现Event-Collector服务器呢？

解决问题的办法：这还得通过DHCP过程来解决，DHCP sever通过Option43/Option17的新的type来解决，如下图所示。

IP地址
FQDN名称 =》需要DNS支持
消息通知的格式，目前只支持ONAP VES event listener specification（备注，该消息格式并不是O-RAN的NetConf/Yang。

Event-Collector Discovery成功地解决了，大量的、可以随时部署与撤离的、作为服务器端的O-RU，如何通过异步的方式，通知作为Client端的O-RU Controller，这个过程也称为pnfRegistration。

当然，Event-Collector Discovery是可选的，而不是必选的。如果没有Event-Collector，还可以通过其他机制，异步的通知作为Client端的O-RU Controller。

至此，O-RU获取了Event-Collector服务器的信息，也获得了O-RU controller的信息，是时候与ORU controller netconf/Yang连接的时候了。

待续，见下一篇文章.....................