CN102217232A - 确定网元运行状态方法以及相关设备和系统 - Google Patents

确定网元运行状态方法以及相关设备和系统 Download PDF

Info

Publication number
CN102217232A
CN102217232A CN2011800007787A CN201180000778A CN102217232A CN 102217232 A CN102217232 A CN 102217232A CN 2011800007787 A CN2011800007787 A CN 2011800007787A CN 201180000778 A CN201180000778 A CN 201180000778A CN 102217232 A CN102217232 A CN 102217232A
Authority
CN
China
Prior art keywords
network element
target network
message
detect
running status
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
Application number
CN2011800007787A
Other languages
English (en)
Inventor
胡堃
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN102217232A publication Critical patent/CN102217232A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种确定网元运行状态方法以及相关设备和系统。其中,一种确定网元运行状态方法:包括:网管在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动该至少一个关联网元检测该目标网元的运行状态;接收到来自该至少一个关联网元的驱动故障检测响应消息,其中,该驱动故障检测响应消息携带对该目标网元的运行状态的检测结果;综合该检测结果确定该目标网元的运行状态。本发明实施例提供的技术方案有利于提高网管判定网元运行状态的准确性。

Description

确定网元运行状态方法以及相关设备和系统
技术领域
本发明涉及通信技术领域,具体涉及确定网元运行状态方法以及相关设备和系统。
背景技术
目前,通信网络的规模和结构变得庞大和复杂,而如何准确的获取通信网络中各个网元的基本运行状态是网络管理的一个非常重要的方面。
然而,因网络规模等导致组网的高复杂度,直接影响到网管判断的网元基本运行状态的准确性。
一种现有技术中如图1-a所示,网管和被管网元之间通过网络管理协议中的心跳消息保持连接,当网管判断出如果被管网元的连续若干次心跳消息(通常为3次)都丢失,那么就认为被管网元故障(离线)。
另一种现有技术中如图1-b所示,当被管网元的一个关联网元发现其与被管网元连接中断时,该关联网元会以告警的形式主动向网管报告被管网元故障,此时,网管就认为被管网元故障(离线)。
实践发现,现有技术中网管判断被管网元是否故障经常出错,网管准确获知被管网元运行状态的能力较低。例如,当现有网管判断出被管网元发生故障后,维护人员通过手工排查发现被管网元并未故障,而是网管或关联网元与被管网元之间的链路故障。
发明内容
本发明实施例提供确定网元运行状态方法以及相关设备和系统,以提高网管判定网元运行状态的准确性。
为解决上述技术问题,本发明实施例提供以下技术方案:
一种确定网元运行状态方法,包括:
网管在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;
接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;
综合所述检测结果确定所述目标网元的运行状态。
一种网管设备,包括:
驱动模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;
接收模块,用于接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;
确定模块,用于综合所述检测结果确定所述目标网元的运行状态。
一种状态检测系统,包括:
网管设备,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;综合所述检测结果确定所述目标网元的运行状态;
至少一个关联网元,用于接收网管设备发送的驱动故障检测消息,检测所述目标网元的运行状态;向网管设备发送驱动故障检测响应消息,该驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果。
由上可见,本发明实施例中网管在对应目标网元的故障检测事件的触发下,选择分布于一个或多个网络层次的一个或多个靠近目标网元的关联网元作为检测点,驱动检测点检测目标网元的运行状态,网管综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态,相对缩短了管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,减少对实际业务的影响。
附图说明
为了更清楚地说明本发明实施例和现有技术中的技术方案,下面将对实施例和现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1-a是现有技术的一种网元故障确定示意图;
图1-b是现有技术的另一种网元故障确定示意图;
图2是本发明实施例一提供的一种确定网元运行状态方法流程示意图;
图3是本发明实施例二提供的一种确定网元运行状态方法流程示意图;
图4是本发明实施例提供的一种网管设备示意图;
图5是本发明实施例提供的一种状态检测系统示意图。
具体实施方式
本发明实施例提供确定网元运行状态方法以及相关设备和系统。
以下分别进行详细说明。
为使得本发明的发明目的、特征、优点能够更加的明显和易懂,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,下面所描述的实施例仅仅是本发明一部分实施例,而非全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
实施例一
本发明确定网元运行状态方法的一个实施例,可包括:网管在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动该至少一个关联网元检测该目标网元的运行状态;接收到来自该至少一个关联网元的驱动故障检测响应消息,其中,该驱动故障检测响应消息携带有对该目标网元的运行状态的检测结果;综合该检测结果确定该目标网元的运行状态。
参见图2,具体步骤可以包括:
210、网管在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动该至少一个关联网元检测该目标网元的运行状态;
在实际应用中,触发网管发起目标网元(即待检测网元)状态检测的对应该目标网元的故障检测事件例如可包括但不限于如下事件的一种或多种:目标网元与网管之间的连接中断(可能是目标网元与网管之间的心跳消息连续丢失)、目标网元的关联网元和该目标网元之间的连接中断、接收到检测目标网元工作状态的用户指令。
此外,若准备在目标网元上配置一个或多个重要或特定业务,为确保该重要或特定业务的可靠性,在重要或特定业务配置前,网管对该目标网元的运行状态进行检测核实,即准备在目标网元配置重要或特定业务的事件,也可看成是一种对应目标网元的故障检测事件。此外,网管可能周期性的对一些处于链路重要或特定位置的网元(目标网元)的运行状态进行检测核实,而对重要或特定位置的目标网元运行状态的检测周期到达的事件,也可看成是一种对应目标网元的故障检测事件。
当然,也可能还有存在其它一种或者多种可触发网管发起目标网元状态检测的对应该目标网元的故障检测事件,此处不再赘述。
网管可选择靠近(此处的“靠近”可认为是直连或尽量靠近)目标网元的至少一个关联网元作为检测目标网元运行状态的检测点,网管选择的检测点例如可包括如下网元的一个或多个:
靠近目标网元的至少一个业务层关联网元,靠近目标网元的至少一个信令层关联网元、靠近目标网元的至少一个承载层关联网元。
可以理解的是,网管选择其认为当前工作状态正常的关联网元(例如该关联网元与网管间的连接正常),作为目标网元检测点,而通常不会选择可能故障的关联网元作为目标网元检测点,例如,网管不会选择与其连接中断的关联网元作为目标网元检测点,也尽量不选择被报告存在故障的关联网元作为目标网元检测点。
并且,网管在选择靠近目标网元的至少一个关联网元作为目标网元检测点的同时,还可通过网管协议主动检测目标网元的运行状态(网管将自身作为一个目标网元检测点),当然,若是由于目标网元与网管之间的连接中断(对应目标网元的故障检测事件)而触发网管发起对目标网元状态检测的,例如目标网元与网管之间的心跳消息连续丢失,则此时网管可再不通过网管协议直接检测目标网元的运行状态,而是选择驱动一个或多个关联网元对目标网元进行检测。分析发现,首先,在复杂网络中,网管和被管网元(如目标网元)通常不是直接连接的,而可能是经过了若干路由器或者其它承载网设备来连接的,网管和被管网元间心跳消息丢失可能的原因除了被管网元自身故障之外,也有可能是网管和被管网元之间的承载网设备出现了问题,因此网管系统和被管网元之间心跳丢失并不能完全说明是被管网元自身故障;其次,复杂网络中,为了保证网络的安全性,整个网络通常会被划分为至少两层,一层是管理网络,被管网元和网管同属于管理网络,还有一层是业务网络,被管网元和其它相关联网元同属于业务网络。因此,即使网管和被管网元在管理网络的连接中断,也并不能说明被管网元在业务网络的状态,即不能判定被管网元是否故障;类似的,若某个关联网元主动报告与目标网元连接中断,也并不能肯定是目标网元自身故障,也可能是该网元自身故障,或者是其与目标网元之间的承载网络设备出现问题。
在实际应用中,网管可向靠近目标网元的至少一个业务层关联网元发送驱动故障检测消息(例如可向与目标网元归属于同一业务群或业务池的网元发送驱动故障检测消息;和/或,向目标网元的上游业务网元发送驱动故障检测消息;和/或,向目标网元的下游业务网元发送驱动故障检测消息;和/或,向靠近目标网元的其它业务层关联网元发送驱动故障检测消息);和/或,向靠近目标网元的至少一个信令层关联网元发送驱动故障检测消息(例如向目标网元的上游信令网元发送驱动故障检测消息;和/或,向目标网元的下游信令网元发送驱动故障检测消息;和/或,向靠近目标网元的其它信令层关联网元发送驱动故障检测消息);和/或,向靠近目标网元的至少一个承载层关联网元发送驱动故障检测消息(例如可向与目标网元连接在同一交换机(LanSwitch)或集线器的网元发送驱动故障检测消息;和/或,向物理连接上位于目标网元与网管之间的路由器(Router)或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或,向物理连接上位于目标网元与其它网元之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或向靠近目标网元的其它承载层关联网元发送驱动故障检测消息),以驱动目标网元的至少一个关联网元检测该目标网元的运行状态。
也就是说,网管可选择从业务层(业务层运行状态)、信令层(信令层运行状态)和承载层(承载层运行状态)这三个层面中的至少一个层面(或者还可包括网管作为检测点的网管层),检测目标网元的运行状态。
其中,驱动故障检测消息可以携带目标网元的标识(该标识可以是关联网元能够识别的任意标识),若网管需要指示状态检测的方式,则驱动故障检测消息中还可携带故障状态检测方式指示,关联网元可以在接收到来自网管的该驱动故障检测消息后,故障状态检测方式指示所对应指示的检测方式,检测该目标网元的运行状态;若网管不指示状态检测的方式,则关联网元可以在接收到来自网管的驱动故障检测消息后,自主选择适宜的检测方式(例如可能是预先配置或默认的),检测该目标网元的运行状态。可以理解,网管可对部分或全部关联网元指示具体的状态检测方式,对不同的类型的关联网元指示的状态检测方式可能是相同或不同的,当然,网管亦可不对任何关联网元指示具体的状态检测方式。
220、网管接收到来自该至少一个关联网元的驱动故障检测响应消息,该驱动故障检测响应消息携带有对该目标网元的运行状态的检测结果;
其中,网管根据来自各个关联网元的驱动故障检测响应消息,可以获悉各个关联网元对该目标网元的运行状态的检测结果(正常或故障)。
230、网管综合上述检测结果确定该目标网元的运行状态。
其中,网管可综合各个关联网元的检测结果进行分析,根据综合分析结果确定该目标网元的运行状态。例如,网管中可维护一张状态判定表,该状态判定表中可记载有各种检测结果对应的运行状态,网管综合各个关联网元的检测结果,查询状态判定表,即可确定出目标网元的运行状态;或者网管可综合各个关联网元的检测结果,通过状态判定公式(状态判定公式可根据具体场景具体设定)出目标网元的运行状态。
举例来说,网管若发现全部业务层关联网元和/或信令层关联网元检测出目标网元故障,并且部分或全部承载层关联网元检测出目标网元未故障,则可确定出目标网元处于故障状态;网管若发现部分业务层关联网元和/或信令层关联网元检测出目标网元故障,并且全部承载层关联网元检测出目标网元未故障,则可确定出目标网元处于故障状态,以此类推。
可以看出,本实施例中网管在对应目标网元的故障检测事件的触发下,选择分布于一个或多个网络层次的一个或多个靠近目标网元的关联网元作为检测点,驱动检测点检测目标网元的运行状态,网管综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态,相对缩短了管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,减少对实际业务的影响。
实施例二
为便于更好的理解和实施本发明实施例的技术方案,本实施主要以网管至少从业务层、信令层和承载层这三个层面发起对目标网元A的检测,以判定目标网元的运行状态的一种过程为例,进行具体详细的描述。
参见图3,具体步骤可以包括:
301、在对应目标网元A的故障检测事件的触发下,网管选取靠近目标网元A的至少1个业务层关联网元、靠近目标网元A的至少1个信令层关联网元和靠近目标网元A的至少1个承载层关联网元,作为检测目标网元运行状态的检测点。
在实际应用中,对应目标网元A的故障检测事件例如可包括但不限于如下事件的一种或多种:目标网元A与网管之间的连接中断(可能是目标网元A与网管之间的心跳消息连续丢失)、目标网元A的关联网元和该目标网元A之间的连接中断、接收到检测目标网元A工作状态的用户指令。
此外,若准备在目标网元A上配置一个或多个重要或特定业务,为确保该重要或特定业务的可靠性,在重要或特定业务配置前,网管对该目标网元A的运行状态进行检测核实,即准备在目标网元A配置重要或特定业务的事件,也可看成是一种对应目标网元A的故障检测事件。此外,网管可能周期性的对一些处于链路重要或特定位置的网元(例如目标网元A)的运行状态进行检测核实,而对重要或特定位置的目标网元A运行状态的检测周期到达的事件,也可看成是一种对应目标网元A的故障检测事件。当然,也可能还有存在其它一种或者多种对应目标网元A的故障检测事件,此处不再赘述。
在复杂网络中,网管和被管网元(包括目标网元A)通常不是直连的,而可能是经过了若干路由器或者其它承载网设备来连接的,网管和目标网元A间心跳消息丢失可能的原因除了目标网元A自身故障之外,也有可能是网管和目标网元A之间的承载网设备出现了问题,因此,网管系统和目标网元A之间心跳丢失并不能完全说明是目标网元A自身故障;其次,即使网管和目标网元A在管理网络的连接中断,也并不能说明目标网元A在业务网络的状态,即不能仅据此判定目标网元A是否故障;类似的,若某个关联网元主动报告与目标网元A连接中断,也并不能肯定是目标网元A自身故障,也可能是该关联网元自身故障,或者是其与目标网元A之间的承载网络设备出现问题。
而本实施例中,网管可以选择靠近(此处的“靠近”可认为是直连或尽量靠近)目标网元A的至少1个(例如两个或两个以上)业务层关联网元、靠近目标网元A的至少1个(例如两个或两个以上)信令层关联网元和靠近目标网元A的至少1个(例如两个或两个以上)承载层关联网元,作为检测目标网元A运行状态的检测点。
即,本实施例中网管选择业务层(业务层运行状态)、信令层(信令层运行状态)和承载层(承载层运行状态)这三个层面(甚至还可包括网管作为检测点的网管层)的检测点,以便全面客观的检测目标网元A的运行状态,这样有利于剔除外在原因对目标网元A运行状态检查结果的影响。
可以理解的是,网管选择其认为当前工作状态正常的关联网元(例如该关联网元与网管间的连接正常),作为目标网元A检测点,而通常不会选择可能故障的关联网元作为目标网元A检测点,例如,网管不会选择与其连接中断的关联网元作为目标网元A检测点,也尽量不选择被报告存在故障的关联网元作为目标网元A检测点。
并且,网管在选择靠近目标网元A的至少1个业务层关联网元、至少1个信令层关联网元和至少1个承载层关联网元作为目标网元检测点的同时,还可通过网管协议主动检测目标网元A的运行状态(网管将自身作为一个目标网元A检测点),当然,若是由于目标网元A与网管之间的连接中断(该事件为对应目标网元A的故障检测事件)而触发网管发起对目标网元A状态检测的,例如目标网元A与网管之间的心跳消息连续丢失,则此时网管可再不通过网管协议直接检测目标网元A的运行状态,而是选择驱动多个关联网元对目标网元A进行检测。
302、网管向选取的多个关联网元发送驱动故障检测消息,以驱动该多个关联网元检测目标网元A的运行状态。
其中,网管可向选取的靠近目标网元A的至少1个业务层关联网元发送驱动故障检测消息,例如,网管可向与目标网元A归属于同一业务群或业务池的网元发送驱动故障检测消息;和/或,向目标网元A的上游业务网元发送驱动故障检测消息;和/或,向目标网元A的下游业务网元发送驱动故障检测消息;和/或,向靠近目标网元A的其它业务层关联网元发送驱动故障检测消息,以驱动目标网元A的至少1个业务层关联网元检测目标网元A的运行状态。
并且,网管可向选取的靠近目标网元A的至少1个信令层关联网元发送驱动故障检测消息,举例来说,网管可向目标网元A的上游信令网元发送驱动故障检测消息;和/或,向目标网元A的下游信令网元发送驱动故障检测消息;和/或,向靠近目标网元A的其它信令层关联网元发送驱动故障检测消息,以驱动目标网元A的至少1个信令层关联网元检测目标网元A的运行状态。
并且,网管可向选取的靠近目标网元A的至少1个承载层关联网元发送驱动故障检测消息,举例来说,网管可向与目标网元A连接在同一交换机或集线器的网元发送驱动故障检测消息;和/或,可向物理连接上位于目标网元A与网管之间的路由器或交换机中,靠近目标网元A的一个或多个发送驱动故障检测消息;和/或,可向物理连接上位于目标网元A与其它网元之间的路由器或交换机中,靠近目标网元A的一个或多个发送驱动故障检测消息;和/或,向靠近目标网元A的其它承载层关联网元发送驱动故障检测消息,以驱动目标网元A的至少1个承载层关联网元检测目标网元A的运行状态。
在实际应用中,驱动故障检测消息可以携带目标网元A的标识(该标识可以是关联网元能够识别的任意标识),若网管需要指示状态检测的方式,则驱动故障检测消息中还可携带故障状态检测方式指示,关联网元可以在接收到来自网管的该驱动故障检测消息后,故障状态检测方式指示所对应指示的检测方式,检测目标网元A的运行状态;若网管不指示状态检测的方式,则关联网元可以在接收到来自网管的驱动故障检测消息后,自主选择适宜的检测方式(例如可能是预先配置或默认的,例如某种业务协议或业务信令协议),检测该目标网元A的运行状态。可以理解,网管可对部分或全部关联网元指示具体的状态检测方式,对不同的类型的关联网元指示的状态检测方式可能是相同或不同的,当然,网管亦可不对任何关联网元指示具体的状态检测方式。
例如,网管可通过驱动故障检测消息指示目标网元A的1个或多个承载层关联网元,采用ICMP(Internet Control Message Protocol,互联网控制报文协议)或SNMP(Simple Network Management Protocol,简单网络管理协议)检测目标网元A的运行状态,当然,网管可通过驱动故障检测消息指示目标网元A的1个或多个承载层关联网元采用其它协议检测目标网元A的运行状态。
举例来说,本发明实施例的一种驱动故障检测消息具有如下格式,但不局限于此:
Figure BDA0000075554750000101
其中,destNE指示待检测网元(目标网元A)的标识;
check-Method指示状态检测的方式。
例如,check-Method可有两个可选的值,其中,CHK SERVICE指示为使用业务层消息对目标网元A进行检测;而CHK LINK则指示为使用PING或者SNMP GET方式尝试检测目标网元A。
303、多个关联网元接收来自网管的驱动故障检测消息,在该驱动故障检测消息的驱动下检测目标网元A的运行状态。
其中,驱动故障检测消息可以是一种网管协议消息,网管通过驱动故障检测消息来驱动来多个关联网元执行对目标网元A的检测行为。
304、多个关联网元向网管发送驱动故障检测响应消息,以将对目标网元A的运行状态的检测结果通知网管。
其中,该驱动故障检测响应消息携带有对该目标网元A的运行状态的检测结果,网管根据来自各个关联网元的驱动故障检测响应消息,可以获悉各个关联网元对目标网元A的运行状态的检测结果(正常或故障等)。
例如,网管根据来自各个业务层关联网元的驱动故障检测响应消息,获悉其检测出的目标网元A的业务层运行状态;根据来自各个信令层关联网元的驱动故障检测响应消息,获悉其检测出的目标网元A的信令层运行状态;根据来自各个承载层关联网元的驱动故障检测响应消息,获悉其检测出的目标网元A的承载层运行状态。
举例来说,本发明实施例一种驱动故障检测响应消息具有如下格式,但不局限于此:
其中,checkResult指示对目标网元A的运行状态的检测结果;
可选的,desc返回检测的详细信息。
例如,checkResult可有三种可选的值,其中,CHK OK指示检测出目标网元A运行状态正常;CHK UNREACHABLE指示检测出目标网元A故障(如使用网管指定或自选的检测方法,检测目标网元A无响应);CHK UNKNOWN指示无法识别目标网元A。
305、网管接收来自各个关联网元的驱动故障检测响应消息,综合上述检测结果确定目标网元A的运行状态。
其中,网管可综合各个关联网元的检测结果进行分析,根据综合分析结果确定该目标网元A的运行状态。
例如,网管中可维护一张状态判定表,该状态判定表中可记载有各种检测结果对应的运行状态,网管综合各个关联网元的检测结果,查询维护的状态判定表,即可确定出目标网元A的运行状态;或者,网管可综合各个关联网元的检测结果,通过状态判定公式(状态判定公式可根据具体场景具体设定)出目标网元A的运行状态。
举例来说,网管中可维护如表1所示的状态判定表,但不局限于此;
其中,各个检测层面的检测结果可分为三种情况:
所有检测点报故障(AF);
部分检测点报故障(POK);
所有检测点报正常(OK);
表1
  编号   网管  业务层/信令层   承载层   状态判定
  1   AF  AF   AF   目标网元故障
  2   AF  AF   OK   目标网元故障
  3   AF  AF   POK   目标网元故障
  4   AF  POK   AF   网络故障
  5   AF  POK   OK   目标网元故障
  6   AF  POK   POK   目标网元故障
  7   AF  OK   AF   网络故障
  8   AF  OK   OK   目标网元OM故障
  9   AF  OK   POK   网络故障
  10   OK  AF   AF   目标网元业务故障
  11   OK  AF   OK   目标网元业务故障
  12   OK  AF   POK   网络故障
  13   OK  POK   AF   网络故障
  14   OK  POK   OK   目标网元业务故障
  15   OK   POK   POK   网络故障
  16   OK   OK   AF   无此场景
  17   OK   OK   OK   无故障
  18   OK   OK   POK   无此场景
其中,网管通过查询表1,可确定出目标网元A的运行状态。
例如,网管若发现全部业务层关联网元和/或信令层关联网元检测出目标网元A故障,并且部分或全部承载层关联网元检测出目标网元A未故障,则可确定出目标网元A处于故障状态(例如表1的记录2~3、11~12所示);网管若发现部分业务层关联网元和/或信令层关联网元检测出目标网元A故障,并且全部承载层关联网元检测出目标网元A未故障,则可确定出目标网元A处于故障状态(例如表1的记录5、14所示),其它情形以此类推。
可以理解的是,本实施例以网管选取至少三个层面的检测点来检测目标网元的运行状态,而在实际操作中,检测点的选取可能不完全覆盖本实施例中提及的全部检测面,可能只需要检测网管层、业务网络/信令网络、承载网络中的一个或者多个即可较准确的判断出目标网元的基本运行状态。
进一步的,当网管管理了一个多层次的复杂网络时,可尽可能选取目标网元对应到各个网络层面的关联网元作为检测点,来检测目标网元对应的运行状态,网络越复杂,选取关联网元的网络层面可越多,每个层面选取的关联网元的数量亦可越多。网管可对状态判定表进行相应扩展和更新,以适应不同场景的需求。
可以看出,本实施例中网管在对应目标网元的故障检测事件的触发下,选择分布于业务层、信令层和承载层等多个网络层次的一个或多个靠近目标网元的关联网元作为检测点,驱动检测点检测目标网元的运行状态,网管综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态或网络状态,相对缩短了管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,也就可减少对实际业务的影响。
并且,由于网管中可维护一张记载有各种检测结果对应的运行状态的状态判定表,网管综合各个关联网元的检测结果,通过查询维护的状态判定表来确定出目标网元A的运行状态,简单快捷。
为便于更好的实施本发明实施例的技术方案,本发明实施例还提供用于实施上述方案的相关装置和系统。
参见图4、本发明实施例提供的一种网管设备400,可包括:
驱动模块410、接收模块420和确定模块430
其中,驱动模块410,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;
其中,对应目标网元的故障检测事件例如可包括但不限于如下事件的一种或多种:目标网元与网管设备400之间的连接中断(具体可能是目标网元与网管设备400之间的心跳消息连续丢失)、目标网元的关联网元和该目标网元之间的连接中断、接收到检测目标网元工作状态的用户指令。
此外,若准备在目标网元上配置一个或多个重要或特定业务,为确保该重要或特定业务的可靠性,在重要或特定业务配置前,网管设备400对该目标网元的运行状态进行检测核实,即,准备在目标网元配置重要或特定业务的事件,也可看成是一种对应目标网元的故障检测事件。此外,网管设备400可能周期性的对一些处于链路重要或特定位置的网元(目标网元)的运行状态进行检测核实,而对重要或特定位置的目标网元运行状态的检测周期到达的事件,也可看成是一种对应目标网元的故障检测事件。
当然,也可能还有存在其它一种或者多种可触发网管设备400发起目标网元状态检测的对应该目标网元的故障检测事件,此处不再赘述。
接收模块420,用于接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;
确定模块430,用于综合所述检测结果确定所述目标网元的运行状态。
在一种应用场景下,驱动模块410可包括如下子模块的一个或多个:第一驱动子模块、第二驱动子模块和第三驱动子模块(图4中未示出)。
第一驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个业务层关联网元发送驱动故障检测消息,以驱动所述至少一个业务层关联网元检测所述目标网元的运行状态。
在实际应用中,第一驱动子模块具体可用于,向与目标网元归属于同一业务群或业务池的网元发送驱动故障检测消息;和/或,向目标网元的上游业务网元发送驱动故障检测消息;和/或,向目标网元的下游业务网元发送驱动故障检测消息;和/或,向靠近目标网元的其它业务层关联网元发送驱动故障检测消息,以驱动至少一个业务层关联网元检测所述目标网元的运行状态。
第二驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个信令层关联网元发送驱动故障检测消息,以驱动所述至少一个信令层关联网元检测所述目标网元的运行状态。
在实际应用中,第二驱动子模块具体可用于,向目标网元的上游信令网元发送驱动故障检测消息;和/或,向目标网元的下游信令网元发送驱动故障检测消息;和/或,向靠近目标网元的其它信令层关联网元发送驱动故障检测消息,以驱动至少一个信令层关联网元检测所述目标网元的运行状态。
第三驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个承载层关联网元发送驱动故障检测消息,以驱动所述至少一个承载层关联网元检测所述目标网元的运行状态。
在实际应用中,第三驱动子模块具体可用于,向与目标网元连接在同一交换机或集线器的网元发送驱动故障检测消息;和/或,向物理连接上位于目标网元与网管之间的路由器(Router)或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或,向物理连接上位于目标网元与其它网元之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或向靠近目标网元的其它承载层关联网元发送驱动故障检测消息,以驱动目标网元的至少一个关联网元检测该目标网元的运行状态,以驱动至少一个承载层关联网元检测所述目标网元的运行状态。
也就是说,驱动模块410可选择驱动目标网元的业务层、信令层和承载层这3个层面中的至少一个层面的关联网元,检测目标网元的运行状态。
其中,驱动模块410发送的驱动故障检测消息可以携带目标网元的标识(该标识可以是关联网元能够识别的任意标识),若网管设备400需要指示状态检测的方式,则驱动故障检测消息中还可携带故障状态检测方式指示,关联网元可以在接收到来自网管设备400的该驱动故障检测消息后,故障状态检测方式指示所对应指示的检测方式,检测该目标网元的运行状态;若网管设备400不指示状态检测的方式,则关联网元可以在接收到来自网管设备400的驱动故障检测消息后,自主选择适宜的检测方式(例如可能是预先配置或默认的),检测该目标网元的运行状态。可以理解,网管设备400可对目标网元的部分或全部关联网元指示具体的状态检测方式,对不同的类型的关联网元指示的状态检测方式可能是相同或不同的,当然,网管设备400亦可不对任何关联网元指示具体的状态检测方式。
在实际应用中,网管设备400中可维护一张状态判定表,该状态判定表中可记载有各种检测结果对应的运行状态,确定模块430综合各个关联网元的检测结果,查询状态判定表,即可确定出目标网元的运行状态;或者确定模块430可综合各个关联网元的检测结果,通过状态判定公式(状态判定公式可根据具体场景具体设定)出目标网元的运行状态。
举例来说,确定模块430若发现全部业务层关联网元和/或信令层关联网元检测出目标网元故障,并且部分或全部承载层关联网元检测出目标网元未故障,则可确定出目标网元处于故障状态;确定模块430若发现部分业务层关联网元和/或信令层关联网元检测出目标网元故障,并且全部承载层关联网元检测出目标网元未故障,则可确定出目标网元处于故障状态,以此类推。
可以理解的是,本实施例中的网管设备400可如上述方法实施例中的网管,其各个功能模块的功能可以根据上述方法实施例中的方法具体实现,其具体实现过程可以参照上述方法实施例的相关描述,此处不再赘述。
可以看出,本实施例中的网管设备400在对应目标网元的故障检测事件的触发下,选择分布于一个或多个网络层次的一个或多个靠近目标网元的关联网元作为检测点,驱动检测点检测目标网元的运行状态,网管设备400综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态,有利于缩短系统管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,减少对实际业务的影响。
参见图5、本发明实施例提供的一种状态检测系统,可包括:
网管设备510和至少一个关联网元520。
其中,网管设备510,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元520发送驱动故障检测消息,以驱动至少一个关联网元520检测所述目标网元的运行状态;接收到来自至少一个关联网元520的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;综合所述检测结果确定所述目标网元的运行状态。
关联网元520,用于接收网管设备510发送的驱动故障检测消息,检测所述目标网元的运行状态;向网管设备510发送驱动故障检测响应消息,该驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果。
在实际应用中,网管设备510可向靠近目标网元的至少1个业务层关联网元520发送驱动故障检测消息(例如网管设备510可向与目标网元归属于同一业务群或业务池的网元发送驱动故障检测消息;和/或,向目标网元的上游业务网元发送驱动故障检测消息;和/或向目标网元的下游业务网元发送驱动故障检测消息;和/或,向靠近目标网元的其它业务层关联网元发送驱动故障检测消息);和/或,网管设备510可向靠近目标网元的至少1个信令层关联网元520发送驱动故障检测消息(例如向目标网元的上游信令网元发送驱动故障检测消息;和/或,向目标网元的下游信令网元发送驱动故障检测消息;和/或向靠近目标网元的其它信令层关联网元发送驱动故障检测消息);和/或,网管设备510可向靠近目标网元的至少1个承载层关联网元520发送驱动故障检测消息,例如网管设备510可向与目标网元连接在同一交换机或集线器的网元发送驱动故障检测消息;和/或,向物理连接上位于目标网元与网管之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或,向物理连接上位于目标网元与其它网元之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;和/或向靠近目标网元的其它承载层关联网元发送驱动故障检测消息,以驱动目标网元的至少一个关联网元520检测该目标网元的运行状态。
其中,驱动故障检测消息可以携带目标网元的标识(该标识可以是关联网元能够识别的任意标识),若网管设备510需要指示状态检测的方式,则驱动故障检测消息中还可携带故障状态检测方式指示,关联网元520可以在接收到来自网管的该驱动故障检测消息后,故障状态检测方式指示所对应指示的检测方式,检测该目标网元的运行状态;若网管设备510不指示状态检测的方式,则关联网元520可以在接收到来自网管设备510的驱动故障检测消息后,自主选择适宜的检测方式(例如可能是预先配置或默认的),检测该目标网元的运行状态。可以理解,网管设备510可对部分或全部关联网元指示具体的状态检测方式,对不同的类型的关联网元指示的状态检测方式可能是相同或不同的,当然网管设备510亦可不对任何关联网元指示具体的状态检测方式。
例如,网管设备510中可维护一张状态判定表(例如表1所示),该状态判定表中记载有各种检测结果对应的运行状态,网管设备510可综合各个关联网元的检测结果,查询维护的状态判定表,进而确定出目标网元的运行状态;或者,网管设备510可综合各个关联网元的检测结果,通过状态判定公式(状态判定公式可根据具体场景具体设定)出目标网元的运行状态。
可以理解的是,本实施例中的网管设备510可如上述实施例中的网管,关联网元520可如上述实施例中的关联网元,其功能可以根据上述方法实施例中的方法具体实现,其具体实现过程可以参照上述方法实施例的相关描述,此处不再赘述。
可以看出,本实施例中的网管设备510在对应目标网元的故障检测事件的触发下,选择分布于一个或多个网络层次的一个或多个靠近目标网元的关联网元520作为检测点,驱动检测点检测目标网元的运行状态,网管设备510综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态,有利于缩短系统管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,减少对实际业务的影响。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
综上,本发明实施例中网管在对应目标网元的故障检测事件的触发下,选择分布于一个或多个网络层次的一个或多个靠近目标网元的关联网元作为检测点,驱动检测点检测目标网元的运行状态,网管综合各关联网元对目标网元的运行状态的检测结果,确定目标网元的运行状态,故而能够相对较准确有效的判断出目标网元的基本运行状态,相对缩短了管理员确认故障点的检查时间,进而可为管理员迅速修复故障提供依据,减少对实际业务的影响。
并且,由于网管中可维护一张记载有各种检测结果对应的运行状态的状态判定表,网管综合各个关联网元的检测结果,通过查询维护的状态判定表来确定出目标网元的运行状态,简单快捷。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:只读存储器、随机存储器、磁盘或光盘等。
以上对本发明实施例所提供的确定网元运行状态方法以及相关设备和系统进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上,本说明书内容不应理解为对本发明的限制。

Claims (12)

1.一种确定网元运行状态方法,其特征在于,包括:
网管在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;
接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;
综合所述检测结果确定所述目标网元的运行状态。
2.根据权利要求1所述的方法,其特征在于,所述向靠近目标网元的至少一个关联网元发送驱动故障检测消息,包括:
向靠近目标网元的至少一个业务层关联网元发送驱动故障检测消息;
和/或,
向靠近目标网元的至少一个信令层关联网元发送驱动故障检测消息;
和/或,
向靠近目标网元的至少一个承载层关联网元发送驱动故障检测消息。
3.根据权利要求2所述的方法,其特征在于,所述向靠近目标网元的至少一个业务层关联网元发送驱动故障检测消息,包括:
向与目标网元归属于同一业务群或业务池的网元发送驱动故障检测消息;
和/或,
向目标网元的上游业务网元发送驱动故障检测消息;
和/或,
向目标网元的下游业务网元发送驱动故障检测消息。
4.根据权利要求2所述的方法,其特征在于,所述向靠近目标网元的至少一个信令层关联网元发送驱动故障检测消息,包括:
向目标网元的上游信令网元发送驱动故障检测消息;
和/或,
向目标网元的下游信令网元发送驱动故障检测消息。
5.根据权利要求2所述的方法,其特征在于,所述向靠近目标网元的至少一个承载层关联网元发送驱动故障检测消息,包括:
向与目标网元连接在同一交换机或集线器的网元发送驱动故障检测消息;
和/或,
向物理连接上位于目标网元与网管之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息;
和/或,
向物理连接上位于目标网元与其它网元之间的路由器或交换机中,靠近该目标网元的一个或多个发送驱动故障检测消息。
6.根据权利要求1所述的方法,其特征在于,所述驱动故障检测消息携带有所述目标网元的标识和故障状态检测方式指示。
7.根据权利要求2所述的所述的方法,其特征在于,所述综合所述检测结果确定所述目标网元的故障状态,包括:
综合各个关联网元的检测结果后,通过查询状态判定表确定所述目标网元的故障状态,所述状态判定表中记载有各种检测结果对应的运行状态。
8.根据权利要求1~7任一项所述的方法,其特征在于,
所述对应目标网元的故障检测事件包括如下事件的一种或多种:
目标网元与网管之间的连接中断、目标网元的关联网元和该目标网元之间的连接中断、接收到检测目标网元故障的用户指令。
9.一种网管设备,其特征在于,包括:
驱动模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;
接收模块,用于接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;
确定模块,用于综合所述检测结果确定所述目标网元的运行状态。
10.根据权利要求9所述的网管设备,其特征在于,
所述驱动模块包括:
第一驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个业务层关联网元发送驱动故障检测消息,以驱动所述至少一个业务层关联网元检测所述目标网元的运行状态;
和/或,
第二驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个信令层关联网元发送驱动故障检测消息,以驱动所述至少一个信令层关联网元检测所述目标网元的运行状态;
和/或,
第三驱动子模块,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个承载层关联网元发送驱动故障检测消息,以驱动所述至少一个承载层关联网元检测所述目标网元的运行状态。
11.根据权利要求9或10所述的网管设备,
确定模块,用于综合各个关联网元的检测结果后,通过查询状态判定表确定所述目标网元的故障状态,所述状态判定表中记载有各种检测结果对应的运行状态。
12.一种状态检测系统,其特征在于,包括:
网管设备,用于在对应目标网元的故障检测事件的触发下,向靠近目标网元的至少一个关联网元发送驱动故障检测消息,以驱动所述至少一个关联网元检测所述目标网元的运行状态;接收到来自所述至少一个关联网元的驱动故障检测响应消息,其中,所述驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果;综合所述检测结果确定所述目标网元的运行状态;
至少一个关联网元,用于接收网管设备发送的驱动故障检测消息,检测所述目标网元的运行状态;向网管设备发送驱动故障检测响应消息,该驱动故障检测响应消息携带对所述目标网元的运行状态的检测结果。
CN2011800007787A 2011-05-13 2011-05-13 确定网元运行状态方法以及相关设备和系统 Pending CN102217232A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2011/074026 WO2011137766A2 (zh) 2011-05-13 2011-05-13 确定网元运行状态的方法以及相关设备和系统

Publications (1)

Publication Number Publication Date
CN102217232A true CN102217232A (zh) 2011-10-12

Family

ID=44746744

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2011800007787A Pending CN102217232A (zh) 2011-05-13 2011-05-13 确定网元运行状态方法以及相关设备和系统

Country Status (2)

Country Link
CN (1) CN102217232A (zh)
WO (1) WO2011137766A2 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103178991A (zh) * 2011-12-21 2013-06-26 中国移动通信集团黑龙江有限公司 一种多网络关系分析的方法和系统
CN104348641A (zh) * 2013-07-30 2015-02-11 华为技术有限公司 一种故障的检测方法和故障检测装置
WO2016180197A1 (zh) * 2015-09-17 2016-11-17 中兴通讯股份有限公司 一种网元链路发现方法及装置、网管服务器
CN111294248A (zh) * 2018-12-06 2020-06-16 中国移动通信集团福建有限公司 网元故障质检方法、装置、设备及介质
CN115514615A (zh) * 2021-06-07 2022-12-23 中国移动通信集团有限公司 用于宽带网络的故障检测方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111277551A (zh) * 2018-12-05 2020-06-12 中国移动通信集团四川有限公司 一种应用服务器as系统内部检测方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1588895A (zh) * 2004-07-23 2005-03-02 北京邮电大学 互联网的服务质量监测系统及实现方法
CN101296115A (zh) * 2007-11-22 2008-10-29 中国移动通信集团山东有限公司 电信网络多维监控方法
CN101729305A (zh) * 2008-10-28 2010-06-09 华为技术有限公司 故障自动恢复的方法、系统和控制网元
CN101764717A (zh) * 2008-12-25 2010-06-30 中国移动通信集团天津有限公司 一种网管告警数据核查的方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1588895A (zh) * 2004-07-23 2005-03-02 北京邮电大学 互联网的服务质量监测系统及实现方法
CN101296115A (zh) * 2007-11-22 2008-10-29 中国移动通信集团山东有限公司 电信网络多维监控方法
CN101729305A (zh) * 2008-10-28 2010-06-09 华为技术有限公司 故障自动恢复的方法、系统和控制网元
CN101764717A (zh) * 2008-12-25 2010-06-30 中国移动通信集团天津有限公司 一种网管告警数据核查的方法及系统

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103178991A (zh) * 2011-12-21 2013-06-26 中国移动通信集团黑龙江有限公司 一种多网络关系分析的方法和系统
CN104348641A (zh) * 2013-07-30 2015-02-11 华为技术有限公司 一种故障的检测方法和故障检测装置
WO2016180197A1 (zh) * 2015-09-17 2016-11-17 中兴通讯股份有限公司 一种网元链路发现方法及装置、网管服务器
CN106549775A (zh) * 2015-09-17 2017-03-29 中兴通讯股份有限公司 一种网元链路发现方法及装置、网管服务器
CN111294248A (zh) * 2018-12-06 2020-06-16 中国移动通信集团福建有限公司 网元故障质检方法、装置、设备及介质
CN115514615A (zh) * 2021-06-07 2022-12-23 中国移动通信集团有限公司 用于宽带网络的故障检测方法及装置

Also Published As

Publication number Publication date
WO2011137766A2 (zh) 2011-11-10
WO2011137766A3 (zh) 2012-02-16

Similar Documents

Publication Publication Date Title
CN102217232A (zh) 确定网元运行状态方法以及相关设备和系统
CN101800675B (zh) 故障监控方法、监控设备及通信系统
EP2622792A1 (en) Method for determining a severity of a network incident
EP2795841B1 (en) Method and arrangement for fault analysis in a multi-layer network
CN109039763A (zh) 一种基于回溯法的网络故障节点检测方法及网络管理系统
CN103138988B (zh) 网络故障的定位处理方法及装置
CN103986604A (zh) 网络故障定位方法和装置
CN104219107A (zh) 一种通信故障的检测方法、装置及系统
CN107888455A (zh) 一种数据检测方法、装置和系统
US8908505B2 (en) Methods, apparatus and articles of manufacture to monitor communication paths in communication systems
CN104601394A (zh) 一种业务链连通性检测的方法、装置及系统
CN103023815B (zh) 聚合链路负载分担方法及装置
EP2807563A1 (en) Network debugging
CN111010298A (zh) Pon网络故障监控方法及装置
CN102196472A (zh) 网元异常告警方法、装置及系统
CN105379180B (zh) 一种业务流链路的连通性检测方法、相关装置及系统
CN103220189A (zh) 一种mad检测备份方法和设备
CN102739445A (zh) 一种环网故障快速定位的方法和系统
US20100149994A1 (en) Systems Configured to Automatically Identify Open Shortest Path First (OSPF) Protocol Problems in a Network and Related Computer Program Products and Methods
CN111162962A (zh) 一种环状网络通道类业务隧道状态检测方法及系统
CN103457792A (zh) 一种故障检测方法和装置
CN111130917A (zh) 线路测试的方法、装置及系统
CN112769653B (zh) 一种基于网口绑定的网络检测与切换方法、系统及介质
CN102946321B (zh) 一种基于irf网络的故障处理方法和设备
JP2017034403A (ja) サービス影響原因推定装置、サービス影響原因推定プログラム、及びサービス影響原因推定方法

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: 20111012