一种通用分组无线服务隧道用户面路径保活方法和系统
技术领域
本发明涉及一种在LTE(Long Term Evolution,长期演进)系统中eNB(evolved Node B,演进的节点B)之间,或者eNB与EPC(Evolved PacketCore,演进的分组数据的核心网)之间GPRS(General Packet RadioService,通用分组无线服务)隧道用户面(简称GTPU,GPRS TunnelProtocol User-plane)路径保活的处理技术。
背景技术
在LTE移动通讯系统里面,eNB网元提供了各式各样的UE(UserEquipment,用户设备)接入EPC(Evolved Packet Core,演进的分组数据的核心网)的通道。LTE系统采用扁平化网络结构,对eNB来说,地面传输主要涉及两个接口:S1接口(S1接口为EPC和eNB间接口)和X2接口(X2接口为eNB间接口)。接口示意图如附图1所示。S1、X2接口采用IP(Internet Protocol,网际协议)传输,S1接口断链会导致业务不可行,X2接口断链会导致跨eNB切换不可行。接口上用户面数据采用GTPU协议进行传输。
在实际组网中,一个eNB可能和多个eNB连接,S1和X2口也不是仅直接连接着eNB或者EPC,也就是说有可能中间经过了多级交换和路由设备甚至多种物理承载,而这些路由和交换设备甚至传输承载的可靠性并不能百分之百的保证。
GTPU协议是基于UDP(User Datagram Protocol,用户数据报文协议)协议的,UDP协议是一个无连接无确认的协议,也就是说,如果底层断链,UDP协议以及下层协议缺乏一个有效的发现机制,所以GTPU协议规定了一个路径保活的机制,但是这个路径保活机制需要较长的时间才能确认底层链路断链,GTPU路径保活主要有以下几个步骤:
1)eNB或EPC任何一端都可以作为保活机制的发起端,而另一端作为响应端,发起端主动定时向响应端发送保活消息,响应端响应消息,发起端在定时器超时的时间间隔里面收到响应,则认为链路正常;
2)如果定时器超时而发起端未收到响应报文,发起端不能马上判定路径异常,而需要再次发送路径保活消息;
3)只有在发送消息超时多次未收到任何响应,发起端才会认为底层链路异常,从而释放对应链路上的所有相关资源。
在上述保活流程里面,协议没有限定超时定时器的时长和重发次数,但是限定了正常情况下发送路径保活消息的间隔必须不小于60秒。而考虑网络繁忙情况下正常丢包,重发次数可能需要10次左右才算合理。也就是说,按照协议流程,GTPU以及上层需要10分钟才能识别底层链路断链。
需要特别说明的是,在GTPU的传输路径上面,时刻都有可能有业务数据在传输,而不仅仅是路径保活消息在传输。而对应这些业务数据是会占用其它资源的,例如,eNB通过S1接口发往EPC的报文,最初的来源是UE,UE产生业务数据,通过UE的接入层处理,在空口上被发送到eNB,然后通过eNB的用户面处理,才以GTPU协议报文的方式通过S1接口发往EPC。也就是说,如果S1接口断链,但是UE不能即时检测到,则UE会按照正常流程发送业务报文,这些业务报文会占用UE、eNB的处理资源,会占用空中接口的带宽,但是报文实际上是送不到预期的对端的。
如果按照标准的协议流程,则在这10分钟里面,断链的路径上面对应的业务实际上是不通的,对应业务的UE处理资源、eNB处理资源、空中无线资源是浪费的;又因为系统侧不能及时识别异常并通知到用户,例如用户正在通话中S1/X2通道断链,用户认为系统正常但是实际已经无法通话了,用户对系统的满意度会下降。
之所以GTPU协议定义一个这样的保活协议,是因为GTPU协议最初是适配2G和3G组网的,在2/3G时代,系统组网尚未扁平化,eNB被拆分成基站和基站控制器,GTPU协议在基站控制器和核心网之间发生作用,而基站控制器和核心网之间的组网往往非常简单(甚至可能基站控制器和核心网的接入设备就在统一机房),同时,早期的组网多采用异步传输模式组网,网络的连通性可以通过其它方式检测。而LTE系统组网采用IP传输,检测断链的方便性大大减少,同时,eNB和核心网之间的距离拉大,导致底层传输链路断链的可能性大大加大。但是LTE系统沿用GTPU协议,协议本身并未做任何改进。因此,LTE系统里面有较大可能会出现因为GTPU链路异常导致相关资源浪费,用户满意度降低的情况。
发明内容
本发明要解决的技术问题是提出一种路径保活的方法和系统,使包含GTPU协议层的各网元能更快地检测到之间的传输链路异常,从而减少相关资源的浪费,提升用户满意度。
本发明的技术方案是:
一种GTPU路径保活方法,包括以下处理步骤:
1)正常状态下,各网元的GTPU协议层按照协议规定发送业务报文,并定时发送路径保活消息;
2)网元同时通过非GTPU路径保活方式侦测GTPU传输路径的连接情况;
3)当网元通过底层监测到所述链路断链,而GTPU协议层尚未检测到时,监测端网元中的GTPU协议层作为保活发起端,加大向保活响应端发送路径保活消息的频率,并等待保活响应端的路径保护响应,保活发起端根据保活消息的响应消息判断链路的状态;
4)如果链路正常,返回步骤1);如果链路异常,通知网元GTPU协议层的上层释放链路相关业务。
进一步地,所述步骤2)中具体为:通过网元之间的发送GTPU报文,并侦测中间设备反馈的ICMP报文的方式监测传输通道链路连接情况。
优选的,所述步骤3)进一步包括以下处理步骤:
31)保活发起端接收到传输通道链路断链的通知;
32)保活发起端加大路径保活消息的发送频率,并对消息设定响应接收定时器;该步骤中设定的响应接收定时器的时长应大于传输链路的正常时延;一般略大即可,为了提升效率,不用设置的特别大。
33)保活发起端统计在各定时器定时范围内接收的响应情况,判断链路的状态。
所述步骤33)进一步包括以下处理步骤:
331)设定响应次数门限;
332)如果在响应次数门限内保活发起端收到保活消息响应,则判断为链路正常;
333)否则,判断为链路异常。
所述的保活发起端和保活响应端之间的传输接口为S1接口或者X2接口。所述的保活发起端为eNB时,所述的保护响应端为与发起端连接的其他eNB或者EPC;所述的保护发起端为EPC时,所述的保护响应端为与发起端连接的eNB。
一种通用分组无线服务隧道用户面路径保活系统,包括:
保活发起端,用于在正常状态下,向保活响应端发送业务报文和定时发送路径保活消息;还用于在传输通道断链时,加大向保活响应端发起路径保活消息的频率,等待保活响应端的路径保护响应,并根据保活消息的响应消息判断链路的状态;以及在判断传输通道断链后,通知网元GTPU协议层的上层释放链路业务;
保活响应端,用于响应保活发起端的路径保活消息。
进一步地,所述保活发起端还用于向保活响应端发送GTPU报文,以及根据接收到的中间设备反馈的ICMP报文判断传输通道断链情况。
本发明通过GTPU协议层的底层主动通知GTPU协议层传输通道可能断链,从而触发GTPU协议层加快频率的路径保活消息发送的处理方式,加快了GTPU协议层对底层链路异常的发现过程,从而减少了S1/X2接口的丢包,同时减少了相关资源的浪费,提升了业务质量。其中提升业务质量,减少相关资源浪费的程度取决于更快发送频率的设定。例如正常的协议流程是每分钟发送一个路径保活消息,10次超时判定路径异常;而异常路径保活可以是每秒发送一个路径保活消息,10次超时判定路径异常,10秒对比10分钟是一个很大的改善。本发明基于LTE系统提出,在LTE系统有较大的应用价值,在使用GTPU协议的2/3G系统里面也有应用价值。
附图说明
图1为eNodeB和EPC的组网结构原理图;
图2为GTPU与IP协议栈以及传输链路之间的关系图;
图3为本发明优选实施例的LTE系统路径保活方法流程图;
图4为本发明与现有技术对比的优选实施例路径保活方法原理图。
具体实施方式
下面结合附图并通过具体实施例对本发明的技术方案进行详细说明。
如图1所示的组网结构。eNodeB可以与多个eNodeB通过X2接口相连,也可以与多个EPC通过S1接口相连。S1接口和X2接口采用IP传输。eNodeB之间以及eNodeB与EPC之间可能还有一些中间设备,例如多级交换和路由设备等,这些设备之间还可能有多种物理承载,这些承载的可靠性无法得到保证。本发明的路径保活方法就是为了更快速的发现链路异常,释放业务。
如图2所示的GTPU协议层和传输链路的关系:GTPU承载业务层的报文,GTPU的协议数据和业务层的数据通过GTPU的封装,被打包成IP/UDP报文,IP/UDP报文可以承载在以太网等传输路径上面,为了完成IP协议的数据传输,有一套相关的协议配合,一般将IP协议以及相关协议统称为IP协议栈。为了描述方便,对于两个网关之间监测传输链路时,设定一个网元为保活发起端,另一个网元为保活响应端。本发明系统的基本思路是:在正常状态下,保活发起端向保活响应端发送业务报文和定时发送路径保活消息;在传输通道断链时,保活发起端加大向保活响应端发起路径保活消息的频率,等待保活响应端的路径保护响应,并根据保活消息的响应消息判断链路的状态;以及在判断传输通道断链后,保活发起端通知该网元GTPU协议层的上层释放链路业务。而保活响应端,仅用于响应保活发起端的路径保活消息。其中判断传输通道的链路连接情况可以采用:保活发起端向保活响应端发送GTPU报文,保活发起端根据接收到的中间设备反馈的ICMP报文判断传输通道断链情况。即图示网元中传输的包括:业务数据流、IP协议栈交互数据(ICMP、路由等协议报文)和路径保活消息。如图1中网元eNodeB与EPC都可以作为保活发起端和保活响应端,之间的传输接口可以为:S1接口或者X2接口。
如图3所示的保活处理流程,S1/X2接口两端设备按照协议规定正常处理路径保活流程,同时正常做业务数据的收发。将一端定义为保活发起端,另一端定义为保活响应端。正常的路径保活流程是保活发起端定时向保活响应端发送路径保活消息,本发明采用的是:如果中间设备存在断链,则这种断链可能被GTPU协议下层的IP协议栈检测到,IP协议层主动通知GTPU协议层启动特定路径保活流程,例如中间设备会向发起端发送一个目的不可达的ICMP(Internet Control Message Protocol,网络控制消息协议)报文。发起端在收到这个ICMP报文的时候,会由发起端的IP协议栈侦测到并进行IP协议层的处理,IP协议栈同时通知GTPU协议层启动特定路径保活流程。特定保活情况下,保活发起端以更快的频率向保活响应端发送路径保活消息,并启动定时器,对发送消息进行响应计数。如在路径保活消息对应的定时器超时范围内有收到响应,则认为底层误报、链路正常、断链是暂态行为,恢复正常的路径保活消息发送频率,S1/X2接口按照GTPU协议正常处理。如果保活消息在对应定时器超时范围内都没有收到响应,并且其次数达到设定的计数阈值,则认为链路异常,通知高层释放链路相关业务。
以下再通过一个具体实施例,对比现有计数的处理方法和本发明处理方法的区别。
如图4所示,步骤1为链路正常情况下的路径保活信令流程,步骤2为当中间设备和保活响应端之间发生链路断链的情况下,现有技术提出的路径保活消息信令流程;步骤3为当中间设备和保活响应端之间发生链路断链的情况下,本发明提出的路径保活消息信令流程。
步骤1:
a)发起端向响应端周期发送路径保活消息,发送周期可以取值为60s,例如箭头a、箭头c所示,发起端在发送消息的同时启动定时器,定时器时长设置应该比传输链路的正常时延稍长,例如可以是1s。
b)链路正常的情况下,响应端收到保活消息,向发起端回应响应,响应在发起端定时器超时前到达,则认为链路正常,例如箭头b、箭头d,收到响应,发起端取消定时器。
步骤2:
a)发起端依旧周期向响应端发送路径保活消息,并启动定时器,如箭头e,箭头f所示;
b)此时中间设备和响应端中间链路存在异常,图示中为X,这个保活消息实际上到达不了响应端,响应端也无从回应发起端;
c)则发起端发送保活消息时设置的定时器会超时;
d)多次(一般设定10次)周期发送保活消息(即箭头g的消息)以及等待回应的定时器超时后,发起端判定传输路径异常,则发起端通知GTPU协议上层释放业务,方框h所示。
现有的处理流程至少需要10分钟以上的时间才能够判定路径异常。
步骤3:
a)发起端和响应端之间一般存在多级传输设备和传输链路,如果中间链路断链,则靠断链位置最近的传输设备应该能马上检测到并体现在其路由信息里面。
b)在正常频率发送路径保活消息的时候,发起端还会发送非保活消息的GTPU报文,也就是正常的业务报文,例如箭头i,这个报文到达断链位置附近的中间设备,中间设备会因为找不到响应端的路由信息而将这个报文丢弃,同时向报文的源地址发送ICMP报文,例如箭头j。通过ICMP协议中的目的不可达类型的报文触发GTPU进入特定路径保活流程是本发明实施的一种典型方式,但是不应局限于这种方式,例如IP协议栈路由协议的某些流程也可以达到同样效果。当底层用ppp链路的时候,PPP协议会通过PPP协议的控制流程检测链路是否正常;在动态路由过程中,通过路由学习,底层也可以检测到链路异常。
c)发起端收到这个ICMP报文,马上启动加快频率的路径保活处理流程;
i.发起端向响应端加快频率发送路径保活消息,图中的箭头k、箭头l,箭头m,同时启动定时器和计数,定时器时长与正常保活流程的定时器设定相同。
ii.如果在定时器超时时限内收到路径保活响应,则认为链路正常,ICMP误报,结束特殊保活流程。
iii.如果超时未收到响应,则判断计数是否大于设定的门限(10次),如果未超出门限,则转流程i。
iv.如果计数大于设定门限,则认为路径异常,结束加快频率的保活流程。
d)参见方框n,如果通过加快频率的保活流程判定链路异常,则发起端通知GTPU协议上层释放业务。
按照上述实施方式,本发明的处理流程只需要100秒左右,就可以够判定路径异常。因此本发明相对于现有技术,加快了链路异常的发现过程,减少了系统资源的浪费,提升了业务质量。