CN101304343A - 一种网络故障检测的方法、网络设备和网络*** - Google Patents

Abstract

本发明实施例公开了一种网络故障检测方法，包括：向下游网元发送业务请求；当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果是，则向所述下游网元发起故障检测请求。本发明实施例还公开了相关网络设备和网络***。通过本发明实施例，可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。

Description

一种网络故障检测的方法、网络设备和网络***

技术领域

本发明涉及通信技术领域，特别是涉及网络故障检测的方法、网络设备和网络***。

背景技术

网络故障管理技术一般包括：故障检测、故障定位、故障隔离、故障恢复等，其中故障检测技术是其它技术的基础，一个***/网络在其某个组成单元失效/故障后，首先要能够检测出该故障状况来，才能针对该故障状况进行定位、告警、隔离、恢复等操作。

现有的网络故障检测技术基本上是通过周期触发而进行故障检测的：如网关GPRS支持节点GGSN与服务GPRS支持节点SGSN之间的GTP Echo故障检测机制、流量控制传输协议SCTP链路检测机制、双向转发检测BFD异步故障检测机制、虚拟路由冗余协议VRRP Hello机制等。

发明人在实现本发明的过程中，发现现有技术至少存在以下缺点：

1、降低网络传输效率：前端网络需要在每个周期中例行向下游网元传输大量的检测请求，占用宝贵的带宽资源；

2、加大网元处理负荷：前端网元(或者下游网元)需要在每个周期中额外发起(或接收)大量检测请求信息，而在大部分情况下这是无用功。

发明内容

有鉴于此，本发明实施例提出一种网络故障检测方法，包括：

向下游网元发送业务请求；

当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

如果是，则向所述下游网元发起故障检测请求。

本发明实施例还提出一种网络设备，其特征在于，包括业务请求处理模块、故障检测判断模块和故障检测消息发送模块，其中：

业务请求发送模块，用于向下游网元发送业务请求；

故障检测判断模块，用于当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

故障检测消息发送模块，用于当故障检测判断模块判断需要对所述下游网元发起故障检测请求时，向所述下游网元发起故障检测请求。

本发明实施例还提出一种网络***，其特征在于，包括前端网元和下游网元，其中：

前端网元，用于向下游网元发送业务请求；当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果是，则向所述下游网元发起故障检测请求；

下游网元，用于接收来自所述前端网元的业务请求，如果该网络设备没有发生故障，则对所述业务请求作出响应；接收来自所述前端网元的故障检测请求，如果该下游网元没有发生故障，则对所述故障检测请求作出响应。

与现有技术相比，通过本发明实施例至少可以产生以下有益效果：

可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一的方法流程图；

图2-a为本发明实施例二的方法流程图；

图2-b为本发明实施例二的另一方法流程图；

图2-c为本发明实施例二的另一方法流程图；

图3-a为本发明实施例三的方法流程图；

图3-b为本发明实施例三的另一方法流程图；

图3-c为本发明实施例三的另一方法流程图；

图4-a为本发明实施例四的方法流程图；

图4-b为本发明实施例四的另一方法流程图；

图4-c为本发明实施例四的另一方法流程图；

图5-a为本发明实施例五的方法流程图；

图5-b为本发明实施例五的另一方法流程图；

图5-c为本发明实施例五的另一方法流程图；

图6为本发明实施例六的网络设备结构示意图；

图7为本发明实施例七的网络设备结构示意图；

图8为本发明实施例八的网络***组成示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在以下各个实施例中，网络的类型可以是移动网络、固定网络、移动固定融合网络等，可以是局域网、城域网、广域网，可以是接入网、核心网、传输网，可以是点对点网络(P2P)、客户机/服务器架构的网络(C/S)等。

前端网元和下游网元的命名是相对的，在业务路径的前端时即为前端网元，处在业务路径的下端时即为下游网元。

实施例一：

如图1所示，本发明实施例的方法包括：

步骤S102：前端网元向下游网元发送业务请求；

步骤S104：当前端网元超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

在本步骤中，可以是在前端网元向所述下游网元在一定时间内发送预定次数的业务请求之后，仍然没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果否，则转步骤S108；

步骤S 106：如果是，则前端网元判断是否已经对下游网元进行故障检测，如果是，则转步骤S108；如果否，则前端网元向下游网元发起故障检测请求；

在本步骤中，前端网元的判断操作为可选的，可以不判断而直接向下游网元发起故障检测请求。

步骤S108；前端网元不发起故障检测请求，流程结束；

步骤S110：如果前端网元没有接收到来自下游网元对故障检测请求的响应，则确定下游网元发生故障；如果接收到响应，则转步骤S112；

或者，

如果前端网元没有接收到来自下游网元对故障检测请求的响应，则向下游网元继续发起至少一次的故障检测请求，如果都没有接收到来自下游网元对所述至少一次故障检测请求的响应，则确定下游网元发生故障；如果接收到响应，则转步骤S112；

在本步骤中，继续发起的故障检测请求可以有多个。

步骤S112：确定下游网元没有发生故障，流程结束；

步骤S114：前端网元继续向所述下游网元发起故障检测请求，故障检测请求可以是一直发，也可以是发送直至停止发送故障检测请求的条件发生，所述条件包括：

接收到来自所述下游网元的对故障检测请求的响应；或者，

超过一定的预设时间；或者，

在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

本步骤为可选的，前端网元确定下游网元发生故障后，开始统计是否还有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这里统计的只是“是否有发送意向或需求”)，可以是，通过计数器统计需要发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某个预设值，则前端网元可以停止向该故障网元的发送故障检测请求。

通过本实施例，可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。

实施例二：

如图2-a所示，以IP多媒体子***IMS网络为例，前端网元和下游网元可以分别为代理呼叫会话控制功能P-CSCF、问询呼叫会话控制功能I-CSCF、服务呼叫会话控制功能S-CSCF、应用服务器AS、媒体网关控制功能MGCF、互通边界控制功能IBCF等。前端网元和下游网元的命名是相对的，当网元处在业务路径的前端时即为前端网元，当处在业务路径的下端时即为下游网元，如：出IMS本局呼叫中S-CSCF可能为I-CSCF的前端网元，而入IMS本局的呼叫中，I-CSCF可能为S-CSCF的前端网元。

本实施例的网络故障检测方法包括以下步骤：

步骤S202：前端网元向下游网元发送业务请求；

步骤S204～S206：当超过一定时间没有接收来自到下游网元对业务请求的响应时，前端网元可以重传业务请求；

在步骤S202～S206中，业务请求可以是任何类型的业务请求，图中以INVITE和REGISTER为例。

步骤S208：当重传预定次数的业务请求后，或者从第一个业务请求发送算起超过一定时间没有接收到来自下游网元对业务请求的响应时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；

在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测，因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这样则不需要再次触发该故障检测请求；

步骤S210：如果前端网元确定需要对下游网元进行故障检测，则向下游网元发起故障检测请求；

在本步骤中，各个网络(包括IMS)可以选择适合网络自身特点的故障检测请求/响应消息，这里不做限定；在IMS中可以采用SIP OPTIONS消息作为故障检测请求，对应的响应可以为200OK消息。

步骤S212～S214：前端网元如果没有接收到来自下游网元对故障检测请求OPTIONS消息的响应，则可以再次或多次向下游网元发起故障检测请求。

步骤S216：如果没有接收到来自下游网元对故障检测请求OPTIONS消息的响应，比如在连续一定次数的检测请求超时无响应后，或者一定的时间内检测请求无响应后，前端网元可以确定下游网元发生故障。

参照图2-b，本实施例方法还可以进一步包括：

步骤S218：下游网元可能在前端网元确定其发生故障之前，针对某个故障检测消息返回响应200 OK消息；

步骤S220：前端网元根据返回的响应200 OK消息，确定下游网元没有发生故障，可以停止对该下游网元的检测。

参照图2-c，本实施例方法还可以进一步包括：

步骤S222：在S216确定下游网元发生故障之后，将下游网元列为需要监控的故障对象，继续向下游网元发起故障检测请求OPTIONS消息。

因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请求的条件，在步骤S222之后当该条件发生时，则停止发送故障检测请求，所述条件可以包括：

C1、接收到来自所述下游网元的对故障检测请求的响应；或者，

C2、超过一定的预设时间；或者，

C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

上述只是一部分条件，还可以根据实际情况设定其他条件。

前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这里统计的只是“是否有发送意向或需求”)，可以是，通过计数器统计需要发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停止向该故障网元的发送故障检测请求。

通过本实施例，可以在IMS网络中，通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低IMS网络设备在故障检测方面的工作负荷，提高了IMS网络传输效率。

实施例三：

如图3-a所示，以WiMAX网络为例，前端网元和下游网元可以分别为基站BS、网关GW等。前端网元和下游网元的命名是相对的，当网元处在业务路径的前端时即为前端网元，当处在业务路径的下端时即为下游网元，如：BS向GW发起业务请求时，BS为前端网元，而GW向BS发起业务请求时，GW为前端网元。

本实施例的网络故障检测方法包括以下步骤：

步骤S302：前端网元向下游网元发送业务请求；

步骤S304～S306：当超过一定时间没有接收来自到下游网元对业务请求的响应时，前端网元可以重传业务请求；

在步骤S302～S306中，业务请求可以是任何类型的业务请求，图中以Path_Reg_Req和HO_Req为例。

步骤S308：当重传预定次数的业务请求后，或者从第一个业务请求发送算起超过一定时间没有接收到来自下游网元对业务请求的响应时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；

在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测，因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这样则不需要再次触发该故障检测请求；

步骤S310：如果前端网元确定需要对下游网元进行故障检测，则向下游网元发起故障检测请求；

在本步骤中，各个网络(包括WiMAX)可以选择适合网络自身特点的故障检测请求/响应消息，这里不做限定；如在WiMAX中可以通过扩展标准接口消息的“功能类型”、“消息类型”等方式来定义适合自身的故障检测消息。在本实施例中，可以采用HandShake_Req作为故障检测请求，采用HandShake_Rsp作为相应的响应消息。

步骤S312～S314：前端网元如果没有接收到来自下游网元对故障检测请求HandShake_Req的响应HandShake_Rsp，则可以再次或多次向下游网元发起故障检测请求HandShake_Req。

步骤S316：如果没有接收到来自下游网元对故障检测请求HandShake_Req的响应HandShake_Req，比如在连续一定次数的检测请求HandShake_Req超时无响应后，或者一定的时间内检测请求HandShake_Req无响应后，前端网元可以确定下游网元发生故障。

参照图3-b，本实施例方法还可以进一步包括：

步骤S318：下游网元可能在前端网元确定其发生故障之前，针对某个故障检测消息HandShake_Req返回响应HandShake_Rsp；

步骤S320：前端网元根据返回的响应，确定下游网元没有发生故障，可以停止对该下游网元的检测。

参照图3-c，本实施例方法还可以进一步包括：

步骤S322：在S316确定下游网元发生故障之后，将下游网元列为需要监控的故障对象，继续向下游网元发起故障检测请求。

因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请求的条件，在步骤S322之后当该条件发生时，则停止发送故障检测请求，所述条件可以包括：

C1、接收到来自所述下游网元的对故障检测请求的响应；或者，

C2、超过一定的预设时间；或者，

C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

上述只是一部分条件，还可以根据实际情况设定其他条件。

前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这里统计的只是“是否有发送意向或需求”)，可以是，通过计数器统计需要发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停止向该故障网元的发送故障检测请求。

通过本实施例，可以在Wimax网络中，通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低Wimax网络设备在故障检测方面的工作负荷，提高了Wimax网络传输效率。

实施例四：

如图4-a所示，以移动网络为例，前端网元和下游网元可以分别为NodeB、无线基站控制器RNC、SGSN、GGSN等。

本实施例的网络故障检测方法包括以下步骤：

步骤S402：前端网元向下游网元发送业务请求；

步骤S404～S406：当超过一定时间没有接收来自到下游网元对业务请求的响应时，前端网元可以重传业务请求；

在步骤S402～S406中，业务请求可以是任何类型的业务请求，图中以Activate PDP Context Request为例，也可以是RNC与SGSN之间的AttachRequest等。

步骤S408：当重传预定次数的业务请求后，或者从第一个业务请求发送算起超过一定时间没有接收到来自下游网元对业务请求的响应时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；

在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测，因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这样则不需要再次触发该故障检测请求；

步骤S410：如果前端网元确定需要对下游网元进行故障检测，则向下游网元发起故障检测请求；

在本步骤中，各个网络(包括移动网)可以选择适合网络自身特点的故障检测请求/响应消息，这里不做限定；在SGSN与GGSN之间，可以使用Echo Request作为故障检测请求，采用故障Echo Response作为相应的响应消息。

步骤S412～S414：前端网元如果没有接收到来自下游网元对故障检测请求Echo Request的响应Echo Response，则可以再次或多次向下游网元发起故障检测请求。

步骤S416：如果没有接收到来自下游网元对故障检测请求的响应，比如在连续一定次数的检测请求超时无响应后，或者一定的时间内检测请求无响应后，前端网元可以确定下游网元发生故障。

参照图4-b，本实施例方法还可以进一步包括：

步骤S418：下游网元可能在前端网元确定其发生故障之前，针对某个故障检测消息返回响应；

步骤S420：前端网元根据返回的响应，确定下游网元没有发生故障，可以停止对该下游网元的检测。

参照图4-c，本实施例方法还可以进一步包括：

步骤S422：在S416确定下游网元发生故障之后，将下游网元列为需要监控的故障对象，继续向下游网元发起故障检测请求。

因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请求的条件，在步骤S422之后当该条件发生时，则停止发送故障检测请求，所述条件可以包括：

C1、接收到来自所述下游网元的对故障检测请求的响应；或者，

C2、超过一定的预设时间；或者，

C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

上述只是一部分条件，还可以根据实际情况设定其他条件。

前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这里统计的只是“是否有发送意向或需求”)，可以是，通过计数器统计需要发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停止向该故障网元的发送故障检测请求。

通过本实施例，可以在移动网络中，通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低移动网络设备在故障检测方面的工作负荷，提高了移动网络传输效率。

实施例五：

如图5-a所示，以下一代网络NGN为例，NGN网络支持多种通信协议，如SIP、H.248等，当使用SIP消息时，故障检测机制可参考实施例一，本实施例以采用H.248消息为例进行介绍。

本实施例的网络故障检测方法包括以下步骤：

步骤S502：前端网元向下游网元发送业务请求；

步骤S504～S506：当超过一定时间没有接收来自到下游网元对业务请求的响应时，前端网元可以重传业务请求；

在步骤502～S506中，前端网元一般可以是MGC，业务请求可以是任何类型的业务请求，图中以NTFY_REQ为例。

步骤S508：当重传预定次数的业务请求NTFY_REQ后，或者从第一个业务请求发送算起超过一定时间没有接收到来自下游网元对业务请求的响应时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；

在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测，因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这样则不需要再次触发该故障检测请求；

S510：如果前端网元确定需要对下游网元进行故障检测，则向下游网元发起故障检测请求；

在本步骤中，各个网络(包括NGN)可以选择适合网络自身特点的故障检测请求/响应消息，这里不做限定；在MG与MGC之间使用H.248协议时，可以采用注册消息(SVC_CHG_REQ)或者其它扩展消息等作为故障检测请求，可以采用SVC_CHG_REPLY作为响应消息。

步骤S512～S514：前端网元如果没有接收到来自下游网元对故障检测请求SVC_CHG_REQ的响应SVC_CHG_REPLY，则可以再次或多次向下游网元发起故障检测请求。

步骤S516：如果没有接收到来自下游网元对故障检测请求SVC_CHG_REQ的响应SVC_CHG_REPLY，比如在连续一定次数的检测请求超时无响应后，或者一定的时间内检测请求无响应后，前端网元可以确定下游网元发生故障。

参照图5-b，本实施例方法还可以进一步包括：

步骤S518：下游网元可能在前端网元确定其发生故障之前，针对某个故障检测消息SVC_CHG_REQ返回响应SVC_CHG_REPLY；

步骤S520：前端网元根据返回的响应，确定下游网元没有发生故障，可以停止对该下游网元的检测。

参照图5-c，本实施例方法还可以进一步包括：

步骤S522：在S516确定下游网元发生故障之后，将下游网元列为需要监控的故障对象，继续向下游网元发起故障检测请求。

因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请求的条件，在步骤S522之后当该条件发生时，则停止发送故障检测请求，所述条件可以包括：

C1、接收到来自所述下游网元的对故障检测请求的响应；或者，

C2、超过一定的预设时间；或者，

C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

上述只是一部分条件，还可以根据实际情况设定其他条件。

前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这里统计的只是“是否有发送意向或需求”)，可以是，通过计数器统计需要发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停止向该故障网元的发送故障检测请求。

通过本实施例，可以在NGN网络中，通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低NGN网络设备在故障检测方面的工作负荷，提高了NGN网络传输效率。

实施例六：

如图6所示，本实施例提供一种网络设备，可以作为前端网元，包括业务请求处理模块602、故障检测判断模块604和故障检测消息发送模块606，其中：

业务请求发送模块602，用于向下游网元发送业务请求；

故障检测判断模块604，用于当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

故障检测消息发送模块606，用于当故障检测判断模块判断需要对所述下游网元发起故障检测请求时，向下游网元发起故障检测请求。

进一步地，该网络设备还可以包括：

响应接收模块608，用于接收来自所述下游网元对故障检测请求的响应。

进一步地，该网络设备还可以包括：

故障判断模块610，用于当响应接收模块没有接收到来自所述下游网元的对故障检测请求的响应时，确定下游网元发生故障。

进一步地，故障检测消息发送模块还可以用于：

当所述故障判断模块确定所述下游网元发生故障时，继续向所述下游网元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包括：

响应接收模块接收到来自下游网元的对故障检测请求的响应；或者，

超过一定的预设时间。

进一步地，该网络设备还可以包括：

计算模块612，用于统计在一定的时间内需要发向所述下游网元的业务请求的数量；当所述数量小于预设值时，指示故障检测消息发送模块停止向下游网元发起故障检测请求。

本实施例的网络设备作为前端网元，其类型可以是：路由器、交换机、网关、基站、基站控制器、网关GPRS支持节点GGSN、服务GPRS支持节点SGSN、数字用户线复用器DSLAM、AAA服务器、呼叫会话控制CSCF等网络设备。

通过本实施例，在通信网络中，前端网元可以通过业务请求来感知下游网元的异常，进而发起故障检测，减少了向下游网元发送的故障检测请求的数量，降低前端网元在故障检测方面的工作负荷。

实施例七

如图7所示，本实施例提供一种网络设备，包括：

故障检测消息接收模块702，用于接收来自其他网元的故障检测请求；

故障检测消息响应模块704，用于对故障检测消息接收模块接收到的故障检测请求作出响应。

进一步地，该网络设备还可以包括：

业务请求处理模块706，用于接收来自其他网元的业务请求，如果该网络设备没有发生故障，则对所述业务请求作出响应。

本实施例的网络设备作为下游网元，其类型可以是：路由器、交换机、网关、基站、基站控制器、网关GPRS支持节点GGSN、服务GPRS支持节点SGSN、数字用户线复用器DSLAM、AAA服务器、呼叫会话控制CSCF等网络设备。

通过本实施例，在通信网络中，下游网元可以通过业务请求响应异常来启发前端网元发起故障检测，减少了接收来自前端网元的故障检测请求的数量，降低下游网元在故障检测方面的工作负荷。

实施例八

如图8所示，本实施例提供一种网络***，包括：前端网元802和下游网元804，其中：

前端网元802，用于向下游网元发送业务请求；当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对下游网元发起故障检测请求；如果是，则向下游网元发起故障检测请求；

下游网元804，用于接收来自前端网元的业务请求，如果该网络设备没有发生故障，则对所述业务请求作出响应；接收来自前端网元的故障检测请求，如果该下游网元没有发生故障，则对故障检测请求作出响应。

本实施例的前端网元和下游网元可以部署在移动网络、或固定网络、或移动固定融合网络、或传输网、或接入网、或核心网。

通过本实施例，前端网元可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。

综上可见，通过本发明实施例的网络故障检测的方法、网络设备和网络***，可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。

专业人员还可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或任意其它形式的存储介质中。

以上所述仅是本发明的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (13)

1、一种网络故障检测方法，其特征在于，包括：

向下游网元发送业务请求；

当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

如果需要对所述下游网元发起故障检测请求，则向所述下游网元发起故障检测请求。

2、如权利要求1所述的网络故障检测方法，其特征在于，所述当没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求的步骤之前进一步包括：

向所述下游网元发送预定次数的业务请求之后，没有接收到来自所述下游网元对业务请求的响应。

3、如权利要求1所述的网络故障检测方法，其特征在于，所述确定是否需要对所述下游网元发起故障检测请求的步骤包括：

判断是否已经对所述下游网元进行故障检测，如果是，则不需要对所述下游网元发起故障检测请求，如果否，则需要对所述下游网元发起故障检测请求。

4、如权利要求1所述的网络故障检测方法，其特征在于，所述对所述下游网元发起故障检测请求的步骤之后进一步包括：

如果没有接收到来自所述下游网元对故障检测请求的响应，则确定所述下游网元发生故障；或者，

如果没有接收到来自所述下游网元对故障检测请求的响应，则向所述下游网元发起至少一次的故障检测请求，如果没有接收到来自所述下游网元对所述至少一次故障检测请求的响应，则确定所述下游网元发生故障。

5、如权利要求4所述的网络故障检测方法，其特征在于，在确定所述下游网元发生故障的步骤之后，进一步包括：

继续向所述下游网元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包括：

接收到来自所述下游网元的对故障检测请求的响应；或者，

超过一定的预设时间；或者，

在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。

6、一种网络设备，其特征在于，包括：

业务请求发送模块，用于向下游网元发送业务请求；

故障检测判断模块，用于当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；

故障检测消息发送模块，用于当故障检测判断模块判断需要对所述下游网元发起故障检测请求时，向所述下游网元发起故障检测请求。

7、如权利要求6所述的网络设备，其特征在于，进一步包括：

响应接收模块，用于接收来自所述下游网元对故障检测请求的响应。

8、如权利要求7所述的网络设备，其特征在于，进一步包括：

故障判断模块，用于当所述响应接收模块没有接收到来自所述下游网元的对故障检测请求的响应时，确定所述下游网元发生故障。

9、如权利要求8所述的网络设备，其特征在于，所述故障检测消息发送模块还用于：

当所述故障判断模块确定所述下游网元发生故障时，继续向所述下游网元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包括：

所述响应接收模块接收到来自所述下游网元的对故障检测请求的响应；或者，

超过一定的预设时间。

10、如权利要求9所述的网络设备，其特征在于，进一步包括：

计算模块，用于统计在一定的时间内需要发向所述下游网元的业务请求的数量；当所述数量小于预设值时，指示所述故障检测消息发送模块停止向所述下游网元发起故障检测请求。

11、如权利要求6至10中任一项所述的网络设备，其特征在于，所述网络设备的类型包括：

路由器、交换机、网关GW、基站BS、基站控制器、网关GPRS支持节点GGSN、服务GPRS支持节点SGSN、数字用户线复用器DSLAM、AAA服务器、呼叫会话控制器CSCF。

12、一种网络***，其特征在于，包括前端网元和下游网元，其中，

前端网元，用于向下游网元发送业务请求；当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果是，则向所述下游网元发起故障检测请求；

下游网元，用于接收来自所述前端网元的业务请求，如果该网络设备没有发生故障，则对所述业务请求作出响应；接收来自所述前端网元的故障检测请求，如果该下游网元没有发生故障，则对所述故障检测请求作出响应。

13、如权利要求12所述的网络***，其特征在于，所述前端网元和下游网元部署在移动网络、或固定网络、或移动固定融合网络、或传输网、或接入网、或核心网。

Images