没有合适的资源?快使用搜索试试~ 我知道了~
首页O-RAN联盟工作小组4管理平面规范
"O-RAN.WG4.MP.0-v07.00.00.pdf" 是O-RAN Alliance工作小组4(WG4)关于管理平面规范的技术规格文档,版本为v07.00。该文档涵盖了ORAN(开放无线接入网络)的前传接口相关标准,特别是MPLANE(管理平面)的部分,主要关注的是2021年的更新内容。
O-RAN Alliance是一个由通信行业领先的运营商和供应商组成的联盟,致力于推动无线接入网(RAN)的开放和智能化。其目标是通过开放接口和软件定义的方法来增强网络灵活性、效率和创新。WG4是这个联盟中的一个重要工作团队,专注于管理平面的规范制定,以促进网络设备之间的互操作性和自动化。
在文档的修订历史中,我们可以看到从2019年开始的两个关键更新:
1. 2019年3月11日,发布了01.00版,这是基于xRAN M-Plane导入的第一个版本。xRAN是O-RAN Alliance之前的名称,这个版本可能是将原有xRAN的管理平面功能转化为O-RAN框架下的初步尝试。
2. 2019年7月3日,更新到02.00版,这个版本修复了错误并对01.00版进行了改进,同时引入了新的功能,包括:
- Beam tilting(波束倾斜):这是一种无线传输技术,允许基站动态调整波束的角度,以优化覆盖范围和容量,特别是在密集的城市环境中。
- Antenna calibration(天线校准):确保天线阵列的性能,通过对天线单元进行精确的调整和校准,以提高无线链路的质量和可靠性。
- CU plane monitoring(CU平面监控):集中单元(CU)是5G网络架构的一部分,负责处理非实时处理任务,此功能可能涉及对CU的操作状态、性能指标和故障检测的监控。
- Trace(跟踪):在网络中实施跟踪机制,用于收集和分析数据,以进行故障诊断、性能优化和网络行为研究。
- 3G:虽然具体细节未给出,但提及3G可能意味着该规范也考虑了与现有3G网络的兼容性或过渡策略。
这个文档详细阐述了O-RAN的管理平面如何处理这些功能,以及如何通过开放接口与其他组件交互,实现更高效、智能的网络运营。管理平面通常涉及网络配置、状态监控、故障管理、性能管理和安全管理等核心功能。通过开放接口,O-RAN联盟的目标是创建一个更加灵活、可扩展和多样化的无线接入网络生态系统。
Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 16
Copyright © 2021 by the O-RAN Alliance e.V.
O-RAN.WG4.MP.0-v07.00
If there is any conflict between the YANG models and the accompanying text description in this specification, the definition of
1
the YANG models shall take precedence.
2
1.5 Topics for Future Specification Versions
3
Extensions to this version of the O-RAN WG4 Management Plane specification together with corrected errors will be included
4
in the future versions of this document.
5
6
The following topics are to be considered for future versions of the specification:
7
1. Beam Id field interpretation for various types of beamforming
8
2. Redundancy and failover scenario
9
3. Shared cell support for IP-defined flows
10
4. Enhancements to better align with O-RAN Alliance O1 specification
11
12
1.6 Revision and Compatibility Handling
13
The revision statement in the YANG models will be used to describe future revisions to the models that are backwards
14
compatible, where backwards compatibility changes follow the rules defined in section 11 of RFC 7950 [4]. Backwards
15
incompatible changes will be addressed by incrementing the number used as part of the model name and namespace, effectively
16
creating a new YANG model. The format of the namespace used in all O-RAN YANG models is “urn:o-ran:”<model-
17
name>“:”<model-number>, where the initial <model-number> used in a newly defined YANG model is “1.0”. Where this
18
document makes reference to models, irrespective of their backward compatibility, a generic <model-number> of “x.y” is used
19
to enable reference to all versions of the namespace for a particular <model-name>.
20
21
The revision statement in all YANG models includes a reference statement used to cross-reference to the first version of this
22
document where the corresponding description was introduced. For example, the reference in all revision statements for the
23
initial O-RAN models include cross-reference to “ORAN-WG4.MP.0-v01.00”.
24
25
The revision statement of the YANG models also includes a description which is used to track the versioning of the YANG
26
model. All revision statement descriptions will begin with “version ”<a>“.”<b>“.”<c>, where <a>, <b> and <c> are used to
27
reflect the version of the YANG model, where
28
29
<a> corresponds to the first digit of the O-RAN WG4 management plane specification version where the
30
corresponding description was first introduced, corresponding to <x> in sub-section 1.1
31
<b> is incremented when errors in the YANG model have been corrected
32
<c> is incremented only in working versions of the YANG model indicating incremental changes during the editing
33
process
34
35
Note, O-RU Controllers that receive YANG library information from the O-RU with a module revision that is a higher version
36
than the module revision currently used by the O-RU Controller can assume that models with the same namespace have been
37
updated to ensure backwards compatibility. The O-RU Controller can continue to use its current module version and any
38
unknown schema nodes received from the O-RU, i.e., those introduced in later revisions, should be ignored by the O-RU
39
Controller.
40
41
1.7 Namespace Compatibility Handling
42
If backwards incompatible changes have been made, the <model-number> used in the YANG model namespace shall be
43
incremented. Following such changes, an O-RU may include multiple backwards incompatible namespaces in its YANG
44
library, for example “urn:o-ran:”<model-name>“:1.0” and “urn:o-ran:”<model-name>“:2.0”.
45
The O-RAN Adopter License Agreement in Chapter ZZZ defines terms regarding the modification of O-RAN defined
46
specifications. When such modifications are necessary, the preferred approach for realizing such is for the third-party licensee
47
to publish their own augmentations to the O-RAN defined YANG models and procedures. An O-RU that supports such third-
48
party modifications shall include such model augmentations in its YANG library. Consequently, an O-RU Controller should be
49
prepared to ignore any unknown models, e.g., developed according to such a procedure.
50
Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 17
Copyright © 2021 by the O-RAN Alliance e.V.
O-RAN.WG4.MP.0-v07.00
Chapter 2 High Level Description
1
2.1 Top level functional description, terminology, including hybrid,
2
hierarchical
3
2.1.1 Architecture for O-RAN WG4 Fronthaul functional split
4
This O-RAN FH specification addresses the lower layer functional split as depicted in Figure 1. Refer to the O-RAN CUS plane
5
specification [2] for more details on the split architecture. The Lower-Layer Split M-plane (LLS-M) facilitates the initialization,
6
configuration and management of the O-RU to support the stated functional split.
7
8
Figure 1 – O-RAN WG4 FH functional split
9
2.1.2 M-Plane architecture model
10
A NETCONF/YANG based M-Plane is used for supporting the management features including “start up” installation, software
11
management, configuration management, performance management, fault management and file management towards the O-
12
RU. The M-Plane supports two architectural models:
13
1. Hierarchical model. As shown on the left side Figure 1, the O-RU is managed entirely by one or more O-DU(s) using
14
a NETCONF based M-Plane interface. When the O-RU is managed by multiple O-DUs, it is typically for enabling O-DU
15
and/or transport connectivity redundancy capabilities. Refer to Chapter 3 for more details.
16
2. Hybrid model. As shown on the right side of Figure 1, the hybrid architecture enables one or more direct logical
17
interface(s) between management system(s) and O-RU in addition to a logical interface between O-DU and the O-RU. It
18
should be noted that the NETCONF clients connecting to the O-RU may be of different classes (e.g. O-DU and SMO). For
19
example, functions like O-RU software management, performance management, configuration management and fault
20
management can be managed directly by the management system(s).
21
In the hybrid model, the O-RU has end to end IP layer connectivity with the SMO. From a physical network point of view, this
22
connectivity could be via the O-DU, where the O-DU is acting as an IP/Ethernet packet forwarder, forwards the packets between
23
O-RU and the SMO. Direct logical communication between an O-RU and SMO can be enabled via O-RUs being assigned
24
Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 18
Copyright © 2021 by the O-RAN Alliance e.V.
O-RAN.WG4.MP.0-v07.00
routable IPs or local private IPs resolved by a NAT function in the network (or implemented at the O-DU). Refer to chapter 3
1
for details how O-RU acquires the IP address of O-DU and SMO for the M-plane communication.
2
As described in Chapter 3, there is no explicit signaling to indicate that an O-RU is operating in a hierarchical or hybrid
3
configuration. All NETCONF servers supporting this M-Plane specification shall support multiple NETCONF sessions, and
4
hence all compliant O-RUs shall be able to support both hierarchical and hybrid deployment.
5
6
Figure 2 - M-Plane Architecture
7
NETCONF/YANG is used as the network element management protocol [3] and data modeling language [4]. Use of such a
8
standardized framework and common modeling language simplifies integration between O-DU and O-RU as well as operator
9
network integration (in terms of running service) in case of elements sharing a common set of capabilities. The framework
10
supports integration of products with differing capabilities enabled by well-defined published data models. NETCONF also
11
natively supports a hybrid architecture which enables multiple clients to subscribe and receive information originating at the
12
NETCONF server in the O-RU.
13
2.1.3 Transport Network
14
Based on the transport topology, various modes of network connectivity are possible between O-RU and O-DU and SMO.
15
The basic requirement for M-Plane is to have end to end IP connectivity between the O-RU and the elements managing it (O-
16
DU, SMO, or so called “O-RU Controllers”). The connectivity between the O-DU and SMO and its management plane are not
17
in scope of this specification. The O-RU shall support either IPv4 or IPv6 and optionally support dual stack (IPv4 and IPv6).
18
Note, in previous versions of this specification, only IPv4 was mandatory. In order to ensure backwards compatibility
19
with equipment supporting earlier versions of this specification, an operator and vendor can agree to use a common IP
20
version in the O-RU, O-DU and any other O-RU controllers.
21
Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 19
Copyright © 2021 by the O-RAN Alliance e.V.
O-RAN.WG4.MP.0-v07.00
2.1.4 M-Plane functional description
1
The M-Plane provides the following major functionalities to the O-RU. These features are implemented using the NETCONF
2
provided functions.
3
“Start up” installation
4
During startup, the O-RU acquires its network layer parameters either via static (pre-configured in the O-RU) or dynamically
5
via DHCP or DHCPv6. During this process the O-RU may acquire the IP address of the O-RU controller(s), in which case the
6
O-RU establishes the NETCONF connectivity using the “call home” feature. When the O-RU is operating in an environment
7
which include the O-RAN defined SMO, the O-RU may acquire the IP address of the event-collector(s), in which case the O-
8
RU performs a pnfRegistration which triggers the SMO to establish NETCONF connectivity using the information recovered
9
from the pnfRegistration procedure. The capability exchange is performed between the client and server as part of the initial
10
NETCONF Hello exchanges. Details of these steps are provided in chapter 3.
11
Note, the use of “start up” terminology in this specification is distinct from the “startup” capability used in a NETCONF
12
environment to indicate that a device supports separate running and startup configuration datastores. This specification makes
13
specific reference to configuration which is required to be stored in “reset persistent memory”. The O-RU shall use this stored
14
configuration as its “startup” configuration.
15
SW management
16
The M-Plane is responsible for software download, installation, validation and activation of new SW when requested by O-RU
17
Controller. The software download is triggered by NETCONF RPC procedures, and the actual software package download is
18
performed using sFTP with SSH or FTPES [54] with TLS.
19
Configuration management
20
Configuration management covers various scenarios like Retrieve Resource State, Modify Resource State, Modify Parameters
21
and Retrieve Parameters. NETCONF get-config and edit-config RPCs shall be used for configuration parameter retrieval and
22
updates at the O-RU
23
Performance management
24
Performance management describes the measurements and counters used to collect data related to O-RU operations. The
25
purpose of Performance Management is optimizing the operation of the O-RU.
26
The measurement results are reported by two options:
27
1. YANG Notification: This option uses the stats definition of YANG model per measurement group. In this case, get
28
rpc and/or notification will be used (see Chapter 7 for more details).
29
2. File Upload: This option uses the file upload procedure defined in File management. The measurement results are
30
saved to a data file periodically.
31
Fault Management
32
Fault management is responsible for sending alarm notifications to the NETCONF Client. Fault Management allows alarm
33
notifications to be disabled or enabled as well as alarm subscription.
34
File Management
35
File management allows the O-RU Controller to trigger an O-RU to perform upload of files stored on O-RU to O-RU Controller.
36
The O-RU may provide different kinds of files and retrieved files can be used for various purposes. Simultaneous multiple file
37
upload operations can be supported under the same sFTP or FTPES [54] connection between O-RU to O-DU/SMO.
38
2.2 Interfaces
39
The M-Plane interface is defined between the O-RU Controller and the O-RU. The protocol stack of the M-Plane interface is
40
shown in the figure below. The transport network layer is built on IP transport and SSH/TCP, and optionally TLS, is used to
41
carry the M-Plane message between the O-RU Controller and the O-RU. As an option, the O-RU may support the capability
42
to support asynchronous notifications to be sent using HTTPS. This option enables system optimization when the O-RU
43
Controller corresponds to the SMO which is operating with a non-persistent NETCONF session to the O-RU.
44
Your use is subject to the terms of the O-RAN Adopter License Agreement in Annex ZZZ 20
Copyright © 2021 by the O-RAN Alliance e.V.
O-RAN.WG4.MP.0-v07.00
1
2
3
Figure 3: M-plane protocol stack
4
2.3 YANG Module Introduction
5
The data models representing the M-Plane are organized as a set of reusable YANG modules. It is also the intent to reuse the
6
publicly available and generic YANG models as much as possible instead of developing customized O-RAN specific modules.
7
Refer to the various chapters, Annex D and the repository of YANG models for more details on each of these modules.
8
2.4 Security
9
The M-Plane provides end to end security as a mandatory feature, see Table 1. M-Plane security shall support SSHv2 in
10
accordance with RFC 6242 [5]. TLS 1.2 in accordance with RFC 7589 [41] may be optionally supported. TLS 1.3 in accordance
11
with RFC 8446 [42] may also be optionally supported in addition to TLS 1.2. RFC 6242 [5] and RFC 7589 [41] provide the
12
procedures for interoperability with NETCONF implementations. If there are multiple NETCONF sessions established with a
13
single O-RU, either SSH tunnels or TLS connections may be used and each session should be established over a separate SSH
14
tunnel or TLS connection. An O-RU shall support sFTP based file transfer over SSH. An O-RU that supports optional
15
NETCONF/TLS shall also support FTPES based file transfer over TLS. For the O-DU, the operator may use SSH, TLS, or
16
both. It is recommended that operators use NETCONF/TLS and FTPES in production networks.
17
Note that TLS versions 1.0 and 1.1 have been deprecated by the IETF [55] and shall not be used.
18
Plane
Integrity (protection
from modifications)
Confidentiality
(encryption
protection)
Authentication
(validity of the
originator)
Remarks
M-Plane/
NETCONF
Yes
Yes
Yes
NETCONF transport:
a) Mandatory support for
SSHv2, RFC 6242 [5]
b) Optional support for TLS
1.2, RFC 7589 [41]
c) Optional support for TLS
1.3, RFC 8446 [42]
Optional
support of
JSON/REST
Yes
Yes
Yes
HTTPS used for JSON/REST
transport
Table 1- M-Plane Security
19
SSHv2 may be used to perform SSH server host authentication, key exchange, encryption, and integrity protection. It also
20
derives a unique session ID that may be used by higher-level protocols. The end point (SSH client) authentication should be
21
done as per RFC 4252 [6]. Chapter 3 describes the authentication approach based on username and password as well as based
22
on X.509 certificates.
23
剩余213页未读,继续阅读
文火冰糖的硅基工坊
- 粉丝: 22w+
- 资源: 25
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 黑板风格计算机毕业答辩PPT模板下载
- CodeSandbox实现ListView快速创建指南
- Node.js脚本实现WXR文件到Postgres数据库帖子导入
- 清新简约创意三角毕业论文答辩PPT模板
- DISCORD-JS-CRUD:提升 Discord 机器人开发体验
- Node.js v4.3.2版本Linux ARM64平台运行时环境发布
- SQLight:C++11编写的轻量级MySQL客户端
- 计算机专业毕业论文答辩PPT模板
- Wireshark网络抓包工具的使用与数据包解析
- Wild Match Map: JavaScript中实现通配符映射与事件绑定
- 毕业答辩利器:蝶恋花毕业设计PPT模板
- Node.js深度解析:高性能Web服务器与实时应用构建
- 掌握深度图技术:游戏开发中的绚丽应用案例
- Dart语言的HTTP扩展包功能详解
- MoonMaker: 投资组合加固神器,助力$GME投资者登月
- 计算机毕业设计答辩PPT模板下载
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功