分布式基站升级处理方法及系统

技术领域

本发明涉及通信技术领域，尤其涉及一种分布式基站升级处理方法及系统。

背景技术

分布式基站系统包括三种网元设备类型：基带处理单元 (Building Base bandUnit, BBU)、扩展单元 (Extended Unit, EU)、射频拉远单元 (Radio Remote Unit,RRU)。在一套分布式基站系统中，上述三种设备总数可达几十个，且各网元需要协同工作。目前对分布式基站系统的设备软件多采用远程的方式，通过自动配置服务器(Automatically Configuration Server, ACS)进行升级，而如何高效地管理众多设备软件的远程升级过程，减少人工干预，且不影响设备正常运转，变得尤为重要。图1为系统架构图，ACS下挂分布式基站系统（包括BBU、EU、RRU），其中EU之间级联在一起，扩展下挂RRU设备，ACS通过TR069消息对分布式基站系统进行升级控制。ACS与BBU之间采用网线或光纤连接，BBU、EU、RRU之间采用光纤连接。

图2为现有技术中对分布式基站系统的设备软件升级方法，一般包括如下步骤。

1. ACS将BBU、EU、RRU的软件升级包压缩成一个升级文件，然后下发给BBU;

2. BBU从升级文件中剥离EU、RRU升级文件，然后通知EU下载;

3. EU从升级文件中剥离RRU升级文件，然后通知RRU下载;

4. RRU执行升级重启;

5. EU执行升级重启;

6. BBU执行升级重启;

7. 完成升级。

图3为升级状态图，分布式基站系统下每个设备升级状态包括：初始化、下载、安装、等待激活、激活、完成六个状态。

现有技术存在以下缺陷：

1.ACS缺少智能升级整体方案，以提升升级成功率，及减少升级过程中、升级失败后的人工干预。现有技术需要大量的远程运维工作以及设备更换、维修的现场运维工作，增加了系统运维成本。

2. 缺少事前智能检测的机制。在升级前，未检查分布式基站系统是否满足升级条件。增加了升级失败的几率、问题定位和设备软件回滚的难度，从而导致部分设备需要现场维修甚至更换；

3. 针对升级失败的设备，未提供有效策略以管理异常信息，如异常信息采集和可视化、异常信息处理。因此需要经验丰富的运维人员对升级中的异常进行分析和处理，增加了人力成本；

4. 缺少结合设备整体拓扑组网模式的升级可视化策略，使得运维人员难以全盘掌握设备升级情况，可能导致设备升级遗漏、性能和功能不匹配、客户体验差等问题，运维人员需要进一步地测试升级设备，增加了运维成本。

发明内容

本发明实施例所要解决的技术问题在于，提供一种分布式基站升级处理方法及系统，以实现预防、管理以及解决升级问题。

为了解决上述技术问题，本发明实施例提出了一种分布式基站升级处理方法，包括：

步骤1：ACS检测软件发布服务器是否发布新版本的软件，若是，则下载软件至ACS；

步骤2：ACS校验下载软件的签名是否正确，若签名不正确，则提示错误，并停止本次升级；若正确，则进入步骤3；

步骤3：ACS测试所下载的软件，若测试通过则进入步骤4，若测试未通过，则从软件发布服务器再次下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；

步骤4：ACS生成升级任务；

步骤5：ACS更新待升级设备的运行情况、链路带宽信息、设备CPU利用率及内存情况；其中，若存在问题，则提示错误，并停止本次升级；

步骤6：ACS采集设备拓扑和软件依赖；

步骤7：ACS生成待升级列表和下载源列表，其中，待升级列表包括本次升级各设备需要升级的软件及其相关信息，按软件间依赖排序；下载源列表包括各设备可以下载某个软件的源；

步骤8：ACS根据所采集的信息制定下载和安装策略，该下载和安装策略满足以下约束：（a）各软件的依赖关系决定的安装顺序；（b）网络拓扑；（c）ACS、BBU、EU仅在拥有完整的软件后才能进行软件转发；（d）单位时间内，一个设备仅能进行一个下载动作；（e）不得超过预计的总时间；

步骤9：ACS广播下载和安装策略至各个连接的BBU；若待升级设备包括EU，则相应BBU将下载和安装策略广播至指定的EU；若待升级设备包括RRU，则相应EU将下载和安装策略广播至指定的RRU；

步骤10：ACS接收BBU返回的应答，若待升级设备包括RRU，RRU返回应答至连接的EU；若待升级设备包括EU，EU返回应答至连接的BBU；

步骤11：ACS确认全部应答后，广播开始指令至BBU；若待升级设备包括EU，BBU广播开始指令至EU；若待升级设备包括RRU，EU广播开始指令至RRU；

步骤12：待升级设备按下载策略进行下载，下载的软件包包括一组压缩的文件以及元数据；

步骤13：校验各待升级设备是否下载成功，若校验失败，则重新下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

步骤14：通过下载校验后，各待升级设备按安装策略进行安装；

步骤15：校验各待升级设备是否安装成功；若校验失败，重新安装；若达到阈值后仍未通过，则提示错误，然后回滚至原始版本，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

步骤16：完成安装后，各设备进行激活；

步骤17：校验各待升级设备是否激活成功，若校验失败，则重新激活；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

步骤18：完成激活后，重启待升级设备。

相应地，本发明实施例还提供了一种分布式基站升级处理系统，包括：

模块1：ACS检测软件发布服务器是否发布新版本的软件，若是，则下载软件至ACS；

模块2：ACS校验下载软件的签名是否正确，若签名不正确，则提示错误，并停止本次升级；若正确，则进入模块3；

模块3：ACS测试所下载的软件，若测试通过则进入模块4，若测试未通过，则从软件发布服务器再次下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；

模块4：ACS生成升级任务；

模块5：ACS更新待升级设备的运行情况、链路带宽信息、设备CPU利用率及内存情况；其中，若存在问题，则提示错误，并停止本次升级；

模块6：ACS采集设备拓扑和软件依赖；

模块7：ACS生成待升级列表和下载源列表，其中，待升级列表包括本次升级各设备需要升级的软件及其相关信息，按软件间依赖排序；下载源列表包括各设备可以下载某个软件的源；

模块8：ACS根据所采集的信息制定下载和安装策略，该下载和安装策略满足以下约束：（a）各软件的依赖关系决定的安装顺序；（b）网络拓扑；（c）ACS、BBU、EU仅在拥有完整的软件后才能进行软件转发；（d）单位时间内，一个设备仅能进行一个下载动作；（e）不得超过预计的总时间；

模块9：ACS广播下载和安装策略至各个连接的BBU；若待升级设备包括EU，则相应BBU将下载和安装策略广播至指定的EU；若待升级设备包括RRU，则相应EU将下载和安装策略广播至指定的RRU；

模块10：ACS接收BBU返回的应答，若待升级设备包括RRU，RRU返回应答至连接的EU；若待升级设备包括EU，EU返回应答至连接的BBU；

模块11：ACS确认全部应答后，广播开始指令至BBU；若待升级设备包括EU，BBU广播开始指令至EU；若待升级设备包括RRU，EU广播开始指令至RRU；

模块12：待升级设备按下载策略进行下载，下载的软件包包括一组压缩的文件以及元数据；

模块13：校验各待升级设备是否下载成功，若校验失败，则重新下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块14：通过下载校验后，各待升级设备按安装策略进行安装；

模块15：校验各待升级设备是否安装成功；若校验失败，重新安装；若达到阈值后仍未通过，则提示错误，然后回滚至原始版本，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块16：完成安装后，各设备进行激活；

模块17：校验各待升级设备是否激活成功，若校验失败，则重新激活；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块18：完成激活后，重启待升级设备。

本发明的有益效果为：本发明解决了分布式基站系统升级时，运维人员无法直观的观察升级设备在组网中的状态，升级情况，升级前的异常以及升级过程出现问题后，该如何解决，如何收集异常信息等问题。

附图说明

图1是分布式基站的设备关系图。

图2是现有的分布式基站的升级流程简化图。

图3是现有的分布式基站的升级状态图。

图4是本发明实施例的界面示意图。

图5是本发明实施例的升级总体概况的示意图。

图6是本发明实施例的升级预检查的示意图。

图7是本发明实施例的升级策略的示意图。

图8是本发明实施例的升级日志的示意图。

图9是本发明实施例的升级经验库的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互结合，下面结合附图和具体实施例对本发明作进一步详细说明。

本发明实施例的分布式基站升级处理方法包括以下步骤：

1. ACS检测到软件发布服务器发布了新的软件版本，下载软件至ACS。

2. ACS校验下载软件的签名。若签名不正确，则提示错误，并停止本次升级。

3. ACS测试下载软件。若测试未通过，则应从软件发布服务器再次下载。若达到阈值后仍未通过，则提示错误，并停止本次升级。

4. ACS生成升级任务。包括待升级设备、待升级版本等信息。

5. ACS更新待升级设备的运行情况，链路带宽信息，设备CPU利用率及内存情况。若存在问题（如设备未运行、无法连接、CPU或内存占用率超过阈值），则提示错误，并停止本次升级。

6. ACS采集设备拓扑和软件依赖。设备可能运行一个或多个软件，这些软件之间存在依赖关系，形成有向无环图，设其为G

7. ACS生成待升级列表和下载源列表，待升级列表包括本次升级各设备需要升级的软件及其相关信息，按软件间依赖排序，下载源列表包括各设备可以下载某个软件的源。

8. 制定下载和安装策略。ACS基于采集的信息制定下载和安装策略。该下载和安装策略满足以下约束：（a）各软件的依赖关系决定的安装顺序；（b）网络拓扑；（c）ACS、BBU、EU仅在拥有完整的软件后才能进行软件转发；（d）单位时间内，一个设备仅能进行一个下载动作；（e）不得超过预计的总时间。作为一种实施方式，步骤8包括以下子步骤。

8.1 ACS计算得到从ACS节点到各个BBU节点的下载时间{DT

8.2 得到从各个BBU节点到各个EU节点的下载时间{DT

8.3 得到从各个EU节点到各个RRU节点的下载时间{DT

8.4 构造基于各节点下载时间的带权有向无环图，权值为各节点的下载时间。

8.5取得出度为0的节点，所有节点放入同一个队列或根据其权值将每个节点放入不同队列，然后从有向无环图中删除这些节点。

8.6重复子模块8.5直到有向无环图中没有节点，得到的m个队列即为下载策略。

8.7构造基于各节点安装时间的带权有向无环图，权值为各节点的安装时间。

8.8取得出度为0的节点，所有节点放入同一个队列或根据其权值将每个节点放入不同队列，然后从有向无环图中删除这些节点。

8.9重复8.8直到有向无环图中没有节点，得到的n个队列即为安装策略。

作为一种实施方式，针对每一个设备都存在以下步骤：（a）下载软件S

8.4基于各节点下载时间和安装时间构造有向无环图。

8.5 取得出度为0的节点，所有节点放入同一个队列（串行）或根据其权值将每个节点放入不同队列（并行），然后从有向无环图中删除这些节点。

8.6 重复8.5直到有向无环图中没有节点，得到的p个队列即为下载和安装策略。

9. ACS广播下载和安装策略至各个连接的BBU。若待升级设备包括EU，则相应BBU将下载和安装策略广播至指定的EU。若待升级设备包括RRU，则相应EU将下载和安装策略广播至指定的RRU。

10. 若待升级设备包括RRU，RRU返回应答至连接的EU。若待升级设备包括EU，EU返回应答至连接的BBU。BBU返回应答至连接的ACS。

11. ACS确认全部应答后，广播开始指令至BBU。若待升级设备包括EU，BBU广播开始指令至EU。若待升级设备包括RRU，EU广播开始指令至RRU。

12. 待升级设备按下载策略进行下载。下载的软件包包括一组压缩的文件以及元数据（如包名、版本号、设备类型）。

13. 校验各待升级设备是否下载成功。各待升级设备校验各自是否下载成功，若校验失败，则重新下载。若达到阈值后仍未通过，则提示错误，并停止本次升级。若校验成功，逐级返回信息至ACS，实时更新待升级设备状态。

14. 安装。通过下载校验后，各待升级设备按安装策略进行安装。

15. 校验各待升级设备是否安装成功。若校验失败，重新安装。若达到阈值后仍未通过，则提示错误，然后回滚至原始版本，并停止本次升级。若校验成功，逐级返回信息至ACS，实时更新待升级设备状态。

16. 激活。完成安装后，各设备激活所下载的升级版本。

17. 校验各待升级设备是否激活成功。若校验失败，则重新激活。若达到阈值后仍未通过，则提示错误，并停止本次升级。若校验成功，逐级返回信息至ACS，实时更新待升级设备状态。

18. 重启。完成激活后，重启待升级设备。

作为一种实施方式，分布式基站升级处理方法还包括以下步骤：

19. 校验各待升级设备是否重启成功。若校验失败，则重新重启。若达到阈值后仍未通过，则提示错误，并停止本次升级。若校验成功，逐级返回信息至ACS，实时更新待升级设备状态。

20. 完成升级。将各待升级设备升级日志逐级汇总至ACS。

21. 基于本次升级的日志更新设备升级知识库。

1.本发明建立智能升级ACS，增加升级前智能检测设备状态、设备固件版本可视化展示、设备拓扑可视化展示、升级时状态/进度展示、升级异常自动收集/展示、失败经验库建立、失败原因搜索引擎、智能升级大数据分析系统，减少人工干预，节省系统运维成本。

2.本发明升级前预检查，根据升级任务中设备的版本，拓扑连接关系，搜集设备的运行情况，链路带宽信息，设备CPU利用率及内存情况，校验本次升级是否存在基础问题，并提示如何解决。避免在升级后遇到环境问题再解决，提高效率。

3.本发明的设备升级信息自动搜集，存储到设备升级信息数据库中，并提供失败原因搜索引擎，使得失败定位不需要经验丰富的运维人员。

4.本发明通过对升级成功信息、失败信息的大数据分析与训练，建立智能升级失败问题定位，逐渐替代人工定位，直至自动定位，自动重新升级设备，完全替代运维人员。

5.本发明根据登录的不同用户，展示其所负责区域设备与拓扑连接图，让其可以直观选择需要升级的设备，创建升级任务来升级设备，减少运维人员定位升级设备的时间。

6. 本发明升级时展示升级任务中各设备的升级状态信息，通过实时获取升级过程的状态与异常，将详细信息展示到升级任务的拓扑图上，让用户实时了解最新的升级进展情况，包括升级进度，升级版本，硬件信息，软件信息，升级时长，剩余时长等，便于运维人员同步升级多个设备。

本发明实施例的分布式基站升级处理系统，包括：

模块1：ACS检测软件发布服务器是否发布新版本的软件，若是，则下载软件至ACS；

模块2：ACS校验下载软件的签名是否正确，若签名不正确，则提示错误，并停止本次升级；若正确，则进入模块3；

模块3：ACS测试所下载的软件，若测试通过则进入模块4，若测试未通过，则从软件发布服务器再次下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；

模块4：ACS生成升级任务；

模块5：ACS更新待升级设备的运行情况、链路带宽信息、设备CPU利用率及内存情况；其中，若存在问题，则提示错误，并停止本次升级；

模块6：ACS采集设备拓扑和软件依赖；

模块7：ACS生成待升级列表和下载源列表，其中，待升级列表包括本次升级各设备需要升级的软件及其相关信息，按软件间依赖排序；下载源列表包括各设备可以下载某个软件的源；

模块8：ACS根据所采集的信息制定下载和安装策略，该下载和安装策略满足以下约束：（a）各软件的依赖关系决定的安装顺序；（b）网络拓扑；（c）ACS、BBU、EU仅在拥有完整的软件后才能进行软件转发；（d）单位时间内，一个设备仅能进行一个下载动作；（e）不得超过预计的总时间；

模块9：ACS广播下载和安装策略至各个连接的BBU；若待升级设备包括EU，则相应BBU将下载和安装策略广播至指定的EU；若待升级设备包括RRU，则相应EU将下载和安装策略广播至指定的RRU；

模块10：ACS接收BBU返回的应答，若待升级设备包括RRU，RRU返回应答至连接的EU；若待升级设备包括EU，EU返回应答至连接的BBU；

模块11：ACS确认全部应答后，广播开始指令至BBU；若待升级设备包括EU，BBU广播开始指令至EU；若待升级设备包括RRU，EU广播开始指令至RRU；

模块12：待升级设备按下载策略进行下载，下载的软件包包括一组压缩的文件以及元数据；

模块13：校验各待升级设备是否下载成功，若校验失败，则重新下载；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块14：通过下载校验后，各待升级设备按安装策略进行安装；

模块15：校验各待升级设备是否安装成功；若校验失败，重新安装；若达到阈值后仍未通过，则提示错误，然后回滚至原始版本，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块16：完成安装后，各设备激活所下载的版本；

模块17：校验各待升级设备是否激活成功，若校验失败，则重新激活；若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块18：完成激活后，重启待升级设备。

作为一种实施方式，分布式基站升级处理系统还包括：

模块19：校验各待升级设备是否重启成功，若校验失败，则重新重启，若达到阈值后仍未通过，则提示错误，并停止本次升级；若校验成功，逐级返回信息至ACS，实时更新待升级设备状态；

模块20：完成升级后，将各待升级设备升级日志逐级汇总至ACS；

模块21：基于本次升级的日志更新设备升级知识库。

作为一种实施方式，模块8包括以下子模块：

8.1：得到从ACS节点到各个BBU节点的下载时间{DT

8.2：得到从各个BBU节点到各个EU节点的下载时间{DT

8.3：得到从各个EU节点到各个RRU节点的下载时间{DT

8.4：构造基于各节点下载时间的带权有向无环图，权值为各节点的下载时间；

8.5：取得出度为0的节点，所有节点放入同一个队列或根据其权值将每个节点放入不同队列，然后从有向无环图中删除这些节点；

8.6：重复子模块8.5直到有向无环图中没有节点，得到的m个队列即为下载策略。

作为一种实施方式，模块8包括以下子模块：

8.7：构造基于各节点安装时间的带权有向无环图，权值为各节点的安装时间；

8.8：取得出度为0的节点，所有节点放入同一个队列或根据其权值将每个节点放入不同队列，然后从有向无环图中删除这些节点；

8.9：重复子模块8.8直到有向无环图中没有节点，得到的n个队列即为安装策略。

下面结合附图4和对本发明的界面进行详细介绍：

该功能模块界面包含：任务列表区，任务拓扑区，以及对应的任务管理区。

任务列表区：展示用户创建的所有升级任务实例。

任务拓扑区：展示升级任务对应的设备拓扑及其关联关系，并对其在升级过程的情况通过关系图展示给用户。其中升级按钮是控制整个任务的升级开关。

任务管理区：包含升级总体概况，升级预检查，升级策略，告警，升级异常信息。

1. 升级总体概况：展示目前升级任务的整体情况，包括整体状态，升级开始时间，升级结束时间，升级设备信息(BBU/EU/RU的个数，各设备的升级阶段，原始版本，当前版本，目标版本)。具体见图5：

2. 升级预检查：升级设备之前，对升级任务中的设备进行检测，包括：

版本信息检查：是否当前版本与目标版本允许升级。

升级链路检查：检查升级设备中连接链路是否满足升级要求。

设备状态检查：检查升级的设备运行状态是否正常。

内存检查：检查升级设备运行内存空间是否满足升级要求。

CPU利用率检查：检查升级设备的CPU利用率是否满足升级要求。

如果上述情况均正常，检查结果显示正常，部分检查项目异常时，该检查项目与整体检查结果均显示异常。将对应的异常信息显示出来。具体见图6。

升级预检查中的检查项目，由系统综合分析升级经验，将升级过程遇到的主要升级异常点整理出来，作为升级前主要的检查项目，加入到升级预检查模块，提早发现升级问题，提高升级成功率。检查后如果出现检查结果异常，在处理建议中给出异常信息点，并提出对异常信息的处理意见。

3. 升级策略：包含总策略及子策略。

总策略：升级开始时间，配置升级设备的开始时间。

智慧模式：开/关。当设置为开时，升级系统会基于升级大数据进行分析，当升级失败时，自动定位分析失败原因，执行解决方案。当设置为关时，初始化失败重试次数，下载失败重试次数，安装失败重试次数，激活失败重试次数，重启失败重试次数，失败回滚开关以及子策略有效。

初始化失败重试次数：在初始化失败时，执行重试的次数。

下载失败重试次数：在下载软件包失败时，执行重试的次数。

安装失败重试次数：在安装软件包失败时，执行重试的次数。

激活失败重试次数：在激活软件版本失败时，执行重试的次数。

重启失败重试次数：在重启设备失败时，执行重试的次数。

失败回滚开关：开/关。当开启时，最终失败会执行回滚。

子策略：通过新增按钮，用户可以基于升级经验库的失败案例，新增对应失败阶段和关键失败信息对应的解决方案，增加解决方法。删除按钮删除对应的子策略。具体见图7。

4. 升级日志：记录升级过程产生的日志信息，基于设备类型（包含BBU/EU/RRU），设备序列号，上报时间，日志阶段（包含初始化，下载，安装，激活，重启5个阶段），日志详情（通过点击查看按钮查看详情），以列表的形式展示，并提供基于设备关键字信息进行查找分析，便于人工介入时进行定位。见图8：

5. 升级经验库：升级经验库根据升级设备时各升级阶段异常信息进行搜集，将其存储到后台数据库中，便于后续升级失败时进行参考。经验库的信息可以通过手动方式录入，也可以由设备自主学习，设备在升级失败时，将升级阶段，升级异常关键信息上传（智慧升级系统对升级阶段，异常关键信息以Hash方式找出数据库中的记录，如果不存在则新增，如果存在则进一步判断异常信息字符是否与已经存储的记录类似，如果类似则放弃存储，否则存储进经验库中），当人为解决了该异常点后，则更新经验库中该条记录的处理方案，为后续升级失败给出指导作用或直接参考该解决方案解决。见图9：

搜索：通过输入关键字，搜索异常情况下的处理方案。

新增：点击按钮后，弹出对话框输入异常阶段、异常介绍和处理方案。

删除：点击每条子标题，点击删除，弹出确认窗体后，删除掉该处理记录。

保存：修改上图右侧框中的文本，点击保存后，完成对修改内容的更新。

本发明通过建立升级处理系统，提供了设备升级可视化系统、设备拓扑管理系统、智能升级失败原因搜索引擎、智能升级大数据分析系统，逐步将分布式基站从人工经验式升级过渡到可视化傻瓜式升级，再提升到智能升级。在过程中，通过建立的智能升级大数据分析系统，收集、处理、分析升级过程中产品的问题，产品的实时状态，异常信息搜集等数据综合到一起，形成设备升级经验库和大数据分析训练库，通过大数据分析系统，对设备升级失败做到自动、智能的处理，而不再需要人工干预。

尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同范围限定。