一种实现QoS管理的方法及装置

摘要

本文公开了一种实现QoS管理的方法及装置，包括：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求；收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。本申请提供的QoS管理中实现保活的方法并不要求上行下行路由对称，适用于图2所示的实现QoS管理的架构，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。

权利要求

1.一种实现服务质量QoS管理的方法，其特征在于，包括：收到保活请求的策略执行监控点PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；

最后一跳PEMP收到保活请求，按照预先设置的保活处理策略进行相应的处理。

2.根据权利要求1所述的方法，其特征在于，所述收到保活请求的PEMP为第一PEMP；该方法之前还包括：第一PEMP收到来自网络控制网元的保活请求，按照所述保活处理策略进行保活处理并根据所述保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

3.根据权利要求1或2所述的方法，其特征在于，所述保活处理策略包括：向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；

或者，设置定时器等待下一跳PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；

或者，将所述保活请求转发给下一跳PEMP。

4.根据权利要求1或2所述的方法，其特征在于，所述保活处理策略为设置定时器等待下一跳PEMP回复所述保活临时应答消息时，还包括：如果所述定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，所述收到保活请求的PEMP向所述网络控制网元返回保活失败通知，并结束。

5.根据权利要求1或2所述的方法，其特征在于，所述按照预先设置的保活处理策略进行保活处理之前，还包括：所述收到保活请求的PEMP感知出自身节点存活。

6.根据权利要求3所述的方法，其特征在于，所述最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理包括：如果所述最后一跳PEMP感知自身节点存活，

向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，向所述最后一跳PEMP的后向节点返回保活临时应答消息，以便确定所述最后一跳PEMP自身与其后向PEMP之间的链路是畅通；以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。

7.一种实现QoS管理的装置，其特征在于，包括接收模块、处理模块；其中，接收模块，用于接收保活请求；

处理模块，用于按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

8.根据权利要求7所述的装置，其特征在于，所述保活处理策略包括：向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；

或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；

或者，直接将保活请求转发给下一跳PEMP。

9.根据权利要求8所述的装置，其特征在于，所述处理模块具体用于：当自身所属的PEMP不是最后一跳PEMP时，

按照所述保活处理策略，向所述网络控制网元回复表示收到保活请求的通知；或者，设置所述定时器等待下一跳PEMP即前向PEMP回复所述保活临时应答消息；或者，将所述接收到的保活请求转发给下一跳PEMP；

当自身所属的PEMP是最后一跳PEMP时，按照所述保活处理策略进行相应处理包括：向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；

或者，向自身所属的PEMP的后向节点返回保活临时应答消息，以便确定自身所属的PEMP与其后向PEMP之间的链路是畅通，以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；

或者，向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。

10.根据权利要求7所述的装置，其特征在于，当所述保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，所述处理模块还用于：当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，自身所属PEMP向发起所述保活请求的网络控制网元返回保活失败通知。

说明书

一种实现QoS管理的方法及装置

技术领域

[0001] 本发明涉及但不限于移动宽带系统技术，尤指一种实现QoS管理的方法及装置。

背景技术

[0002] 移动通信的发展给人们生活方式、工作方式以及社会的政治、经济等各方面都带来了巨大的影响。随着人类社会进入高效的信息化时代，各个方面业务应用需求呈现爆发式增长，给未来无线移动带宽系统在频率、技术以及运营等各方面都带来了巨大的挑战。

[0003] 第五代(5G)移动宽带系统将成为面向人类信息社会需求的无线移动通信系统，5G移动宽带系统是一个多业务多技术融合的网络，通过技术的演进和创新，满足未来广泛的数据、连接的各种业务不断发展的需要，以提升用户体验。随着无线移动通信系统带宽和能力的提升，面向个人和行业的移动互联网和物联网应用也在快速发展，移动通信相关产业生态将发生重要变化。无线移动通信技术与计算机及信息技术会更加紧密和更深层次的交叉融合，集成电路、器件工艺、软件技术等也将持续快速发展，以支撑未来5G移动宽带产业发展。

[0004] 根据社会职责和功能、终端用户、业务应用和网络运营等对未来5G的愿景分析，从技术的角度总结5G的关键能力需求如下：

[0005] 一方面，基于对近年来移动通信网络数据流量增长趋势，业界预测到2020年，全球总移动数据流量将达到2010年总移动数据流量的1000倍。这要求单位面积的吞吐量能力，特别是忙时吞吐量能力同样有1000倍的提升，需要达到100Gbps/km2以上。

[0006] 另一方面，未来5G网络用户范畴极大扩展，随着物联网的快速发展，业界预计到2020年连接的器件数目将达到500-1000亿。这就要求单位覆盖面积内支持的器件数目将极大增长，在一些场景下单位面积内通过5G移动网络连接的器件数目达到100万/km2，相对4G将增长100倍。

[0007] 另外，5G网络需要为用户提供随时在线的体验，并满足诸如工业控制、紧急通信等更多高价值场景需求。这样，一方面要求进一步降低用户面时延和控制面时延，相对4G缩短5-10倍，达到人类反应的极限如5ms(触觉反应)，并提供真正的永远在线体验。另一方面，一些关系人的生命、重大财产安全的业务，要求端到端可靠性提升到99.999％甚至100％。

[0008] 现有的第四代(4G)全IP的分组核心网(EPC，Evolved Packet Core)，演进分组系统(EPS，Evolved Packet System)的服务质量(QoS)管理架构如图1所示：

[0009] 现有的QoS管理主要由终端、基站以及分组网关等节点进行控制，用户签约的QoS参数由控制网元如移动管理实体(MME，Mobility Management Entity)通过控制信令控制面信令传递到终端、基站及分组网关等节点，这种处理机制主要存在以下问题：

[0010] 终端和服务器之间，没有真正实现端到端的QoS保证服务链接，如图1中所示，基站和分组网关之间的传输网，以及分组网关与外部服务器之间没有实现完善的QoS保障。而为了实现QoS管理，终端、基站和分组网关转发面设备需要建立承载连接，并保存承载的状态信息，这样无疑增加了转发设备的复杂度，并最终可能影响到转发设备的转发性能。

发明内容

[0011] 本发明提供一种实现QoS管理的方法及装置，能够降低转发设备的复杂度，并提高转发设备的转发性能。

[0012] 为了达到本发明目的，本发明提供了一种实现服务质量QoS管理的方法，包括：

[0013] 收到保活请求的策略执行监控点PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；

[0014] 最后一跳PEMP收到保活请求，按照预先设置的保活处理策略进行相应的处理。

[0015] 可选地，所述收到保活请求的PEMP为第一PEMP；该方法之前还包括：

[0016] 第一PEMP收到来自网络控制网元的保活请求，按照所述保活处理策略进行保活处理并根据所述保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

[0017] 可选地，所述保活处理策略包括：向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；

[0018] 或者，设置定时器等待下一跳PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；

[0019] 或者，将所述保活请求转发给下一跳PEMP。

[0020] 可选地，所述保活处理策略为设置定时器等待下一跳PEMP回复所述保活临时应答消息时，还包括：

[0021] 如果所述定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，[0022] 所述收到保活请求的PEMP向所述网络控制网元返回保活失败通知，并结束。

[0023] 可选地，所述按照预先设置的保活处理策略进行保活处理之前，还包括：所述收到保活请求的PEMP感知出自身节点存活。

[0024] 可选地，所述最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理包括：

[0025] 如果所述最后一跳PEMP感知自身节点存活，

[0026] 向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，

[0027] 向所述最后一跳PEMP的后向节点返回保活临时应答消息，以便确定所述最后一跳PEMP自身与其后向PEMP之间的链路是畅通；以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；或者，

[0028] 向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。

[0029] 本发明还提供了一种实现QoS管理的装置，包括接收模块、处理模块；其中，[0030] 接收模块，用于接收保活请求；

[0031] 处理模块，用于按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

[0032] 可选地，所述保活处理策略包括：

[0033] 向发起所述保活请求的网络控制网元回复表示收到保活请求的通知；

[0034] 或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；

[0035] 或者，直接将保活请求转发给下一跳PEMP。

[0036] 可选地，所述处理模块具体用于：

[0037] 当自身所属的PEMP不是最后一跳PEMP时，

[0038] 按照所述保活处理策略，向所述网络控制网元回复表示收到保活请求的通知；或者，设置所述定时器等待下一跳PEMP即前向PEMP回复所述保活临时应答消息；或者，将所述接收到的保活请求转发给下一跳PEMP；

[0039] 当自身所属的PEMP是最后一跳PEMP时，按照所述保活处理策略进行相应处理包括：

[0040] 向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；

[0041] 或者，向自身所属的PEMP的后向节点返回保活临时应答消息，以便确定自身所属的PEMP与其后向PEMP之间的链路是畅通，以及，向所述网络控制网元返回保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通；

[0042] 或者，向所述网络控制网元发送保活应答消息，以便所述网络控制网元根据保活应答消息确认业务链链路畅通。

[0043] 可选地，当所述保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，

[0044] 所述处理模块还用于：当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，自身所属PEMP向发起所述保活请求的网络控制网元返回保活失败通知。

[0045] 与现有技术相比，本申请提供的技术方案包括：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求；收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP；最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。本发明提供的QoS管理中实现保活的方法并不要求上行下行路由对称，适用于图2所示的实现QoS管理的架构，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。

[0046] 本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

[0047] 此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

[0048] 图1为相关技术中EPS的QoS管理架构示意图；

[0049] 图2为本发明中实现QoS管理的架构的示意图；

[0050] 图3为本发明实现QoS管理的方法的实施例的流程图；

[0051] 图4为本发明实现QoS管理的第一实施例的流程示意图；

[0052] 图5为本发明实现QoS管理的第二实施例的流程示意图；

[0053] 图6为本发明实现QoS管理的第三实施例的流程示意图；

[0054] 图7为本发明实现QoS管理的装置的组成结构示意图。

具体实施方式

[0055] 为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

[0056] 为了降低转发设备的复杂度，并提高转发设备的转发性能，本申请提出了一种实现QoS管理的架构，如图2所示，图2为本发明中实现QoS管理的架构的示意图，其中至少包括：接入网元、策略执行监控点(PEMP，Policy Enforcement&Monitor Point)、网络控制网元(Network Controller)，以及边际网关；其中，

[0057] 接入网元，包括接入控制网元和转发网元。其中，接入控制网元，主要用于在用户发起上行业务时，根据用户签约的QoS信息和访问的业务预留带宽，在报文中插入用户QoS信息并为该报文选择QoS路径；转发网元，用于转发该报文；

[0058] PEMP，主要用于根据报文中携带的QoS信息，检测路径是否满足QoS要求，当路径质量降低不能满足该报文的QoS要求时，向网络控制网元告警；

[0059] 网络控制网元，用于对收到的告警进行处理，如对网络进行调整等。

[0060] 边际网关，主要用于在传递下行数据报文时，根据用户签约的QoS信息和访问的业务预留带宽，在报文中插入用户QoS信息并为该报文选择QoS路径。

[0061] 基于图2所示的本申请提出的实现QoS管理的架构，按照相关技术方案，实现保活的方法大致会包括：下行方向，网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识；如果第一PEMP存活，则会根据业务链标识转发报文至下一跳即第二PEMP，并设置定时器等待下一跳PEMP回复保活应答，直到报文转发至最后一跳PEMP，按照下行路径原路向后向节点PEMP逐级返回保活应答消息。

[0062] 从本领域技术人员公知的实现保活的方法来看，报文转发的下行路径和上行应答路径必须是同一条路径，即是对称路径，否则，保活应答消息是无法正确返回的。而图2所示的实现QoS管理的架构中，PEMP间的路由机制采用业务链路由方式，是一种非对称路由即单向路由方式，如果还直接将本领域技术人员公知的实现保活的方法应用在图2所示的架构中，PEMP根据报文中业务链标识是无法将保活应答消息返回到第一PEMP的，也就是说会导致保活实现的失败。

[0063] 本发明为了适应图2所示的实现QoS管理的架构，对保活的处理包括：收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至下一跳PEMP；直至最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。图3为本发明实现QoS管理的方法的实施例的流程图，如图3所示，包括：

[0064] 步骤300：第一PEMP收到来自网络控制网元的保活请求，按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

[0065] 如果第一PEMP感知自身节点存活，则进行后续处理，否则退出本流程。

[0066] 本步骤中的保活处理策略可以包括：向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP。

[0067] 当保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，如果定时器超时仍未收到下一跳PEMP返回的保活临时应答消息，本发明方法还包括：

[0068] 第一PEMP认为自身与下一跳PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。

[0069] 步骤301：收到保活请求的PEMP按照预先设置的保活处理策略进行保活处理并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求直至最后一跳PEMP。

[0070] 本步骤的具体实现与步骤300中的完全一致，这里不再赘述。

[0071] 步骤302：最后一跳PEMP收到保活请求，进行与按照预先设置的保活处理策略相应的保活处理。

[0072] 如果最后一跳PEMP感知自身节点存活，本步骤中的按照预先设置的保活处理策略相应的保活处理包括：

[0073] 向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，向后向节点返回保活临时应答消息，以便确定最后一跳PEMP自身与后向PEMP之间的链路是畅通的；以及，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。

[0074] 本发明提供的QoS管理中实现保活的方法并不要求上行下行路由对称，适用于图2所示的实现QoS管理的架构，为保活的实现提供了前提，同时降低了转发设备的复杂度，并提高了转发设备的转发性能。

[0075] 下面结合具体实施例对本发明基于图2所示的架构提出的实现保活的方法进行详细描述。

[0076] 图4为本发明实现QoS管理的第一实施例的流程示意图，如图4所示，第一实施例中，假设保活处理策略为：向网络控制网元回复表示收到保活请求的通知。具体实现包括：

[0077] 步骤400：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。

[0078] 步骤401：如果第一PEMP存活，根据业务链标识转发保活请求至下一跳如图4中的第二PEMP，并且，第一PEMP向网络控制网元回复表示收到保活请求的通知。

[0079] 本步骤中，表示收到保活请求的同时可以是现有的保活应答消息，或者是预先设置的新的通知消息，这里强调的是在PEMP收到保活请求后通知网络控制网元，至于通知的方式并不用于限定本发明的保护范围。

[0080] 步骤403～步骤404：后续收到保活请求的PEMP(除最后一跳PEMP外)的处理与第一PEMP收到报文的处理是完全一致的，这里不再赘述。

[0081] 步骤405～步骤406：最后一跳PEMP收到保活请求，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。

[0082] 图5为本发明实现QoS管理的第二实施例的流程示意图，如图5所示，第二实施例中，假设保活处理策略为：设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息。本实施例中以包括四级PEMP为例进行描述，具体实现包括：

[0083] 步骤500：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。

[0084] 步骤501～步骤502：如果感知第一PEMP存活，根据业务链标识转发保活请求至下一跳PEMP即第二PEMP，并且，第一PEMP按照预先设置的保活处理策略，设置定时器，用于等待其前向节点即第二PEMP返回保活临时应答消息。

[0085] 其中，保活临时应答消息用于表示第一PEMP和第二PEMP之间的链路是畅通的。

[0086] 进一步地，如果定时器超时仍未收到第二PEMP返回的保活临时应答消息，那么，第一PEMP认为自身与第二PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。

[0087] 步骤503～步骤504：第二PEMP收到保活请求，如果感知自身存活，则向后向节点即第一PEMP返回保活临时应答消息，向前向节点即第三PEMP转发保护请求，并按照预先设置的保活处理策略，设置定时器，用于等待其前向节点即第三PEMP返回保活临时应答消息。

[0088] 本步骤的具体实现与步骤501～步骤502完全一致，这里不再赘述。

[0089] 同样地，如果定时器超时仍未收到第三PEMP返回的保活临时应答消息，那么，第二PEMP认为自身与第三PEMP之间的链路可能中断，则直接向网络控制网元返回保活失败通知，并结束本流程。

[0090] 步骤505～步骤507：最后一跳PEMP收到保活请求，感知自身存活，则向后向节点返回保活临时应答消息，并向网络控制网元返回保活应答消息。

[0091] 本步骤中，最后一跳PEMP除了按照预先设置的保活处理策略向其后向节点返回表示自身和与其后向节点之间的链路是畅通的保活临时应答消息外，还会向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。

[0092] 图6为本发明实现QoS管理的第三实施例的流程示意图；如图6所示，第三实施例中，假设保活处理策略为：直接将保活请求转发给下一跳PEMP。具体实现包括：

[0093] 步骤600：网络控制网元向第一PEMP发送保活请求，在保活请求中携带有业务链标识。

[0094] 步骤601：如果第一PEMP感知节点存活，直接将收到的保活请求发送给其前向节点即第二PEMP。

[0095] 步骤602：第二PEMP对收到的保活请求的处理与步骤601完全一致，这里不再赘述。

[0096] 步骤603：最后一跳PEMP收到保活请求后，向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。

[0097] 本发明实施例还提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行上述任一实现QoS管理的方法。

[0098] 图7为本发明实现QoS管理的装置的组成结构示意图，如图7所示，至少包括：接收模块，处理模块；其中，

[0099] 接收模块，用于接收保活请求；

[0100] 处理模块，用于按照预先设置的保活处理策略进行保活处理，并根据保活请求中携带的业务链标识向下一跳PEMP转发保活请求。

[0101] 其中，保活处理策略可以包括：向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP。

[0102] 处理模块具体用于：

[0103] 当自身所属的PEMP不是最后一跳PEMP时，按照预先设置的保活处理策略，向网络控制网元回复表示收到保活请求的通知；或者，设置定时器等待下一跳PEMP即前向PEMP回复用于表示当前PEMP和其前向PEMP之间的链路是畅通的保活临时应答消息；或者，直接将保活请求转发给下一跳PEMP；

[0104] 当自身所述的PEMP是最后一跳PEMP时，按照预先设置的保活处理策略进行相应处理：向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，向后向节点返回保活临时应答消息，以便确定最后一跳PEMP自身与后向PEMP之间的链路是畅通；以及，向网络控制网元返回保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通；或者，向网络控制网元发送保活应答消息，以便网络控制网元根据保活应答消息确认业务链链路畅通。

[0105] 进一步地，

[0106] 当预先设置的保活处理策略为设置定时器等待下一跳PEMP回复保活临时应答消息时，处理模块还用于：

[0107] 当定时器超时仍未收到下一跳PEMP返回的保活临时应答消息时，自身所属PEMP认为自身与下一跳PEMP之间的链路可能中断，直接向网络控制网元返回保活失败通知。

[0108] 本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

[0109] 以上所述，仅为本发明的较佳实例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。