CN103687028B - 资源保活方法以及资源释放方法 - Google Patents

Abstract

本发明涉及一种应用于SGW网元的资源保活方法，该方法基于业务板和信令板分布式部署，包括：S1.信令板分别向相应的业务板发送保活检测消息；S2.判断是否收到所述业务板反馈的响应消息，如果是，则判断所述业务板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；S3.根据预定次数的保活检测失败来判断对应的业务板故障。本发明还涉及一种利用上述资源保活方法的资源释放方法，该资源释放方法包括：S4.业务板故障时，与该业务板对应的业务处理节点故障；S5.根据所述故障的业务处理节点查找需要进行资源释放的用户；S6.对于需要资源释放的用户，根据预先在信令节点保存的用户TEIDU_SGW信息和TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源。

Description

资源保活方法以及资源释放方法

技术领域

本发明涉及无线网络技术领域，尤其涉及一种资源保活方法和利用所述资源保活方法的资源释放方法。

背景技术

LTE（Long Term Evolution，长期演进)网络中，对于SGW（Serving Gate Way）服务网关网元，按照功能实体的划分，主要包括信令面，用户面两大功能模块，为满足负载均衡和容灾备份的要求，在网元的内部，信令板跟业务板都采用分布式部署，即通常情况下，都存在多块信令板跟业务版，用户量大的情况下，信令面会分摊在多个信令板上，用户面也会分摊在多个业务板上，逻辑上来说，信令板跟用户板之间就存在多对多的关系，如图1所示。

为了保证SGW内部网元的资源一致性，信令板跟业务板之间采用心跳检测方式，进行定时的单板保活，出现异常时，比如某块信令板发生故障，那么为了保证内部网元的资源一致，业务板检测到这种故障之后，会自行释放业务板上的用户资源，同理，信令板检测到业务板故障之后，也会释放信令板上的用户资源，保证资源的一致性。目前，按照用户及级别进行资源的保活检测，比如对于用户A来说，信令处理单元位于信令板1上，业务处理单元位于业务板1上，那么信令板1会定时的对于该用户的业务面进行保活检测，业务板1上也会对该用户的信令面进行保活检测。信令板1出现故障时，上面的用户A，D异常，那么业务板1上，对用户A进行资源释放，业务板2上，对用户D进行资源释放，保证SGW网元内部资源的一致性；业务板1故障时，用户A，E，F异常，信令板1,2， n分别对于用户A，E，F进行资源释放，保证SGW网元内部资源的一致性。

但是因为SGW处于一个中间网元状态，目前的协议（23.401协议）不允许SGW主动发起对前端网元MME（Mobility Management Entity）移动性管理实体或者后端网元PGW(PDNGateWay)分组数据网关的资源释放，那么在上面情况下，虽然保证了网元内用户面、信令面的资源一致性，但是会出现网元间的资源出现异常，并且这种情况下，因为单板上一般存在多个用户，会导致大量用户的资源不一致，即 MME跟PGW存在该用户资源，但是SGW不存在该用户资源。

对于目前的业务属性来说，大部分的业务都是先上行，后下行，所以对于MME侧来说，一旦用户有上行业务，可以通过ErrorIndication 来释放，但是对于下行业务来说，因为没有上行的触发，可能会一直没有下行业务，导致检测不到该用户在SGW侧已经被释放了，导致 PGW和SGW侧的资源长时间不一致。

发明内容

本发明所要解决的技术问题是：在用户量大的时候，由于基于用户级别的保活检测，导致内部的保活消息非常频繁，造成内部消息拥塞，增加系统的负荷处理；而且网元出现异常时，在资源释放过程中，无法保证网元间资源相一致 。

为此目的，本发明提出了一种应用于服务网关SGW网元的资源保活方法，该方法基于信令板和业务板的分布式部署，该方法包括：

S1.信令板分别向相应的业务板发送保活检测消息；

S2.判断是否收到所述业务板反馈的响应消息，如果是，则判断所述业务板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3.根据预定次数的保活检测失败来判断对应的业务板故障。

优选地，该方法在步骤S1之前包括：

S01.设置定时保活定时器，在所述信令板正常启动后，自动启动所述定时保活定时器；

S02.判断定时器是否超时，如果超时则执行所述步骤S1。

优选地，该方法在步骤S1之前包括：

S011.设置保活失败计数器，在所述信令板正常启动后，自动启动所述保活失败计数器，并初始化，所述保活失败计数器和业务板相对应。

优选地，所述步骤S2包括：

在判断所述业务板正常时，保活失败计数器清零，在判断保活检测失败时，保活失败计数器加1。

本发明还提供一种利用前面所述的资源保活方法的资源释放方法，该资源释放方法包括：

S0.在用户接入网络的过程中，在信令处理节点保存用户的SGW 侧用户面隧道标识TEIDU_SGW信息和PGW侧用户面隧道标识 TEIDU_PGW信息；

S4.业务板故障时，则判断与该业务板对应的业务处理节点故障；

S5.根据所述故障的业务处理节点查找需要进行资源释放的用户；

S6.对于需要资源释放的用户，根据其TEIDU_SGW信息和TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

优选地，所述步骤S5具体包括：

S51.依次获取每个用户下存储的业务处理节点IP(T_IP)；

S52.将所述业务处理节点IP(T_IP)与所述故障的业务处理节点 IP(T_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6，否则，判断该用户不需要进行资源释放；

S53.返回步骤S51处理下一个用户。

本发明提供一种应用于服务网关SGW网元的资源保活方法，该方法基于信令板和业务板的分布式部署，包括：

S1’.业务板分别向相应的信令板发送保活检测消息；

S2’.判断是否收到所述信令板反馈的响应消息，如果是，则判断所述信令板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3’.根据预定次数的保活检测失败来判断对应的信令板故障。

优选地，该方法在步骤S1’之前包括：

S01’.设置定时保活定时器，在所述业务板正常启动后，自动启动所述定时保活定时器；

S02’.判断定时器是否超时，如果超时则执行所述步骤S1’。

优选地，该方法在步骤S1’之前包括：

S011’.设置保活失败计数器，在所述业务板正常启动后，自动启动所述保活失败计数器，并初始化，所述保活失败计数器和信令板相对应。

优选地，所述步骤S2’包括：

在判断所述信令板正常时，保活失败计数器清零，在判断保活检测失败时，保活失败计数器加1。

本发明还提供一种利用前面所述的资源保活方法的资源释放方法，该资源释放方法包括：

S0’.在用户接入网络的过程中，在信令处理节点保存用户的SGW 侧用户面隧道标识TEIDU_SGW信息和PGW侧用户面隧道标识 TEIDU_PGW信息；

S4’.信令板故障时，则判断与该信令板对应的信令处理节点故障；

S5’.根据所述故障的信令处理节点查找需要进行资源释放的用户；

S6’.对于需要资源释放的用户，根据其TEIDU_SGW信息和 TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

优选地，所述步骤S5’具体包括：

S51’.依次获取每个用户下存储的信令处理节点IP(S_IP)；

S52’.将所述信令处理节点IP(S_IP)与所述故障的信令处理节点 IP(S_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6’，否则，判断该用户不需要进行资源释放；

S53’.返回步骤S51’处理下一个用户。

13、如权利要求5、6、11、12任一项所述的资源释放方法，其特征还在于，所述错误指示消息还包含对端网元侧用户的IP地址。

通过采用本发明所公开的资源保活方法和资源释放方法，能够减少SGW网元内容的消息量，能够实现网元间的资源一致。

附图说明

通过参考附图会更加清楚的理解本发明的特征和优点，附图是示意性的而不应理解为对本发明进行任何限制，在附图中：

图1为表示SGW网元中信令处理单元和业务处理单元分布式部署的示意图；

图2为表示本发明实施例1的保活检测方法的流程图；

图3为表示本发明实施例1优化后的保活检测方法的流程图；

图4为表示本发明在attach过程中的信令面、业务面配置流程图；

图5为表示本发明实施例3中的资源释放方法的流程图；

图6为表示本发明实施例3中优化后的资源释放方法的流程图；

具体实施方式

下面将结合附图对本发明的实施例进行详细描述。特别要说明的是，下面的实施例是为了更清楚的表达本发明的技术方案，但本发明并不局限于下面的具体实施方式。

实施例1

为了减少内部的消息量，采用基于单板级别的用户资源保活，如图1所示，信令板1对于业务板1，m，分别进行单板的保活探测，业务板和信令板分布式部署时，业务板跟信令板的个数相对于用户数来说，要少的多，进行单板级别的资源保活，相对于现有技术中的基于用户及其级别的资源保活可以大大减少内部消息量。本实施例提供一种应用于服务网关SGW网元的资源保活方法，该方法基于信令板和业务板的分布式部署，如图2所示，该方法包括：

S1.信令板分别向相应的业务板发送保活检测消息；

S2.判断是否收到所述业务板反馈的响应消息，如果是，则判断所述业务板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3.根据预定次数的保活检测失败来判断对应的业务板故障。

优选的，如图3所示，针对每个业务板设置相对应的定时保活定时器，在所述信令板正常启动后，自动启动所述定时保活定时器，判断定时器是否超时，如果超时则执行所述步骤S1。即利用所述定时保活定时器定时的发送保活检测消息（如心跳消息），每到一个定时，就完成一次保活检测。为了避免误检测，设置保活失败计数器，在所述信令板正常启动后，自动启动所述保活失败计数器，并初始化，所述保活失败计数器和业务板相对应。在判断所述业务板正常时，保活失败计数器清零，在判断保活检测失败时，保活失败计数器加1。使用一个保活失败次数P控制，即连续P次都保活失败，则认为相对应的业务板单板异常。

实施例2

业务板1对信令板1，n，分别进行单板的保活探测，分布式部署时，业务板跟信令板的个数相对于用户数来说，要少的多，进行单板级别的资源保活，可以大大减少内部消息量，

本实施例提供另一种应用于服务网关SGW网元的资源保活方法，该方法基于信令板和业务板的分布式部署，该方法包括：

S1’.业务板分别向相应的信令板发送保活检测消息；

S2’.判断是否收到所述信令板反馈的响应消息，如果是，则判断所述信令板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3’.根据预定次数的保活检测失败来判断对应的信令板故障。

优选的，针对每个信令板设置定时保活定时器，在所述业务板正常启动后，自动启动所述定时保活定时器，判断定时器是否超时，如果超时则执行所述步骤S1’。即利用所述定时保活定时器定时的发送保活检测消息，每到一个定时，就完成一次保活检测。

优选地，该方法在步骤S1’之前包括：

S011’.针对每个信令板设置保活失败计数器，在所述业务板正常启动后，自动启动所述保活失败计数器，并初始化，所述保活失败计数器和信令板相对应。

优选地，所述步骤S2’包括：

在判断所述信令板正常时，保活失败计数器清零，在判断保活检测失败时，保活失败计数器加1。使用一个保活失败次数P控制，即连续P次都保活失败，则认为相对应的信令板单板异常。

实施例3

如图4所示，Attach过程中，SGW收到MME的请求消息后，分配本地的TEIDU_SGW资源，再发送消息给PGW网元，收到PGW网元的成功响应之后，根据PGW的响应消息，获取PGW网元的TEIDU_PGW，配置本地的用户面，同时携带本信令板的地址S_IP，收到用户面的响应之后，存储该用户的业务板地址T_IP，正常情况下，这些用户面的资源，对于信令面来说，是不需要关心了，为了后续的网元间资源释放，需要在信令处理节点保存该用户(PDN)的TEIDU_SGW， TEIDU_PGW信息。

如实施例1所述，业务板m出现故障时，对应的信令单元能够检测到。之后，信令板根据业务板m的地址，释放信令板上的用户内部资源，同时，根据该用户的TEIDU_SGW，TEIDU_PGW信息，信令面主动组织一条ErrorIndication消息，通知对端网元进行资源的释放。

具体地，本实施例提供一种利用实施例1所述的资源保活方法的资源释放方法，如图5所示，该资源释放方法包括：

S4.业务板故障时，则判断与该业务板对应的业务处理节点故障；

S5.根据所述故障的业务处理节点查找需要进行资源释放的用户；

S6.对于需要资源释放的用户，根据其TEIDU_SGW信息和 TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

优选地，如图6所示，所述步骤S5具体可包括：

S51.依次获取每个用户下存储的业务处理节点IP(T_IP)；

S52.将所述业务处理节点IP(T_IP)与所述故障的业务处理节点 IP(T_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6，否则，判断该用户不需要进行资源释放；

S53.返回步骤S51处理下一个用户。

如实施例2所述，信令板n出现故障时，对应的业务板能够检测到。之后，根据信令板n的地址S_IPn，释放业务板上的内部资源，同时，根据该用户的TEIDU_SGW，TEIDU_PGW信息，主动组织一条 ErrorIndication消息，通知对端网元进行资源的释放。

实施例4

如实施例2所述，信令板n出现故障时，对应的业务单元检测到之后，根据信令n的地址S_IPn，释放业务板上的内部资源，同时，根据该用户的TEIDU_SGW，TEIDU_PGW信息，主动组织一条 ErrorIndication消息，通知对端网元进行资源的释放。

具体地，本实施例提供一种利用实施例2所述的资源保活方法的资源释放方法，该资源释放方法包括：

S0’.在用户接入网络的过程中，在信令处理节点保存用户的SGW 侧用户面隧道标识TEIDU_SGW信息和PGW侧用户面隧道标识 TEIDU_PGW信息；

S4’.根据实施例2所述的资源保活方法判断出信令板故障时，则判断与该信令板对应的信令处理节点故障；

S5’.根据所述故障的信令处理节点查找需要进行资源释放的用户；

S6’.对于需要资源释放的用户，根据其TEIDU_SGW信息和 TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

优选地，所述步骤S5’具体包括：

S51’.依次获取每个用户下存储的信令处理节点IP(S_IP)；

S52’.将所述信令处理节点IP(S_IP)与所述故障的信令处理节点 IP(S_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6’，否则，判断该用户不需要进行资源释放；

S53’.返回步骤S51’处理下一个用户。

值得说明的是，所述错误指示消息还应包含对端网元侧用户的IP 地址。

本发明通过针对单板级别的用户资源保活检测大大减少内部消息的产生；通过信令面跟用户面互相结合进行资源释放的方法，不需要修改现有的协议，能够解决SGW侧不能主动发起资源释放的问题，可以在SGW需要进行资源时，彻底解决核心网内各个网元的资源不一致问题。本发明内部网元仅仅在组织一个Errorindication包，不影响正常流程，因而处理开销小，便于实现。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (5)

1.一种资源释放方法，其特征在于，该资源释放方法包括：

S0.在用户接入网络的过程中，在信令处理节点保存用户的SGW侧用户面隧道标识TEIDU_SGW信息和PGW侧用户面隧道标识TEIDU_PGW信息；

S1.信令板分别向相应的业务板发送保活检测消息；

S2.判断是否收到所述业务板反馈的响应消息，如果是，则判断所述业务板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3.根据预定次数的保活检测失败来判断对应的业务板故障；

S4.业务板故障时，则判断与该业务板对应的业务处理节点故障；

S5.根据所述故障的业务处理节点查找需要进行资源释放的用户；

S6.对于需要资源释放的用户，根据其TEIDU_SGW信息和TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

2.如权利要求1所述的资源释放方法，其特征还在于，所述S5具体包括：

S51.依次获取每个用户下存储的业务处理节点IP(T_IP)；

S52.将所述业务处理节点IP(T_IP)与所述故障的业务处理节点IP(T_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6，否则，判断该用户不需要进行资源释放；

S53.返回步骤S51处理下一个用户。

3.一种资源释放方法，其特征在于，该资源释放方法包括：

S0’.在用户接入网络的过程中，在信令处理节点保存用户的SGW侧用户面隧道标识TEIDU_SGW信息和PGW侧用户面隧道标识TEIDU_PGW信息；

S1’.业务板分别向相应的信令板发送保活检测消息；

S2’.判断是否收到所述信令板反馈的响应消息，如果是，则判断所述信令板正常，本次保活检测结束，否则，判断本次保活检测失败，本次保活检测结束；

S3’.根据预定次数的保活检测失败来判断对应的信令板故障；

S4’.信令板故障时，则判断与该信令板对应的信令处理节点故障；

S5’.根据所述故障的信令处理节点查找需要进行资源释放的用户；

S6’.对于需要资源释放的用户，根据其TEIDU_SGW信息和TEIDU_PGW信息组织错误指示消息，发送给对端网元，以指示对端网元释放资源，并同时释放SGW网元内部资源。

4.如权利要求3所述的资源释放方法，其特征还在于，所述S5’具体包括：

S51’.依次获取每个用户下存储的信令处理节点IP(S_IP)；

S52’.将所述信令处理节点IP(S_IP)与所述故障的信令处理节点IP(S_Ipi)相比较，如果相同，则判断该用户需要进行资源释放，然后执行步骤S6’，否则，判断该用户不需要进行资源释放；

S53’.返回步骤S51’处理下一个用户。

5.如权利要求3或4所述的资源释放方法，其特征还在于，所述错误指示消息还包含对端网元侧用户的IP地址。