ORAN M-plane high level descript
2.1 Top level functional description, terminology, including hybrid, hierarchical
2.1.1 Architecture for O-RAN WG4 Fronthaul functional split
如图1， ORAN FH specification 着眼于下层函数功能上的分割。更多信息参考ORAN CUS plane specification。The Lower-Layer Split M-Plane(LLS-M)，有利于实现初始化、配置、管理ORU，并支持所谓的“functional split”。
Figure 1 -- O-RAN WG4 FH functional split
2.1.2 M-Plane architecture model
一个基于NETCONF/YANG的M-Plane，是用于支持对ORU的management(包括"start up" installation, 以及对software、configuration、performance、fault、file的management)。M-Plane支持2种archetecture model：
-
Hierarchical model
ORU完全被(一或多个)ODU用基于NETCONF的M-Plane interface控制。
当 O-RU 由多个 O-DU 管理时，它通常用于enabling O-DU and/or transport connectivity redundancy capabilities(传输连接冗余能力?)。第3章有更多细节。 -
Hybrid model
除了在ODU和ORU之间的一个逻辑接口，此模式还在management system和ORU之间启用了(一或多个)直接逻辑接口。
这里要说明一下，连接ORU的NETCONF client可能是属于不同class的(比如ODU和SMO)。 像ORU的software、performance、configuration、fault的management功能，是可以被management system直接管理的。
在hybrid model中，ORU与SMO有end to end的IP层连接。从网络连接的角度来看，它们应该是是通过ODU连的，ODU扮演IP/Ethernet packet forwarder，只转发它们的包而不处理。通过给ORU assign一个routable IP，或一个NAT解析过的private IP，可以实现ORU与SMO之间逻辑上的直接通信。关于ORU如何获得ODU和SMO的IP address以实现M-Plane communication的细节，参考第3章。
从第3章中可以知道，没有明确的信号可以指明ORU是处于hierarchical或hybrid configuration。所有支持此M-Plane specification的NETCONF server应当支持多NETCONF session，因此所有ORU应当同时支持hierarchical和hybrid deployment。
NETCONF/YANG是作为network element management protocol和data modeling language使用的。在成员都共享一组通用功能的情况下，使用这种标准化框架和common modeling language简化了 O-DU 和 O-RU 之间的集成以及运营商网络集成(在运行服务方面)。 NETCONF还原生地支持hybrid架构，在这种架构下多个client可以订阅和接收源自 O-RU 的 NETCONF server的信息。
2.1.3 Transport Network
基于transport topology，O-RU 和 O-DU 和 SMO 之间可以有多种网络连接模式。
对M-Plane的基本的要求是，ORU和它的管理者(ODU, SMO, 或所谓的"ORU controller")之间要有end to end的IP连接。ODU和SMO之间的连接不在本spec讨论范围内。 ORU应至少支持IPv4和IPv6其中之一，全支持更好。
2.1.4 M-Plane functional description
M-Plane主要向ORU提供以下的功能。这些都是通过NETCONF提供的function实现的。
"Start up" installation
在startup期间，O-RU 通过静态（在 O-RU 中预配置）或通过 DHCP 或 DHCPv6 动态获取其网络层参数。在此过程中，O-RU 可以获取 O-RU controller的 IP 地址，同时O-RU 使用“call home”功能建立 NETCONF 连接。当ORU在包含SMO的环境中运行时，ORU会获取event-collector的IP地址，同时执行 pnfRegistration procedure， 并trigger SMO 使用从 pnfRegistration 过程中恢复的信息来建立 NETCONF 连接。
[Note] 本spec中“start up”术语与 NETCONF 环境中使用的“startup”功能不同，后者用于表示设备支持单独的运行和startup configuration datastores。本spec特别提到了需要存储在“reset persistent memory”.”中的配置。 O-RU 应使用此存储的配置作为它的“startup”配置。
SW management
当 O-RU controller请求时，M-Plane负责software的download, installation, validation, 和新SW的activation。
Software download由NETCONF RPC procedure触发，而software package的download由sFTP来实现。
在此版本的spec中，sFTP是用来做software和file management的唯一file transfer protocol。
Configuration management
Configuration management覆盖了多种场景：Retrieve Resource State, Modify Resource State, Modify Parameters and Retrieve Parameters。
ORU进行configuration parameter的retrieval和updates时，应该使用NETCONF get-config和edit-config RPC(Remote Procedure Call)。
Performance management
描述了用于收集ORU operation相关信息的measurements和counters。其目的是优化ORU operation。
measurement的结果通过以下2种方式报告：
- YANG Notification
此选项使用每个measurement group中的YANG model stat definition。此时，将使用get rpc and/or notification。
更多信息见第7章。 - File Upload
此选项使用File management中定义的file upload procedure。measurement result被周期性地保存到data file中。
Fault Management
负责向NETCONF Client发送alarm notification。
它允许enable/disable alarm notification，以及alarm subscription。
File Management
它允许ORU controller trigger ORU将其中的file上传给ORU Controller。
ORU能提供不同类型的file，且取得的file也可用于不同的目的。
O-RU到O-DU/SMO的同一个sFTP连接下可支持同时进行多文件上传操作。
2.2 Interfaces
M-Plane interface定义在ORU和ORU controller之间。M-Plane interface的协议栈如图3所示。 传输层协议基于IP和SSH/TCP，以及可选的TLS，用于在ORU和ORU controller之间传输M-Plane messages。 作为一个可选项，ORU可支持用HTTPS传输的异步notification。此选项在ORU controller对应的是SMO，且其与ORU之间的NETCONF session是non persistent的时候，enable了system optimization。
Figure 3: M-plane protocol stack
2.3 YANG Module Introduction
代表M-Plane的data model被组织成一组resuable YANG module。并且打算尽可能多地重用公开可用和通用的 YANG 模型，而不是开发定制的 O-RAN 特定模块。
2.4 Security
（略）
