用于确定通信系统中的关联事件的技术.pdf

本发明提供一种用于确定一个或多个网元中发生的事件之间的关联性的技术。该事件之间的关联性是因根事件通过该一个或多个网元的通信实体的传播而产生。在方法实现中，本发明包括步骤：从一个或多个网元接收多个事件消息，其中，与特定网元所报告的事件有关的事件消息用信号传递发生上下文，该发生上下文包括描述在该事件发生之时该事件发生的该通信实体的内部通信状态的一个或多个上下文标识符。在另一步骤中，确定相同上下文标识符所链接的关联事件集合。基于该关联事件集合，可以标识该根事件。

权利要求书
1.  一种用于确定在一个或更多个网元(30；40)中发生的事件之间的关联性的方法，其中，所述事件之间的关联性是因根事件通过所述一个或更多个网元(30；40)的通信实体的传播而产生，所述方法包括：
从一个或更多个网元(30；40)接收多个事件消息，其中，与特定网元(30；40)所报告的事件相关的事件消息用信号传递一个或更多个上下文标识符，所述一个或更多个上下文标识符描述在所述事件发生时所述事件发生的所述通信实体的内部通信状态；以及
确定相同上下文标识符所链接的关联事件的集合。

2.  如权利要求1所述的方法，其中，每个上下文标识符包括指示上下文类型的第一参数以及指示相关联标识值的第二参数。

3.  如权利要求2所述的方法，其中，当所述关联事件消息包括具有相同上下文类型并且具有相同标识值的至少一个上下文标识符时，确定两个事件为关联的。

4.  如前述权利要求中的任一项所述的方法，其中，所述事件消息中的至少一个指示与所述事件中所涉及的不同通信实体相关的两个或更多个上下文标识符。

5.  如权利要求4所述的方法，其中，当所述关联事件消息是经由包括一个或更多个中间事件消息的链进行链接的时，确定两个事件为关联的，其中，两个事件消息之间的链接是由所述两个事件消息中具有相同上下文类型并且具有相同标识值的至少一个上下文标识符所定义的。

6.  如前述权利要求中的任一项所述的方法，其中，所述通信实体的内部通信状态是通过以下上下文类型中的一个或更多个进行描述的：
用户上下文；
网络小区上下文；
报告网元侧的网元上下文、网元组件上下文、网络接口上下文、 网络协议上下文和卖家特定容器上下文中的至少一个；以及
所述报告网元的对等侧的网元上下文、网元组件上下文、网络接口上下文、网络协议上下文和卖家特定容器上下文中的至少一个。

7.  如权利要求6所述的方法，其中，针对每个上下文，定义允许至少在本地区分不同上下文的唯一标识值。

8.  如前述权利要求中的任一项所述的方法，其中，所述至少一个上下文标识符与未包括在报告所述事件的所述网元(30)中或与报告所述事件的所述网元(30)不同的通信实体有关。

9.  如前述权利要求中的任一项所述的方法，其中，所述至少一个上下文标识符与位于报告所述事件的所述网元(30)的对等侧的网元(40)的通信实体有关。

10.  如权利要求9所述的方法，其中，所述网元(30)报告的所述事件消息包括：与所述报告网元(30)的第一通信实体有关的至少一个第一上下文标识符，以及与所述对等侧的所述网元(40)的第二通信实体有关的至少一个第二上下文标识符。

11.  如权利要求10所述的方法，其中，报告网元(30)已经在上下文设置处理和配置处理中的至少一个期间从中央网络管理实体(20)获得关于与所述对等侧有关的所述第二上下文标识符的信息。

12.  如权利要求10所述的方法，其中，所述报告网元(30)已经在上下文交换处理期间从所述对等侧的网元(40)获得关于与所述对等侧有关的所述第二上下文标识符的信息。

13.  如权利要求9所述的方法，其中，所述网元(30)报告的所述事件消息包括与所述报告网元(30)的第一通信实体有关的至少一个第一上下文标识符，并且所述方法还包括：响应于接收所述事件消息，基于所存储的配置信息确定与对等侧的所述网元(40)的第二通信实体有关的至少一个第二上下文标识符。

14.  如权利要求13所述的方法，其中，所述第二上下文标识符是基于所述第一上下文标识符在配置数据库中通过查找处理来确定的。

15.  如前述权利要求中的任一项所述的方法，还包括：
生成用于所述关联事件的集合的关联性图，所述关联性图包括顶 点以及连接所述顶点的边，其中，每个顶点表示特定事件，每个边表示所连接的顶点所表示的事件之间的关联性，如果存在与两个事件相关联的至少一个相同的上下文标识符，则在两个顶点之间添加边；
分析所述图以确定至少一个根顶点；以及
基于所述至少一个根顶点，确定所述关联事件之间的至少一个根事件。

16.  如权利要求15所述的方法，其中，所述关联性图具有有向顶点。

17.  如权利要求15或16所述的方法，其中，生成所述关联性图包括：
根据所述关联事件集合来生成无向图；
通过将规则集合应用于所述无向图来将方向添加到所述顶点，其中，每个规则指定两个事件之间的发生关系的顺序。

18.  如权利要求15至17中的任一项所述的方法，其中，所述事件消息指示时间发生信息，以及，根据所述时间发生信息来导出所述顶点方向。

19.  如权利要求15至18中的任一项所述的方法，其中，生成所述关联性图包括：
确定针对多对关联事件的关联性强度；以及
基于所述关联性强度来将权重添加到所述关联性图的所述顶点和边中的至少一个。

20.  如前述权利要求中的任一项所述的方法，其中，从包括网元、网元组件、网络协议层和网络接口的组中选择所述通信实体。

21.  如前述权利要求中的任一项所述的方法，其中，所述事件包括告警事件和性能事件中的至少一个。

22.  如权利要求21所述的方法，其中，相同上下文标识符链接的所述关联事件的集合包括告警事件和性能事件。

23.  如权利要求21或22所述的方法，其中，所述性能事件包括计数器和密钥性能指示符中的至少一个。

24.  一种用于生成事件消息的方法，所述事件消息能够实现一个或 更多个网元(30；40)中发生的事件之间的关联性的确定，其中，所述事件之间的关联性因根事件通过所述一个或更多个网元(30；40)的通信实体的传播而产生，所述方法在网元(30；40)中执行，并且包括：
在所述网元(30；40)的第一通信实体中检测事件的发生；
确定描述当所述事件发生时所述第一通信实体的内部通信状态的一个或更多个上下文标识符；
生成被配置为用信号传递所述一个或更多个上下文标识符的事件消息；以及
向中央网络管理实体报告所述事件消息。

25.  如权利要求24所述的方法，其中，所述网元所报告的事件消息包括：与所述报告网元(30)的第一通信实体有关的至少一个第一上下文标识符，以及与所述报告网元(30)的对等侧的网元(40)的第二通信实体有关的至少一个第二上下文标识符，并且，所述报告网元(30)在以下处理期间已经获得关于与所述对等侧有关的所述第二上下文标识符的信息：
来自所述中央网络管理实体(20)的上下文设置处理和配置处理中的至少一个；或
来自所述对等侧的网元(40)的上下文交换处理。

26.  如权利要求24或25所述的方法，还包括：
将所述至少一个上下文标识符插入以下对象中的至少一个中：
根据第三代合作伙伴计划或3GPP规范的AlarmInformation记录对象；以及
根据所述3GPP规范的性能测量记录对象；以及
其中，生成所述事件消息包括：在所述事件消息中插入所得到的对象。

27.  一种计算机程序产品，包括：用于当在计算设备上执行所述计算机程序产品时执行前述权利要求中的任一项的步骤的程序代码部分。

28.  如权利要求27所述的计算机程序产品，所述计算机程序产品 存储在计算机可读记录介质上。

29.  一种用于确定在一个或更多个网元(30；40)中发生的事件之间的关联性的装置(20)，其中，所述事件之间的关联性是因根事件通过所述一个或更多个网元(30；40)的通信实体的传播而产生，所述装置包括：
接口(22)，被适配为：从一个或更多个网元(30；40)接收多个事件消息，其中，与特定网元(30；40)所报告的事件相关的事件消息用信号传递一个或更多个上下文标识符，所述一个或更多个上下文标识符描述在所述事件发生时所述事件发生的所述通信实体的内部通信状态；
处理器(24)，被适配为：确定相同上下文标识符所链接的关联事件集合。

30.  一种用于生成事件消息的装置(30；40)，所述事件消息能够实现一个或更多个网元(30；40)中发生的事件之间的关联性的确定，其中，所述事件之间的关联性是因根事件通过所述一个或更多个网元(30；40)的通信实体的传播而产生，所述装置(30；40)包括：
检测器(34；44)，被适配为：在所述网元(30；40)的通信实体中检测事件的发生；
处理器(36；46)，被适配为：确定描述当所述事件发生时所述事件发生的所述通信实体的内部通信状态的一个或更多个上下文标识符，其中，所述处理器(36；46)还被适配为：生成被配置为用信号传递所述一个或更多个上下文标识符的事件消息；以及
接口(32；42)，被适配为：向中央网络组件报告所述事件消息。

31.  一种关联性确定系统(10)，包括如权利要求29所述的装置(20)以及多个如权利要求30所述的装置(30；40)。

说明书用于确定通信系统中的关联事件的技术
技术领域
本发明通常涉及确定在通信系统的一个或多个网元中发生的事件之间的关联性。事件的关联性因根事件通过所述一个或多个网元的通信实体的传播而产生。
背景技术
在现代通信系统中，网元配备有故障管理功能，其涉及在检测到某种故障时生成告警。当故障发生在网元的通信实体中(例如在协议层中)时，通信实体所提供的服务可能降级或完全受阻。因此，依赖于这些服务的网元和／或其它网元的其它通信实体也将显现出故障症状，并且可能自己开始生成告警。因此，一个单一故障可能通过通信系统的大部分进行传播，并且引起大量的关联告警。
图1示意性示出故障通过单独网元的不同协议层(L1至L7)以及通过不同网元(NE1至NE3)进行传播。在图1中，假设故障发生在NE3的L2中，并且告警将因此由L2生成。由于L2中的这种故障，NE3的L2对L3所提供的服务将受阻，从而NE3的L3同样将不能正确地运作(因其依赖于L2的服务)。因此，NE3的L3自身将生成告警。同样的机制将产生在NE3的L3与L4之间以及NE3的协议栈的所有更高协议层之间。因此，已经在L2中发生的故障在NE3的协议栈中“向上”传播。单个网元内的这种故障传输在以下将被称为“垂直”故障传播(当然，故障也可以在协议栈中垂直地“向下”传播)。
单独网元(例如NE3)中的故障也可以传播到出故障的网元的对等侧上的一个或多个网元，如图1对于网络元件NE1和NE2所示的那样。如图1所示，NE3的L2中的故障将导致NE3的对等NE1和NE2的对应L2的故障，从而NE1和NE2将自己生成告警。通信网元之间的这种故障传播将在下文中还被称为“水平”故障传播。应注意， 水平故障传播可以进而引起垂直故障传播，如图1对于NE1所示的那样。
告警关联性的目的在于找寻相同故障(“根故障”)所导致的告警之间的联系并且将告警追溯到在对根故障的直接响应中所生成的告警(“根告警”)。由于在较大通信网络中，几百个告警在任何给定时刻可能并行有效，因此在长告警列表中标识一个或多个根告警并不是容易的任务。还应注意，告警的时间顺序一般与关联故障已经发生的逻辑顺序并不对应。这种对应性的缺乏可以归因于在不同通信实体中(在图1的示例中，NE3中的L3告警可以超前于NE3中的L2告警)以及不同网元(在图1的示例中，NE2的L2告警可以超前于NE1的L2告警)用于告警生成的不同触发阈值。
为了找出多个告警之间的关联性，可以分析各个告警消息的内容。告警消息规范对于大量不同通信系统是可用的。对于根据第三代伙伴项目(3GPP)的通信系统，在技术规范(TS)32.111-2V10.0.0(2010-12)；Fault Management；Part2∶Alarm Integration Reference Point(IRP)∶Information Service(IS)中定义告警消息的内容和格式等。在该TS的章节5.3.1.2中，列出可以在告警消息中用信号传递的不同告警属性。告警属性包括以下信息：关于发生告警的时间、关于很可能的告警原因以及关于所提议的修复动作。然而，可从告警属性推导的信息受限于报告告警的网元。因此，很难找出不同网元所生成的告警之间的关系。
WO2006／057588A1公开了一种用于对具有客户端-服务器关系的不同网元所生成的告警进行关联的技术。本地检测故障的服务网元以随机生成的数字的形式来生成故障标识符(FID)。故障服务网元经由第一告警消息连同FID一起将所得故障报告给网络管理系统。此外，服务网元经由FID应用于的业务消息向其客户端网元通知服务损失或降级。每个客户端网元从该业务消息提取FID，并且将其附接到也发送到网络管理系统的另一告警消息。由于一方面经由故障服务网元并且另一方面受故障所影响的客户端网元所生成的告警消息来将同一FID报告给网络管理系统，因此网络管理系统可以将所得告警消息进 行关联。
WO2006／057588A1中提出的关联性方法的一个缺点在于这样的事实：其需要经由服务网元与受服务网元之间的专用业务消息的用于每个故障的信令来传播FID。此外，还必须有预先建立的客户端-服务器关系，从而允许服务网元在故障的情况下经由业务消息确定需要联系的客户端网元。
发明内容
相应地，需要一种允许高效确定通信系统中发生的告警或其它事件之间的关联性的方法。
根据第一方面，提供一种确定一个或多个网元中发生的事件之间的关联性的方法，其中，所述事件之间的关联性是因根事件通过所述一个或多个网元的通信实体的传播而产生。所述方法包括：从一个或多个网元接收多个事件消息，其中，与特定网元所报告的事件有关的事件消息用信号传递一个或多个上下文标识符，该一个或多个上下文标识符描述在所述事件产生之时所述事件产生的所述通信实体的内部通信状态。所述方法还包括：确定相同上下文标识符所链接的关联事件集合。
在一种情况下，所述根事件通过单个网元的通信实体垂直地传输。在另一情况下，所述根事件通过两个或更多个单独网元的通信实体水平地传输。根据第三方面，所述根事件既垂直地又水平地传输。
在此应理解，通信实体构成特定事件消息所报告的事件已经发生的硬件实体和／或软件实体。例如，在垂直故障传输的情况下，通信实体可以构成网元的组件(例如软件组件和／或硬件组件)。在特定情况下，例如，在水平故障传输的情况下，所述网元故此可以被看作所述通信实体。
每个上下文标识符可以包括一个或多个参数。在一个实现中，每个上下文标识符至少包括第一参数和第二参数，其中，所述第一参数指示上下文类型，所述第二参数指示关联标识值。作为示例，所述上下文标识符可以包括名称／值对，其中，所述名称指示上下文类型，所 述值指示关联(例如数字或字母数字)标识符值(例如地址或ID)。
当经由一个或多个相同上下文标识符直接或间接地链接关联事件消息时，两个事件可以被确定为关联的。作为示例，当关联事件消息包括相同上下文类型并且具有相同标识值的至少一个上下文标识符时，两个事件可以被确定为关联的。
所述事件消息中的至少一个可以指示属于所述事件的两个或更多个上下文标识符。在此情况下，当经由相同上下文标识符对或集合经由包括一个或多个中间事件消息的链来链接所述关联事件消息时，两个事件可以被确定为关联的。作为示例，两个事件消息中的相同上下文类型的并且具有相同标识值的至少一个上下文标识符可以定义所述两个事件消息(其可以包括至少一个中间事件消息)之间的链接。
如上所述，包括特定事件消息中所包括的一个或多个上下文标识符的发生上下文描述特定通信实体的内部通信状态。所述通信状态可以例如与关于通信中当前所涉及的本地或远程组件的特定通信参数(包括地址信息和／或标识符信息)有关。
一个或多个上下文类型可以描述所述通信实体的内部通信状态。所述上下文类型可以包括以下项中的一个或多个：用户上下文、网络单元上下文以及(在所述报告网元的一侧上或其对等侧上的)网元上下文、网元组件上下文、网络接口上下文、网络协议上下文和卖家特定容器上下文中的至少一个。对于每个上下文，可以定义允许(例如在特定网元或关联网元集合内)至少在本地区分不同上下文的唯一标识值(例如数字或字母数字标识符或地址)。
单个上下文标识符或在包括多个标识符的事件消息的情况下所述上下文标识符中的至少一个可以与未包括于报告所述事件的网元中或不同于报告所述事件的网元的通信实体有关。作为示例，该上下文标识符可以与位于报告所述事件的网元的对等侧上的网元的通信实体有关。在所述两个对等网元之间可以建立通信链路。
在一个实现中，特定网元所报告的事件消息包括与所述报告网元的第一通信实体有关的至少一个第一上下文标识符以及与所述对等侧上的网元的第二通信实体有关的至少一个第二上下文标识符。可以通 过各种方式来获得关于与所述对等侧有关的所述第二上下文标识符的信息。作为示例，所述报告网元可以在来自中央网络管理实体的上下文设置处理和配置处理中的至少一个期间获得该信息。或者或此外，所述报告网元可以在来自所述对等侧上的网元的上下文交换处理期间获得该信息。
在另一实现中，从报告网元接收到的事件消息可以包括与所述报告网元的第一通信实体有关的至少一个第一上下文标识符并且可选地不包括与所述对等侧上的所述网元的第二通信实体有关的第二上下文标识符。在此情况下，可以响应于接收所述事件消息而确定与所述对等侧上的所述网元的第二通信实体有关的所述至少一个第二标识符。确定所述至少一个第二上下文标识符可以基于所存储的配置信息。作为示例，可以基于所述事件消息中所接收到的所述至少一个第一上下文标识符在配置数据库中通过查找处理来确定所述第二上下文标识符。
在一个变形中，可以确定所述关联事件之间的至少一个根事件。可以通过各种方式来执行确定根事件。在一个示例中，对于所述关联事件集合生成关联性图。所述关联性图包括顶点以及连接所述顶点的边，其中，每个顶点表示特定事件，每个边表示所连接的顶点所表示的事件之间的关联性。如果存在与所述两个事件关联的至少一个相同上下文标识符，则在两个顶点之间添加边。一旦已经生成图，其就可以分析以确定至少一个根顶点。在后续步骤中，可以基于所述至少一个根顶点来确定所述关联事件之间的所述至少一个根事件。作为示例，每个根顶点可以与根事件对应。
所述关联性图可以具有方向性顶点。为此，在第一步骤中，可以据关联事件集合生成无方向图。在第二步骤中，可以通过将规则集合应用于所述无方向图来将方向添加所述顶点。每个规则可以指定两个事件之间的发生关系的顺序。此外，所述事件消息可以指示时间发生信息。在此情况下，可以据时间发生信息来推导顶点方向。
可以考虑对于关联事件对所确定的关联性强度来生成所述关联性图。在该实现中，可以基于所述关联性强度来将权重添加到所述关 联性图的所述顶点和边中的至少一个。可以例如基于通信参数来确定所述关联性强度。
网元或任何网元组件可以表示通信实体，包括网络协议层、网络接口或任何其它软件或硬件方面。当事件消息由网元报告时，其可以由所述网元如此报告或由其任何通信实体报告。
待确定关联性的事件可以与各个网络有关方面有关。故此，所述事件可以包括告警事件和性能事件中的至少一个。具体地说，相同上下文标识符所链接的关联事件集合可以包括一个或多个告警事件以及一个或多个性能事件。所述性能事件可以包括计数器和密钥性能指示符中的至少一个。可以从对应事件消息和／或从所存储的性能测量数据推导关于所述性能事件的信息。
根据另一方面，提供一种生成能够确定一个或多个网元中发生的事件之间的关联性的事件消息的方法，其中，所述事件之间的关联性是因根事件通过所述一个或多个网元的通信实体的传播而产生。所述方法在网元中执行，并且包括：在所述网元的第一通信实体中检测事件的发生；确定在所述事件发生之时描述所述第一通信实体的内部通信状态的一个或多个上下文标识符；生成被配置为传递所述一个或多个上下文标识符的事件消息；向中央网络管理实体报告所述事件消息。
所述网元所报告的事件消息可以包括与所述报告网元的第一通信实体有关的至少一个第一上下文标识符以及与所述报告网元的对等侧上的网元的第二通信实体有关的至少一个第二上下文标识符。此外，所述报告网元已经在来自中央网络管理实体的上下文设置处理和配置处理中的至少一个或来自所述对等侧上的网元的上下文交换处理期间获得关于与所述对等侧有关的所述第二上下文标识符的信息。
可以在各个信息对象中插入所述至少一个上下文标识符。所述信息对象包括根据3GPP规范的AlarmInformation记录对象。或者或此外，可以在根据3GPP规范的性能测量记录对象中插入所述至少一个上下文标识符。生成所述事件消息的步骤在此情况下可以包括：在所述事件消息中插入所得对象。
根据另一方面，提供一种计算机程序产品。所述计算机程序产品 包括程序代码部分，用于当在计算设备上运行或执行所述计算机程序产品时执行在此所描述的方法中的一种或多种的步骤中的一个或多个。所述计算机程序产品可以存储在计算机可读记录介质(例如永久或可重写存储器、CD-ROM或DVD)中。也可以提供所述计算机程序产品，以用于经由计算机网络(例如互联网、移动通信网络或无线或有线局域网(LAN))下载。
根据另一方面，提供一种确定一个或多个网元中发生的事件之间的关联性的装置，其中，所述事件之间的关联性是因根事件通过所述一个或多个网元的通信实体的传播而产生。所述装置包括：接口，被适配为：从一个或多个网元接收多个事件消息，其中，属于特定网元所报告的事件的事件消息传递在所述事件产生之时描述所述事件产生的所述通信实体的内部通信状态的一个或多个上下文标识符。所述装置还包括：处理器，被适配为：确定相同上下文标识符所链接的关联事件集合。
还提供一种生成能够确定一个或多个网元中发生的事件之间的关联性的事件消息的装置，其中，所述事件之间的关联性是因根事件通过所述一个或多个网元的通信实体的传播而产生。所述装置包括：检测器，被适配为：检测所述网元的通信实体中的事件的发生；处理器，被适配为：确定在所述事件发生之时描述所述事件发生的所述通信实体的内部通信状态的一个或多个上下文标识符，其中，所述处理器进一步被适配为：生成被配置为传递所述一个或多个上下文标识符的事件消息。所述装置还包括：接口，被适配为：向中央网络组件报告所述事件消息。
关联性确定系统包括用于确定事件之间的关联性的至少一个装置以及在此所讨论的用于生成事件消息的多个装置。所述用于确定关联性的装置可以是中央网络管理实体。所述中央网络管理实体可以位于通信系统的核心网络部分中。所述用于生成事件消息的装置可以位于核心网络部分、接入网络部分或通信系统的终端中。
单独装置可以被配置为实现在此所公开的任何方法、功能和步骤。
附图说明
本发明的其它方面、细节和优点将从下文结合附图对示例性实施例的描述中变得清楚，其中：
图1示意性示出了故障通过不同网元的协议栈的垂直和水平传播；
图2示意性示出了网元的实施例和网络管理实体的实施例，该网元被适配为生成事件消息，所述网络管理实体被适配为确定网元所报告的事件之间的关联性。
图3示出了说明生成并且报告事件消息的方法实施例的流程图；
图4示出了说明确定与多个事件消息相关联的事件之间的关联性的方法实施例的流程图；
图5A至图5C示出了说明确定与对等网元有关的上下文标识符的信令图；
图6A示意性示出了事件消息的格式；
图6B和图6D示意性示出了基于上下文标识符的事件消息的关联性以及得到的关联性图的生成。
图7示意性示出基于图2的通信系统的告警和性能事件关联性系统的实施例。
图8示出了说明确定用于图7的系统实施例的关联告警集合的方法实施例；
图9是示出了3GPP告警信息对象的实施例的属性的列表；
图10是示出了3GPP性能测量对象的实施例的属性的列表。
具体实施方式
以下，为了解释而非限制的目的，阐述具体细节，例如具体装置配置、具体流程图以及具体信令情况，以提供对本文所公开的技术的透彻理解。本领域技术人员应理解，可以在脱离这些具体细节的其它实施例中实践本发明。本领域技术人员应理解，例如，本文所公开的技术不限于下文中示例性讨论的根据3GPP规范的通信系统。
本领域技术人员还应理解，可以使用的单个硬件电路、与已编程微处理器或通用计算机结合的软件功能、一个或多个专用集成电路(ASIC)、一个或多个数字信号处理器(DSP)和／或一个或多个现场可编程门阵列(FPGA)来实现本文所解释的方法、步骤和功能。还应理解，可以在处理器以及与处理器耦合的存储器中实施本文所公开的技术，其中，所述存储器存储当由处理器执行时执行本文所讨论的步骤的一个或多个程序。
图2示出了可以实现本文所提出的技术的通信系统10的实施例。通信系统10包括中央网络管理实体(CNME)20以及多个网元(NE)30、40。NE30、40被适配为与彼此并且与CNME20进行通信，如箭头所示。
CNME20可以位于通信系统10的核心网络部分中。作为示例，CNME20可以位于网络运营商的操作和管理(O&M)站点上。
网元30、40可以位于通信系统10的核心网部分或接入网部分中。作为示例，可以通过符合长期演进(LTE)的或任何其它接入网的基站(例如eNodeB)来实现NE30、40中的一个或多个。备选地或此外，可以通过固定或移动终端(例如移动电话、智能电话、网络卡或棒或PC)来实现NE30、40中的一个或多个。此外，可以以网络路由器、网络交换机等的形式来实现NE30、40中的一个或多个。
NE30、40中的每一个可以具有带有一个或多个网络层的协议栈，如图1所示。例如，图2的NE30可以与图1中的NE3相对应，图2中的NE40可以与图1中的NE1和NE2中的任一个对应。
如图2所示，CNME20包括接口22，接口22被适配为从NE30、40接收事件消息。通过相似方式，每个NE30、40分别包括接口32、42，接口32、42被适配为向CNME20报告事件消息。此外，网元30、40的接口32、42分别允许在NE30与NE40之间交换各种消息和信令。
与特定NE30、40所报告的事件有关的事件消息可以通常遵守现有规范，例如3GPP TS32.111-2(告警集成参考点)、3GPP TS32.404(性能管理)、IETF标准RFC3877(告警管理信息库)、ITU-T推荐 X.733-02／92(信息技术开放系统互联系统管理：告警报告功能)以及TMF、OSS／J(见www.tmforum.org上的多技术操作系统接口(MTOSI)规范)。
在本实施例中，事件消息传递针对特定事件的发生信息。该发生信息包括一个或多个上下文标识符，该一个或多个上下文标识符描述在事件发生之时事件发生的通信实体的内部通信状态。通信实体可以是潜在地引起一个或多个次级事件的事件(例如故障、告警或与性能有关的动作)可能发生的任何实体。作为示例，通信实体故此可以是比如NE30、40中的任一。另外地或备选地，通信实体可以是NE30、40的任意组件，包括硬件组件、软件组件或其组合。此外，通信实体可以是NE30、40中的任意一个的网络协议层(如图1所示)或网络接口。由一个或多个上下文标识符描述的针对通信实体的内部通信状态可以与受事件所影响的通信实体或与受事件所影响的通信实体相关联的通信实体(例如其对等)的任意参数相关。
返回图2，除了接口22之外，CNME20还包括处理器24，处理器24被适配为确定相同上下文标识符所链接的关联事件集合。处理器24还可以被适配为执行一个或多个附加处理操作(例如，根据关联事件集合确定根事件)，下文将更详细地描述。
除了接口32之外，NE30还包括检测器34以及处理器36。检测器34被适配为检测NE30的通信实体中的(本地)事件的发生。处理器36被适配为确定发生信息，发生信息包括在事件发生之时描述事件发生的通信实体的内部通信状态的一个或多个上下文标识符。处理器36还被适配为生成事件消息，事件消息被配置为经由接口32向CNME20用信号传递发生信息。
在图2所示的实施例中，NE40具有与NE30相似的配置，因此除了接口42还包括检测器44和处理器36。应注意，在其它实施例中，NE40可以不具有任何事件检测和事件报告功能，并且从NE30看充当传统对等NE40。
以下，将参照图3和图4的流程图300、400来描述在事件报告和事件关联性的情况下NE30、NE40和CNME20的操作。由于NE40 被配置为以与NE30相似的方式进行操作，因此将仅更详细地描述NE30的操作。
NE30的操作在步骤302中开始，其中，检测器34检测NE30的通信实体中的事件的发生。事件可以是与NE30(如图1中所示的NE3)的协议栈的特定协议层中发生的告警关联的故障。特定协议层因此构成事件发生的通信实体。
在下一步骤304中，处理器36确定包括在事件发生之时描述通信实体的内部通信状态的一个或多个上下文标识符的发生信息。每个上下文标识符可以采取名称-值对的形式或任何其它适合于传送的数据结构，在该实施例中，一方面上下文类型指示以及另一方面有关上下文标识值。通常，可以由以下上下文类型指示(以及相关联的上下文标识值)中的一个或多个描述通信实体的通信状态：
用户上下文
上下文类型指示可以指示用户上下文(例如用户设备(UE)上下文)。在这种实现中，有关的上下文标识值可以是给定事件与之有关的UE的标识符。如果例如eNodeB或当对于特定UE执行任何动作时经历故障的移动性管理实体(MME)实现NE30，则可以在针对该特定故障的发生信息(以及相关联的告警)中包括上下文类型指示的对应上下文标识符“用户上下文”。可以通过用于特定UE的有关上下文值指示(例如相关联的国际移动订户身份(IMSI)、国际移动设备身份(IMEI)或S1_AP_ID(取决于NE30是由eNodeB还是在LTE的情况下由MME实现))来补充对应上下文标识符。
网络小区上下文
除了“用户上下文”类型的上下文标识符之外或作为对其的备选，针对给定事件的发生信息可以包括具有上下文类型指示的上下文标识符“网络小区上下文”。有关的上下文值指示可以在此情况下是受事件(例如与告警相关联的故障、性能管理动作或性能测量动作)影响的小区的标识符。
网元上下文
此外，发生信息可以附加地或备选地包括与受事件所影响的网元 (例如eNodeB)的有关标识符(即上下文标识值)相关联的上下文类型指示“网元上下文”。
网元组件上下文
网元组件可以是受事件所影响的网元的内部板或接口。可以(附加地或备选地)添加到发生信息的对应上下文标识符可以包括对应上下文类型指示“网元组件上下文”连同对应内部组件的标识符(即上下文标识值)。
网络接口上下文
上下文类型指示“网络接口上下文”与事件与之有关的NE30的一侧上的接口连接有关。取决于特定协议层，可以通过互联网协议(IP)地址、(以太网)媒体访问控制(MAC)地址等作为有关上下文标识值来标识接口。
网络协议上下文
上下文类型指示“网络协议上下文”，“网络协议上下文”指示生成事件的协议层。有关上下文标识值可以是特定协议层保持在NE30的一侧上的上下文的标识符。通常，上下文标识值取决于特定协议层维护上下文信息的聚集等级。作为示例，可以按用户上下文(在此情况下，有关上下文标识值可以与针对上述上下文类型“用户上下文”是相同的)、按接口连接等来维护上下文信息。
卖家特定容器上下文
卖家特定容器上下文是每个网元卖家或网元组件卖家可以确定一个或多个专用(例如，非标准)上下文标识符的占位符。
应注意，可以在针对NE30所报告的事件的发生信息中包括针对报告NE30的一侧和报告NE30的对等侧(例如NE40)的分离上下文标识符。相应地，针对在NE30的一侧上发生的事件的NE30用信号传递的发生信息还包括与其对等NE40有关的上下文标识符。具体地说，NE30所报告的发生信息中可以包括与对等NE40关联的以下上下文类型(以及有关标识)：网元上下文、网元组件上下文、网络接口上下文、网络协议上下文和卖家特定容器上下文。对于这些特定上下文类型，有关上下文标识值将因此与对等NE40的一侧上的对应标 识符有关。
一旦在步骤304中处理器36已经对于特定事件确定发生信息(包括一个或多个上下文标识符)，处理器36就在步骤306中生成事件消息。取决于事件和通信系统的性质，NE30可以通过各种方式来生成事件消息。事件消息被配置为用信号传递发生信息并且将通常包括上下文标识符集合。
如上所述，特定事件消息可以同时用信号传递与报告NE30的一个或多个通信实体(例如协议层或接口)有关的至少一个第一上下文标识符以及与对等侧上的NE40的通信实体有关的一个或多个第二上下文标识符。NE30可以通过各种方式来获得关于一个或多个第二上下文标识符的对应信息。作为示例，NE30可以在上下文设置处理和／或配置处理期间从CNME20或在上下文交换处理期间(直接)从NE40获得一个或多个第二上下文标识符。备选地，CNME20可以在从NE30接收事件消息时在本地确定与NE40有关的一个或多个第二上下文标识符，其中，事件消息(仅)包括与NE30有关的一个或多个第一上下文标识符。
一旦处理器36在步骤306中已经生成了事件消息时，在步骤308中经由NE30的接口32向CNME20报告该事件消息，以用于事件关联性。
现将参照图4的流程图400更详细地描述在事件关联性的情况下的CNME20的操作。在初始步骤402中，CNME20一般经由接口22从多个网元(例如，图2所示的NE30和NE40)接收多个事件消息。
对于通过单个网元(例如通过NE30的协议栈)垂直地传播的事件，CNME20将从单个网元接收多个事件消息，其中，事件消息与该网元的不同通信实体(例如，协议层)有关。另一方面，对于通过多个网元(例如图1中的NE3、NE2和NE1以及图2中的NE30和NE40)水平传播的事件，CNME20将从不同网元接收针对关联事件的事件消息。通常，事件既水平地又垂直地传输，从而CNME20将从一个且同一网元接收针对给定根事件的多个事件消息，并且从不同网元接收多个其它事件消息。
CNME20收集在步骤402中接收到的事件消息，并且在步骤404中连续地或不连续地确定一个或多个关联事件集合。在相同上下文标识符链接两个事件的情况下，这两个事件被看作是关联的。这种链接可以经由直接链接或间接链接而发生。对于针对特定事件指示两个或更多个上下文标识符的事件消息，间接链接的关联事件包括通过相同上下文标识符的链经由一个或多个中间事件所链接的具有非相同上下文标识符的事件，将在下文中参照图6B更详细地讨论。
如上所述，NE30向CNME20报告的发生信息可以提供与NE30的对等(例如NE40)有关的关联性信息。这种关于对等侧的信息可以连同关于源侧(即，NE30)的对应信息一起传送针对CNME20的整体协议层上下文。虽然受事件所影响的NE30可以在本地确定以上所列出的很多上下文信息，通过NE30或CNME20将必须在分离的过程中获得与对等侧有关的上下文信息。在下文中，将参照图5A、图5B和图5C更详细地解释用于在图2的通信系统10内分发上下文标识符或有关信息的三个示例性过程。在图5A、图5B和图5C的情况下应理解，上下文信息可以通常包括一个或多个上下文标识符。
图5A示出集中式上下文分发方案，其中，CNME20(或关联域管理器或DM)具有关于单独NE30、40、……在通信系统10内如何彼此连接并且关联的信息。图5A所示的方法包括上下文设置或配置处理。
如图5A所示，在第一请求／响应步骤502中，CNME20检索与NE30的对等(例如，NE40)有关的上下文信息。在一个实现中，从事件可以发生在源侧上的对等的管理对象实例中检索上下文信息。
3GPP规范中定义管理对象实例。简而言之，管理对象实例是针对O&M系统的网元表示。管理对象通常描述特定网元、其属性等。例如，可以存在针对接入网元(例如eNodeB)的管理对象实例，其描述eNodeB的属性(例如eNodeB的名称和地址、其操作的频率、其相邻eNodeB等)。
如果CNME20是该上下文信息的源，则可以省略步骤502。一般来说，CNME20在网络进入操作之前配置网元的属性，该属性包括诸 如对等网元的名称和地址等的具体属性。在特定情况下，CNME20可以因此不需要网元的对等上下文，因为CNME20可以初始地配置此信息(并且因此应具有其本地信息，而无需联系网元)。
在随后的上下文设置／确认步骤504中，CNME20向NE30发送与NE30的一个或多个对等有关的上下文信息。响应于对等上下文信息的接收，NE30在可以基于该对等上下文信息生成事件，在NE30中执行所有管理对象实例的设置。
在发生事件时，NE30于是在步骤506中将事件消息报告给CNME20，如以上参照图3的流程图所描述。事件消息用信号传递与事件关联的发生信息，该发生信息包括与源NE30有关的上下文信息以及与一个或多个对等网元(例如NE40)有关的上下文信息。
图5A所示的上下文分发方案对静态网络配置(例如对于小区和传送网络配置不频繁改变的网络)尤其有用。图5A所示的方案的优点在于：当事件消息到达CNME20时，CNME20不需要进行的附加后处理(因为事件消息已经包含与源NE30和对等NE40有关的上下文信息)。对于动态配置(例如UE连接)，上述上下文分发方案将在CNME20的一侧上消耗大量处理能力，从而与图5A的集中式方法不同的内容分发方案可能是优选的。需要在CNME20与NE30、40之间的接口上定义特定上下文请求／上下文设置信令机制的事实也可以在特定情况下被看作集中式内容分发方案的缺点。
图5B示出结合每个网元对之间的协议接口配置来执行上下文初始化的分布式内容分发方案。相应地，图5B所示的方法可以被看作网元之间的上下文交换处理。
如图5B所示，在NE30与NE40之间并且在另外每一对网元之间执行上下文握手请求／确认步骤512。也可以基于所指定的传统连接设置命令的指定属性或通过包括必要上下文信息作为信号属性的标准化或私有握手信号来执行用信号传递步骤512。当使用连接设置命令时，可以在例如特定协议层的现有信令消息中包括上下文信息。于是在步骤514中用信号传递的任何事件消息可以包括与源NE30有关的上下文信息以及与对等NE40有关的上下文信息，如上文参照步骤506 所描述。
图5B的上下文分发方案具有无需CNME20的一侧上的附加后处理的优点，因为事件消息已经包括与NE30的对等侧有关的上下文信息。然而，在一些情况下，可能需要在各个网元之间的接口上定义新的握手信号。
图5C示出用于在通信系统10内分发上下文信息的示例性第三方法。根据图5C所示的后处理方案，CNME20具有网元在整个通信系统10内如何彼此连接的信息，但上下文信息在网元配置或设置处理期间并未被初始化。此外，在步骤522中，当事件发生在NE30的一侧上时，NE30向CNME20提交事件消息(具有丢失对等上下文信息)。一旦CNME20获取事件消息，其就基于事件消息中所包括的源上下文信息并且基于所存储的配置信息来确定丢失对等上下文信息。可以例如基于事件消息中所包括的源上下文信息，通过在CNME20的配置数据库中的查找处理来确定所存储的与对等上下文信息有关的配置信息。
与图5A的集中式上下文分发方案相似，图5C所示的后处理方法尤其适用于静态网络配置。后处理方法的优点在于不需要CNME20与报告NE30之间的附加信令。另一方面，必须在可以开始事件关联之前执行后处理。因此，当例如以类似突发的方式来报告事件并且CNME20需要在短时间段内关联用于大量事件的对等上下文信息时，图5A和图5B的上下文分发方案可能优于图5C的后处理方法。
以下，将参照图6A至图6D讨论事件消息的示例性格式以及CNME20的处理器24所执行的相关联的事件关联性方案。
图6A示出包括发生信息部分和内容部分的事件消息的实施例。发生信息部分包括多个上下文标识符(ID)，该多个上下文标识符(ID)描述：在事件发生时事件消息之下的事件已经发生的通信实体的内部通信状态。在下文中，将假设事件发生的通信实体是NE30的协议堆栈的特定协议层L(i)。应理解，通信实体也可以同样是NE30或其任何其它组件或接口。
用IDs_L(i)来表示对于协议层L(i)已知的上下文标识符集合。 上下文标识符可以是上述任何上下文类型，并且可以与报告NE30以及其对等NE40有关。图6A所示的事件消息的内容部分可以包括时间戳(例如，指示事件发生或生成事件消息的时间点)，并且可选地包括指定事件的其它细节的任何必要事件描述以及事件特定值或属性。
总之，事件消息可以表示如下：
Event Message(IDs_L(i)，content)，
其中，IDs_L(i)={id_L(i，1)，id_L(i，2)，…id_L(i，n)}，
并且，content={时间,其它事件细节}。
在以上所示的事件消息实施例中，可以通过索引对(i，j)来对每个上下文标识符进行索引，其中，第一索引(i)标识协议层或发布特定事件的网元组件，而(可选)第二索引(j)标识给定协议层或网元组件(i)所使用的特定上下文标识符。作为示例，id_L(i，1)发消息通知的参数n=1可以表示用户上下文。id_L(i，1)的值发消息通知有关上下文标识指示(例如IMSI)。
应注意，层L(i)的单独上下文标识符将与对于NE30的其它协议层(例如层L(i+1)或层L(i-1))发消息通知的或由其它网元(例如，NE40)发消息通知的特定上下文标识符相同。经由不同事件消息所用信号传递的公共上下文标识符的构思允许：同一网元的不同组件或层所报告的(垂直事件传播)或不同网元(例如，针对同一层)所报告的(水平事件传播)事件的关联性。
图6B示出六个不同事件消息M1至M6所表示的六个关联事件。如图6B所示，如果相同上下文标识符链接两个事件消息M(a)和M(b)以及关联事件，则它们被解释为关联的。如果相同上下文标识值id_L(i，k)存在于两条消息的上下文标识符集合的相同上下文类型k，则第一消息M(a)的上下文标识符被解释为与第二消息M(b)的上下文标识符相同。
事件可以由相同上下文标识符直接或间接地链接。在图6B的情况下，直接链接由每个消息对的相同上下文标识符之间的线指示。如图6B所示，也可以存在通过相同上下文标识符的链的经由中间事件 消息(或事件)在关联事件之间的间接链接。例如，在图6B中，消息M1与消息M2直接链接，并且消息M1经由消息M2间接与消息M3、M4和M5链接。经由涉及消息M2和M4的二阶间接链接，消息M1还与消息M6链接。
CNME20的处理器24被配置为通过分析关联上下文标识符来确定关联事件消息集合(并且因此确定关联事件集合)，如上文参照图6A和图6B所述。一旦已经确定关联事件集合，处理器24就被配置为生成关联性图，如图6C和图6D所示。
从图6C可以清晰看到，关联性图通常包括顶点V和连接顶点V的边E。每个顶点V表示特定事件(或事件消息)，每个边E表示所连接的顶点V所表示的事件之间的关联性，其中，如果存在与两个事件关联的至少一个相同上下文标识符，则在两个顶点V之间添加边E。基于图6所示的消息M1至M6之间的关系，将因此获得图6C所示的关系图。
处理图6C所示的关联性图还可以由处理器24处理，如图6D所示。在第一步骤中，可以应用剥离(stripping)操作，以移除不重要的关系(即，边)。剥离操作可以取决于特定分析使用情况，并且可以基于执行关联性操作的关联性引擎中的内建信息的控制。作为示例，如果仅估计硬件故障对性能的影响，则可以省略与软件有关告警事件关联的边。
在下一步骤中，应用一个或多个规则，以将方向和权重添加到顶点。规则可以例如指定两个事件之间的发生关系的顺序。于此，可以估计关联事件消息中所包括的时间戳。可以基于每一对关联事件的关联性强度来将任何权重添加到顶点(和／或边)。可以基于关联性引擎中的内建先验信息来确定关联性强度。
处理器24可以在其他步骤中分析具有方向性和加权的顶点的所得关联性图，以用于确定通过各个通信实体传播并且导致次级事件的根事件。一旦已经确定根事件，就可以发起适当的管理动作。
以下，将参照告警事件(见，例如，3GPP TS 32.111-2)和性能事件(见，例如，3GPP TS32.404)讨论图2所示的通信系统10的示例 性3GPP实现。图7示出包括多个网元30、40等以及用于告警关联性的中央O&M组件20的对应告警和性能事件关联性系统10。告警事件由网元(NE30、NE40、……)在本地检测，并且经由专用告警消息(见例如3GPP TS 32.111-2)报告给充当CNME的O&M组件20。每个网元包括网元告警报告(NEAR)功能，NEAR功能充当负责检测故障、生成告警消息并且出于关联性目的而以可用的上下文标识符来标记告警消息的给定网元中的逻辑实体。
O&M组件20集中地收集来自各个网元(例如NE30和NE40)的告警消息，用于进一步处理和分析。如图7所示，O&M组件20包括告警关联性功能，告警关联性功能负责找出给定网元的不同组件或不同协议层所报告的告警事件之间以及还有不同网元所报告的告警事件之间的关联性。上文已经参照图6A至图6C描述了告警关联性功能的示例性操作模式。
告警关联性功能的输出是将受规则引擎所处理的无方向关联性图，如以上参照图6D所讨论。规则引擎的输出是告警关联性的有向和加权图，可以直接处理该图用于告警根原因分析。
可以可选地通过使用对于告警事件关联性所使用的相似上下文标识符匹配机制将性能事件与告警事件进行关联来扩展所得告警关联性图。该方面使得以通常如上所述的上下文标识符来扩充每个性能事件(例如每个性能事件消息或记录)成为必要。以性能有关数据所扩充的所得图可以用于告警影响分析或告警优先化目的。
现将基于图8的流程图800解释以上参照图6A所讨论的O&M组件20关于示例性事件消息格式的告警关联性功能的操作。
在第一步骤802中，一个接一个地取得O&M组件20所维护的告警列表上的单独告警事件(具有对应上下文标识符)，以用于作为新顶点添加现有或新关联性图中。在下一步骤804中，确定在步骤802中从列表取得的告警是否与任何现有关联告警集合关联。如果对于任意(n，m)，都有id_L(i，n)=id_L(j，m)，则告警被解释为与另一告警关联(并且属于相同的关联告警集合)。应注意，可以可选地仅对可用上下文标识符的子集执行步骤804中的匹配处理。
如果存在现有关联告警集合AS(k)，则在步骤806中，将下一告警添加该集合中。此外，在图中在步骤802中新取得的告警的顶点与告警集合AS(k)中的其余告警的顶点之间绘制边。然后在步骤810中确定告警列表是否包含待处理的任何其它告警。如果情况如此，则方法循环回到步骤802，其中，从列表取得下一告警。如果已经处理所有列出的告警，则完成关联性操作(步骤812)。
如果在步骤804中确定步骤802中所取得的告警不隶属任何现有告警集合AS(k)，则在步骤814中创建新关联告警集合AS(l)。然后，在步骤816中，对应告警添加到告警集合AS(l)，方法继续步骤810。
可以通过与图8所示相同的方式来完成告警与性能事件的关联。在此情况下，在告警与性能事件之间而不是两个告警之间匹配上下文标识符。为此，将生成具有与告警事件相同上下文标识符(或至少它们的子集)的(包括，例如，计数器、密钥性能指示符(例如，所接收到的信号强度)等的)性能事件。
以下，将更多地关于一方面告警以及另一方面性能测量数据讨论以上提出的上述技术的示例性3GPP实现。
至于告警报告功能，针对上下文标识符的可选属性contextIds可以添加到标准化告警记录，如3GPP TS32.111-2的章节5.3.1.2中所讨论。图9所示的列表实施例包括AlarmInformation对象类的传统属性外加新属性contextIds。
AlarmInformation对象类通常与关于在受监控的实体(例如受监控的网元)中已经发生的并且在IRP代理与IRP管理器之间的接口Itf-N上的告警IRP基准点上所交换的告警事件的信息有关，如3GPP TS32.111-2所讨论。应注意，出于关联性的原因，没有属性contextIds的AlarmInformation对象中的现有属性将通常并不足够。作为示例，属性alarmId用于标识受监控的实体所调用的告警列表内的给定告警。alarmId属性仅在objectInstance属性所标识的一个给定的受监控实体所生成的给定告警列表内是唯一的。notificationId属性标识携带告警列表中所包含的特定AlarmInformation对象的告警通知。其余现有属性描述关于告警的细节，例如其已经发生的时间、关于已经发生的特 定事件的信息等。
具体地说，现有AlarmInformation对象中可用的标识符(alarmId、notificationId、objectInstance)可以仅用于告警的无歧义标识，但它们并不传送其它受监控实体或同一受监控实体的不同组件潜在地生成的关于对其它告警的可能关系的任何有用信息。故此，现有标识符并不足以确定相同或不同受监控实体所生成的多个告警之间的关联性。
另一方面，新定义的属性contextIds是允许告警关联性的名称-值对的形式(每个对包括上下文类型指示参数和有关上下文标识值参数)。在下文中所讨论的具体实现中，讨论使用八个名称-值对并且使用可以保存未来扩展的列表结构。
以下是八个名称-值对的名称(即，上下文类型标识)。上文已经定义了它们语义。
用户上下文：  UE上下文标识符，
网络小区上下文：  单元标识符，
NE上下文：  节点标识符，
NE组件上下文：  节点内部元件标识符，
网络协议上下文(源)：  协议上下文标识符-源侧，
网络协议上下文(对等)：  协议上下文标识符-对等侧，
网络接口上下文(源)：  接口标识符-源侧，
网络接口上下文(对等)：  接口标识符-对等侧
卖家特定容器  私有id容器。
以下是抽象句法标记1(ASN.1)格式中的八个名称-值对的示例性表述：


以下是接口定义语言(IDL)格式中的八个名称-值对等的示例性表述：


3GPP TS32.111-2的章节5.3.1.2中所定义的相同contextIds属性可以添加到网元所生成的性能测量数据中。性能测量数据可以是计数 器、密钥性能指示符或性能管理事件。为了传送此信息，可以通过图10所示的contextIds属性来扩展性能测量记录对象定义(见3GPP TS32.404的章节2.3)。以上已经描述了针对属性的可能的ASN.1和IDL表述。
从以上示例性实施例的描述变得显而易见的是，本发明允许所生成的事件的关联性是通信系统的不同部分。可以仅对于告警、仅对于性能测量数据或对于告警和性能测量数据的组合执行关联。性能测量数据可以源于用户终端(例如UE)或一个或多个网元。基于关联事件，可以执行数据分析功能以确定根事件(例如问题的根原因)或估计事件的严重性、用户所感知的事件对系统性能的影响或来自操作者观点的影响。
在一个实现中，可以实现仅用于单个网元的内部方面的技术，从而仅需要现有实现中的最小修改。例如，可以省略对于对等上下文信息发布而具体地引入的任何通信机制，因为依赖于例如经由遗留协议消息在特定网元中可用的网络内元件上下文标识符是足够的。在最小实现中，扩展具有在网元中无论如何可用的合适的上下文标识符的事件消息(例如告警报告)并且为了事件关联性的目的而可能地与CMNE中可用的静态或半静态配置数据组合而使用它们将是足够的。
虽然以上所讨论的实施例关注3GPP IRP规范，但应理解，本文所示技术还可以用于包括上述情况的任何其它事件管理方法、系统或规范。
虽然已经参照示例性实施例描述了本发明，但应理解，描述仅为了说明的目的。相应地，期望本发明的范围仅由所附权利要求限定。