CN103081403A - 用于使用事件分析通信系统的操作的方法和装置 - Google Patents
用于使用事件分析通信系统的操作的方法和装置 Download PDFInfo
- Publication number
- CN103081403A CN103081403A CN2010800678626A CN201080067862A CN103081403A CN 103081403 A CN103081403 A CN 103081403A CN 2010800678626 A CN2010800678626 A CN 2010800678626A CN 201080067862 A CN201080067862 A CN 201080067862A CN 103081403 A CN103081403 A CN 103081403A
- Authority
- CN
- China
- Prior art keywords
- event
- burst
- unit
- causality
- record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/04—Processing captured monitoring data, e.g. for logfile generation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
- H04L41/064—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving time analysis
Abstract
本发明涉及一种用于通信(电信或者计算机)系统中的事件分析的方法和装置。具体来说,本发明涉及一种用于分析表示通信系统中活动的事件的方法和装置。实施例提供用于分析通信系统的操作的进步技术。实施例通过首先检测事件的突发并且使用检测的事件突发记录建立事件和系统操作报告之间的因果关系来提供自底向上法,检测的事件突发记录表示系统里的事件中突发行为的发生。基于发现的因果关系,可以通过确定与系统操作变化相关的事件突发的事件相关联的参数来识别系统操作变化的原因。
Description
技术领域
本发明涉及一种用于通信(电信或者计算机)系统中的事件分析的方法和装置。具体来说,本发明涉及一种用于分析表示通信系统中活动的事件的方法和装置。
背景技术
本发明涉及通信系统中的事件的分析。在以下的描述中,事件是表示通信系统中的活动的对象。事件不仅仅是消息,还可以包括相关数据,例如描述事件所表示的活动的参数。通常,可以通过数据结构表示事件,所述数据结构具有标识事件的事件id;定义事件的类型的事件类型字段;定义事件发生的时间的事件定时字段;以及可选地,包含关于事件所表示的活动的更多信息的事件参数字段。事件具有与事件所表示的活动一样的相互之间的关系,例如,事件的相对定时或者事件之间的因果关系。
在一些实施例中,术语“事件”涉及通信系统中的操作和维护(O&M)事件,例如,携带关于O&M发生的信息的对象。在一个示范性移动无线电通信系统中,事件的一个定义如下:
对象或者信号,携带关于任何可辨别发生的信息,它对于管理移动无线电基础设施或者服务的交付以及评估偏差可能对服务造成的影响有意义。
事件可用来监测网络和服务性能,并且为网络运营者提供用于分析网络操作的统计数据。特别是,基于事件的应用处理通信系统产生的事件可以提供:实时的网络性能的重要统计指示符;以及详细网络统计数据的长时间存储的解决方案;以及使网络的详细故障排查成为可能的信息。
监测表示通信系统的O&M活动的事件的突发的发生是有意义的,因为事件突发的检测对于发现系统问题或者瓶颈可能是非常有用的。
通常,当数据流中的事件发生频率相对于正常发生频率在短时间段内明显上升并且可能持续一定的时段时,认为发生了事件突发。事件的临时脉冲可能由很多因素引起,并且不太可能表明存在问题或者用户服务体验的恶化。
当考虑时间连续数据(例如通信系统中的事件)时,通信系统中的变化的一个重要指示符为事件的突发的存在。特别是,取决于容量和触发,过多数量的带有失败代码参数的事件可以是节点或者系统的节点之间的链路中失败的有效指示,而过多数量的非失败事件(例如没有失败代码参数)可以在任何失败发生之前指示系统中的变化,例如拥塞。因此,突发的识别能够提供关于所监测服务质量和/或网络性能的变化的有用洞察,允许运营者以及时的方式行动,以作出明智的决定。
然而,指示通信系统中事件突发发生的事件突发行为的可靠检测具有以下问题:
首先,普遍认识到,当在不同的时标上考虑时,网络接入和服务使用能够变化很大。这导致当在不同的时间段上测量时,事件发生的频率会明显变化。
另外,不同类型的事件具有不同的发生行为和不同的重要程度。某些类型的事件可能比其它事件发生频率更高,并带有更多的正常可变性,因此不可能通过简单计数和比较每一事件发生的绝对数量来确定事件的突发行为。
最后,事件处理可施加显著的性能要求,因为移动无线电系统和/或固定IP网络可产生大量的事件,例如,以每秒60k事件的速率。处理这样大量的事件要求高性能应用以及尽可能少的存储空间和内存消耗。
移动无线电系统或固定网络中的现有事件处理方法包括:
第一种事件处理方法依赖于计算简单的成功/失败比率,是最简单的事件处理方式。例如,为了确定附连成功比率,用成功附连尝试的数量除以附连事件的总数,如下所示:
尽管简单,比率计算仅提供服务性能的概括性观点,并且计算结果可能使人误解。特别是,事件发生的频率当然是可变的,计算平均失败或成功比率对于具有不同等级的事件发生可变性的事件可能导致同样的结果。
第二种事件处理方法依赖于定义和配置一个或多个计数器。当处理事件时,取决于所处理的事件而更新不同的计数器。在由粒度周期参数控制的正则点,计数器值被抽样,被收集到报告中并复位。这些报告随后被输出,作为分开的文件。人工选择要计算的计数器的集合。例如,可能应用滤波器,以便仅对带有特定参数集的事件的数量计数到特定值。滤波器标准可以是单值标准或多值标准,其中,如果多值列表中的任何值与特定事件参数相匹配,则滤波器传递该事件。
为了针对每一属性值监测事件(例如,带有原因代码13的不成功附连事件),可以为每一选择的滤波器值(例如分配)创建一个计数器。
基于计数器的分析方法,尽管流行,但是有它们固有的约束。
第一,可能无法在会话基础上相关来自系统中不同计数器的结果,因为通常计数器缺少良好的相关特性。创建服务质量测量和实现基于计数器的问题诊断是困难的。
第二,基于计数器的事件分析为系统引入瓶颈。存储和处理的可缩放性是基于事件的应用的最大难题之一。计数器的值如果得不到进一步分析(这要求额外的处理资源)就无意义。通过在多个属性中选择几个属性值上的分配,创建的计数器的总数是对于每一属性的滤波器值的数量之积。这能够从单监测器创建很大数量的计数器,当执行问题诊断时导致显著的复杂性。
第三,通常计数器是基于固定间隔来计算的,例如间隔值为5,15,30和60分钟。一方面,突发检测要求计数器计算之间的间隔相当短,因为当事件突发发生时甚至5分钟间隔也可能影响问题分析的准确性。然而,固定间隔越短,计数器产生的数据越多,这造成系统上的进一步存储和处理开销。在很多布置中,在基于计数器的方法中,很难选择平衡粒度与存储和处理开销的计数器间隔。
第三种方法是复合事件处理(CEP),其主要是如下的事件处理概念:处理多个事件,目标是在事件云内识别有意义的事件,使用诸如许多事件的复合模式的检测、事件相关和提取、事件层次、事件之间的关系(诸如因果关系、成员资格和定时)以及事件驱动的过程之类的技术。
但是,在事件因果关系和模式发现中的现有的复合事件处理方法主要是基于人工的。考虑到移动无线电系统和固定IP网络中事件的性质,为事件相关人工定义和维护规则和策略可能是很困难的。
突发检测方法已经用于金融市场环境。为金融和股票市场提出的突发检测方法把事件看作新闻、消息或者任何其它信息格式。在这样的环境中的事件不适合用于分析通信系统的操作或者用于通信系统中的故障诊断。
发明内容
根据本发明的一个方面,提供一种使用表示通信系统中活动的事件分析通信系统的操作的方法。在本方法的第一步骤中,检测事件的突发。在本方法的第二步骤中,在因果关系处理步骤中使用所检测的事件的突发和系统操作信息来识别引起系统操作变化的至少一个有效事件突发。在第三步骤中,从与有效事件突发内的事件相关联的信息确定系统操作变化的原因。
根据本发明的第二方面,提供一种使用表示通信系统中活动的事件的通信系统操作的分析器。分析器包括突发分析单元,用于接收多个表示系统中活动的事件,并且用于检测事件的突发和产生对应的事件突发记录。分析器还具有因果关系单元,该单元被设置成接收事件突发记录和系统操作信息,并在因果关系处理步骤中使用事件突发记录和系统操作信息以识别引起系统操作变化的至少一个有效事件突发。分析器还具有耦合到因果关系单元的原因分析单元,原因分析单元从与有效事件突发内的事件相关联的信息确定系统操作变化的原因。
根据本发明的第三方面,提供一种具有操作分析器的通信系统节点,操作分析器包括元件突发分析单元、因果关系单元和原因分析单元中的至少一个。元件突发分析单元被设置成接收多个表示系统中活动的事件,并且检测事件的突发,产生对应的事件突发记录,而且耦合到因果关系单元,从而为因果关系单元提供事件突发记录。因果关系单元耦合到元件突发分析单元,并被设置成从元件突发分析单元接收事件突发记录,还被设置成接收系统操作信息,并被设置成在因果关系处理步骤中使用事件突发记录和系统操作信息以识别引起系统操作变化的至少一个有效事件突发,并提供对应的相关事件突发记录给原因分析单元。原因分析单元耦合到因果关系单元以接收有效事件突发记录,并被设置成从与有效事件突发记录内的事件相关联的信息确定系统操作变化的一个或多个原因。
附图说明
现在参考附图,通过示例来描述本发明,附图中:
图1是一个示范性系统的框图,在该系统中可实现本发明的实施例;
图2是示出根据一个实施例的方法的步骤的流程图;
图3是示出根据一个实施例的示范性分析器的框图;
图3a示出根据一个示范性实施例的示范性突发记录;
图4说明用于事件突发检测的滤波器桶模型;
图5是示出根据一个示范性实施例的移动无线电系统中事件的自动突发检测的数据流程图;
图6是示出用于事件突发检测的滤波器桶模型的流程图;
图7是示出根据一个示范性实施例的移动无线电系统中事件的自动突发检测的方法中的步骤的流程图;
图8示出事件之间自动相关的方法;
图9示出用户服务性能和事件之间的自动相关的方法;
图10说明示出事件之间以及事件与服务之间的因果关系的因果图;
图11说明根据一些实施例将事件汇聚到多个事件流中。
具体实施方式
实施例提供进步的技术来分析通信系统的操作。实施例提供自底向上法,其中,首先检测事件的突发,并且使用表示系统中的事件中突发行为发生的所检测事件突发记录建立事件和系统操作报告之间的因果关系;以及基于所发现的因果关系,通过确定与系统操作变化相关的事件突发的事件相关联的参数来识别系统操作变化的原因。
在一些实施例中,事件参数,例如,失败代码(和子失败代码)或者事件ID(或者能够将具有相似特征的事件编组的任何其它参数),可被用于识别系统中的服务问题或者潜在的服务问题。
在示范性实施例的描述中,失败代码和子失败代码被用作事件参数,用来分析服务问题的根本原因。然而,本领域技术人员要认识到,所提出的原因分析方法适用于其它事件参数和其它与事件相关的信息,并且并不是对于所有实施例都需要使用失败代码和子失败代码。特别是,在任何失败实际发生之前的情形中,实施例可被用于确定网络操作变化的原因。
因此,例如,对于靠近足球场的基站,当足球比赛导致足球迷到场人数的增加时,附连事件可能有突发发生。基站的负荷将增加,并可能导致移动宽带服务的延迟增大。
本发明的实施例的适当实现将使附连事件的突发发生能够与导致服务供应变化的网络操作变化相链接。在这种情况下,即使还没有失败,事件突发也正在发生。
将参考附图描述一个示范性实施例。虽然该示范性实施例是在移动无线电系统内实现的,但是要认识到,可在包括固定网络和移动无线电系统在内的很多不同类型的网络中实现不同的实施例。
图1是示出通信系统的简图,在该通信系统中可实现本发明的实施例。图1的系统中各要素之间的实线连接表示业务或者数据连接,而虚线表示信令连接,这对于本领域技术人员来说从图1的教导中会清楚。
图1中的网络布置提供通信系统100,包括无线电接入网102和核心网104,它们为用户设备(未示出)提供通信服务。核心网104可以连接至互联网协议(IP)网络106。
无线电接入网102被设置成提供空中接口,通过它,用户设备能够接入核心网104。如本领域技术人员将认识到的,很多不同的空中接口技术都是可用的,不同的空中接口技术可以作为通信系统的一部分被包括在内。在图1所示的示范性布置中,全球移动通信系统(GSM)网络108具有示范性基站收发信台(BTS)110和基站控制器(BSC)112;第三代通用移动电信系统(3G-UMTS)网络114具有示范性Node B 116和无线电网络控制器(RNC)118;以及长期演进(LTE)网络120具有示范性增强型Node B(eNode B)122,这些示于无线电接入网102中。
核心网104被设置成为由无线电接入网102支持的往返于用户设备(未示出)的通信提供呼叫路由和呼叫管理功能。示范性核心网104是基于系统架构演进(SAE)布置,具有系统架构演进网关(SAE GW)124,该网关提供业务路由功能,并耦合到IP网络106和示范性eNode 122以及示范性无线电网络控制器(RNC)118。另外,SAE网关(SAE GW)124经由在服务GPRS(通用分组无线电服务)支持节点(SGSN)126耦合到示范性基站控制器(BSC)112。
核心网104具有移动管理实体(MME)128,它耦合到SAE网关(SAEGW)124、在服务GPRS(通用分组无线电服务)支持节点(SGSN)126和增强型Node B(eNode B)122,从而为用户设备提供移动管理功能。
核心网104具有3GPP策略与计费规则功能(PCRF)130,它与SAE网关124耦合,以控制用户、用户组以及应用与通信系统的交互。
核心网104具有与在服务GPRS(通用分组无线电服务)支持节点(SGSN)126和移动管理实体(MME)128耦合的归属位置寄存器/归属订户服务器(HLR/HSS)132,它提供订户位置和注册功能。
按照对应的标准,图1所示网络的操作对本领域技术人员来说很常见,与本发明的操作并不直接相关。因此,在以下描述中将不会对图1中所示网络的操作进行进一步详细说明。
如图1所示,提供根据本发明的实施例的事件处理模块134。虽然图1中为了清楚而分开地示出事件处理模块134,但是在不同实施例中,事件处理模块134可以被实现为通信网络内的另一节点的一部分,这由本领域技术人员来选择。最一般地,本发明可以被实现在产生事件的任何节点中;或者在汇聚事件的任何节点中,或者在例如示范性实施例的通信系统中处理事件的任何节点中。另外,在一些实施例中,事件处理被分配到通信系统内的若干节点上。其它实施例可以被实现于终端或者监测设备中,例如从机顶盒或者服务质量监测器来监测服务质量事件。
示范性实施例的事件处理模块134从核心网节点接收移动管理事件136,以及从无线电接入网节点接收性能事件138。将参考附图来更详细地描述事件处理模块134。
图2是示出可实现于根据本发明实施例的事件处理模块134中的方法200的步骤的流程图。
在图2中所示的方法200的第一步骤202中,接收事件204,对事件204执行自动事件突发检测202以产生事件突发记录206。在示范性实施例中,事件204可包括移动管理事件136和性能事件138。将参考图6更详细地描述自动事件突发检测。
在图2中所示的方法200的第二步骤208中,步骤202中产生的事件突发记录206与操作报告210相关,以确定相关事件突发记录212。在这个实施例中,操作报告可涉及网络操作报告和/或用户服务报告。将事件突发记录206与操作报告210相关的步骤将参考图8和图9来更详细地描述。
在图2中所示的方法200的第三步骤214中,分析相关事件突发记录212以确定相关事件突发的事件之中最频繁操作参数。在这个实施例中,产生操作变化(例如用户服务问题)的可能原因216并输出,这将在以下描述中更详细地描述。
在示范性实施例中,事件204包括来自核心网节点的移动管理事件136和来自无线电接入网节点的性能事件138。
虽然在图2所示的示范性实施例中,在事件处理模块134中执行步骤202、208和214,但是在其它实施例中,步骤202、208和214中的事件的处理可以被分配在通信系统的若干节点上。特别是,可以在通信系统中的中央节点、产生136和138的本地节点、事件处理模块134或者任何其它事件处理应用中的一个或多个中以任何组合执行步骤202、208和214中的事件的处理。
在事件的分布式处理的实施例中,不发送每一事件给事件处理模块134,而是可更靠近事件的发源点来处理事件,使得在事件处理期间通信链路上发送的事件量减少。
可以以本领域技术人员认为适当的任何方式来实现该示范性实施例。例如,步骤208和214还可在本地执行,仅收集步骤208的相关事件突发记录(212)或者甚至仅收集发现的原因216。
图3示出适合于实现图2中所示方法的事件处理模块134的示范性实现。在图2的方法中呈现的事件204、事件突发记录206、操作报告210、相关事件突发记录212和操作变化的可能原因216也在图3中呈现,并且给予了对应的参考标号。
提供突发分析单元302以用于接收事件记录204,并对事件204执行自动事件突发检测以产生事件突发记录206。在示范性实施例中,突发分析单元302包括:事件流汇聚单元3021,被设置成接收事件记录和将事件汇聚成感兴趣的事件流;到达时间间隔计算单元3022,耦合到事件流汇聚单元3021;以及突发检测器3033,耦合到到达时间间隔计算单元3022。
在示范性实施例的移动无线电系统中,从网络的多个节点收集事件,这些事件或者在远程操作(ROP)文件中或者作为数据流,并且被馈送到突发分析单元302中。示范性实施例的突发分析单元302自动识别事件的突发行为并且输出突发记录206。示范性实施例中的突发分析单元的详细操作将参考图6在下文中更详细地描述。
图3a中示出突发记录206的示范性实施例。图3a的示范性突发记录206包括:
突发记录标识(ID)字段2061:用于标识突发记录;
突发记录长度字段2062:用于记录突发记录的长度;
事件信息块字段2063,用于记录关于突发中每一事件的信息(基于图3的事件流汇聚单元3021的编组标准),诸如事件标识(ID)或者事件标识(ID)的阵列,失败代码或者其它参数(如果存在),由于属于突发的原始事件可被缓存,如果必要的话,还包括指向原始事件的指针;以及
突发信息块2064:用于记录关于突发的信息,例如突发开始时标和突发持续时间以及突发门限。
然而,在其它实施例中,事件突发记录206可以包含与此处所描述的相比更多或更少或不同的信息,这由本领域技术人员来选择。
提供因果关系单元304,它从突发分析单元302接收事件突发记录206,从服务质量监测器(未示出)接收例如用户服务问题报告或者用户服务质量反馈之类的操作报告210。这样的服务质量监测器的一个例子是Agama IPTV监测解决方案,而本领域技术人员可以选择其它的服务质量监测器。在步骤202中产生的事件突发记录206与操作报告210相关,以确定相关事件突发记录212。在下面的描述中,将参考图8和图9更详细地描述因果关系单元304的操作。
提供原因分析单元306,它从突发相关单元304接收相关事件突发记录212。分析相关事件突发记录212(与突发识别过程并行或者在之后执行)以确定在相关事件突发的事件之中最频繁操作原因参数。最后,通过分析在与服务质量退化相关的那些突发事件之中不同操作原因的频率,来识别用户服务问题的原因216。
在下面的描述中将更详细地描述原因分析单元306的操作。
在示范性实施例中,提供用户接口308以接收用户服务问题216的可能原因,用于呈现给通信系统用户或者由其使用。
可以完全在软件模块中实现一些实施例,并且可以在硬件和软件的任何适当组合中实现其它实施例。可以以本领域技术人员认为适当的任何方式来实现该示范性实施例。在图3中所示的示范性实施例中,在硬件310中实现事件流汇聚单元3021和到达时间间隔计算单元3022。与IP分组处理类似,使用网卡(带有处理器和某些存储器)接收和处理事件。在该硬件模块中,基于事件ID或者其它标准来匹配事件,并把事件汇聚成事件流(图3)。使用计数器计算每一事件流的到达时间间隔。
在图3所示的示范性实施例中,在第一软件模块312中实现突发检测器3033,因果关系单元304和原因分析单元306。在图3所示的示范性实施例中,可选的用户接口308被实现为第二软件模块314。以软件模块实现的突发检测器模块3033读取硬件计数器以确定是否有突发。其余模块被实现为软件。
根据示范性实施例的自动事件突发检测现在将参考附图中的图4-7来描述。
在示范性实施例中,如果事件流的所接收事件的到达时间间隔突然并且显著减小,并且这样的情况持续一定时段,则识别出事件流中的突发。
根据一个示范性实施例,桶滤波器模型用于事件突发检测,这将参考图4和图5来描述。每一个桶表示临时保存事件和事件行为的记录的数据缓冲器。在一些实施例中,数据缓冲器可以实现为栈数据结构。
图4中所示的示范性突发滤波器模型具有三个桶,即,历史桶402、突发桶404和离群桶406。取决于事件流的事件接收之间的时间间隔的变化,事件流的每一事件被放置于历史桶402、突发桶404和离群桶406其中之一,这将在以下描述中说明。考虑以下的描述会清楚,可从先前的事件确定用于确定事件应该被放置于哪个桶的标准。
到达时间间隔为事件流中的一个事件的到达和下一事件的到达之间的时间间隔,针对事件流中的首个事件之后的每一事件实时地计算到达时间间隔。
在一些实施例中,可以通过记录先前事件的到达时标(tn-1)来实现这一点。通过到来的事件的到达时标(tn)减去先前事件的到达时标,能够计算到来的事件的到达时间间隔。
因此,inter-arrivaltime(n-1,n)=tn-tn-1。
到达时间间隔的倒数可用于为事件流中的事件提供估计到达率λn。
所接收事件的计算到达率λn可被用于确定事件流中的下一事件的预期到达率λ和到达率差异Δλ。
本领域技术人员将认识到,有多种方法可用于计算预期到达率λ。在一个方法中,保持历史事件到达行为的记录,并且从事件流中先前事件的到达率的平均值求出事件的估计到达率λn。
在示范性实施例中,指数移动平均算法被使用如下:
λ=α×λ+(1-α)λn 0<α<1
其中:
λn为所接收事件的计算到达率;
λ为该类型的事件的预期到达率;
类似地,本领域技术人员将认识到,到达率差异Δλ的计算可以在不同的实现中使用多种不同的方法。
在示范性实施例中,修改的指数移动平均算法被使用如下:
Δλn=|λn-λ|
Δλ=β×max(Δλ,Δλn)+(1-β)×min(Δλ,Δλn) 0.5<β≤1
其中:
Δλn为所接收事件的差异;
Δλ为该事件类型的事件的预期差异;
β为预定义的平滑因子,在一个示范性实施例中为:
使用以下公式,将所接收事件的计算到达率λn与预期到达率λ和预期差异Δλ进行比较: 公式1.1 公式1.2
其中τ为预定义的门限因子:τ≥1,通常τ=1或者2。
如果事件的计算到达率λn满足公式1.1,则事件发生中潜在地有效的突发正在发生。然而,这样的突发还可能是噪声,例如,事件到达率的临时增加。这在移动无线系统中可能是常见的,如用户设备故障之类的因素可触发失败事件的数量的临时增加。如果这是临时的,这样的事件行为不应该在突发检测步骤中被检测为突发。
图5是示出根据一个示范性实施例用于事件突发检测的桶滤波器模型的使用的数据流程图。
图5中,通过事件流汇聚单元502来汇聚事件204以形成至少一个汇聚事件流504。将参考图6的步骤602来更详细地描述该操作。
到达时间间隔计算单元506确定到达间隔度量,例如上述的事件流中的每一所接收事件的到达率λn,得出事件到达行为数据508。
突发检测器510一般对应于图3的突发检测器3033,包括事件突发简档器(profiler)512和历史桶402、突发桶404以及离群桶406。
事件突发简档器512接收事件到达行为数据508,并且,如稍后将参考图6进行说明的,获取当前网络负荷信息(图5中未示出),并选择对应当前网络负荷信息的事件简档。然后根据事件简档来处理事件到达行为508,以形成按简档的事件到达数据514。按照事件简档的事件到达数据的处理将参考图6在以下描述中进行说明。
然后,取决于事件的计算到达率λn与事件流中的事件的预期到达率λ和预期差异Δλ的比较(使用上面给出的公式),将按简档的事件到达行为数据514应用于历史桶402、突发桶404和离群桶406,这将参考图6更详细地说明。
历史桶402的功能是确定事件发生的正常状态。预期到达率λ和到达率差异Δλ为桶的主要属性。取决于计算这些属性的方法,桶可存储一些历史事件和事件发生行为。例如,如果在计算中使用了移动平均,最后k(突发)事件需要被存储。在示范性实施例中,使用上面讨论的指数移动平均算法,不需要存储历史事件。
突发桶404的功能是缓存潜在突发事件。如果事件的计算到达率λn满足上述公式1.1但不满足上述公式1.2,则该事件和计算到达率被推(例如记录)入这个桶。
离群桶406的功能是缓存潜在噪声/离群事件。如果事件的计算到达率λn满足上述公式1.2,则该事件和计算到达率被推(例如记录)入此桶。
应该指出,公式1.1和1.2中使用的事件流中事件的预期到达率λ和预期差异Δλ是从分配到历史桶402的该事件流的先前事件来确定的,这将参考图6和图7进行说明。
一旦检测到事件突发,能够输出对应的事件突发记录206,这将参考图6和图7进行说明。
一种示范性事件突发检测方法现在将参考图6进行描述。
在图6的步骤602中,根据预定义的事件格式模板来解析事件204,以确定感兴趣的事件,然后,基于分析要求将感兴趣的事件汇聚成事件流。例如,如果运营者需要监测移动管理的突发行为,在突发检测中将仅考虑移动管理事件。这一解析活动可例如通过设置事件滤波器以只选择所期望事件类型的所接收事件以形成事件流来完成。备选地或者附加地,在其它实施例中,这一解析活动可例如通过设置事件滤波器以只选择具有特定参数(例如特定失败代码)的所接收事件以形成事件流来完成。事件滤波标准可以是任何事件字段或者多个事件字段的组合。
图11说明通过桶滤波器模型51、52、53将事件204的流解析和汇聚到多个不同的事件流206a、206b、206c中。不同的标准可确定为每个事件流206a、206b、206c选择的事件。例如,拥有作为事件参数的特定失败代码的所有事件可形成事件流之一。
然后,在步骤604中计算所监测事件流的到达时间间隔。到达时间间隔为事件流中一个事件的到达和下一事件的到达之间的时间量,并且为每一随后接收的事件计算到达时间间隔。
在示范性实施例中,在检测到突发状态之前,在步骤606中确定事件的网络负荷简档。此处假设事件发生与网络负荷状况(即,网络中活跃用户的数量)密切相关。因此,可以预期,当更多用户附连到网络并消耗服务时,事件到达率将增加,当用户变为空闲状态或者离开网络或服务时,事件到达率将减小。考虑到取决于网络负荷的预期或者正常事件到达率的变化,在一些实施例中,运营者基于网络负荷状况定义两个或更多个事件简档。
在一些实施例中,运营者可监测和测量网络的负荷。在一些实施例中,例如通过确定网络的活跃用户的数量来监测和测量网络的负荷。在示范性实施例中,网络负荷数据608提供网络的负荷的测量。在一些实施例中,网络负荷数据608可以是来自图1中所示的核心网104的移动管理事件136。在一些实施例中,来自核心网104的移动管理事件136可以是SGSN移动管理事件。
另外,本领域技术人员会知道,运营者可以进一步估计负荷分布或者概率密度,并将网络负荷分类为例如以下三种不同情况:
高网络负荷情况:70000~90000(最大值)活跃用户;
低网络负荷情况:低于10000活跃用户;
正常网络负荷情况:活跃用户数量在10000到70000之间。
显然,在不同实施例中,所选不同负荷情况的数量和用于对负荷进行分类的门限可以由本领域技术人员选择适合于系统的。
为了确定处理简档,突发检测器确定当前网络负荷,然后将当前网络负荷与预定义的简档匹配。事件在每一简档下得到进一步处理。因此,例如,每一简档可具有其自己的突发门限和对应的桶。例如,如果当前网络负荷为3000个用户,基于上面给出的预定义门限,可进行与低负荷情况的匹配。然后将突发行为与低负荷情况的门限进行比较,以确定它是否是突发。
在步骤610中,使用在参考图3的示范性实施例中上述的公式1.1,通过将所接收事件的到达率λn与该事件类型的事件的预期到达率λ和预期差异Δλ进行比较,确定事件是否可能为突发的一部分。
响应于肯定的确定(步骤610-是),在步骤612中递增突发_持续时间计数器,并且在步骤614中,使用在参考图3的示范性实施例中上述的公式1.2,通过将所接收事件的到达率λn与该事件类型的事件的预期到达率λ和预期差异Δλ进行比较,确定事件是否为潜在离群事件。
响应于肯定的确定(步骤614-是),事件被确定为潜在离群事件,在步骤616中将其放入离群桶406。
响应于否定的确定(步骤614-否),事件被确定为潜在突发事件,在步骤618中将其放入突发桶404。
只要相继的事件204在步骤610被确定为潜在地突发的一部分,则突发_持续时间计数器将在步骤612中继续递增。
响应于否定的确定(步骤610中—否),该事件类型的事件的预期到达率λ和预期差异Δλ在步骤620中更新,突发_持续时间计数器在步骤622中递减。最后,将在步骤624中执行突发确定,这将参考图7进一步说明。
从图6的考虑将会清楚,如果事件的计算事件到达率λn满足公式1.1,突发_持续时间变量将在步骤612中递增(递增某个常数,缺省情况下,递增1)。此外,如果计算的事件到达率λn不满足公式1.1,突发_持续时间变量将在步骤622中递减(递减某个常数,缺省情况下,递减1)。
步骤624中的突发确定将参考图7进一步说明,图7更详细地示出在示范性实施例中图6的步骤624中执行的处理以进一步确定突发是否为临时的。
参考图7,作为第一步骤,在步骤702中,确定突发_持续时间变量是否具有小于0的值。如果突发_持续时间变量变为负数(步骤702-是),则离群桶中的缓存事件被认为是噪声,并且在步骤704中可被忽略。在这种情况下,只有缓存于突发桶中的事件在步骤706中被用来更新预期事件到达率λ和预期差异Δλ。
如果突发_持续时间变量具有大于或等于0的值(在步骤702-否),在步骤708中,确定突发_持续时间变量的值是否大于或等于预定义的值MIN_BURST_DURATION。如果突发持续时间变为大于(或等于)预定义的值MIN_BURST_DURATION(步骤708-是),确认存在事件突发发生。在突发桶404和离群桶406中都缓存的事件在步骤710中被用于更新预期到达率λ和预期差异Δλ,在步骤712中记录关于突发的详情,包括突发内的事件的事件ID、突发开始时标和突发持续时间。然后,事件突发记录206可被输出。
在一些实施例中,进一步分析事件突发记录206以识别事件突发之间的因果关系。在一些实施例中,通过计算来自事件突发记录206的事件突发之间的因果概率来实现这一点。
如本领域技术人员会知道的,在不同的实施例中可以使用不同的算法来确定事件突发记录之间的因果关系。
图8示出在一些实施例中使用的确定事件突发之间的因果关系的示范性方法。
在步骤802中,获得事件突发记录206。
在步骤804中,通过使用观测窗口,确定在指定的事件突发之前有哪些事件突发发生。本领域技术人员在不同实施例中可以选择合适的窗口长度。
在示范性实施例中,通过检查全部突发记录来确定指定事件e1的突发的总数。在预定义的观测窗口we内,例如30秒内,在所指定事件突发(事件e1)之前所确定事件突发(事件e2)共同发生的次数也被确定在这个上下文中,当所确定事件突发(事件e2)的开始时间在所指定事件突发(事件e1)的开始时间之前出现时,认为所确定事件突发(事件e2)在所指定事件突发(事件e1)之前共同发生。
在步骤808中,使用所计算因果概率建立了事件突发之间的因果图。直接链路可以和所计算因果概率一起被添加到因果图(如图10所示)。本领域技术人员会清楚,因果概率不是固定的,而是动态更新的,因为周期性地更新因果概率。
图10中所示的示范性因果图将稍后描述。
进一步分析事件突发记录206以识别服务质量和事件突发之间的因果关系。在一些实施例中,通过从事件突发记录206和那些事件的服务质量报告计算服务质量和事件突发之间的因果概率来实现这一点。
参考图9,在第一步骤902中,指定感兴趣的服务。
在步骤904中,获得感兴趣的服务的服务质量反馈。服务质量反馈可以是所指定用户服务的任何报告或者测量。在一个实施例中,这可以由Agama TV监测设备(http://www.agama.tv/analyzer.html)提供,然而不同实施例可以使用用户服务的不同报告或者测量,这是本领域技术人员所熟知的。
在步骤906中,进一步分析服务质量反馈,以确定服务质量的任何有效变化,例如,通过分析服务质量关键性能指示符(KPI)的任何有效退化。本领域技术人员在不同实施例中可以选择确定服务质量变化的方法。例如,一个这样的方法是基于门限的,例如,选择超过预定义门限(例如5%)的那些质量变化(例如,分组丢失增加)作为有效退化。
在图9所示的示范性方法的步骤908中,采用观测窗口ws,确定在KPI退化之前有哪些事件突发发生。观测窗口的长度可取决于服务质量反馈的报告或者测量间隔,还取决于用户设备的缓冲器大小,并且可以由本领域技术人员针对不同实施例进行选择。在一些实施例中,ws的适当缺省值为5分钟。然而,在一些实施例中使用机器学习技术和训练数据以确定这个观测窗口的值是可能的。
计算(例如,)事件e1和指定服务的退化(例如保持能力比率)之间的因果概率。存在确定两个实体之间的因果关系的不同算法,这是本领域技术人员可以选择的。在示范性方法中,通过检查服务质量反馈来计算s-KPI1(如最终用户所体验的)的退化发生总数在预定义的观测窗口ws之内,e1的事件突发在退化(例如)之前共同发生的次数也被确定
在步骤912中,使用所计算的因果概率建立指定服务性能(例如KPIs)和事件之间的因果图。直接链路能够与所计算的因果概率一起被添加到因果图(如图10所示)。对本领域技术人员显而易见的是,因果概率不是固定的,而是动态更新的,因为周期性地更新因果概率。
在图10中示出一个使用参考图8和9上述的实施例为Web TV系统生成的示范性因果图。事件因果图1002中示出事件突发之间的所计算因果概率,服务事件因果图1004中示出指定服务性能和事件之间的所计算因果概率。
在一些实施例中,通过上述的自动事件突发检测来识别感兴趣的事件的突发。通过用户服务性能指示符和事件突发之间的自动相关,建立服务性能和事件之间的因果关系,从而识别引起服务性能退化的事件。
然后,分析在事件突发中引起服务性能退化的事件的原因,以便揭示服务问题的潜在根本原因。在这个上下文中,注意可以为事件定义诸如失败代码和子失败代码之类的事件参数,以帮助对网络进行故障排查。这样的信息对于移动无线电网络的事件是唯一的,并且在网络问题的原因分析的上下文中是有用的。
注意,在所有事件类型之中仅仅寻找带有特定失败代码的最频繁事件是没用的,因为事件的发生取决于多种因素,举例来说,例如网络负荷和事件性质。
因此,在识别出事件突发中的与服务问题相关或者造成服务问题的事件之后,分析在事件的突发发生内的最频繁失败原因。
基于事件突发记录(图3a中的事件信息块2063中的事件ID和突发信息块中的突发开始时标),可以获得所有参与突发的事件。在一个实施例中,在数据库中存储突发记录206,可以通过查询事件数据库从突发记录206获得参与突发的事件,这是本领域技术人员所熟知的。
现在,需要识别突发的失败原因。在一些实施例中,事件流汇聚单元3021可以使用通配符来将不同类型的事件汇聚到相同的事件流,例如,汇聚所有带有相同失败代码的事件。所以,突发记录可以包括不同类型的事件。
该问题的解决方案取决于实现,并且可以由本领域技术人员在不同的实施例中选择。最简单的方法是对每一可能原因的频率(基于事件的事件失败代码或者原因代码)计数,并选择最高k个失败原因。但是,这样的方法涉及高存储器成本和低处理速度,并且在一些实施例中可能效率不高。
在示范性实施例中,可以使用以下算法来寻找事件突发中的事件的最高k个失败原因:
在这个示范性算法中:
依次检查与突发中的每一事件相关联的原因代码;
如果原因代码已经存在于原因代码集合中,原因代码的频率计数加1;
如果原因代码还不存在,并且已经在原因代码集合中的原因代码数量比k小,则将新的原因代码插入原因代码集合;
如果原因代码还不存在,并且原因代码集合中已经有最多的k个原因代码,原因代码集合中的带有最低频率计数的原因代码被新的原因代码替代;
一旦突发中所有事件的事件代码已经被依次检查,算法返回感兴趣的突发中的事件的最频繁k个原因。
因此,进步的事件分析可以确定服务问题的根本原因。
本领域技术人员会理解,本发明的实施例使用复合事件处理概念,并且实现事件随着它们发生的实时处理,不要求保留事件信息和过程状态。本发明的至少一些实施例提供的优点包括:
自动化:不使用规则或者预定义的事件模式来检测异常事件,因而问题诊断完全是自动化的,仅使用一些预定义的参数。
准确性:实施例的基于突发的方法比上述的计算失败比率更准确地捕获系统的异常状态。对于服务问题的故障排查,这样的信息比失败比率有用得多。而且,事件简档化有助于改进检测事件突发的准确性。
简化的操作:事件基于它们的突发状态被汇总,与基于计数器的方法相比。运营者仅需要关注这些可以指示异常网络状态的事件突发,而不是关注所有反映正常网络状态的事件。
显著减小的存储空间和分析开销:与现有的收集和存储每个事件的方案相比,所提出的方案仅存储带有突发发生(例如事件突发记录)的事件,不带有突发发生的事件可以以摘要或者压缩方式来存储。以这种方式存储事件信息的方法是本领域技术人员所知晓的,将不更详细地说明。这显著减小存储和分析事件的开销,并提供用于根本原因分析的事件记录的生存期存储的解决方案。
显著减小通过网络到管理系统传送事件的开销:可以在本地执行自动事件突发检测(步骤202),例如在产生事件的节点或者临近产生事件的节点。因此,不是传送每一单个事件,可以通过网络传送事件突发记录206(或者相关事件突发记录212,或者发现的原因216)到进一步处理单元(步骤208和/或214),或者任何其它基于事件的系统。这显著减小传送的数据量。
处理/解析性能:如果没有检测到突发行为,就不需要解码事件的全部细节,所以,可以使用相对较小的存储器来执行该方法,从而实现本发明的实施例。可以完成解析而无处理瓶颈,这导致可缩放的实现。
本领域技术人员从前述描述及相关附图中所给出的教导中获益,易于想到所公开的发明的修改和其它实施例。因此,应当理解,本发明不限于所公开的特定实施例,修改和其它实施例意在被包括在本公开范围内。虽然可能在此使用了特定的术语,但是使用它们仅仅是一般性的以及描述性的,而不是用于限制目的。
Claims (19)
1.一种使用表示通信系统中活动的事件的所述通信系统的操作的分析方法,所述方法包括以下步骤:
检测(202)事件的突发;
在因果关系处理步骤(208)中,使用所检测的事件的突发和系统操作信息来识别引起系统操作变化的至少一个有效事件突发;以及
从与所述有效事件突发内的事件相关联的信息确定(214)所述系统操作变化的原因。
2.如权利要求1所述的分析方法,其中,检测事件的突发的步骤包括接收多个事件并且基于汇聚标准将所述事件汇聚到至少一个事件流中的步骤。
3.如权利要求2所述的分析方法,其中,基于事件的参数将所述事件汇聚到所述至少一个事件流中。
4.如上述任一权利要求所述的分析方法,其中,检测(202)事件的突发的步骤包括如下步骤:取决于所接收事件的到达时间、预期到达时间和事件流中的事件的预期到达时间的预期差异,将所述事件流中的所接收事件识别(610)为突发的一部分。
5.如权利要求4所述的分析方法,其中,在确定事件流的下一事件的预期到达时间和所述事件流中的事件的预期到达时间的预期差异的步骤(620,706,710)中,使用所述事件流中的多个所接收事件的到达时间。
6.如上述任一权利要求所述的分析方法,其中,仅在门限数量的所接收事件被识别为突发的一部分之后,确定(708)事件流中的事件的突发的存在。
7.如上述任一权利要求所述的分析方法,包括基于网络负荷将事件简档应用(606)到事件到达行为(508)的步骤。
8.如上述任一权利要求所述的分析方法,其中,所述因果关系处理步骤(208)包括计算事件突发之间的因果概率的步骤(806)。
9.如上述任一权利要求所述的分析方法,其中,所述因果关系处理步骤(208)包括计算服务性能指示符和具有突发发生的事件之间的因果概率的步骤(910)。
10.如上述任一权利要求所述的分析方法,其中,确定(214)系统操作变化的原因的所述步骤包括如下步骤:确定所检测的事件的突发内的事件的失败和/或子失败参数。
11.如上述任一权利要求所述的分析方法,其中,在第一事件处理单元中预处理事件以检测(202)事件的突发,而且所得到的事件突发记录(206)通过至少一个通信链路被传送到至少一个另外的事件处理单元以便进一步分析,其中使用识别引起系统操作变化的至少一个有效事件突发的因果关系处理步骤(208),以及从与所述有效事件突发内的事件相关联的信息确定(214)所述系统操作变化的原因的步骤。
12.如权利要求1-10其中之一所述的分析方法,其中,在至少一个事件处理单元中预处理事件以检测(202)事件的突发,以及使用因果关系处理步骤(208)识别引起系统操作变化的至少一个有效事件突发,而且所得到的相关事件突发记录(212)通过至少一个通信链路被传送到至少一个另外的事件处理单元以便进一步分析,从与所述有效事件突发内的事件相关联的信息确定(214)所述系统操作变化的原因。
13.如权利要求1-10其中之一所述的分析方法,其中,在至少第一事件处理单元中预处理事件以检测(202)事件的突发,以及使用因果关系处理步骤(208)识别引起系统操作变化的至少一个有效事件突发,并且从与所述有效事件突发内的事件相关联的信息确定(214)所述系统操作变化的原因;以及把所述系统操作变化的原因传送到任一基于事件的应用以便进一步分析。
14.一种使用表示通信系统中活动的事件的所述通信系统的操作的分析器,所述分析器包括:
突发分析单元(302),用于接收多个表示所述系统中活动的事件,以及用于检测事件的突发,并产生对应的事件突发记录;
因果关系单元(304),被设置成接收所述事件突发记录(206)和系统操作信息(210),并且在因果关系处理步骤中使用所述事件突发记录(206)和系统操作信息(210)以识别引起系统操作变化的至少一个有效事件突发;以及
耦合到所述因果关系单元(304)的原因分析单元(306),所述原因分析单元(306)从与所述有效事件突发内的事件相关联的信息确定所述系统操作变化的原因。
15.如权利要求14所述的分析器,其中,所述突发分析单元(302)包括事件流汇聚单元(3021),用于接收多个事件(204),并且基于汇聚标准将所述事件汇聚到至少一个事件流中。
16.如权利要求15所述的分析器,其中,基于事件的参数将所述事件汇聚到所述至少一个事件流中。
17.如权利要求14-16其中之一所述的分析器,其中,所述突发分析单元(302)包括突发检测器(3033),它取决于所接收事件的到达时间、预期到达时间和该事件类型的事件的预期到达时间的预期差异,将所接收事件识别为突发的一部分。
18.如权利要求14-17其中之一所述的分析器,其中,所述突发检测器(3033)包括事件突发简档器(510),用于基于网络负荷将事件简档应用(606)于事件到达行为(508)。
19.一种具有操作分析器的通信系统节点,所述操作分析器包括元件突发分析单元(302)、因果关系单元(304)和原因分析单元(306)其中至少一个,其中:
元件突发分析单元(302)被设置成接收多个表示所述系统中活动的事件并检测事件的突发,产生对应的事件突发记录,并且耦合到因果关系单元(304),从而为因果关系单元(304)提供事件突发记录;
因果关系单元(304),耦合到元件突发分析单元(302)并且被设置成从其接收事件突发记录(206),还被设置成接收系统操作信息(210),并且被设置成在因果关系处理步骤中使用所述事件突发记录(206)和系统操作信息(210)以识别引起系统操作变化的至少一个有效事件突发,并且提供对应的相关事件突发记录到原因分析单元;
原因分析单元(306)耦合到因果关系单元(304)以接收有效事件突发记录,并被设置成从与所述有效事件突发记录内的事件相关联的信息确定系统操作变化的一个或多个原因。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2010/059205 WO2012000540A1 (en) | 2010-06-29 | 2010-06-29 | Method and apparatus for analysis of the operation of a communication system using events |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103081403A true CN103081403A (zh) | 2013-05-01 |
Family
ID=42670421
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2010800678626A Pending CN103081403A (zh) | 2010-06-29 | 2010-06-29 | 用于使用事件分析通信系统的操作的方法和装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US9774506B2 (zh) |
EP (1) | EP2589181A1 (zh) |
CN (1) | CN103081403A (zh) |
WO (1) | WO2012000540A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104838620A (zh) * | 2012-10-17 | 2015-08-12 | 瑞典爱立信有限公司 | 电信网中的事件管理 |
CN111859384A (zh) * | 2020-07-23 | 2020-10-30 | 平安证券股份有限公司 | 异常事件监控方法、装置、计算机设备及存储介质 |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2589181A1 (en) * | 2010-06-29 | 2013-05-08 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for analysis of the operation of a communication system using events |
US8832505B2 (en) | 2012-06-29 | 2014-09-09 | Intel Corporation | Methods and apparatus to provide failure detection |
US8929236B2 (en) | 2012-07-30 | 2015-01-06 | Hewlett-Packard Development Company, L.P. | Network flow analysis |
CN105636097B (zh) * | 2014-10-30 | 2019-03-05 | 中国移动通信集团设计院有限公司 | 一种校验网络性能统计数据的方法及装置 |
US10140642B2 (en) * | 2015-07-27 | 2018-11-27 | Data Capable, Inc. | Automated customer engagement and issue location, prediction, and response through utilization of public and private data sources |
CN107086923B (zh) * | 2016-02-16 | 2021-03-16 | 中兴通讯股份有限公司 | 通信网络性能指标分析方法及装置 |
WO2017142692A1 (en) * | 2016-02-18 | 2017-08-24 | Nec Laboratories America, Inc. | High fidelity data reduction for system dependency analysis related application information |
WO2017157438A1 (en) * | 2016-03-16 | 2017-09-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and device for real-time network event processing |
US11372744B1 (en) * | 2017-03-31 | 2022-06-28 | Headspin, Inc. | System for identifying issues during testing of applications |
US11165856B2 (en) | 2017-04-25 | 2021-11-02 | Citrix Systems, Inc. | Detecting uneven load balancing through multi-level outlier detection |
EP3646138A1 (en) | 2017-06-27 | 2020-05-06 | Telefonaktiebolaget LM Ericsson (PUBL) | Power management of an event-based processing system |
US11314573B2 (en) * | 2018-11-30 | 2022-04-26 | Hewlett Packard Enterprise Development Lp | Detection of event storms |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050188240A1 (en) * | 2003-12-19 | 2005-08-25 | Brendan Murphy | Determination of related failure events in a multi-node system |
US7107496B1 (en) * | 2000-07-24 | 2006-09-12 | Nortel Networks Limited | Method, apparatus, computer-readable media and user interface for annunciating problems in a system |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7043661B2 (en) * | 2000-10-19 | 2006-05-09 | Tti-Team Telecom International Ltd. | Topology-based reasoning apparatus for root-cause analysis of network faults |
JP4403348B2 (ja) * | 2000-12-14 | 2010-01-27 | ソニー株式会社 | 通信装置及び通信方法 |
US7568045B1 (en) * | 2001-03-30 | 2009-07-28 | Cisco Technology, Inc. | Method and apparatus for estimating periodic worst-case delay under actual and hypothetical conditions using a measurement based traffic profile |
US8463899B2 (en) * | 2005-07-29 | 2013-06-11 | Bmc Software, Inc. | System, method and computer program product for optimized root cause analysis |
US7940672B2 (en) * | 2005-09-30 | 2011-05-10 | International Business Machines Corporation | Systems and methods for correlation of burst events among data streams |
US20080037432A1 (en) * | 2006-08-01 | 2008-02-14 | Cohen Alain J | Organizing, displaying, and/or manipulating network traffic data |
US7889666B1 (en) * | 2007-12-26 | 2011-02-15 | At&T Intellectual Property Ii, L.P. | Scalable and robust troubleshooting framework for VPN backbones |
US8700761B2 (en) * | 2008-09-04 | 2014-04-15 | At&T Intellectual Property I, L.P. | Method and system for detecting and managing a fault alarm storm |
US8407170B2 (en) * | 2008-11-25 | 2013-03-26 | Lockheed Martin Corporation | Root-cause analysis system and associated methods |
EP2589181A1 (en) * | 2010-06-29 | 2013-05-08 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus for analysis of the operation of a communication system using events |
-
2010
- 2010-06-29 EP EP10729710.3A patent/EP2589181A1/en not_active Withdrawn
- 2010-06-29 CN CN2010800678626A patent/CN103081403A/zh active Pending
- 2010-06-29 WO PCT/EP2010/059205 patent/WO2012000540A1/en active Application Filing
- 2010-06-29 US US13/807,912 patent/US9774506B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7107496B1 (en) * | 2000-07-24 | 2006-09-12 | Nortel Networks Limited | Method, apparatus, computer-readable media and user interface for annunciating problems in a system |
US20050188240A1 (en) * | 2003-12-19 | 2005-08-25 | Brendan Murphy | Determination of related failure events in a multi-node system |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104838620A (zh) * | 2012-10-17 | 2015-08-12 | 瑞典爱立信有限公司 | 电信网中的事件管理 |
US9717011B2 (en) | 2012-10-17 | 2017-07-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Event management in telecommunications networks |
CN104838620B (zh) * | 2012-10-17 | 2018-05-11 | 瑞典爱立信有限公司 | 电信网中的事件管理的设备和方法 |
CN111859384A (zh) * | 2020-07-23 | 2020-10-30 | 平安证券股份有限公司 | 异常事件监控方法、装置、计算机设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
US9774506B2 (en) | 2017-09-26 |
EP2589181A1 (en) | 2013-05-08 |
WO2012000540A1 (en) | 2012-01-05 |
US20130179568A1 (en) | 2013-07-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103081403A (zh) | 用于使用事件分析通信系统的操作的方法和装置 | |
EP3436951B1 (en) | Systems and methods for measuring effective customer impact of network problems in real-time using streaming analytics | |
KR102418969B1 (ko) | 딥러닝 기반 통신망 장비의 장애 예측 시스템 및 방법 | |
CN102143507B (zh) | 一种业务质量监测方法、系统、以及分析方法和系统 | |
CN104584483B (zh) | 用于自动确定服务质量降级的原因的方法和设备 | |
CN103188119A (zh) | 通信网络中关键性能指标的置信区间 | |
EP2894813A1 (en) | Technique for creating a knowledge base for alarm management in a communications network | |
CN110312279A (zh) | 一种网络数据的监测方法及装置 | |
US20050216241A1 (en) | Method and apparatus for gathering statistical measures | |
US20060026467A1 (en) | Method and apparatus for automatically discovering of application errors as a predictive metric for the functional health of enterprise applications | |
US9015312B2 (en) | Network management system and method for identifying and accessing quality of service issues within a communications network | |
CN101189895A (zh) | 异常检测方法和系统以及维护方法和系统 | |
EP2887728A1 (en) | Technique for performance management in a mobile communications network | |
CN107147535A (zh) | 一种分布式的网络测量数据统计分析方法 | |
WO2016017208A1 (ja) | 監視システム、監視装置、および検査装置 | |
CN102045222A (zh) | 网络系统实时整体测试的方法 | |
US20070004399A1 (en) | Quality assessment for telecommunications network | |
CN100512162C (zh) | 流量数据采集方法和系统以及设备 | |
CN109963292B (zh) | 投诉预测的方法、装置、电子设备和存储介质 | |
CN102547789B (zh) | 端到端业务质量预警方法、装置及系统 | |
CN116974805A (zh) | 根因确定方法、设备和存储介质 | |
CN113727092B (zh) | 基于决策树的视频监控质量巡检方法及装置 | |
CN102378180A (zh) | 用户身份的确定方法和装置 | |
CN113746688B (zh) | 实现异常检测模型更新的方法、装置和计算设备 | |
KR20070080353A (ko) | 이동 통신망에서의 서비스 품질 관리 시스템 및 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20130501 |