专利名称：一种网络故障检测的方法、网络设备和网络系统的制作方法
技术领域：
本发明涉及通信技术领域，特别是涉及网络故障检测的方法、网络设备 和网纟各系统。
背景技术：
网络故障管理技术一般包括故障检测、故障定位、故障隔离、故障恢 复等，其中故障检测技术是其它技术的基础， 一个系统/网络在其某个组成单 元失效/故障后，首先要能够检测出该故障状况来，才能针对该故障状况进行 定位、告警、隔离、恢复等操作。
现有的网络故障检测技术基本上是通过周期触发而进行故障检测的如 网关GPRS支持节点GGSN与服务GPRS支持节点SGSN之间的GTP Echo 故障检测机制、流量控制传输协议SCTP链路检测机制、双向转发检测BFD 异步故障检测机制、虚拟路由冗余协议VRRP Hello机制等。
发明人在实现本发明的过程中，发现现有技术至少存在以下缺点
1、 降低网络传输效率前端网络需要在每个周期中例行向下游网元传输 大量的检测请求，占用宝贵的带宽资源；
2、 加大网元处理负荷前端网元(或者下游网元)需要在每个周期中额 外发起(或接收)大量^r测请求信息，而在大部分情况下这是无用功。
发明内容
有鉴于此，本发明实施例提出一种网络故障检测方法，包括 向下游网元发送业务请求；
当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确 定是否需要对所述下游网元发起故障检测请求；如果是，则向所述下游网元发起故障;险测请求。
本发明实施例还提出一种网络设备，其特征在于，包括业务请求处理模
块、故障检测判断模块和故障检测消息发送模块，其中
业务请求发送模块，用于向下游网元发送业务请求；
故障检测判断模块，用于当超过一定时间内没有接收到来自所述下游网 元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；
故障检测消息发送模块，用于当故障检测判断模块判断需要对所述下游 网元发起故障检测请求时，向所述下游网元发起故障检测请求。
本发明实施例还提出一种网络系统，其特征在于，包括前端网元和下游 网元，其中
前端网元，用于向下游网元发送业务请求；当超过一定时间内没有接收 到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发 起故障检测请求；如果是，则向所述下游网元发起故障检测请求；
下游网元，用于接收来自所述前端网元的业务请求，如果该网络设备没 有发生故障，则对所述业务请求作出响应；接收来自所述前端网元的故障检 测请求，如果该下游网元没有发生故障，则对所述故障检测请求作出响应。
与现有技术相比，通过本发明实施例至少可以产生以下有益效果
可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发 起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低 网络设备在故障检测方面的工作负荷，提高了网络传输效率。
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实 施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图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)等。 前端网元和下游网元的命名是相对的，在业务3各径的前端时即为前端网
元，处在业务i 各径的下端时即为下游网元。 实施例一
如图1所示，本发明实施例的方法包括 步骤S102:前端网元向下游网元发送业务请求；
步骤S104:当前端网元超过一定时间没有接收到来自所述下游网元对业 务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；
在本步骤中，可以是在前端网元向所述下游网元在一定时间内发送预定 次数的业务请求之后，仍然没有接收到来自所述下游网元对业务请求的响应 时，确定是否需要对所述下游网元发起故障检测请求；如果否，则转步骤S108;
步骤S106:如果是，则前端网元判断是否已经对下游网元进行故障检测， 如果是，则转步骤S108;如果否，则前端网元向下游网元发起故障检测请求；
在本步骤中，前端网元的判断操作为可选的，可以不判断而直接向下游 网元发起故障才全测请求。
步骤S108;前端网元不发起故障;险测请求，流程结束；
步骤S110:如果前端网元没有接收到来自下游网元对故障检测请求的响 应，则确定下游网元发生故障；如果接收到响应，则转步骤S112;
或者，
如果前端网元没有接收到来自下游网元对故障检测请求的响应，则向下 游网元继续发起至少一次的故障检测请求，如果都没有接收到来自下游网元 对所述至少一次故障;险测请求的响应，则确定下游网元发生故障；如果接收 到响应，则转步骤S112;在本步骤中，继续发起的故障检测请求可以有多个。
步骤S112:确定下游网元没有发生故障，流程结束；
步骤S114:前端网元继续向所述下游网元发起故障才企测请求，故障才企测 请求可以是一直发，也可以是发送直至停止发送故障检测请求的条件发生， 所述条件包括
接收到来自所述下游网元的对故障检测请求的响应；或者， 超过一定的预设时间；或者，
在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。 本步骤为可选的，前端网元确定下游网元发生故障后，开始统计是否还 有业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元， 这里统计的只是"是否有发送意向或需求")，可以是，通过计数器统计需要 发向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的 业务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于 某个预设值，则前端网元可以停止向该故障网元的发送故障检测请求。
通过本实施例，可以通过业务请求来感知下游网元的异常，启发前端网 元对下游网元发起故障4企测，减少了前端网元向下游网元发送的故障;险测请 求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。
实施例二
如图2-a所示，以IP多媒体子系统IMS网络为例，前端网元和下游网元 可以分别为代理呼叫会话控制功能P-CSCF、问询呼叫会话控制功能I-CSCF、 服务呼叫会话控制功能S-CSCF、应用服务器AS、媒体网关控制功能MGCF、 互通边界控制功能IBCF等。前端网元和下游网元的命名是相对的，当网元处 在业务路径的前端时即为前端网元，当处在业务3各径的下端时即为下游网元， 如出IMS本局呼叫中S-CSCF可能为I-CSCF的前端网元，而入IMS本局的呼叫中，I-CSCF可能为S-CSCF的前端网元。 本实施例的网络故障4企测方法包括以下步骤 步骤S202:前端网元向下游网元发送业务请求；
步骤S204 S206:当超过一定时间没有接收来自到下游网元对业务请求的 响应时，前端网元可以重传业务请求；
在步骤S202 S206中，业务请求可以是任何类型的业务请求，图中以 INVITE和REGISTER为例。
步骤S208:当重传预定次数的业务请求后，或者从第一个业务请求发送 算起超过一定时间没有接收到来自下游网元对业务请求的响应时，前端网元 感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；
在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测， 因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这 样则不需要再次触发该故障检测请求；
步骤S210: 如果前端网元确定需要对下游网元进行故障检测，则向下游 网元发起故障检测请求；
在本步骤中，各个网络(包括IMS)可以选择适合网络自身特点的故障 检测请求/响应消息，这里不做限定；在IMS中可以采用SIP OPTIONS消息 作为故障检测请求，对应的响应可以为200 0K消息。
步骤S212-S214:前端网元如果没有接收到来自下游网元对故障检测请 求OPTIONS消息的响应，则可以再次或多次向下游网元发起故障;险测请求。
步骤S216:如果没有接收到来自下游网元对故障检测请求OPTIONS消 息的响应，比如在连续一定次数的检测请求超时无响应后，或者一定的时间 内4企测请求无响应后，前端网元可以确定下游网元发生故障。
参照图2-b，本实施例方法还可以进一步包括
步骤S218:下游网元可能在前端网元确定其发生故障之前，针对某个故障;险测消息返回响应200 OK消息；
步骤S220:前端网元才艮据返回的响应200 OK消息，确定下游网元没有 发生故障，可以停止对该下游网元的4企测。
参照图2-c,本实施例方法还可以进一步包括
步骤S222:在S216确定下游网元发生故障之后，将下游网元列为需要监 控的故障对象，继续向下游网元发起故障检测请求OPTIONS消息。
因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其 发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请 求的条件，在步骤S222之后当该条件发生时，则停止发送故障检测请求，所 述条件可以包括
Cl、接收到来自所述下游网元的对故障检测请求的响应；或者，
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作为故障4企测请求，釆用 HandShake—Rsp作为相应的响应消息。
步骤S312 ~ S314:前端网元如果没有接收到来自下游网元对故障检测请 求HandShake—Req的响应HandShake—Rsp ，则可以再次或多次向下游网元发 起故障4企测请求HandShake一Req。
步骤S316 :如果没有接收到来自下游网元对故障检测请求 HandShake—Req的响应HandShake—Req，比如在连续一定次数的检测请求 HandShake—Req超时无响应后，或者一定的时间内检测请求HandShake—Req 无响应后，前端网元可以确定下游网元发生故障。
参照图3-b，本实施例方法还可以进一步包括
步骤S318:下游网元可能在前端网元确定其发生故障之前，针对某个故 障检测消息HandShake—Req返回响应HandShake—Rsp;
步骤S320:前端网元根据返回的响应，确定下游网元没有发生故障，可 以停止对该下游网元的检测。
参照图3-c，本实施例方法还可以进一步包括
步骤S322:在S316确定下游网元发生故障之后，将下游网元列为需要监 控的故障对象，继续向下游网元发起故障检测请求。
因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其 发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请 求的条件，在步骤S322之后当该条件发生时，则停止发送故障检测请求，所 述条件可以包括
Cl、接收到来自所述下游网元的对故障检测请求的响应；或者，
C2、超过一定的预设时间；或者，
C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。上述只是一部分条件，还可以根据实际情况设定其他条件。 前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有 业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这 里统计的只是"是否有发送意向或需求")，可以是，通过计数器统计需要发 向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业 务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某 个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停 止向该故障网元的发送故障检测请求。
通过本实施例，可以在Wimax网络中，通过业务请求来感知下游网元的 异常，启发前端网元对下游网元发起故障才企测，减少了前端网元向下游网元 发送的故障检测请求的数量，降低Wimax网络设备在故障检测方面的工作负 荷，提高了 Wimax网络传输效率。
实施例四
如图4-a所示，以移动网络为例，前端网元和下游网元可以分别为NodeB、 无线基站控制器RNC、 SGSN、 GGSN等。
本实施例的网络故障;险测方法包括以下步骤 步骤S402:前端网元向下游网元发送业务请求；
步骤S404 S406:当超过一定时间没有接收来自到下游网元对业务请求的 响应时，前端网元可以重传业务请求；
在步骤S402 S406中，业务请求可以是任何类型的业务请求，图中以 Activate PDP Context Request为例，也可以是RNC与SGSN之间的Attach Request等。
步骤S408:当重传预定次数的业务请求后，或者从第一个业务请求发送 算起超过一定时间没有4矣收到来自下游网元对业务请求的响应时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障检测请求；
在本步骤中，前端网元可以判断当前是否已经在对该下游网元进行检测， 因为可能有时间比较靠前的业务请求超时已经触发了故障检测请求，如果这
样则不需要再次触发该故障检测请求；
步骤S410: 如果前端网元确定需要对下游网元进行故障4全测，则向下游 网元发起故障4企测请求；
在本步骤中，各个网络(包括移动网)可以选择适合网络自身特点的故
障检测请求/响应消息，这里不做限定；在SGSN与GGSN之间，可以使用
Echo Request作为故障;险测请求，釆用故障Echo Response作为相应的响应消 自
步骤S412-S414:前端网元如果没有接收到来自下游网元对故障检测请 求Echo Request的响应Echo Response,则可以再次或多次向下游网元发起故 障检测请求。
步骤S416:如果没有接收到来自下游网元对故障^r测请求的响应，比如 在连续一定次数的检测请求超时无响应后，或者一定的时间内检测请求无响 应后，前端网元可以确定下游网元发生故障。
参照图4-b,本实施例方法还可以进一步包括
步骤S418:下游网元可能在前端网元确定其发生故障之前，针对某个故 障才企测消息返回响应；
步骤S420:前端网元根据返回的响应，确定下游网元没有发生故障，可 以停止对该下游网元的4企测。
参照图4-c，本实施例方法还可以进一步包括
步骤S422:在S416确定下游网元发生故障之后，将下游网元列为需要监 控的故障对象，继续向下游网元发起故障检测请求。
因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请
求的条件，在步骤S422之后当该条件发生时，则停止发送故障检测请求，所 述条件可以包括
Cl、接收到来自所述下游网元的对故障检测请求的响应；或者，
C2、超过一定的预设时间；或者，
C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。
上述只是一部分条件，还可以根据实际情况设定其他条件。 前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有 业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这 里统计的只是"是否有发送意向或需求")，可以是，通过计数器统计需要发 向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业 务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某 个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停 止向该故障网元的发送故障检测请求。
通过本实施例，可以在移动网络中，通过业务请求来感知下游网元的异 常，启发前端网元对下游网元发起故障才企测，减少了前端网元向下游网元发 送的故障检测请求的数量，降低移动网络设备在故障检测方面的工作负荷， 提高了移动网络传输效率。
实施例五
如图5-a所示，以下一代网络NGN为例，NGN网络支持多种通信协议， 如SIP、 H,248等，当使用SIP消息时，故障检测机制可参考实施例一，本实 施例以采用H.248消息为例进行介绍。
本实施例的网络故障;险测方法包括以下步骤步骤S502:前端网元向下游网元发送业务请求；
步骤S504 S506:当超过一定时间没有接收来自到下游网元对业务请求的 响应时，前端网元可以重传业务请求；
在步骤502~S506中，前端网元一般可以是MGC,业务请求可以是任何 类型的业务请求，图中以NTFY一REQ为例。
步骤S508: 当重传预定次数的业务请求NTFY—REQ后，或者从第一个 业务请求发送算起超过一定时间没有接收到来自下游网元对业务请求的响应 时，前端网元感知到下游网元发生异常，确定是否需要对下游网元发起故障 检测请求；
因为可能有时间比较靠前的业务请求超时已经触发了故障;险测请求，如果这 样则不需要再次触发该故障检测请求；
S510: 如果前端网元确定需要对下游网元进4亍^:障^r测，则向下游网元 发起故障检测请求；
在本步骤中，各个网络(包括NGN)可以选择适合网络自身特点的故障 检测请求/响应消息，这里不做限定；在MG与MGC之间使用H.248协议时， 可以采用注册消息(SVC一CHG—REQ)或者其它扩展消息等作为故障检测请求， 可以采用SVC—CHG—REPLY作为响应消息。
步骤S512 S514:前端网元如果没有接收到来自下游网元对故障才企测请 求SVC—CHG—REQ的响应SVC—CHG—REPLY,则可以再次或多次向下游网 元发起故障检测请求。
步骤S516 :如果没有接收到来自下游网元对故障#r测请求 SVC—CHG—REQ的响应SVC—CHG—REPLY,比如在连续一定次数的检测请求 超时无响应后，或者一定的时间内4企测_清求无响应后，前端网元可以确定下 游网元发生故障。参照图5-b，本实施例方法还可以进一步包括
步骤S518:下游网元可能在前端网元确定其发生故障之前，针对某个故 障才企测消息SVC—CHG—REQ返回响应SVC—CHG—REPLY;
步骤S520:前端网元根据返回的响应，确定下游网元没有发生故障，可 以停止对该下游网元的#:测。
参照图5-c,本实施例方法还可以进一步包括
步骤S522:在S516确定下游网元发生故障之后，将下游网元列为需要监 控的故障对象，继续向下游网元发起故障检测请求。
因为下游网元可能发生故障后可能被停用或删除，所以，如果一直对其 发起故障检测请求可能会浪费资源。所以，还可以设置停止发送故障检测请 求的条件，在步骤S522之后当该条件发生时，则停止发送故障检测请求，所 述条件可以包括
Cl、接收到来自所述下游网元的对故障检测请求的响应；或者，
C2、超过一定的预设时间；或者，
C3、在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。
上述只是一部分条件，还可以根据实际情况设定其他条件。 前端网元在将下游网元列入需要监控的故障对象后，开始统计是否还有 业务需要发向该网元(由于该网元处于故障态，请求最终不发给该网元，这 里统计的只是"是否有发送意向或需求")，可以是，通过计数器统计需要发 向下游网元的业务请求数量，如果超过一定的时间没有需要发向该网元的业 务请求、或者在一定的时间内需要发向该下游网元的业务请求的数量低于某 个预设值，则前端网元不需要再对该发生故障的下游网元进行监控，可以停 止向该故障网元的发送故障检测请求。
通过本实施例，可以在NGN网络中，通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障才全测，减少了前端网元向下游网元发
送的故障检测请求的数量，降低NGN网络设备在故障检测方面的工作负荷， 提高了 NGN网络传输效率。
实施例六
如图6所示，本实施例提供一种网络设备，可以作为前端网元，包括业 务请求处理模块602、故障检测判断模块604和故障检测消息发送模块606， 其中
业务请求发送模块602，用于向下游网元发送业务请求；
故障检测判断模块604，用于当超过一定时间内没有接收到来自所述下游 网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；
故障检测消息发送模块606，用于当故障检测判断模块判断需要对所述下 游网元发起故障检测请求时，向下游网元发起故障检测请求。
进一步地，该网络设备还可以包括
响应接收模块608,用于接收来自所述下游网元对故障检测请求的响应。 进一步地，该网络设备还可以包括
故障判断模块610,用于当响应接收模块没有接收到来自所述下游网元的 对故障;险测请求的响应时，确定下游网元发生故障。 进一步地，故障检测消息发送模块还可以用于
当所述故障判断模块确定所述下游网元发生故障时，继续向所述下游网 元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包 括
响应接收模块接收到来自下游网元的对故障检测请求的响应；或者，
超过一定的预设时间。
进一步地，该网络设备还可以包括计算模块612，用于统计在一定的时间内需要发向所述下游网元的业务请 求的数量；当所述数量小于预设值时，指示故障检测消息发送模块停止向下 游网元发起故障检测请求。
本实施例的网络设备作为前端网元，其类型可以是路由器、交换机、 网关、基站、基站控制器、网关GPRS支持节点GGSN、服务GPRS支持节 点SGSN、数字用户线复用器DSLAM、 AAA服务器、呼叫会话控制CSCF 等网络设备。
通过本实施例，在通信网络中，前端网元可以通过业务请求来感知下游 网元的异常，进而发起故障^r测，减少了向下游网元发送的故障检测请求的 数量，降低前端网元在故障检测方面的工作负荷。
实施例七
如图7所示，本实施例提供一种网络设备，包括 故障检测消息接收模块702,用于接收来自其他网元的故障检测请求； 故障检测消息响应模块704，用于对故障检测消息接收模块接收到的故障 ;险测请求作出响应。
进一步地，该网络设备还可以包括
业务请求处理模块706，用于接收来自其他网元的业务请求，如果该网络 设备没有发生故障，则对所述业务请求作出响应。
本实施例的网络设备作为下游网元，其类型可以是路由器、交换机、 网关、基站、基站控制器、网关GPRS支持节点GGSN、服务GPRS支持节 点SGSN、数字用户线复用器DSLAM、 AAA服务器、呼叫会话控制CSCF 等网络设备。
通过本实施例，在通信网络中，下游网元可以通过业务请求响应异常来 启发前端网元发起故障检测，减少了接收来自前端网元的故障检测请求的数量，降低下游网元在故障检测方面的工作负荷。 实施例八
如图8所示，本实施例提供一种网络系统，包括前端网元802和下游 网元804，其中
前端网元802，用于向下游网元发送业务请求；当超过一定时间内没有接 收到来自所述下游网元对业务请求的响应时，确定是否需要对下游网元发起 故障检测请求；如果是，则向下游网元发起故障检测请求；
下游网元804,用于接收来自前端网元的业务请求，如果该网络设备没有 发生故障，则对所述业务请求作出响应；接收来自前端网元的故障检测请求， 如果该下游网元没有发生故障，则对故障;险测请求作出响应。
本实施例的前端网元和下游网元可以部署在移动网络、或固定网络、或 移动固定融合网络、或传ilr网、或4妄入网、或核心网。
通过本实施例，前端网元可以通过业务请求来感知下游网元的异常，启 发前端网元对下游网元发起故障才企测，减少了前端网元向下游网元发送的故 障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络 传输效率。
综上可见，通过本发明实施例的网络故障;险测的方法、网络设备和网络 系统，可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元 发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降 低网络设备在故障检测方面的工作负荷，提高了网络传输效率。
专业人员还可以意识到，结合本文中所公开的实施例描述的各示例的单 元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了 清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描 述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决 于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明 的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理 器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器
(RAM )、内存、只读存储器(ROM )、电可编程ROM、电可擦除可编程ROM、 寄存器、硬盘、可移动^兹盘、CD-ROM、或任意其它形式的存储介质中。
以上所述仅是本发明的具体实施方式
，应当指出，对于本技术领域的普 通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润 饰，这些改进和润饰也应视为本发明的保护范围。
权利要求
1、一种网络故障检测方法，其特征在于，包括向下游网元发送业务请求；当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果需要对所述下游网元发起故障检测请求，则向所述下游网元发起故障检测请求。
2、 如权利要求1所述的网络故障检测方法，其特征在于，所述当没有接 收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元 发起故障检测请求的步骤之前进一步包括向所述下游网元发送预定次数的业务请求之后，没有接收到来自所述下 游网元对业务^會求的响应。
3、 如权利要求1所述的网络故障检测方法，其特征在于，所述确定是否 需要对所述下游网元发起故障检测请求的步骤包括判断是否已经对所述下游网元进行故障检测，如果是，则不需要对所述 下游网元发起故障检测请求，如果否，则需要对所述下游网元发起故障检测 请求。
4、 如权利要求1所述的网络故障检测方法，其特征在于，所述对所述下 游网元发起故障检测请求的步骤之后进一步包括如果没有接收到来自所述下游网元对故障;险测请求的响应，则确定所述 下游网元发生故障；或者，如果没有接收到来自所述下游网元对故障检测请求的响应，则向所述下 游网元发起至少一次的故障检测请求，如果没有接收到来自所述下游网元对 所述至少一次故障检测请求的响应，则确定所述下游网元发生故障。
5、 如权利要求4所述的网络故障检测方法，其特征在于，在确定所述下 游网元发生故障的步骤之后，进一步包括继续向所述下游网元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包括接收到来自所述下游网元的对故障;险测请求的响应；或者， 超过一定的预设时间；或者，在一定的时间内需要发向所述下游网元的业务请求的数量小于预设值。
6、 一种网络设备，其特征在于，包括 业务请求发送模块，用于向下游网元发送业务请求；故障检测判断模块，用于当超过一定时间内没有接收到来自所述下游网 元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；故障检测消息发送模块，用于当故障检测判断模块判断需要对所述下游 网元发起故障检测请求时，向所述下游网元发起故障检测请求。
7、 如权利要求6所述的网络设备，其特征在于，进一步包括 响应接收模块，用于接收来自所述下游网元对故障检测请求的响应。
8、 如权利要求7所述的网络设备，其特征在于，进一步包括 故障判断模块，用于当所述响应接收模块没有接收到来自所述下游网元的对故障4企测请求的响应时，确定所述下游网元发生故障。
9、 如权利要求8所述的网络设备，其特征在于，所述故障检测消息发送 模块还用于当所述故障判断模块确定所述下游网元发生故障时，继续向所述下游网 元发起故障检测请求，直至停止发送故障检测请求的条件发生，所述条件包 括所述响应接收模块接收到来自所述下游网元的对故障检测请求的响应； 或者，超过一定的预设时间。
10、 如权利要求9所述的网络设备，其特征在于，进一步包括计算模块，用于统计在一定的时间内需要发向所述下游网元的业务请求的数量；当所述数量小于预设值时，指示所述故障检测消息发送模块停止向 所述下游网元发起故障;险测请求。
11、 如权利要求6至10中任一项所述的网络设备，其特征在于，所述网 络设备的类型包括路由器、交换机、网关GW、基站BS、基站控制器、网关GPRS支持节 点GGSN、服务GPRS支持节点SGSN、数字用户线复用器DSLAM、 AAA 服务器、呼叫会话控制器CSCF。
12、 一种网络系统，其特征在于，包括前端网元和下游网元，其中， 前端网元，用于向下游网元发送业务请求；当超过一定时间内没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发 起故障检测请求；如果是，则向所述下游网元发起故障检测请求；下游网元，用于接收来自所述前端网元的业务请求，如果该网络设备没 有发生故障，则对所述业务请求作出响应；接收来自所述前端网元的故障检 测请求，如果该下游网元没有发生故障，则对所述故障;险测请求作出响应。
13、 如权利要求12所述的网络系统，其特征在于，所述前端网元和下游 网元部署在移动网络、或固定网络、或移动固定融合网络、或传输网、或接 人网、或冲亥心网。
全文摘要
本发明实施例公开了一种网络故障检测方法，包括向下游网元发送业务请求；当超过一定时间没有接收到来自所述下游网元对业务请求的响应时，确定是否需要对所述下游网元发起故障检测请求；如果是，则向所述下游网元发起故障检测请求。本发明实施例还公开了相关网络设备和网络系统。通过本发明实施例，可以通过业务请求来感知下游网元的异常，启发前端网元对下游网元发起故障检测，减少了前端网元向下游网元发送的故障检测请求的数量，降低网络设备在故障检测方面的工作负荷，提高了网络传输效率。
文档编号H04L12/26GK101304343SQ20081006781
公开日2008年11月12日 申请日期2008年6月10日 优先权日2008年6月10日
发明者山 吴, 枫 梁, 申林飞 申请人:华为技术有限公司