一种5G微基站的OM管理系统的制作方法

本发明涉及通信系统架构技术，尤其涉及一种5g微基站的om管理系统。

背景技术：

在传统的微基站管理系统中对于微基站om部分各个基站厂家没有统一的技术架构，导致运营商对各个厂家的系统无法统一进行管理与维护，在维护过程中对厂家的依赖严重。并且维护人员往往也是只维护一类基站，无法对所有类型的基站进行维护。对于运营商来说无疑是一种人力成本的浪费，且无法随意调整人员工作内容，也无法随意增减基站的建设，在建设的过程中还得考虑维护的问题，这无疑不是一种技术限制。要打破技术壁垒则需要一个统一的技术架构来实现。

此外，原有的微基站中om与基站强耦合，一旦om出现故障则需要维护人员到现场进行服务重启，无法进行远程维护，产生了巨大的人力成本与时间成本支出。

技术实现要素：

本发明的目的在于提供一种技术架构统一、维护成本低的5g微基站的om管理系统。

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

根据本发明的一方面，提供了一种5g微基站的om管理系统，包括管理平台层、om控制层和设备层，所述管理平台层、om控制层和设备层之间信号连接，所述管理平台层用于为管理人员提供交互界面，所述om控制层用于控制系统业务逻辑和流程，所述设备层包括硬件执行部即omagent，所述omagent执行所述om控制层下发的命令并对硬件进行操作。

在一实施例中，该5g微基站的om管理系统的所述omagent通过调用具体的api执行所述om控制层下发的命令。

在一实施例中，该5g微基站的om管理系统的所述管理平台层包括操作维护中心。

在一实施例中，该5g微基站的om管理系统的所述om控制层包括本地维护终端，所述本地维护终端用于提供交互界面。

在一实施例中，该5g微基站的om管理系统的所述om控制层部署在服务器集群中。

在一实施例中，该5g微基站的om管理系统的所述设备层借助f5负载均衡器与所述om控制层连接。

在一实施例中，该5g微基站的om管理系统的所述设备层包括集中控制单元即cu、分布单元即du、扩展单元即eu和远端单元ru，所述omagent分别设置于所述cu、du、eu和ru内。

本发明实施例的有益效果是：通过将原有om软硬件分离，软件部分形成om控制层，脱离了硬件平台的束缚，适于多种部署模型，不再需要与硬件耦合，对于升级与维护更加便捷，在机房即可完成，不再需要到基站外场。硬件交互部分下沉到设备层，剥离了流程控制与逻辑控制，大大降低了嵌入式开发复杂度。此外，本系统为运营商提供了统一的技术架构，不再需要对每种设备进行学习，避免了大量的手册翻阅。能够采用统一的维护流程与方法，大大节约了人力成本与维护成本。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1是本发明实施例的系统架构图；

图2是本发明另一实施例的系统架构示意图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

本发明实施例提供了一种5g微基站的om管理系统。如图1所示，本系统分为三级架构，包括管理平台层101、om控制层102和设备层103。其中，管理平台层101、om控制层102和设备层103之间信号连接。管理平台层101用于为管理人员提供交互界面，将用户操作转换为机器可以识别的指令便于程序识别，同时将机器的状态与数据转化为界面元素便于用户识别与分析。管理平台层可以采用现有的操作维护中心(operations&maintenancecenter，omc)。om控制层102用于控制系统业务逻辑和流程。设备层103包括硬件执行部，即omagent，omagent执行om控制层102下发的命令并对硬件进行操作。

相较于现有基站om，本系统将原有om软硬件分离，软件部分形成om控制层102，从而脱离了硬件平台的束缚，适于多种部署模型，不再需要与硬件耦合，升级与维护更加便捷。硬件交互部分下沉到设备层103，剥离了流程控制与逻辑控制，大大降低了嵌入式开发复杂度。

对于整个系统来说omagent就是一个一个api。当om控制层102需要对硬件进行操作时则将操作信息转发为一条消息发送到omagent，omagent识别om下发的命令调用具体的api再进行硬件操作。不需要做逻辑控制与流程控制。

om控制层102可包括本地维护终端lmt，本地维护终端lmt也用于提供交互界面。管理人员既可以通过omc对本系统进行交互，也可通过lmt对om控制层进行设置。omc和lmt可设置于机房内，从而升级与维护更加便捷，在机房即可完成。

优选地，可将om控制层102部署云化到服务器集群中进行集中管理与维护，从而使得整个om平台不因单台om故障导致整个平台无法工作，从而降低了故障率。

在可能的实施例中，设备层103可如图2所示，借助f5负载均衡器与om控制层连接，以减轻服务器的压力。

设备层103包括集中控制单元(centralizedunit，cu)、分布单元(distributedunit，du)、扩展单元(externalunit，eu)和远端单元(remoteunit，ru)，omagent分别设置于cu、du、eu和ru内。

本发明的有益效果包括：

1、om软件化脱离硬件平台的束缚，适用于多种部署模型，不再需要与硬件耦合，对于升级与维护更加便捷，在机房即可完成，不再需要到基站外场。

2、om云化不再因为单点故障导致整个基站维护系统的故障，提升了整个系统的健壮性。

3、omagent剥离了流程控制与逻辑控制，大大降低了嵌入式开发复杂度。

4、为运营商提供统一的技术架构，不再需要对每种设备进行学习，避免了大量的手册翻阅。

5、为运营商的维护人员打破微基站厂商的技术壁垒，统一各个基站厂商的技术架构，为维护人员提供统一的技术。不再需要针对某厂商的基站设备进行独立学习与支持。采用统一的流程与方法，大大节约了人力成本与维护成本。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

在本文提及的″模块″通常是指存储在存储器中的能够实现某些功能的程序或指令；在本文中提及的″单元″通常是指按照逻辑划分的功能性结构，该″单元″可以由纯硬件实现，或者，软硬件的结合实现。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

以上所述仅为本申请的较佳实例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。