O-RAN专题系列-37：管理面-WG4.MP.V07-规范解读-第3章-启动安装流程：NETCONF会话的建立、维护、关闭

O-RU是NetConf/Yang的server，O-RU Controller是Client，按照Client Server的协议规范，应该是作为Client端的O-RU Controller发起NETCONF/YANG会话连接，而不是作为NETCONF/YANG server的O-RU发起NETCONF/YANG会话连接。

但如果让O-RU Controller发起这个会话连接，O-RU Controller有面临着一些实际问题：

O-RU作为NETCONF server，并没有布置在核心端，而O-RU Controller作为client，也并分布在远端，却却相反，O-RU分布在远端，O-RU Controller部署在核心端。这与互联网的Client/Server的部署完全是相反的。
网络中分布着大量的O-RU，O-RU Controller并不知道他们什么时候启动，什么时候ready，什么时候可以与他们建立连接，这与互联网的Server时刻ready是不一样的。
O-RU与O-RU controller之间，有可能存在NAT， O-RU controller根本无法主动发起与O-RU的IP连接，甚至这条通路在O-RU发起之前都不存在。

这是一个尴尬的境地：

（1）按照O-RU（远端）和O-RU controller（核心端）在网络中的部署位置，应该由O-RU首先发起连接。

（2）按照O-RU（Server）和O-RU controller（Client）在NETCONF/YANG中的角色，应该由O-RU controller首先发起连接。

如何解决上述尴尬的问题，而又不违背Client Server和网络部署这两个最基本的机制？

O-RAN引入了一个称Call Home（呼叫总部）的机制，在不违背常规的网络部署和Client/Server机制的情况下，成功地解决上述问题。

它的基本思想是：

NETCONF归NETCONF, 网络部署角色归网络部署角色，让O-RU和O-RU Controller这两部分的功能进行分离。

（1）从网络部署位置角度来看，O-RU处于远端，应该首先发起一个新的流程，这个流程就是Call Home，呼叫总部。

（2）从NETCONF/YANG角度来看，O-RU是server，O-RU Controller是client，由O-RU Controller首先发起NETCONF会话流程。

Call Home（呼叫总部流程）其实是比较简单的，就是一个由O-RU主动发起一个TCP连接请求的流程，并通过不同的TCP端口号通知O-RU controller，后续O-RU controller应该采用采用SSH或SSL与O-RU NETCONF server建立连接。其目的，就是起到异步通知的作用。

起到这个异步通知作用的还有前面讨论的Event collector server, 如上图所示。

Call Home详细流程如下：

这里需要注意的是：

O-RU要负责监控与O-RU controller之间的NETCONF session（会话），如果没有NETCONF session，则O-RU需要发起与O-RU conroller的TCP连接请求，直到NETCONF session会话的建立，如果一时无法建立TCP连接请求，则需要周期性的请求。

当然，为了防止在O-RU异常情况下，O-RU始终无法建立与O-RU controller的连接，陷入死循环中，O-RAN规定了一个参数max-call-home-attempts，当超过这个次数还是无法建立连接的时候，O-RU可以自主的重新启动（reset）

O-RU通过TCP呼叫完总部，O-RU controller就收到了O-RU站点启动的异步通知了。至于是否需要建立与O-RU的NETCONF连接，什么时候与O-RU建立NETCONF连接，那就是O-RU controller的事情了。

3.4 PNF Registration

PNF注册流程是O-RAN提供的另一种异步通知O-RU controller的机制，这个流程是可选的。

O-RU通过向event collector发起 pnfRegistration notification流程，异步通知event collector自身的出现和存在, event collector会把收到的新事件，再通知给O-RU controller，然后O-RAN controller就可以与O-RU建立NETCONF连接。

pnfRegistration notification消息的内容：

3.3 NETCONF Connection Establishment

3.3.1 NETCONF数据的安全性

NETCONF协议管理数据是承载在底层的SSH/TLS协议之上的，NETCONF数据的安全是由SSH或TLS保证的，NETCONF本身不需要对数据的安全性在做进一步的保证。

3.3.2 NETCONF Authentication（账号授权）

NETCONF是Client/Server机制，O-RU是Server，但并非所有Client都可以实现对O-RU的配置管理，O-RU需要实现用户账号管理，不同账号的用户与O-RU NETCONF server建立安全连接后，其访问的权限是不一样的，受到O-RU本地账号策略的控制。

（1）账号信息

用户名username
用户组
权限
验证类型：密码或证书
密码

上述账号管理，与Linxu账号管理类似。

（2）账号验证时机

账号验证是在SSH/TLS完全连接的时候验证用户的账号。

（3）证书验证

如果用户是通过证书，而不是用户名和密码，如何进行账号管理呢？

O-RAN规定，需要在证书验证与O-RU内部的账号之间做某种映射。即把证书中的SubjectAltName映射成username。

（4）默认账号

默认账号是O-RU出厂时候的账号，其具备超级管理员的权限。

在添加新的超级管理员的账号后，默认账号应该被disable，直到把设备恢复到出厂设置后，具备超级管理权限的默认账号才会重新生效。

之所以这样设置，是因为同一个厂家的默认账号，有可能都是一样的，容易泄露。运营商应该根据自己的需要，重设超级管理员账号和其他账号。

3.3 用户账号的重新配置：账号管理

运营商的O-RAN controller通过默认账号连接到O-RU之后，需要为O-RU添加不同访问权限的账号，包括添加超级管理员账号，然后disable默认账号。

3.4 NETCONF Access Control （用户访问权限管理）

用户访问权限管理涉及到不同账号的用户名，具备什么权限的管理能力，这就是访问权限控制。

（1）读、写能力

（2）访问不同参数的能力

为了支持不同厂家设置之间的互操作性，O-RAN定义了访问权限的规范，O-RAN把用户分为了6个组，每个组有不同的访问权限。

所谓范围权限，就是对O-RU内部的各种管理对象或模块（Module）的操作权限。

（1）管理对象：见下表中的最右边一列，是O-RU内部的所有软件、硬件实体的抽象。

（2）操作权限：包括读、写、执行、无这几种。

（3）用户组：其实，真正的权限管理是基于用户组的，O-RAN定义了6种用户组，其访问权限由大到小的排列顺序如下：

sudo超级用户权限，可以访问所有的控制对象。
SMO：O-RAN新定义的网管
NMS: 传统的网管
Hybird-ODU：Hybird情形下的O-DU
fm-pm故障管理和性能管理的账号，只能读去信息。
swm,软件管理，只能进行软件管理，不能访问其他对象。

当然，上述规则，并非hardcode的，而是通过ietf-netconf-acm.yang来定义的。

至此，O-RU通过异步通知的方式，通知O-RU controller自身的存在，O-RU controller通过用户名密码或证书的方式，与O-RU建立起来SSH/TLS安全连接，建立了NETCONF session。

这时候，O-RU和O-RU controller才可以执行进行NETCONF的消息交互。

3.5 NETCONF capability discovery

NETCONF session连接建立后的第一条消息是HELLO消息，通过HELLO消息，O-RU和O-RU controller向各自的双方，展现了自己的各种能力。

交换能力，能力之后，O-RU controller根据各种的账号访问权限，实施对O-RU的OAM操作维护管理，包括 CM, PM.FM, SWM等。

3.6 Monitoring NETCONF connectivity

在OAM操作维护过程中，需要有一种机制，帮助NETCONF Client和Server确保双方的NETCONF连接还是正常的。NETCONF通过supervision-notification定时心跳通知和回应来完成的。

（1）O-RU controller首先向O-RU注册定时心跳通知消息supervision-notification

（2）时间间隔可设定。

（2）O-RU定期的发送supervision-notification消息

（4）O-RU controller收到该消息后，发送response消息作为回应

（5）心跳机制是针对每个NETCONF session的，O-RU与多个O-RU controller建立各自的session，每个session有各自独立的心跳机制。

备注：

上述过程实际上是由NETCONF协议栈保证的，而不是OAM操作管理模块保证的。

3.7 Closing a NETCONF Session

通常情况下，Closing a NETCONF Session应该由O-RU controller发起通过RPC close-session命令发起，收到该命令后，接收到端关闭相应的SSH/TLS连接. O-RU重新进入call home状态。

当然，O-RU作为NETCONF session的server，也是有权限在异常的情况下，主动终止与NETCONF client的连接。

备注：

NETCONF的Session的建立、维护、关闭是NETCONF/YANG协议栈的职责，而不是OAM的CM/FM/PM/SWM等功能实体的职责。

后续讲探讨OAM本身的功能以及其NETCONF/YANG协议规范。

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

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

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)