CN103370904A

CN103370904A - 用于确定网络意外事件的严重性的方法

Info

Publication number: CN103370904A
Application number: CN2011800576364A
Authority: CN
Inventors: 迪米特里奥斯·佩雷坎诺斯; O.泽; T.尼兰德; L.里默特
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2010-09-30
Filing date: 2011-07-21
Publication date: 2013-10-23
Anticipated expiration: 2031-07-21
Also published as: US20130176858A1; US9680722B2; EP2622792A1; WO2012041555A1; CN103370904B

Abstract

本发明涉及用于确定引起通信网络中的网络告警的网络意外事件的严重性的方法。该方法包括：获取(201)与网络告警关联的严重性属性，所述严重性属性指示网络意外事件对通信网络中的通信服务的影响；以及将严重性属性与来自严重性指示符的预定集合的严重性指示符相关(203)，以便确定网络意外事件的严重性。

Description

用于确定网络意外事件的严重性的方法

背景技术

在如汇聚网络之类的现代电信网络中，可部署多个实体以用于提供通信服务。但是，如果例如被管理网络实体不是如网络运营商所预期的那样在服务级执行，则单个网络意外事件可随空间和时间而导致从受影响的被管理实体和管理系统生成多个告警。可使接收所生成告警的网络运营商能够评估所接收告警，以便确定对于最终订户在如语音之类的通信服务上的影响，并且识别具有网络故障的实体。在这点上，最终用户影响和有故障实体的快速且准确的确定可缩短修理时间，降低操作成本，并且促进提供通信服务的运营商与服务消费者之间的服务合同的支持。

通过研究运营商与被管理服务提供商之间的WLA(工作级协议)和SLA(服务级协议)，可以发现，对网络中的意外事件的严重性的判断与网络元件或网络实体(NE)所提供的告警的所感知严重性具有根本差异。从运营商观点所看到的意外事件的严重性通过对所交付服务和收益的影响来判断。由运营商用于严重性判断的KPI(关键性能指示符)的示例是：

- 受影响订户的数量，

- 受影响站点的数量，

- 扰动等级，

- 受影响的通信服务，

- 受影响站点的类型(黄金站点、A站点、B站点)，

- 影响或者不影响重要客户，或者

- 某个区域中的某些重要事件，例如音乐节、足球等。

对于对告警的所感知严重性，在3GPP故障管理标准TS 32.111-1所引用的ITU-T X.733第8.1.2.3章中，所感知严重性分为6个不同类别：清除、不确定、关键、主要、次要和警告。这些类别中只有两个，即关键和主要，指示已经形成服务影响条件。遗憾的是，不存在与网络上受影响服务的数量有关的信息。

当前3GPP标准TS 32.121规定，IRP管理器(网络管理系统)应当能够请求IRP代理(域管理器)采用规则对告警分类。这些规则可例如取决于告警的类型、环境、时刻、网络元件的类型、告警严重性、位置、包容树中的位置等。但是，告警的这种分类方式要求详细了解网络元件、元件如何在其间(包容树中的位置)构成，还要了解告警(告警的类型、告警严重性)。

由于缺乏受影响服务的量化，难以基于如WLA/SLA中所描述的网络影响进行严重性的自动判断。

发明内容

本发明的目的是提供有效确定影响如语音服务之类的通信服务的网络意外事件的严重性的概念。这个目的通过独立权利要求的特征来实现。通过从属权利要求、描述和附图，其它实施例是清楚的。

本发明基于如下发现：当确定引起网络告警的网络意外事件的严重性时，可有效地处理网络意外事件。具体来说，意外事件可由若干相互关联的告警、即与诸如网络实体故障之类的相同网络意外事件相关的告警组成。基于一个或多个相互关联的告警，可确定网络意外事件对诸如语音或多媒体之类的通信服务的影响。

本发明提供基于对所交付服务的影响来自动确定由或者可以由若干相互关联的告警组成的意外事件的严重性的方法和对应机制。

按照第一方面，本发明涉及一种用于确定引起通信网络中的网络告警的网络意外事件的严重性的方法，该方法包括下列步骤：获取与网络告警关联的严重性属性，该严重性属性指示网络意外事件对通信网络中的通信服务的影响；以及将严重性属性与来自严重性指示符的预定集合的严重性指示符相关，以便确定网络意外事件的严重性。

按照一个实施例，严重性属性指示下列至少一个：受到网络意外事件影响的订户的数量，受到网络意外事件影响的订户的类型，受到网络意外事件影响的网络小区的数量，受到网络意外事件影响的通信站点的数量，受到网络意外事件影响的通信服务、具体来说是语音服务或分组数据服务，因网络意外事件引起的通信服务、具体来说是语音服务或分组数据服务的降级，受到网络意外事件影响的通信服务的重要性，受到网络意外事件影响的通信服务的类型，网络意外事件所引起的扰动的持续时间，网络意外事件的持续时间，到网络意外事件所引起的扰动的发生为止的剩余时间，以及到网络意外事件所引起的扰动的发生为止可用的冗余通信资源的剩余数量。

按照一个实施例，严重性指示符的预定集合包括下列严重性指示符中的至少一个：大修停机、关键、主要、次要和无服务影响。作为举例，严重性指示符的预定集合可作为例如各与某个严重性指示符关联的严重性标志或者严重性编号预存储在存储装置中。

按照一个实施例，获取严重性属性包括通过通信网络来接收网络告警连同属性。由此，可实现“自底向上”方式，按照这种方式，在向操作系统发出告警时，网络元件或网络节点可提供与网络影响有关的信息，操作系统可例如基于所提供信息来执行网络影响的分析。

按照一个实施例，获取严重性属性包括：接收与网络告警对通信服务的影响相关的网络信息，具体来说是网络告警类型，该网络信息使得能够确定严重性属性；以及基于所接收的网络信息来确定严重性属性。

作为举例，网络或告警类型信息可以是用于在网络告警例如到达域管理器时确定或计算严重性属性的信息。它可指示例如存储严重性属性、配置的关联、告警实例中的被管理对象类/实例属性、与告警的被管理对象/类关联的业务数据的存储装置的网络地址。

按照一个实施例，意外事件引起若干相互关联的网络告警，以及其中该方法包括如下步骤：关于网络意外事件将多个网络告警相互关联以确定若干相互关联的网络告警，获取若干网络告警的若干严重性属性，以及将若干严重性属性与来自严重性指示符的预定集合的至少一个严重性指示符相关以确定网络意外事件的严重性。

按照一个实施例，将若干严重性属性与至少一个严重性指示符相关包括下列步骤：累积若干严重性属性，以及将累积的若干严重性属性与至少一个严重性指示符相关，或者将若干严重性属性之中的最大严重性属性与至少一个严重性指示符相关。

按照一个方面，本发明涉及一种用于表征由通信网络中的网络告警所指示的网络意外事件的方法，该方法包括如下步骤：获取与网络告警对通信服务的影响相关的网络信息以表征网络意外事件，以及通过通信网络来传送网络信息。

按照一个实施例，网络信息指示使得能够确定严重性属性的网络告警类型，该严重性属性表征网络意外事件。

按照一个实施例，将网络信息连同网络告警一起向通信网络传送，具体来说，向域管理器传送。

按照一个实施例，该方法包括通过通信网络将初始阶段期间的告警模型以及随其的操作阶段期间的网络告警具体来说向域管理器传送。由此，可实现上述自顶向下方式。

按照一个实施例，该方法包括通过通信网络将网络告警以及与其关联的严重性指示符具体来说向域管理器传送。由此，可实现上述自底向上方式。

按照一个实施例，意外事件引起若干相互关联的网络告警，以及其中该方法还包括下列步骤：将网络告警相互关联以确定若干相互关联的网络告警，分析如若干相互关联的网络告警所指示的网络意外事件对通信服务的影响以获取若干严重性属性，以及将若干相互关联的网络告警与严重性指示符关联。

按照另一方面，本发明涉及一种用于确定引起通信网络中的网络告警或者多个网络告警的网络意外事件的严重性的网络实体、具体来说是域管理器，该网络实体配置成执行本文所述方法的任一个。作为举例，该网络实体可以是域管理器。

按照一个实施例，网络实体包括：接收器，用于接收网络告警连同严重性属性；以及处理器，用于将严重性属性与来自严重性指示符的预定集合的严重性指示符相关以确定网络意外事件的严重性。由此，可实现自底向上方式。

按照一个实施例，网络实体包括：接收器，用于接收与网络告警对通信服务的影响相关的网络信息、具体来说是网络告警类型，该网络信息使得能够确定严重性属性，严重性属性指示网络意外事件对通信网络中的通信服务的影响；以及处理器，用于基于所接收网络信息来确定严重性属性。由此，可实现自顶向下方式。

按照另一方面，本发明涉及一种用于表征由通信网络中的网络告警所指示的网络意外事件的网络实体、具体来说是无线电网络控制器或NodeB或者基站，该网络实体配置成执行本文所述方法的任一个。

按照一个实施例，本发明涉及一种网络实体，其中包括用于分析如网络告警所指示的网络意外事件对通信服务的影响以获取严重性属性的处理器。

按照一个实施例，本发明涉及一种网络实体，其中包括用于通过通信网络来传送与网络告警对通信服务的影响相关的网络信息的传送器。

按照一个实施例，本发明涉及一种网络实体，其中包括用于将网络告警连同与其关联的严重性属性一起向通信网络传送、具体来说向本文所述的网络实体传送的传送器。

附图说明

可针对下列附图来描述其它实施例，其中：

图1示出网络实体的布置；

图2示出用于确定网络意外事件的严重性的方法的简图；

图3示出获取严重性属性的步骤的一个实施例；

图4示出获取严重性属性的步骤的一个实施例；

图5示出用于确定网络意外事件的严重性的方法的简图；

图6a、图6b、图6c示出用于表征网络意外事件的方法步骤；

图7示出网络实体的一个实施例；

图8示出网络实体的框图；

图9示出网络实体内的功能模型与设备模型之间的关联；以及

图10示出管理工作流程。

具体实施方式

图1示出包括第一网络实体101、第二网络实体103和第三网络实体105的网络实体的布置。第一和第二网络实体101、103可分别形成无线电网络控制器(RNC)或NodeB。第三网络实体105可形成例如域管理器(DM)，该DM从第一和第二网络实体101、103接收告警，例如相互关联的告警。

第一网络实体101可包括处理器107和存储装置109。对应地，第二网络实体包括处理器111和存储装置113。此外，第三网络实体105包括处理器115和存储装置117。

在网络意外事件时，第一网络实体101可将节点告警119相互关联，以便确定与相同的网络意外事件相关的相互关联的告警。在这点上，处理器107可配置成使用例如本地内容管理(CM)数据或业务数据来执行告警相互关联。基于相互关联的告警，处理器107可执行影响分析，以便确定网络意外事件对通信服务、例如语音或流播媒体服务的影响。相互关联的告警可提供给第三网络实体105供进一步处理。第二网络实体103可对应地处理多个节点告警121，如关于第一网络实体101所述。

将相互关联的告警提供给第三网络实体105，第三网络实体105可通过处理器115，使用例如网络(NW)CM或PM数据来进一步相互关联所接收的相互关联的告警。此后，处理器115可执行影响分析，以便确定意外事件对通信服务的影响。第三网络实体105还可经由如图1所示的Itf-N接口来传送相互关联的告警。

按照一些实施例，网络实体(NE)101、103可提供与网络影响有关的信息而不是与各告警的节点影响有关的信息，因为与节点影响有关的信息要求与NE级和网络级上的告警之间的相互关联有关的专门知识，这难以获得，因为仅对告警实例提供所保存严重性。因此，可考虑两种可能的实现：

按照自顶向下方式，NE 101、103可向域管理器105、例如OSS-RC(操作和支持系统无线电和核心)提供关于什么各告警可影响系统上功能性的告警模型以及关于什么功能性可影响网络的信息。当NE告警发生时，则域管理器105可除了把来自不同NE 101、103的告警收集到意外事件文件夹之外，还可基于NE 101、103所提供的告警模型和网络配置信息来执行网络影响的深入分析。告警模型的一个示例是关于例如可100%影响若干公共信道的NE 101、103中的基带模块的告警，并且各公共信道故障可影响网络上的一个小区的业务。

按照图1所示的自顶向下方式，网络中的每个或一个NE 101、103可在告警被发出时提供与网络影响有关的信息，并且具体在初始状态期间(例如在网络实体投入操作之前)将其发送给DM 105。在这种情况下，DM 105可除了把来自不同NE 101、103的告警收集到意外事件文件夹之外，还通过添加网络影响来执行网络影响的分析，这取决于配置信息和/或业务数据。

下面，不失一般性，仅作为举例，将更详细描述自底向上方式。

图2示出用于确定引起通信网络中的网络告警的网络意外事件的严重性的方法的简图。该方法包括获取201与网络告警关联的严重性属性。严重性属性可指示网络意外事件对通信网络中的通信服务的影响。图2所示的方法可由图1所示的网络实体的任一个来执行。

图3示出如图2所示的获取201严重性属性的步骤的一个实施例。该方法包括接收301网络告警和严重性属性。作为举例，网络告警和严重性属性可由例如形成网络实体的一个实施例的域管理器来一起和同时接收。但是，网络告警和严重性属性可由域管理器在不同时刻接收。

图4示出获取201严重性属性的步骤的另一个实施例，其中可包括如下步骤：接收401与网络告警对通信服务的影响相关的网络信息，具体来说是网络告警类型，该网络信息使得能够确定严重性属性；以及基于所接收的网络信息来确定403严重性属性。

图4和图5所示的步骤可由图1所示的网络实体的任一个来执行。在这点上，图3所示的实施例可与上述自底向上方式相关。

按照一些实施例，网络意外事件可引起若干、例如两个或超过两个相互关联的网络告警。图5示出用于确定引起若干相互关联的网络告警的网络意外事件的严重性的对应方法的简图。图5所示的简图可被理解为图2所示方法的增强。该方法包括由例如域管理器来接收501网络告警。该方法还包括关于网络意外事件将网络告警相互关联503，以便确定若干相互关联的网络告警。该方法还包括按照本文所述原理来获取505若干网络告警的若干严重性属性。此外，该方法包括将若干严重性属性与来自严重性指示符的预定集合的至少一个严重性指示符相关507，以便按照本文所述原理来确定网络意外事件的严重性。

步骤505可包括如下步骤：接收指示网络意外事件对通信服务的影响的影响信息，以及基于所接收的影响信息来确定严重性属性。确定步骤可包括基于所接收的影响信息来分析网络意外事件的影响。

按照一些实施例，严重性属性可基于网络告警对通信服务的影响的分析来获取。此外，网络意外事件可基于网络告警和严重性属性在DM中表征。在这点上，图6a示出一种方法，包括获取601与网络告警对通信服务的影响相关的网络信息以表征网络意外事件，以及通过通信网络传送603网络信息。

此外，可选地，如图6b所示的方法步骤可包括分析605网络意外事件对通信服务的影响，以及将网络告警与严重性属性关联607。上述步骤可由图1所示的网络实体101、103中的任一个来执行。

按照一些实施例，该方法可包括通过通信网络将指示如网络告警所指示的网络意外事件的影响的影响信息向例如域管理器传送605。由此，可实现上述自顶向下方式。

备选地，该方法可包括通过通信将网络告警和与其关联的严重性指示符向例如域管理器传送605。由此，可实现自底向上方式。

另一个备选方案是，该方法可包括通过通信将网络告警和与其关联的严重性属性向例如域管理器传送607。由此，也可实现自底向上方式。

按照一些实施例，该方法可如图6c所示来执行。在网络告警出现609之后，在步骤611，分析网络告警的影响以获取告警的严重性属性。此后，在可选步骤613，网络告警可与严重性属性关联。此后，在步骤615，可传送严重性属性。

图7示出网络实体的、例如用于确定引起通信网络中的网络告警的网络意外事件的严重性的域管理器的一个实施例。

网络实体可包括：接收器703，用于接收网络告警连同严重性属性；以及处理器705，用于将严重性属性与来自严重性指示符的预定集合的严重性指示符相关，以按照本文所述原理来确定网络意外事件的严重性。由此，可实现上述自底向上方式。

作为补充或替代，接收器可配置成从NE接收初始状态期间的告警模型。对应地，处理器705可配置成基于所接收告警模型、配置信息以及从NE接收的性能数据来确定严重性属性，并且将严重性属性与来自严重性指示符的预定集合的至少一个严重性指示符相关以确定网络意外事件的严重性。由此，可实现自顶向下方式。

图8示出网络实体的、例如用于表征由通信网络中的网络告警所指示的网络意外事件的无线电网络控制器或NodeB(基站)的框图。图8所示的网络实体可对应于图1所示网络实体101、103其中之一。网络实体包括处理器803，用于分析网络告警对通信服务、例如语音或多媒体的影响以获取严重性属性，并且用于将网络告警与严重性属性关联，以便表征网络意外事件。这是自顶向下方式的实现。

网络实体还可包括传送器805，用于通过通信网络来传送与网络告警对通信服务的影响相关的网络信息。按照一些实施例，传送器805可通过通信来传送初始阶段期间的告警模型以及随其的操作阶段期间的网络告警。这是自底向上方式的实现。

作为替代或补充，传送器可配置成将网络告警连同与其关联的严重性属性一起向通信网络传送，例如，向如图2所示或如图7所示的域管理器105传送。

传送器805，用于通过通信网络来传送与网络告警对通信服务的影响相关的网络信息。

参照上述实施例，在第一步骤，例如，可引入基于对所交付服务的影响的最终用户定义的意外事件严重性定义。意外事件严重性定义可包括可实现为若干记录的严重性指示符的集合，其中各记录描述每种意外事件严重性的标准。严重性指示符的示例是：

- 大修停机(MSO)，

- 关键，

- 主要，

- 次要，以及

- 无服务影响。

标准可包括描述对网络的服务影响的若干属性。标准属性的示例是：

- 受影响订户的数量，

- 受影响小区的数量，

- 受影响站点的数量，

- 受影响的服务、例如语音或分组数据，

- 服务的降级、例如失败的呼叫建立的百分比，

- 扰动的持续时间，

- 到扰动发生为止的剩余时间，例如在干线故障的情况下电池可持续多长时间，

- 在扰动发生之前剩下的剩余冗余资源，例如，在总共三个冗余通信链路其中之一故障的情况下，这个属性可报告2，

除上述标准属性之外，还可存在可具有对区分优先次序的影响的例外，例如，黄金站点、某些站点上正进行的项目、具有时间和位置的特殊事件等。但是，由于这些例外属性可具有相当高的变化频率，所以它们不适合被包含在严重性定义中，而是包含在分开的“例外严重性定义”中。

在步骤2，在NE 101、103中，节点告警可被相互关联，以及如果可能的话，被抑制以便促进DM 105以将其编组在一起。

在步骤3，在NE 101、103已经将告警相互关联之后，它还可基于以上第1项中提到的标准属性的定义来分析相互关联的告警的影响。对于这个分析，NE 101、103可除告警之外，还使用本地可用的信息，例如节点配置信息、业务数据等。影响分析的结果可作为相互关联的告警中的新属性(例如受影响订户的数量、受影响小区的数量等)来发送。

在步骤4，当DM 105从NE 101、103接收到节点告警时，它可将NE 101、103之间的相关节点告警进一步相互关联到意外事件中，以便简化告警处理工作。

在步骤5，在DM 105中，在将节点告警相互关联到意外事件之后，它可以能够使用由意外事件中的相互关联的告警所提供的新属性，加上DM 105上可用的其它信息，例如网络配置信息、性能管理(业务KPI)数据、告警历史等，来分析各意外事件的影响。这时能够通过将结果与意外事件严重性定义进行比较，将这个影响分析的结果用于这个意外事件的严重性的判断。

在意外事件严重性判断在Itf-N之上、即在网络管理系统(NMS)中进行的情况下，DM 105可将影响分析的结果作为相互关联的告警(＝意外事件)中的新属性来传送。

在意外事件严重性判断在Itf-N之下、即在DM 105内执行的情况下，最终用户可通过Itf-N接口向DM 105提交意外事件严重性定义。

在步骤6，还有可能在NMS级上重复步骤4和5，以便相互关联和分析不同域之间的意外事件的影响。

参照如前所述的意外事件严重性标准属性，严重性标准属性可以是所有网络元件的影响分析的统一的关键。按照一些实施例，该数量的属性可被缩减，以便最终用户的配置简化。

按照一些实施例，严重性属性可被识别如下：

- 从告警列表中选择若干告警实体，并且确定能够从其中的每个实体报告哪种严重性属性，以及

- 概括来自前一个步骤的所有所收集属性，并且得出严重性定义中的服务影响属性。

按照一个实施例，两个RNC北行接口其中之一可出故障，这与冗余度损失关联。北行接口被配置为主/从

- 当前的

受影响订户=0，没有影响，因为存在主/从冗余度

受影响小区=0

受影响站点=0

受影响服务=无

服务的降级=0%，这可取决于主/从配置，在负荷平衡的情况下，可通过使用本地业务数据来计算降级

扰动的持续时间=0(与前一个属性相同的注释)

扰动发生之前的剩余冗余资源=1

- 潜在的

受影响订户=10000，这可从本地业务数据得出

受影响小区=350，这可从本地配置数据得出

受影响站点=1，其中只有RNC站点在站点访问的情况下可被影响)

受影响服务=语音和/或数据，这可取决于向CN的配置

服务的降级=100%

扰动的持续时间=无限

按照另一个实施例，例如具有站点上的备用电池的RBS中的干线告警可发生

- 当前的

受影响订户=0，没有影响，因为存在备用电池

受影响小区=0

受影响站点=0

受影响服务=无

服务的降级=0%

扰动的持续时间=0

扰动发生之前的剩余时间=2小时，取决于剩余电荷

- 潜在的

受影响订户=160，这可从本地业务数据得出

受影响小区=6，这可从本地配置数据得出

受影响站点=1，其中只有RBS站点在站点访问的情况下可被影响

受影响服务=语音和数据

服务的降级=100%

扰动的持续时间=无限

按照另一个实施例，没有冗余度的Iub上的RNC通信差错可发生

- 当前的

受影响订户=32，这可从节点业务数据得出，否则为未知

受影响小区=6，这可从节点业务数据得出，否则为未知

受影响站点=1，例如RNC或RBS站点

受影响服务=全部或未知

服务的降级=100%或未知

扰动的持续时间=无限或未知

- 潜在的

不适用

按照另一个实施例，RBS基带板可重启(没有冗余度)

- 当前的

受影响订户=32，这可从节点业务数据得出

受影响小区=6，这可从本地配置数据得出

受影响站点=1，例如RBS站点

受影响服务=全部

服务的降级=100%

扰动的持续时间=1分钟(重启时间)

- 潜在的

不适用

在上述示例的分析之后，下面得出严重性定义中的服务影响属性的第一草案：

- 当前的

受影响订户

受影响小区

受影响站点

受影响服务

服务的降级

扰动的持续时间

扰动发生之前的剩余冗余资源

扰动发生之前的剩余时间

- 潜在的

受影响订户

受影响小区

受影响站点

受影响服务

服务的降级

扰动的持续时间

按照一些实施例，“例外严重性定义”中的属性，例如黄金站点位置、某些站点上正进行的项目、具有时间和位置的特殊事件等可以不包含在上述列表中。

按照与自动化机制相关的一些实施例，为了澄清如何在现实生活中执行意外事件文件夹自动化，接近现实的示例可用于举例说明。下面所述的步骤基于例如图1所示的分布式架构。

按照一些实施例，可执行先决条件。作为举例，在WCDMA系统中，网络实体(例如具有识别码“RNC005”的RNC)上的具有识别码“ET003”的ET板可能坏掉。这个ET板可连接到50个NodeB，每个NodeB由3个小区组成。没有配置到这些eNodeB的冗余度连接。

自动化的目标是在DM 105上创建具有名称<Root cause Node Name>_<Impact>_<Root cause hardware>的意外事件文件夹，其中填充了附加的属性优先级和影响。对于这个特定示例，意外事件文件夹的名称可以是RNC005_50NodeB_ET003。

在步骤1，可定义意外事件严重性。与意外事件严重性定义有关的属性可对应于上述属性。对于例如关键告警，可满足下列标准：

- 当前的

受影响订户：(随意)

受影响小区：(随意)

受影响站点：>=30

受影响服务：(随意)

服务的降级：(随意)

扰动的持续时间：(随意)

扰动发生之前的剩余冗余资源=0

扰动发生之前的剩余时间=0

- 潜在的

受影响订户：(随意)

受影响小区：(随意)

受影响站点：(随意)

受影响服务：(随意)

服务的降级：(随意)

扰动的持续时间：(随意)

Dm 105可实现这个机制。

在步骤2，可执行NE 101、103内的告警相互关联。

在当前实现中来自相应NE 101、103的预计告警可如下：

- RNC(RNC005)

1.以太网交换机端口故障；Comm；LINK_FAILURE；主要；EthernetSwitchModulePort

2.以太网交换机端口故障；Comm；LINK_FAILURE；主要；EthernetSwitchPort

3.ET IP硬件故障；Eq；LINE_CARD_PROBLEM；主要；ExchangeTerminalIp

4.插入式单元HW故障；Eq；REPLACEABLE_UNIT_PROBLEM；主要；PlugInUnit

- RBS(50个NE)

1.远程IP地址不可达；COMMUNICATIONS_ALARM；UNAVAILABLE；MINOR；Sctp

按照一些实施例，RNC告警1-3可被抑制并且告警4(总共1个告警)可以是可见的，以及RBS告警1(50个告警)可以是可见的。

在步骤3，告警影响分析可在NE 101、103内执行。

对于RNC005，与影响有关的附加属性可由RNC指配在告警4上。

- 当前的

受影响订户=x(从RNC内的当前业务信息来取)

受影响小区=150(从连接到RNC内的ET板的小区配置数据来取)

受影响站点=50(基于连接到RNC内的ET板的传输网络配置数据)

受影响服务=全部(基于连接到RNC内的ET板的资源服务配置数据)

服务的降级=100%(因为它是完全坏掉的链路)

扰动的持续时间=无限(因为它是完全坏掉的链路)

扰动发生之前的剩余冗余资源=0(因为它是没有冗余度的完全坏掉的链路)

扰动发生之前的剩余时间=0(因为它是完全坏掉的链路)

- 潜在的(不适用)

等等。

对于全部RBS－在告警1中，与影响有关的附加属性可在这个步骤中设置。为了填充这些新属性，

- 当前的

受影响订户=x(从RBS内的当前业务信息来取)

受影响小区=3(从连接到RBS内的IP地址的小区配置数据来取)

受影响站点=1(始终等于1)

受影响服务=全部(基于连接到IP地址的资源服务配置数据)

服务的降级=100%(因为它是完全坏掉的链路)

扰动的持续时间=无限(因为它是完全坏掉的链路)

扰动发生之前的剩余冗余资源=0(因为它是完全坏掉的IP目的地)

扰动发生之前的剩余时间=0(因为它是完全坏掉的IP目的地)

- 潜在的(不适用)

等等。

在步骤4，告警相互关联可在DM 105上执行。具体来说，来自RNC的告警以及先前来自RBS的告警可被收集到一个意外事件文件夹中。DM 105可执行下列动作：

- RNC与RBS之间的告警实体的相互关联，

- RNC/RBS之间的IP地址配置信息的相互关联。

在这个步骤之后，能够创建意外事件文件夹，但是并非填充所有属性，这时能够填充意外事件标语的<Root cause Node Name>和<Root cause hardware>部分。在这个实施例中，意外事件文件夹的名称将为RNC005_<Impact>_ET003。

需要在OSS级创建和实现节点类型之间的告警条目之间的相互关联规则。

与IP地址配置有关的相互关联能够基于DM 105中存储的网络配置。

在步骤5，可执行在DM 105上的告警影响分析。在意外事件文件夹中，影响属性和优先级属性将通过使用文件夹中的1 RNC+50 RBS告警来填充。

- 影响属性

-- 当前的

受影响订户=x(使用来自RNC告警的属性)

受影响小区=150(使用来自RNC告警的属性)

受影响站点=50(使用来自RNC告警的属性)

受影响服务=全部(使用来自RNC告警的属性)

服务的降级=100%(使用来自RNC告警的属性)

扰动的持续时间=无限(使用来自RNC告警的属性)

扰动发生之前的剩余冗余资源=0(使用来自RNC告警的属性)

扰动发生之前的剩余时间=0(使用来自RNC告警的属性)

- 潜在的(不适用)

等等。

优先级属性：关键(通过查找步骤1所定义的“严重性定义”，其中受影响站点>=30)。

在这个步骤之后，可填充意外事件和属性的全名，即

意外事件名称=“RNC005_50 RBS down_ET003”，其中严重性=“关键”，以及影响=“50 RBS停机”。

作为举例，这个机制可在DM 105中实现。

图9示出网络实体内的功能模型与设备模型之间的关联。功能模型包括被管理元件901、设备903、ET板905、小区907和RNC功能909。图9所示的元件可在功能上相互关联，如图9所示。作为举例，图9概括上述属性，这些属性可从内部配置数据和性能数据结构得出，因为在节点内的硬件模型与功能模型之间存在关联。

按照一个实施例，可执行意外事件文件夹自动化。在这点上，可执行下列动作：将告警自动编组为意外事件，判断意外事件的影响，并且把意外事件区分优先次序。

意外事件文件夹的自动化形式的部署情况可如下：

在激活自动化机制之前，运营商需要为系统配置其自己的区分优先次序矩阵数据，描述意外事件对网络的什么影响将被当作关键、主要、次要和无服务影响等。这个配置可以尽可能通用，即，不需要关于告警实体的特定知识或者关于网络元件的特定硬件或软件特性。

在操作期间，运营商接收告警列表视图上的若干意外事件文件夹，其中影响和优先级属性由系统来填充。

这种自动化的效果之一是，OSS上的告警过滤能够或多或少被省略，因为最终用户将使用意外事件作为概览，以及根原因分析将研究意外事件文件夹中的对应告警，这将使根原因分析更有效率，因为与意外事件有关的所有告警这时被收集在相同的意外事件文件夹中，而不是探究不同网络元件以查找相关告警。

图10示出按照本文所述的原理来组织一组活动的故障、即意外事件管理工作流程。工作流程使用UML符号，其中具有圆角的矩形元件表示活动，矩形表示可用于图解活动之间的输入和输出关系的对象。虚线箭头表示对象流，并且表示活动与创建活动作为输出或者使用活动作为输入的对象之间的关系。对象可包括下列之一：活动告警1001，已过滤告警1003，聚类1005，已区分优先次序的聚类1007以及没有所识别原因的已区分优先次序的聚类1009、事故单1011和工作通知单1013。活动可包括过滤1015、划分1017、区分优先次序1019、分析1021和恢复或自动调整1023。下表针对3GPP TSG-SA5规范来概括图10所示的活动的一些实施例。

一些实施例可简化意外事件或告警的区分优先次序，因为运营商不可具有对可定义其严重性判断的网络元件所生成的告警的任何知识。此外，域管理器不可实现与网络元件的内部结构或功能性有关的知识。此外，意外事件或告警组的判断可自动执行而无需用户的任何交互。

Claims

1. 用于确定引起通信网络中的网络告警的网络意外事件的严重性的方法，所述方法包括：

获取(201)与所述网络告警关联的严重性属性，所述严重性属性指示所述网络意外事件对所述通信网络中的通信服务的影响；以及

将所述严重性属性与来自严重性指示符的预定集合的严重性指示符相关(203)，以便确定所述网络意外事件的严重性。

2. 如权利要求1所述的方法，其中，所述严重性属性指示下列至少一个：

受到所述网络意外事件影响的订户的数量，

受到所述网络意外事件影响的订户的类型，

受到所述网络意外事件影响的网络小区的数量，

受到所述网络意外事件影响的通信站点的数量，

受到所述网络意外事件影响的通信服务，具体来说是语音服务或分组数据服务，

因所述网络意外事件引起的通信服务、具体来说是语音服务或分组数据服务的降级，

受到所述网络意外事件影响的通信服务的重要性，

受到所述网络意外事件影响的通信服务的类型，

由所述网络意外事件引起的扰动的持续时间，

所述网络意外事件的持续时间，

到所述网络意外事件所引起的扰动发生为止的剩余时间，以及

到所述网络意外事件所引起的扰动发生为止可用的冗余通信资源的剩余数量。

3. 如以上权利要求中的任一项所述的方法，其中，所述严重性指示符的预定集合包括下列严重性指示符中的至少一个：

大修停机，

关键，

主要，

次要，以及

无服务影响。

4. 如以上权利要求中的任一项所述的方法，其中，获取(201)严重性属性包括：通过所述通信网络接收(301)所述网络告警连同所述属性。

5. 如以上权利要求1至3中的任一项所述的方法，其中，获取(201)严重性属性包括：

接收(401)与所述网络告警对所述通信服务的影响相关的网络信息，具体来说是网络告警类型，所述网络信息使得能够确定所述严重性属性；以及

基于所接收的网络信息来确定(403)所述严重性属性。

6. 如以上权利要求中的任一项所述的方法，其中，所述意外事件引起若干相互关联的网络告警，并且其中，所述方法包括：

关于所述网络意外事件将多个网络告警相互关联(503)，以便确定所述若干相互关联的网络告警；

获取(505)所述若干网络告警的若干严重性属性；以及

将所述若干严重性属性与来自所述严重性指示符的预定集合的至少一个严重性指示符相关(507)，以便确定所述网络意外事件的严重性。

7. 如权利要求6所述的方法，其中，将所述若干严重性属性与所述至少一个严重性指示符相关(507)包括：

累积所述若干严重性属性并且将所累积的所述若干严重性属性与所述至少一个严重性指示符相关；或者

将所述若干严重性属性之中的最大严重性属性与所述至少一个严重性指示符相关。

8. 用于表征由通信网络中的网络告警所指示的网络意外事件的方法，所述方法包括：

获取(601)与所述网络告警对通信服务的影响相关的网络信息，以表征所述网络意外事件；以及

通过所述通信网络来传送(603)所述网络信息。

9. 如权利要求8所述的方法，其中，所述网络信息指示使得能够确定严重性属性的网络告警类型，所述严重性属性表征所述网络意外事件。

10. 如权利要求8或9所述的方法，其中，将所述网络信息连同所述网络告警一起向所述通信网络、具体来说向域管理器传送。

11. 如权利要求8、9或10所述的方法，其中，所述意外事件引起若干相互关联的网络告警，并且其中，所述方法还包括：

将网络告警相互关联，以便确定所述若干相互关联的网络告警；

分析如所述若干相互关联的网络告警所指示的所述网络意外事件对所述通信服务的影响，以便获取若干严重性属性；以及

将所述若干相互关联的网络告警与严重性指示符关联。

12. 一种用于确定引起通信网络中的一个或多个网络告警的网络意外事件的严重性的网络实体(701)、具体来说是域管理器，所述网络实体配置成执行以上权利要求1至7其中之一的方法。

13. 如权利要求12所述的网络实体(701)，包括：

接收器(703)，用于接收所述网络告警连同所述严重性属性；以及

处理器(705)，用于将所述严重性属性与来自严重性指示符的预定集合的严重性指示符相关，以便确定所述网络意外事件的严重性。

14. 如权利要求12所述的网络实体，包括：

接收器(703)，用于接收与所述网络告警对所述通信服务的影响相关的网络信息、具体来说是网络告警类型，所述网络信息使得能够确定严重性属性，所述严重性属性指示所述网络意外事件对所述通信网络中的通信服务的影响，以及

处理器(705)，用于基于所接收的网络信息来确定所述严重性属性。

15. 一种用于表征由通信网络中的网络告警所指示的网络意外事件的网络实体(801)、具体来说是无线电网络控制器或者基站，所述网络实体配置成执行以上权利要求8至10其中之一的方法。

16. 如权利要求15所述的网络实体(801)，包括：处理器(803)，用于分析如所述网络告警所指示的所述网络意外事件对通信服务的影响，以获取严重性属性。

17. 如权利要求15或16所述的网络实体，包括：

传送器(805)，用于通过所述通信网络传送与所述网络告警对通信服务的影响相关的网络信息。

18. 如权利要求16所述的网络实体，包括：

传送器(805)，用于将所述网络告警连同与其关联的所述严重性属性一起向所述通信网络传送，具体来说，向如权利要求13所述的网络实体传送。