CN111200509A - 告警处理方法及相关装置 - Google Patents

Abstract

本申请提供一种告警处理方法及相关装置，其中，所述方法包括：获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示基础设施层中的第一硬件发生故障；根据配置信息，确定第一硬件承载的第一业务；其中，第一业务为逻辑网元上的业务；对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，第一业务告警信息用于指示所述第一业务发生故障。本申请提供的技术方案能够提高维护人员处理告警的效率。

Description

告警处理方法及相关装置

技术领域

本申请涉及云技术领域，特别涉及告警处理方法及相关装置。

背景技术

随着云技术的不断发展，云技术在各行业的应用越来越广泛。图1为一种应用云技术的系统架构的示意图。如图1所示，该系统可以包括基础设施层和业务层，其中，基础设施层用于提供运行业务层中的各种业务的硬件资源。

应用故障管理系统可以对云系统进行维护。故障管理系统中可以接收云系统中的业务故障告警和硬件故障告警，云系统的维护人员可以通过故障管理系统对云系统中的故障进行定位和处理。

当基础设施中的硬件发生故障时，该硬件承载的业务也会发生故障，由于维护人员通常需要先处理优先级较高的业务故障告警，而业务故障告警的定位信息中没有包含发生故障的硬件的信息，导致告警维护工作的效率较低。

发明内容

本申请提供了告警处理方法及相关装置，用于解决告警维护工作的效率较低的问题。

第一方面，本申请提供一种告警处理方法，首先获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示基础设施层中的第一硬件发生故障；然后根据配置信息，确定第一硬件承载的第一业务；其中，第一业务为逻辑网元上的业务，配置信息包括逻辑网元上的业务与基础设施层中承载业务的硬件之间的对应关系。之后，对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，第一业务告警信息用于指示逻辑网元上的第一业务发生故障。采用这种方式，能够在业务告警是由于硬件告警产生时，避免硬件告警淹没在业务告警中，从而使得维护人员能够直接查看硬件故障告警，对故障产生的根本原因进行快速定位，提高告警维护工作的效率。

在一种可能的实现方式中，上述对EMS上的第一业务告警进行屏蔽处理包括：将第一业务告警的告警状态设置为已恢复，此外，还可以将第一业务告警的故障恢复原因设置为相关性恢复。

在一种可能的实现方式中，在对第一业务告警进行屏蔽处理后，获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；若在预设时间内，获取到逻辑网元发送给EMS的第二业务告警信息，其中，第二业务告警信息用于指示第一业务已恢复；可以将第一业务告警的告警状态的故障恢复原因设置为正常恢复。

在一种可能的实现方式中，在对第一业务告警进行屏蔽处理后，获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；若在预设时间内，未获取到逻辑网元发送给EMS的第二业务告警信息，第二业务告警信息用于指示第一业务已恢复；可以将第一业务告警的告警状态设置为激活。

在一种可能的实现方式中，第一业务为逻辑网元的实时业务，第一硬件属于基础设施层的分布式部署单元DU；获取基础设施层发送给EMS的第一硬件告警信息可以为获取DU发送给EMS的第一硬件告警信息，第一硬件告警信息用于指示DU中的第一硬件发生故障。

在一种可能的实现方式中，逻辑网元可以为云化无线接入网中的基站；第一业务为基站中的逻辑小区或本地小区，第一硬件为DU1中的基带处理单元或者射频发射单元；或者，第一业务为基站中的F1链路，第一硬件为DU1上的主控板或者主控板上的光口。配置信息包括逻辑网元上的实时业务与DU上承载实时业务的硬件之间的对应关系。

第二方面，本申请提供一种告警处理装置，包括：

获取模块，用于获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示基础设施层中的第一硬件发生故障；

确定模块，用于根据配置信息，确定第一硬件承载的第一业务；其中，第一业务为逻辑网元上的业务；

处理模块，用于对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，第一业务告警信息用于指示第一业务发生故障。

在一种可能的实现方式中，处理模块，具体用于将第一业务告警的告警状态设置为已恢复；以及，用于将第一业务告警的故障恢复原因设置为相关性恢复。

在一种可能的实现方式中，获取模块，还用于获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；以及，还用于在预设时间内，获取到逻辑网元发送给EMS的第二业务告警信息，第二业务告警信息用于指示第一业务已恢复；处理模块，还用于将第一业务告警的告警状态的故障恢复原因设置为正常恢复。

在一种可能的实现方式中，获取模块，还用于获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；处理模块，还用于在预设时间内，获取模块未获取到逻辑网元发送给EMS的第二业务告警信息时，将第一业务告警的告警状态设置为激活，第二业务告警信息用于指示第一业务已恢复。

在一种可能的实现方式中，第一业务为逻辑网元的实时业务，第一硬件属于基础设施层的分布式部署单元DU；获取模块，具体用于获取DU发送给EMS的第一硬件告警信息，第一硬件告警信息用于指示DU中的第一硬件发生故障。

第三方面，本申请提供一种告警处理装置，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上述第一方面中的告警处理方法。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有指令，当指令在计算机上运行时，用于执行上述第一方面中的告警处理方法。

第五方面，本申请提供一种计算机程序，当计算机程序被计算机执行时，用于执行上述第一方面中的告警处理方法。

附图说明

图1为一种应用云技术的系统架构的示意图；

图2为一种云化无线接入网的架构的示意图；

图3为一种下一代无线网络的逻辑架构的示意图；

图4为EMS与云化无线接入网的连接关系的示意图；

图5为EMS上的告警界面的示意图；

图6A为本申请提供的告警处理方法涉及的网络架构的示意图；

图6B为本申请提供的告警处理方法的流程图；

图7为本申请提供的告警处理方法的交互流程示意图一；

图8为本申请提供的告警处理方法的交互流程示意图二；

图9为本申请提供的告警处理装置的结构示意图一；

图10为本申请提供的告警处理装置的结构示意图二。

具体实施方式

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。

随着通信技术的不断演进，云技术在通信领域的应用也越来越深，通信网络架构中的网元和功能逐渐演变为采用基于云技术的体系架构来部署。举例来说，采用云技术部署的无线接入网可以称为云化无线接入网。

图2为一种云化无线接入网的架构的示意图。如图2所示，用于承载云化无线接入网的基础设施层包括：集中部署单元(Centralized Unit，CU)和分布式部署单元(Distributed Unit，DU)。其中，CU上承载的业务可以有内容缓存(Cache)、网关(Gateway，GW)、应用(Application，APP)、非实时业务(RAN-Non Real Time)，DU上承载的业务可以为各种宏站(Macro)、微站(Micro)、皮站(Pico)、云化基带板(Cloud BB)、射频发射单元(RRU)、有源天线(Active antenna unit，AAU)等涉及的实时业务(RAN-Real Time)。CU的硬件可以为商用货架产品(Commercial off-the-shelf，COTS)硬件，DU的硬件可以为专有硬件。需要说明的是，承载实时业务的专有硬件可以包括：LTE网络或者5G网络中的宏站(Macro)、微站(Micro)、皮站(Pico)、云化基带板(Cloud BB)、射频发射单元(RRU)、有源天线(Active antenna unit，AAU)等。在本申请中，CU的数量可以为1个，DU的数量可以为多个。

随着专有硬件的不断发展，基础设施层能够支持承载LTE网络的基站(envolvedNodeB，eNB)、下一代无线网络的基站(5G NodeB，gNB)等多种逻辑网元的多种业务。

图3为一种下一代无线网络的逻辑架构的示意图。如图3所示，下一代无线网络中可以包括：第5代核心网(5th Generation Core Network，5GC)和下一代无线接入网(NextGeneration Radio Access Network，NG-RAN)，其中，NR-RAN也可以称为5G无线接入网。NR-RAN与5GC之间的接口可以称为NG接口。NG-RAN中的基站可以称为5G基站。5G基站上的业务可以包括实时业务(RAN-Real time)和非实时业务(RAN-Non Real time)。负责处理5G基站中的非实时业务的逻辑单元可以称为5G基站集中单元(gNB Central Unit,gNB-CU)，负责处理5G基站中的实时业务的逻辑单元可以称为5G基站分布式单元(gNB DistributedUnit,gNB-DU)。gNB-CU与gNB-DU之间的接口可以称为F1接口，不同gNB之间的接口可以称为Xn接口。

为了对基础设施层中的硬件资源和业务层运行的业务进行维护管理，可以设置网元管理系统(Element Management System，EMS)来管理基础设施层中的CU和DU上报的硬件故障告警和各个逻辑网元上报的业务故障告警。

图4为EMS与云化无线接入网的连接关系的示意图。如图4所示，云化无线接入网中的基础设施层可以包括CU、DU1和DU2，基础设施层上承载的逻辑网元可以包括gNB和eNB。EMS提供南向接口(Southbound Interface，SBI)，用以接收CU、DU1、DU2上报的硬件告警信息，以及gNB、eNB上报的业务告警信息。硬件告警信息中携带发生故障的硬件的标识、定位信息、处理建议等信息。业务告警信息中可以携带发生故障的业务的标识、定位信息、处理建议等信息。

需要说明的是，负责处理gNB的非实时业务的逻辑单元gNB-CU承载于CU上，负责处理gNB的实时业务的逻辑单元gNB-DU1和gNB-DU2分别承载于DU1和DU2上，gNB-CU可以分别与gNB-DU1和gNB-DU2连接，gNB-CU、gNB-DU1、gNB-DU2上的业务告警信息通过gNB-CU与EMS之间的SBI接口上报至EMS。类似地，负责处理eNB的非实时业务的逻辑单元eNB-CU承载于CU上，负责处理eNB的实时业务的逻辑单元eNB-DU1和eNB-DU2分别承载于DU1和DU2上，eNB-CU可以分别与eNB-DU1和eNB-DU2连接。eNB-CU、eNB-DU1、eNB-DU2上的业务告警信息通过eNB-CU与EMS之间的SBI接口上报至EMS。

图5为EMS上的告警界面的示意图。EMS可以根据接收到的业务告警信息或硬件告警信息，在告警界面显示一条业务告警或硬件告警。

当CU或者任一DU中的硬件发生故障时，若基础设施层不能及时分配新的硬件，承载于该硬件的业务也会发生故障。例如，发生故障的硬件为DU1上的第一硬件，承载于该第一硬件的业务为逻辑网元的第一业务，则EMS接收到DU1上报的第一硬件告警信息，以及，逻辑网元上报的第一业务告警信息，EMS根据第一硬件告警信息中携带的故障对象等信息在告警界面上显示第一硬件告警，同时，根据第一业务告警信息中携带的故障对象等信息在告警界面上显示第一业务告警。EMS可以设置提示音或者提示消息通知维护人员查看告警界面上的告警。在实际工作中，维护人员通常会先查看业务类的告警，但是，业务发生故障实际是由于基础设施层中的硬件发生故障而导致的，维护人员查看业务故障告警并不能定位业务故障告警产生的原因，还需要继续查看硬件故障告警或者通过其他维护命令定位业务故障发生的根本原因，这导致维护人员的工作效率的降低。

需要说明的是，基于云架构的分离特点，逻辑网元以及逻辑网元中的业务通常不能直接感知基础设施层中的硬件的运行状态，基础设施层通常也不能感知逻辑网元上的业务的运行状态。在某些场景中，基础设施层甚至被要求不能获知所分配的硬件具体承载的业务的标识。云架构中的这种架构分离的管理方式，也被称为松耦合。

为了提升维护人员的工作效率，在一种告警处理方法中，逻辑网元被允许完全清楚所部署的DU上的硬件，这相当于是逻辑网元或者逻辑网元上负责处理实时业务处理部分的逻辑单元，如gNB-DU，与DU上的硬件采取了一种紧耦合的架构管理方式，基于这种紧耦合的架构管理方式，在逻辑网元或者逻辑网元上的实时业务处理部分中的业务发生故障或者受损时，可以定位到所依赖的硬件，逻辑网元可以检查DU中的硬件的状态，并在上报给EMS的业务告警信息中携带DU上的硬件的故障信息。举例来说，gNB中的gNB-DU可以安装与DU1中的硬件相匹配的适配软件，当gNB-DU中的业务发生故障时，查询配置信息，获取该业务所承载的硬件，并利用适配软件与该硬件所属的DU1进行通信，查询该硬件的运行状态是否正常，若该硬件的运行状态为故障，则逻辑网元gNB可以将该硬件的运行状态为故障作为定位信息添加到业务故障告警信息中，上报给EMS。

但是，由于DU中的硬件的种类非常多，各种硬件的形态不断演进，且适配软件的版本也需要随之不断更新，如果逻辑网元没有及时安装新的适配软件，就不能在业务告警信息中添加所承载的硬件的运行状态，在这种情况下，维护人员处理故障的效率仍然会降低。

为解决上述技术问题，本申请提供一种告警处理方法，当业务告警是由于业务所承载的硬件发生故障产生时，保留EMS上的硬件告警，同时，屏蔽存在承载关联的业务告警，从而可以提高维护人员的工作效率。

下面对本申请提供的告警处理方法进行举例描述。

图6A为本申请提供的告警处理方法涉及的网络架构的示意图。

本申请实施例的执行主体可以为故障服务(Fault Service，FS)装置，其中，FS与CU、多个DU、各个逻辑网元以及EMS之间可以存在通信连接。如图6A所示的示例，FS可以与CU、DU1、DU2、gNB-CU1、eNB-CU1、EMS存在通信连接。FS可以通过订阅的方式监测CU、各个DU以及各个逻辑网元准备向EMS上报的告警信息。

在本申请中，FS可以为EMS上的组件，也可以独立于EMS设置。在本申请实施例中，EMS可以为独立于CU和DU的服务器，或者，EMS可以为承载于CU的应用。在一示例中，当FS独立于EMS设置时，FS可以是承载于CU上的应用。

图6B为本申请提供的告警处理方法的流程图。如图6B所示，本申请实施例可以包括以下步骤：

S601，获取基础设施层发送给EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示基础设施层中的第一硬件发生故障。

在本申请实施例中，示例性地，逻辑网元可以为云化无线接入网中的基站，如gNB、eNB；第一硬件可以为DU1、DU2中硬件，如基带处理单元、射频发射单元、主控板或者主控板上的光口等。

在本申请实施例中，第一硬件告警信息可以包括告警时间、告警对象、所属DU标识等。

S602，根据配置信息，确定第一硬件承载的第一业务，其中，第一业务为逻辑网元上的业务。

在本申请实施例中，配置信息可以包括逻辑网元上的业务与DU上承载业务的硬件之间的对应关系。表1为配置信息的一种示意。将第一硬件的硬件标识作为输入，可以从配置信息中查询到承载于该硬件上的第一业务的业务标识。

表1

如表1所示，在一示例中，第一硬件的硬件标识可以为BBP_ID1或者RRU_ID1，该第一硬件上承载的第一业务的业务标识为逻辑小区LCell1，在又一示例中，第一硬件的硬件标识可以为主控板MPU_ID1或者MPU_ID1上的光口，该第一硬件上承载的第一业务的业务标识为F1_ID1。

在本申请实施例中，配置信息可以存储于FS上。配置信息可以是在逻辑网元向基础设施层申请承载业务的硬件资源时生成的。

S603，对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，第一业务告警信息用于指示第一业务发生故障。

在本申请实施例中，上述对EMS上的第一业务告警进行屏蔽处理的步骤，可以采用以下方式实施。

在一示例中，可以将第一业务告警的告警状态设置为已恢复；此外，还可以将第一业务告警的故障恢复原因设置为相关性恢复。采用这种方式，硬件告警就不会被业务告警淹没，维护人员在告警界面查看告警时，可以直接查看硬件告警，进而提升告警维护工作的效率。

在另一示例中，可以将第一硬件告警信息中的第一硬件，添加到第一业务告警的定位信息中。采用这种方式，维护人员无论查看业务告警时，可以直接根据定位信息确定业务告警产生的根本原因，也能够提升告警维护工作的效率。

在再一示例中，也可以同时采用上述两种实施方式的组合，本申请对此不做限制。

在本申请实施例中，上述将第一业务告警的告警状态设置为已恢复可以采用以下方式实施。若FS独立于EMS设置，则FS可以通过生成一条用于指示第一业务已恢复的业务告警信息，以使EMS将第一业务告警的告警状态设置为已恢复。若FS为EMS中的组件，则FS可以直接设置第一业务告警的告警状态为已恢复。

在本申请中，通过获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示所述基础设施层中的第一硬件发生故障；根据配置信息，确定第一硬件承载的第一业务；对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，所述第一业务告警信息用于指示所述逻辑网元上的所述第一业务发生故障，维护人员能够直接查看硬件故障告警，从而能够提升告警维护工作的效率。此外，采用本申请提供的告警处理方法，逻辑网元可以不需要安装与各种DU硬件相适配的适配软件，进而不需要持续更新与不同DU硬件的版本相适配的适配软件，就可以使得维护人员能够快速定位和处理告警，保证告警维护工作的工作效率。另外，这种处理方式不需要修改EMS与基础设施层、业务层之间的已有接口。

下面以第一业务为逻辑小区，第一硬件为承载逻辑小区的基带处理单元(BaseBand Process，BBP)和射频发射单元(Radio Remote Unit，RRU)为例，对本申请提供的告警处理方法的交互流程进行示例性说明。

图7为本申请提供的告警处理方法的交互流程示意图一。本申请实施例涉及逻辑网元gNB、DU1、EMS和FS。示例性地，逻辑小区可以为本地小区(Cell)或者物理小区(LCell)。以第一业务为逻辑网元gNB的LCell1为例，本申请实施例可以包括以下步骤。

S701，gNB向基础设施层请求部署LCell1的硬件资源。

其中，在一示例中，gNB可以向基础设施层的管理模块请求部署LCell1的硬件资源。硬件资源也可以称为物理资源。需要说明的是，图中未示出基础设施层及基础设施层的管理模块。

S702，DU1接收基础设施层的指示，分配承载LCell1的硬件资源。

其中，举例来说，DU1中的BBP1和RRU1可以承载LCell1。

S703，DU1向gNB发送承载LCell1的硬件资源的标识{BBP_ID1，RRU_ID1}。

其中，DU1发送的硬件资源的标识可以为实际的硬件资源ID，也可以是逻辑硬件资源ID，例如，BBP1和RRU1为实际硬件资源ID，BBP1的逻辑硬件资源ID为BBP_ID1，RRU1的逻辑硬件资源ID为RRU_ID1。此处以DU1向gNB发送的硬件资源的标识为逻辑硬件资源ID为例。需要说明的是，上报逻辑硬件资源ID可以便于基础设施层在硬件发生故障时及时替换新的硬件，举例来说，当逻辑硬件资源ID对应的实际硬件资源发生故障时，基础设施层可以调配其他的实际硬件资源替代原来的实际硬件资源，作为替代的实际硬件资源将使用原有的逻辑硬件资源ID。下面以DU1上报的硬件资源的标识为逻辑硬件资源ID为例进行说明。

S704，gNB将承载LCell1的硬件资源的标识与LCell1的对应关系添加到配置信息中。

其中，gNB的配置信息可以如表1所示。

S705，FS向gNB发送业务告警订阅请求。

其中，业务告警订阅请求用于指示gNB在向EMS上报业务告警信息的同时，向FS发送相同的业务告警信息。需要说明的是，该步骤可以在逻辑网元gNB初始建立的时候执行。

S706，FS向DU1发送硬件告警订阅请求。

其中，硬件告警订阅请求用于指示DU1在向EMS上报硬件告警信息的同时，向FS发送相同的硬件告警信息。需要说明的是，该步骤可以在DU1初始启用的时候执行。

S707，DU1检测到标识为BBP_ID1的硬件资源发生故障。

其中，需要说明的是，若承载LCell1的RRU1发生故障，也会导致LCell1发生故障，此处以BBP1发生故障为例进行说明。

S708，DU1向EMS上报故障对象为BBP_ID1的第一硬件告警信息。

S709，DU1向FS发送故障对象为BBP_ID1的第一硬件告警信息。

S710，gNB检测到LCell1发生故障。

S711，gNB向EMS上报故障对象为LCell1的第一业务告警信息。

S712，gNB向FS发送故障对象为LCell1的第一业务告警信息。

S713，EMS根据第一硬件告警信息，在告警界面显示第一硬件告警。

其中，步骤S713可以在步骤S708之后执行，也可以在步骤S709、S711之前执行。

S714，EMS根据第一业务告警信息，在告警界面显示第一业务告警。

其中，步骤S714可以在步骤S711之后执行，也可以在步骤S712之前执行。

S715，FS查询配置信息，获取BBP_ID1上承载的业务包括LCell1。

S716，FS向EMS发送相关性恢复告警信息，指示EMS将LCell1相关的第一业务告警的告警状态设置为已恢复。

其中，恢复原因可以设置为相关性恢复。相关性恢复的含义为，业务告警设置为已恢复的原因是该业务告警产生的原因是由于基础设施层中承载该业务的硬件发生故障所引起的。之后，FS还可以记录发送过的相关性恢复告警信息。即，记录那些业务故障告警是基于硬件发生故障的原因被暂时设置为已恢复的。

S717，EMS设置告警界面上的第一业务告警的告警状态为已恢复，恢复原因为相关性恢复。

其中，故障对象为LCell1的第一业务告警由于标识为BBP_ID1的硬件故障而暂时设置为已恢复。

在本申请实施例中，EMS的告警界面中未恢复的告警只剩下第一硬件告警信息。维护人员可以快速进行问题定位。

在本申请中，若硬件故障恢复，在步骤S717之后，还可以包括步骤S718至S721：

S718，DU1检测到标识为BBP_ID1的硬件资源的故障已经恢复。

S719，DU1向EMS上报故障恢复对象为BBP_ID1的第二硬件告警信息。

S720，DU1向FS发送故障恢复对象为BBP_ID1的第二硬件告警信息。

S721，EMS设置告警界面上的第一硬件告警的告警状态为已恢复。

其中，步骤S721可以在步骤S719之后执行。

在本申请的一示例中，在步骤S721之后，还可以包括步骤S722至S726：

S722，gNB检测到LCell1的故障已经恢复。

S723，gNB向EMS上报故障恢复对象为LCell1的第二业务告警信息。

S724，gNB向FS发送故障恢复对象为LCell1的第二业务告警信息。

S725，EMS设置告警界面上的第一业务告警的告警状态为已恢复，恢复原因为正常恢复。

S726，FS通知EMS删除第一业务告警。

其中，步骤S726不是必须执行的步骤。

在本申请的一示例中，若gNB在预设时间内未检测到LCell1的故障已经恢复，在步骤S721之后，还可以包括步骤S727至S729：

S727，FS在预设时间内未接收gNB发送的故障恢复对象为LCell1的第二业务告警信息。

S728，FS向EMS发送相关性激活告警信息，指示EMS将LCell1相关的第一业务告警的告警状态设置为未恢复。

其中，在一示例中，FS可以查询配置信息，确定标识为BBP_ID1的硬件资源上承载的业务为LCell1，然后确定需要重新激活的业务告警。或者，在另一示例中，FS可以根据在发送相关性恢复告警信息时的记录，确定需要重新激活的业务告警。

S729，EMS设置告警界面上的第一业务告警的告警状态为未恢复，故障原因为相关性激活。

其中，相关性激活的含义为，业务告警设置为未恢复的原因是该业务告警是伴随基础设施层中承载该业务的硬件发生故障产生的，目前承载该业务的硬件的已经恢复，但业务的故障尚未恢复。如，LCell1告警的故障原因为由于BBP_ID1故障已恢复而激活。还需要说明的是，S727至S729不是本申请实施例必须执行的步骤。

在本申请中，如果硬件故障恢复之后，业务故障并没有随之恢复，说明业务故障的产生可能还有其他原因，此时，激活业务告警，可以提醒维护人员及时处理业务告警。在步骤S729之后，如果gNB检测到LCell1的故障已经恢复，则在步骤S729之后，还可以包括步骤S722至S726，此处不再赘述。

本申请实施例还提供一种告警处理方法。前述实施例中的逻辑网元上的业务还可以是gNB-CU与gNB-DU1之间的F1链路，对于gNB-DU1一侧来说，承载F1链路的硬件资源可以是DU1的主控板MPU上的光口，对于gNB-CU一侧来说，承载F1链路的硬件资源可以是CU上的光口。下面以第一业务为F1链路，第一硬件为承载F1链路的MPU上的光口为例，对本申请提供的告警处理方法的交互流程进行示例性说明。

图8为本申请提供的告警处理方法的交互流程示意图二。本申请实施例涉及gNB、DU1、FS和EMS。如图8所示，本申请实施例可以包括以下步骤。

S801，gNB向基础设施层请求部署F1_ID1的硬件资源。

其中，F1_ID1为gNB-CU与gNB-DU1之间的F1链路。gNB可以向基础设施层的管理模块请求部署F1_ID1的硬件资源，基础设施层的管理模块可以指示CU和DU1分别分配gNB-CU1一侧和gNB-DU1一侧承载F1_ID1的硬件资源。

S802，DU1接收基础设施层的指示，分配gNB-DU1一侧承载F1_ID1的硬件资源。

其中，gNB-DU1一侧承载F1_ID1的硬件资源可以为MPU1上的光口ITF1。

S803，DU1向gNB发送gNB-DU1一侧承载F1_ID1的硬件资源的标识{MPU_ID1，ITF_ID1}。

其中，DU1发送的硬件资源的标识可以为实际的硬件资源ID，也可以是逻辑硬件资源ID，例如，MPU1的逻辑硬件资源ID为MPU_ID1，MPU1上的光口ITF1的逻辑硬件资源ID为ITF_ID1。此处以逻辑资源ID为例进行说明。

S804，gNB将承载F1链路的硬件资源的标识与F1链路的对应关系添加到配置信息中。

其中，gNB的配置信息可以如表1所示。

S805，FS向gNB发送业务告警订阅请求。

其中，该步骤与S705类似。

S806，FS向DU1发送硬件告警订阅请求。

其中，该步骤与S706类似。

S807，DU1检测到标识为{MPU_ID1，ITF_ID1}的硬件发生故障。

其中，需要说明的是，若承载F1_ID1的MPU发生故障，也会导致F1_ID1发生故障，此处仅以光口ITF_ID1发生故障为例进行说明。

S808，DU1向EMS上报故障对象为{MPU_ID1，ITF_ID1}的第一硬件告警信息。

S809，DU1向FS发送故障对象为{MPU_ID1，ITF_ID1}的第一硬件告警信息。

S810，gNB检测到F1链路F1_ID1发生故障。

其中，gNB-DU1和gNB-CU均可以检测到F1链路发生故障，若由gNB-DU1检测到F1_ID1发生故障，则gNB-DU1将故障情况发送给gNB-CU，由gNB-CU代表gNB上报故障对象为F1_ID1的业务告警信息。

S811，gNB向EMS上报故障对象为F1_ID1的第一业务告警信息。

S812，gNB向FS发送故障对象为F1_ID1的第一业务告警信息。

S813，EMS根据第一硬件告警信息，在告警界面显示第一硬件告警。

S814，EMS根据第一业务告警信息，在告警界面显示第一业务告警。

S815，FS查询配置信息，获取{MPU_ID1，ITF_ID1}上承载的业务包括F1_ID1。

S816，FS向EMS发送相关性恢复告警信息，指示EMS将F1_ID1相关的第一业务告警的告警状态设置为已恢复。

其中，恢复原因可以设置为相关性恢复。相关性恢复的含义为，业务告警设置为已恢复的原因是该业务告警产生的原因是由于基础设施层中承载该业务的硬件发生故障所引起的。之后，FS还可以记录发送过的相关性恢复告警信息。即，记录那些业务故障告警是基于硬件发生故障的原因被暂时设置为已恢复的。

S817，EMS设置告警界面上的第一业务告警的告警状态为已恢复，恢复原因为相关性恢复。

其中，故障对象为F1_ID1的第一业务告警由于标识为{MPU_ID1，ITF_ID1}的硬件故障而暂时设置为已恢复。

在本申请实施例中，EMS的告警界面中未恢复的告警只剩下第一硬件告警信息。维护人员可以快速进行问题定位。

在本申请中，若硬件故障恢复，在步骤S817之后，还可以包括步骤S818至S821：

S818，DU1检测到资源标识为{MPU_ID1，ITF_ID1}硬件的故障已经恢复。

S819，DU1向EMS上报故障恢复对象为{MPU_ID1，ITF_ID1}的第二硬件告警信息。

S820，DU1向FS发送故障恢复对象为{MPU_ID1，ITF_ID1}的第二硬件告警信息。

S821，EMS设置告警界面上的第一硬件告警的告警状态为已恢复。

在本申请中，在一示例中，在步骤S821之后，还可以包括步骤S822至S826：

S822，gNB检测到F1_ID1的故障已经恢复。

S823，gNB向EMS上报故障恢复对象为F1_ID1的第二业务告警信息。

S824，gNB向FS发送故障恢复对象为F1_ID1的第二业务告警信息。

S825，EMS设置告警界面上的第一业务告警的告警状态为已恢复，恢复原因为正常恢复。

S826，FS通知EMS删除第一业务告警。

其中，需要说明的是，S826不是必须执行的步骤，此外，第一业务告警完全是由于第一硬件故障产生的，即，在第一硬件的故障恢复后，第一业务的故障也随即恢复，因此，FS可以指示EMS删除第一业务告警。

在本申请中，在一示例中，若gNB在预设时间内未检测到F1_ID1的故障已经恢复，在步骤S821之后，还可以包括步骤S827至S829：

S827，FS在预设时间内未接收gNB发送的故障恢复对象为F1_ID1的第二业务告警信息。

S828，FS向EMS发送相关性激活告警信息，指示EMS将F1_ID1相关的第一业务告警的告警状态设置为未恢复。

其中，在一示例中，FS可以查询配置信息，确定标识为{MPU_ID1，ITF_ID1}的硬件资源上承载的业务为F1_ID1，然后确定需要重新激活的业务告警。或者，在另一示例中，FS可以根据在发送相关性恢复告警信息时的记录，确定需要重新激活的业务告警。

S829，EMS设置告警界面上的第一业务告警的告警状态为未恢复，故障原因为相关性激活。

需要说明的是，上述第一硬件还可以是CU中的硬件，第一业务可以是承载于CU中的硬件的业务，由于CU的硬件资源通常为通用型硬件资源且较为充足，即使出现硬件故障，承载于CU中的硬件的业务故障也很快就会恢复。但是，DU中的硬件资源通常为各种类型的专有硬件，且采用分布式部署，也就是说，类型相同的专有硬件的实际位置可能相聚较远，而不能马上替代故障的专有硬件，因此，DU中的硬件故障导致承载的业务发生故障的可能性要远大于CU中的硬件故障导致承载的业务发生故障的可能性。因此，本申请其他实施例中，FS可以仅针对DU中的硬件故障告警，实施对承载的业务相关的业务故障告警的屏蔽处理。

本申请实施例的其他技术效果和技术方案细节可参看本申请其他实施例中的描述。

本申请实施例还提供一种告警处理装置。图9为本申请提供的告警处理装置的结构示意图图一。如图9所示，本实施例的装置900可以包括：获取模块910，确定模块920和处理模块930。

获取模块910，用于获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，第一硬件告警信息用于指示基础设施层中的第一硬件发生故障；

确定模块920，用于根据配置信息，确定第一硬件承载的第一业务；其中，第一业务为逻辑网元上的业务；

处理模块930，用于对EMS上的第一业务告警进行屏蔽处理，其中，第一业务告警为根据逻辑网元发送给EMS的第一业务告警信息生成的，第一业务告警信息用于指示第一业务发生故障。

在一种可能的实现方式中，处理模块930，可以具体用于将第一业务告警的告警状态设置为已恢复；以及，用于将第一业务告警的故障恢复原因设置为相关性恢复。

在一种可能的实现方式中，获取模块910，还可以用于获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；以及，还用于在预设时间内，获取到逻辑网元发送给EMS的第二业务告警信息，第二业务告警信息用于指示第一业务已恢复；处理模块930，还可以用于将第一业务告警的告警状态的故障恢复原因设置为正常恢复。

在一种可能的实现方式中，获取模块910，还可以用于获取基础设施层发送给EMS的第二硬件告警信息，第二硬件告警信息用于指示第一硬件已恢复；处理模块930，还可以用于在预设时间内，获取模块未获取到逻辑网元发送给EMS的第二业务告警信息时，将第一业务告警的告警状态设置为激活，第二业务告警信息用于指示第一业务已恢复。

在一种可能的实现方式中，第一业务为逻辑网元的实时业务，第一硬件属于基础设施层的分布式部署单元DU；获取模块910，可以具体用于获取DU发送给EMS的第一硬件告警信息，第一硬件告警信息用于指示DU中的第一硬件发生故障。

本实施例的装置，可以用于执行图6A至图8所示方法实施例中FS装置执行的技术方案，其实现原理和技术效果类似，此处不再赘述。

本申请实施例还提供一种告警处理装置。图10为本申请提供的告警处理装置的结构示意图二。如图10所示，该装置1000包括处理器1010、存储器1020；装置1000中处理器1010的数量可以是一个或多个，图10中以一个处理器1010为例。此外，装置1000还可以包括接口1030和总线1040，装置1000中的处理器1010、存储器1020、接口1030可以通过总线或其他方式连接，图10中以通过总线连接为例。接口也可以称为收发器。

存储器1020作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本申请图6A至图8所示实施例中的方法对应的程序指令/模块。处理器1010通过运行存储在存储器1020中的软件程序、指令以及模块，从而执行图像处理设备的各种功能应用以及数据处理，即实现上述方法。

存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储上述方法实施例中涉及的数据等，如配置信息，告警信息等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器1020可进一步包括相对于处理器1010远程设置的存储器，这些远程存储器可以通过网络连接至告警处理设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

接口1030可用于与基础设施层中的CU、各个DU、逻辑网元以及EMS进行通信，用于订阅并获取上述实体或功能上的生成的告警信息，如业务告警信息、硬件告警信息，以及，用于向EMS发送与设置告警状态相关的告警信息，如设置告警的告警状态为未恢复或者已恢复，设置告警的恢复原因等。

在一种可能的实现方式中，本申请提供一种计算机可读存储介质，该计算机可读存储介质存储有指令，当该指令在计算机上运行时，用于执行上述图6A至图8任一所示的方法实施例。

在一种可能的实现方式中，本申请提供一种计算机程序，当所述计算机程序被计算机执行时，用于执行上述图6A至图8所示的方法实施例。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid StateDisk)等。

Claims (9)

1.一种告警处理方法，其特征在于，所述方法包括：

获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，所述第一硬件告警信息用于指示所述基础设施层中的第一硬件发生故障；

根据配置信息，确定所述第一硬件承载的第一业务；其中，所述第一业务为逻辑网元上的业务；

对所述EMS上的第一业务告警进行屏蔽处理，其中，所述第一业务告警为根据所述逻辑网元发送给所述EMS的第一业务告警信息生成的，所述第一业务告警信息用于指示所述第一业务发生故障。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述基础设施层发送给所述EMS的第二硬件告警信息，所述第二硬件告警信息用于指示所述第一硬件已恢复；

在预设时间内，获取到所述逻辑网元发送给所述EMS的第二业务告警信息，所述第二业务告警信息用于指示所述第一业务已恢复；

将所述第一业务告警的告警状态的故障恢复原因设置为正常恢复。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取所述基础设施层发送给所述EMS的第二硬件告警信息，所述第二硬件告警信息用于指示所述第一硬件已恢复；

在预设时间内，未获取到所述逻辑网元发送给所述EMS的第二业务告警信息，所述第二业务告警信息用于指示所述第一业务已恢复；

将所述第一业务告警的告警状态设置为激活。

4.根据权利要求1-3任一所述的方法，其特征在于，所述第一业务为所述逻辑网元的实时业务，所述第一硬件为所述基础设施层的分布式部署单元DU中的硬件；

所述获取基础设施层发送给EMS的第一硬件告警信息，包括：获取所述DU发送给所述EMS的所述第一硬件告警信息，所述第一硬件告警信息用于指示所述DU中的所述第一硬件发生故障。

5.一种告警处理装置，其特征在于，所述装置包括：

获取模块，用于获取基础设施层发送给网元管理系统EMS的第一硬件告警信息，其中，所述第一硬件告警信息用于指示所述基础设施层中的第一硬件发生故障；

确定模块，用于根据配置信息，确定所述第一硬件承载的第一业务；其中，所述第一业务为逻辑网元上的业务；

处理模块，用于对所述EMS上的第一业务告警进行屏蔽处理，其中，所述第一业务告警为根据所述逻辑网元发送给所述EMS的第一业务告警信息生成的，所述第一业务告警信息用于指示所述第一业务发生故障。

6.根据权利要求5所述的装置，其特征在于，

所述获取模块，还用于获取所述基础设施层发送给所述EMS的第二硬件告警信息，所述第二硬件告警信息用于指示所述第一硬件已恢复；以及，还用于在预设时间内，获取到所述逻辑网元发送给所述EMS的第二业务告警信息，所述第二业务告警信息用于指示所述第一业务已恢复；

所述处理模块，还用于将所述第一业务告警的告警状态的故障恢复原因设置为正常恢复。

7.根据权利要求5所述的装置，其特征在于，

所述获取模块，还用于获取所述基础设施层发送给所述EMS的第二硬件告警信息，所述第二硬件告警信息用于指示所述第一硬件已恢复；

所述处理模块，还用于在预设时间内，所述获取模块未获取到所述逻辑网元发送给所述EMS的第二业务告警信息时，将所述第一业务告警的告警状态设置为激活，所述第二业务告警信息用于指示所述第一业务已恢复。

8.根据权利要求5-7任一所述的装置，其特征在于，所述第一业务为所述逻辑网元的实时业务，所述第一硬件属于所述基础设施层的分布式部署单元DU；

所述获取模块，具体用于获取所述DU发送给所述EMS的所述第一硬件告警信息，所述第一硬件告警信息用于指示所述DU中的所述第一硬件发生故障。

9.一种告警处理装置，其特征在于，所述装置包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

收发器，用于收发数据；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-4中任一所述的告警处理方法。

Images