一种支撑5G基站CU-DU灵活部署的配置管理方法

谢筱耸

（锐捷网络股份有限公司 福建省福州市 350108）

1 引言

1.1 5G基站的配置管理

第五代移动网络通信（5G）是为了应对未来爆炸性的移动数据流量增长、海量的设备连接、不断涌现的各类新业务和应用场景，而诞生的技术。5G 基站作为用户设备的接入网络的最直接的入口，需要支持大量的配置项。

5G 基站的配置管理，通常基于网管软件。网管软件运行于基站之外的另一台服务器上，使用SNMP、NETCONF、CWMP 等协议与多个基站建立管理通道。

管理通道通常提供两个方向的服务：

（1）南向，下发配置。基站接收来自于网管的管理报文。根据配置项完成相应的配置动作。

（2）北向，上报信息。根据网管的要求，或基站主动地，上报基站的配置、运行状态等信息。

网管代理与业务组件：

5G 基站网络管理架构如图1 所示。

图1：5G 基站网络管理架构

我们将基站端接收配置并分发的组件，称为“网管代理”组件。把具体执行配置的组件，称为“业务组件”。业务组件接受并响应来自于网管软件的配置请求，可分为三类：

（1）CU 协议栈业务：基于3GPP 标准设计的5GNR CU 无线协议软件集合。

（2）DU 协议栈业务：基于3GPP 标准设计的5GNR DU 无线协议软件集合。

（3）OAM 业务：指用于支撑无线协议栈的操作、管理、维护软件集合。它通常包含以下等功能：①告警管理；②时钟管理；③设备拓扑与资产信息管理；④其它管理类功能。

网管代理给业务组件提供两个方向的服务：

（1）南向，下发配置。作为网管在基站上的代理，接收网管发来的管理报文。并承担了解析管理报文，并分发配置给各业务组件的任务。各业务组件接收到配置后，根据配置项完成相应的配置动作。

（2）北向，上报信息。各业务组件发送的配置、版本、硬件等信息，经网管代理的汇总并封装管理报文，通过管理通道，上送到网管。

1.2 5G时代CU/DU拆分给网管带来的挑战

相对于4G 无线接入网（RAN）的基带处理单元（BBU）、射频拉远单元（RRU）两级结构，在5G 时代，原有的BBU 被拆分为集中单元（CU）、分布单元（DU），形成CU+DU+AAU 的三级结构。

（1）CU：原BBU 的非实时部分将分割出来，重新定义为CU，负责处理非实时协议和服务。

（2）DU：物理层协议和实时服务。

（3）AAU：原RRU 及天线合并为AAU。

CU/DU 将5G 协议栈依层级拆分到两个实体中。即PDCP 及以上纳入CU，RLC 及以下，至LOW‐PHY，划分为DU。通过CU/DU 的拆分，5G 基站可以更方便地实现基带共享和虚拟化。协议允许对CU/DU 进行灵活部署，

CU/DU 可以集中于一个物理设备中，也可以分离在两个物理设备中。部署形态因客户需求而定。也就是说，被管理的对象，可能设置于一个物理实体设备中，也可能分布在不同的设备中。

另外，合并部署的CU/DU 中，还可以分为以下两种设备形态：

（1）CU/DU 运行于同一CPU 上。

（2）CU/DU 运行于不同CPU 上。

典型设备形态为：同一机箱内，槽位A 板卡运行CU，槽位B 板卡运行DU，网管接口只在CU 上。此设备形态下，槽位A的板卡统一管理机箱内的其它板卡，也被称为主控板，槽位B 的板卡，也被称为基带板。

这样的灵活部署提高了软件的复杂度。主要体现在，针对以下四种产品形态，要分别开发软件，提高了软件的复杂度。

（1）分离部署的CU。

（2）分离部署的DU。

（3）合并部署的运行于同一CPU 的CU/DU。

（4）合并部署的运行于不同CPU 的CU/DU。

本文针对以上问题，设计一种软件设计方案，实现了软件在不同形态设备上的复用。自动化地、灵活适配5G 基站各种部署的场景。

2 解决方案

2.1 基于数据库的配置管理

2.1.1 概述

为了让业务组件能够灵活部署于不同的场景中，本文提出将业务组件不直接与网管代理建立通道，而是通过数据库，作为配置下发和信息收集的媒介。

基于数据库的配置分发解耦（CU/DU 分离式场景）如图2 所示，基于数据库的配置分发解耦（CU/DU 集中式场景）如图3 所示。

图2：基于数据库的配置分发解耦（CU/DU 分离式场景）

图3：基于数据库的配置分发解耦（CU/DU 集中式场景）

南向：网管代理收到配置后，将配置数据转成数据库中的配置数据保存，业务组件通过监听数据库中的数据，获得下发的配置数据。

北向：业务组件将待通告的信息写入数据库中。网管代理监听数据库中的通告数据，得到通告数据后，封装成报文发送给网管。

将数据库作为业务组件与网管代理解耦的媒介后，不管CU/DU 集中或分离部署，业务组件只关注数据库中的配置参数，不用关心配置来源。实现了业务组件与CU/DU 的部署情况解耦。

2.1.2 配置对象

配置对象是配置参数在配置数据库中的组织形式。对象可以是：

（1）基站协议栈业务的资源对象，如小区、NG 口等；

（2）设备物理对象，如BBU，RRU，接口，天线等

（3）软件代码中的实例模型，如日志收集任务，告警实例等；

基于配置对象，抽象出对象参数，用于表示对象的属性或运行参数。例如小区对象之下，包含CellId,PLMN,PCI 等参数。

2.1.3 用户配置与运行配置分离

本系统采用用户配置与运行配置分离的设计。每一个配置对象，在数据库中都存在两部分副本：用户配置对象和运行配置对象。

用户配置对象，用于配置数据的南向下发的异步处理。网管代理将从网管收到的配置写入用户配置对象之后，即向网管返回结果。

运行配置对象，用于网管代理读取基站正在运行的配置，或基站中实时变化的参数，如温度，风扇转速。

通过配置数据库的解耦，数据库消息的发送端与接收端，都只关心本端的操作。发送端不关心对端是否收到并生效，接收端也不关心发送端的状态。发送端与接收端达到一种松耦合的状态。这种设计优势：

（1）缩短了RPC 的调用链，提高RPC 的可靠性；

（2）使得接收配置的业务与配置来源解耦，更有利于适配多种部署场景下的基站。

2.1.4 RPC 动作在配置数据库中的抽象

配置对象的操作，通常可以抽象为网管通道中的RPC动作。常见的RPC 动作为：

（1）ADD：增加配置对象；

（2）DEL：删除配置对象；

（3）SET：修改配置对象参数值；

（4）GET：读取配置对象参数值；

（5）LIST：读取配置对象列表；

（6）NOTIFICATION：基站端发生的配置变更的北向通告。

常见的数据库操作，通常包含以下几类：

（1）SET：添加或修改配置对象；

（2）DEL：删除配置对象；

（3）GET：读取配置对象参数值；

（4）LIST：读取配置对象列表；

（5）PUB：发布消息。用于消息的发送端；

（6）SUB：订阅消息。用于消息的接收端。

本章节考虑如何将各类网管RPC 动作转化为对配置数据库的操作。

ADD/DEL/SET RPC：

（1）业务SUB 用户配置对象的变更消息；

（2）网管代理在配置数据库中，ADD/SET/DEL 用户配置对象，并向网管返回结果；

（3）PUB 配置对象变更消息；

（4）业务得到配置对象的变更通告，得到配置参数值；

（5）将配置生效到业务中；

（6）在配置生效完成后，业务组件再将运行配置异步地写入运行配置对象中。

GET/LIST RPC：网管代理查询配置数据库中的配置数据（参数值，或参数列表）。根据需求从用户配置对象，或运行配置对象中，读取参数。封装后向网管返回RPC 结果。

NOTIFICATION RPC：

（1）网管代理SUB 运行配置对象的变更信息；

（2）当配置参数发生变更时，业务SET 数据库中运行配置对象；

（3）PUB 运行配置对象变更信息；

（4）网管代理收到对象的变更通知，向网管发起NOTIFICATION RPC，通知配置数据的变更。

网管RPC 的数据库操作抽象如图4 所示。

图4：网管RPC 的数据库操作抽象

2.1.5 数据库同步

配置数据库支持分布式数据同步，它基于主从数据库，实现如下特性：

（1）主从数据库基于TCP/IP 建立连接。主从数据库建立连接后，主数据库向从数据库备份数据。

（2）数据库仅支持由主至从的单向同步。从数据库对外只提供只读接口，不可写入。

（3）使用异步模式同步数据，数据同步状态不会阻塞数据库的数据读写。

（4）支持1：N 同步，即可以支持存在多个从数据库。

利用这一数据库同步的特性，可以用于支撑CU/DU 合并部署但运行于不同CPU 的场景（图5）。部署环境如下：同一机箱内，槽位A 板卡运行CU 协议栈与网管代理，槽位B 板卡运行DU 协议栈，BBU 设备的对外接口只在槽位A的板卡上。在槽位A 上部署配置数据库主库，在槽位B 上部署配置数据库从库，从库接收由主库同步来的配置数据。

图5：CU/DU 合并部署但运行于不同CPU 的场景

由于数据库的单向同步特性，从数据库只读，不支持写入。槽位B 的业务需要向数据库中写入数据时，不写入从数据库，而是使用主数据库开放出来的跨槽位写数据接口，将数据写入主数据库中。

槽位B 的各业务，对各网管RPC 的操作，在此部署条件下，说明如下：

ADD/DEL/SET RPC：网管代理把用户配置数据写入主数据库，并将结果返回给网管。主数据库向从数据库同步配置对象信息，槽位B 业务异步地通过从数据库获取到配置信息。

GET/LIST RPC：B 槽业务将运行配置数据通过跨槽位的写数据接口，写入主数据库中。网管代理检索主数据库中的数据，读取数据后向网管返回信息。

NOTIFICATION RPC：B 槽业务将运行配置数据通过跨槽位的写数据接口，写入主数据库中。网管代理监听到配置对象变化，向网管发出NOTIFICATION。

2.2 基于容器的CU/DU软件

2.2.1 容器部署规则

容器是近年流行起来的软件框架，它让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，并提供了虚拟化的机制。借助容器，解决了软件开发过程中的以下问题：

（1）隔离性：容器之间相互隔离，互不影响。

（2）可配额、可度量：每个容器可按需配置计算资源。

（3）可移植：因为容器然应用以及应用依赖的包打包到一起，一个容器本身，就是一个可以提供服务的单元，无需其它支撑。因此容器可以很方便地在不同的设备间移植。

（4）安全性：容器只对外提供有限的接口，避免应用暴露过多的配置选项和接口。

基于容器的以上特性，我们设计封装出以下镜像：

（1）CU 容器：打包网管代理，OAM 业务，5GNR 协议栈CU 部分。

（2）DU 容器：打包网管代理，OAM 业务，5GNR 协议栈DU 部分。

根据CU/DU 部署环境的不同，按需部署容器。根据第一章的描述，如下四种设备形态下，各容器的部署规则如表1。

表1：容器部署规则

在这几种产品形态中，数据库作为基础中间件，预置于设备，独立于CU/DU 容器之外存在。

2.2.2 部署环境自动识别

容器的部署环境是决定容器内组件如何运行的重要参数，起到协调各容器运行参数的作用。例如：

（1）CU/DU 容器中都包网管代理，在CU/DU 合并部署的设备上，两个网管代理同时提供服务，会有冲突。

（2）在“合并部署的运行于不同CPU的CU/DU”模式下，CU 容器中的OAM 组件，应运行在主动模式下，DU 容器中的OAM 组件，应运行在被动模式下。DU 容器中的OAM组件接受CU 容器中的OAM 组件的管理。

因此，本文提出容器内的组件能够自动探测并识别当前所处的部署环境，容器内业务跟据部署环境参数，决策运行逻辑。

算法描述：

（1）协商的过程基于数据库。容器启动时，在数据库中写入本实例可提供服务的标志，和本机序列号SN。并查询是否有其它容器可提供服务。

（2）在一定的超时时间后，数据库中仍然没有标志证明有其它容器可提供服务，则以分离部署的模式启动当前容器。

（3）如果有发现其它容器可提供服务，则检查对端SN是否与本端相同。

（4）如果两个容器SN 不同，以“合并部署的运行于不同CPU 的CU/DU”模式启动容器。在此模式下，CU 容器中的OAM 业务运行于主动模式下，DU 容器中的网管代理因没有外部接口而被关闭，OAM 业务运行于被动模式下。

（5）如果两个容器SN 相同，以“合并部署的运行于同一CPU 的CU/DU”模式启动容器。在此模式下，DU 容器内的组件会关闭部分服务以避免冲突。例如关闭DU 容器中的网管代理，仅由CU 容器中的网管代理提供服务。

算法流程图如图6 所示。

图6：提供相同服务的多实例自协商过程

3 结语

本文提出的技术方案，让5G 基站的软件的管理面，可以灵活、快速地适配CU/DU 的集中式、分离式部署形态。5G 基站软件无需针对CU/DU 不同的部署形态，开发不同的软件版本。从而简化软件开发、部署的复杂度。具体体现为：

（1）通过数据库，解耦业务组件与配置代理组件。使得业务组件不关心配置来源，只关心数据库中的配置数据。使用业务组件部署更灵活。

（2）基于容器打包CU/DU 软件，根据CU/DU 部署环境的不同，按需部署容器。容器可以通过自协商自动识别部署环境模式，决策容器内组件的业务逻辑。