具体实施方式
下面结合附图对本发明实施例隧道管理方法、装置及***进行详细描述。
实施例1:
本实施例是一种隧道管理方法,如图2所示,该方法具体包括以下步骤:
201、在通信***中,若需要进行用户面转发通道管理,首先由发起节点向隧道管理节点发送一个隧道管理请求。
202、隧道管理节点接收到发起节点的隧道管理请求后进行相关处理,并向发起节点返回一个携带有隧道管理请求成功或失败原因值的响应消息,在该响应消息中同时携带有造成隧道管理请求失败的节点的节点信息。
本实施例还提供一种隧道管理方法,如图3所示,该方法具体包括如下步骤:
301、在通信***中,若需要进行用户面转发通道管理,首先由发起节点向隧道管理节点发送一个隧道管理请求。
302、隧道管理节点接收到发起节点的隧道管理请求后进行相关处理,并向发起节点返回一个携带有处理成功或失败原因值的响应消息,在处理失败后返回的响应消息中携带有节点信息。
303、发起节点根据所述节点信息查找出造成隧道管理请求失败的节点。在实际的应用中,由于错误的原因很多,所以找到造成隧道管理请求失败的节点后,仍需要进行不同的处理,本发明以后的实施例中主要列举了其中4种错误原因的处理方式。
对应于图2中的隧道管理方法,本实施例还提供一种隧道管理装置,如图4所示,该装置包括:接收单元41和发送单元42。
其中,接收单元41用于接收发起节点的隧道管理请求;在对隧道管理请求的处理失败的情况下,发送单元42用于向发起节点发送携带有节点信息的响应消息,所述节点信息为造成隧道管理请求失败的节点的节点信息,以便发起节点能够根据该节点信息找到造成隧道管理请求失败的节点。
对应于图3中的隧道管理方法,本实施例还提供一种隧道管理装置,如图5所示,该装置包括:发送单元51、接收单元52和查找单元53。
其中,发送单元51用于向隧道管理节点发送隧道管理请求,隧道管理节点按照要求对隧道管理请求进行相应处理后,向该装置返回一个携带有节点信息的响应消息;接收单元52用于接收隧道管理节点返回的携带有节点信息的响应消息;查找单元53用于根据所述节点信息查找出造成隧道管理请求失败的节点。
本实施例还提供一种通信***,如图6所示,该通信***包括:发起节点61和隧道管理节点62。在通信***中,在进行用户面转发通道管理时,一般来说,发起节点61用于发送隧道管理请求;隧道管理节点62用于接收发起节点61发送的隧道管理请求,并向发起节点61返回携带有节点信息的响应消息;所述发起节点61还用于根据所述节点信息查找出造成隧道管理请求失败的节点,找到造成隧道管理请求失败的节点后,就能够进行针对性的处理,如:选择有效的错误排查方向、选择新的节点等。所述的错误排查为发起节点在收到响应消息中的失败原因值为“信元缺失”和“信元解析错误”之类的信元错误时,首先检查是否是本身设备实现造成的错误,在自身设备正确的情况下,再由响应消息中指示的出错节点检查其设备实现。以便节点间可以迅速定位出错原因,保证后续流程的正确进行。
本实施例通过节点信息分辨出是隧道管理节点导致的隧道管理请求失败,还是远端节点导致的隧道管理请求失败,使得发起节点处理隧道管理请求失败能够更加方便、高效、快捷。
实施例2:
本实施例的应用环境是EPS网络,如图7所示,EPS网络的终端在进行用户附着过程中网络侧的处理,特别是网络侧在隧道管理请求失败的情况下,其方法流程包括如下步骤:
701、用户设备(UE)先向MME发起附着请求(Attach Request)。
702、MME向UE发起身份请求(Identity Request)。
703、UE根据MME的身份请求(Identity Request)向MME发送身份响应消息(Identity Response)。
704、MME和HSS(归属用户服务器)共同完成对UE的鉴权(Authentication)。
705、MME和EIR(Equipment Identity Register,设备标识寄存器)共同完成对UE的设备认证过程(IMEI Check)。
706、MME向HSS发起位置更新请求(Update Location)。
707、HSS向MME发送***用户签约数据(Insert subscriber data)。
708、MME向HSS返回***用户签约数据确认(Insert subscriber data Ack)。
709、HSS在MME确认了用户签约数据后向MME返回位置更新确认信息。
710、MME得到位置更新信息后,向S-GW发送缺省承载建立请求(Create Default Bearer Request),以便能够完成承载建立。
711、S-GW作为隧道管理节点需要处理MME发送过来的缺省承载建立请求,如果S-GW能够成功地处理该缺省承载建立请求,则执行步骤712、713、714、716及其以后步骤;否则执行步骤715及其以后步骤。
712、S-GW向P-GW发送缺省承载建立请求(Create Default Bearer Request)。
713、P-GW处理S-GW发送过来的缺省承载建立请求,并且P-GW向S-GW发送响应消息(Create Default Bearer Response),并且该响应消息通过原因值表示对该缺省承载建立请求的处理是成功还是失败,并在不能成功处理该缺省承载建立请求的情况下表明本次处理失败的原因。
714、S-GW收到P-GW的响应消息后,S-GW向MME返回缺省承载建立响应(Create Default Bearer Response),通过原因值表示缺省承载建立请求的处理是成功还是失败,并在接收到P-GW返回的表示处理失败的响应消息时,在向MME返回的响应消息中携带P-GW的节点信息,标识造成缺省承载建立请求失败的节点。其中,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
715、在S-GW不能成功地处理该缺省承载建立请求时,S-GW向MME返回缺省承载建立响应(Create Default Bearer Response),通过原因值表示缺省承载建立请求失败的原因,并在响应消息中携带S-GW的节点信息,标识造成缺省承载建立请求失败的节点。其中,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
为了使得MME能够获得更多的关于本次缺省承载建立请求失败的信息,本实施例中还可以在本步骤返回的响应消息中携带定位附加信息,以标识造成缺省承载建立请求失败的原因。
716、MME收到缺省承载建立响应(Create Default Bearer Response)消息后,根据响应消息中的节点信息和定位附加信息进行相应处理。如图8所示,MME的具体处理过程包括如下步骤:
801、解析收到的缺省承载建立响应消息(Create Default Bearer Response),得到其中的节点信息和定位附加信息。
802、根据解析得出的节点信息查找出造成缺省承载建立请求失败的节点。
803、通过原因值分析出造成缺省承载建立请求失败的原因,若造成请求失败的原因为资源不足或者设备故障,则执行步骤804,其中资源不足包括带宽不够、内存不足等;如果造成请求失败的原因为信元缺失或者信元解析错误,例如:缺省承载建立请求中的信元缺失,或者解析不出正确的信元,则执行步骤807。
804、判断造成缺省承载建立请求失败的节点为S-GW还是P-GW,如果为S-GW,则执行步骤805;如果为P-GW,则执行步骤806。
805、MME重新选择一个新的S-GW,保持P-GW不变,继续进行缺省承载建立请求。
806、MME重新选择一个新的P-GW,保持S-GW不变,继续进行缺省承载建立请求。
807、通过定位附加信息定位缺失的具体信元或者解析错误的具体信元。工作人员可以先检查MME是否发生错误,例如:发出的请求消息中信元是否正确,如果不正确,则对MME设备进行错误排查,以便下次附着流程中能够发送正确的缺省承载建立请求;如果正确,检查造成缺省承载建立请求失败的节点是否发生错误。
在具体实施时,由于造成缺省承载建立请求失败的原因还有很多种,则MME需要根据不同的原因进行不同的处理,这里就不一一列举了。
上述实施例中S-GW和P-GW之间采用的是GTP协议,在实际应用时,S-GW和P-GW之间还可以采用PMIP协议,则上述步骤712至步骤713修改为如下步骤:
712′、S-GW向P-GW发送代理绑定更新请求(Proxy Binding Update)。
713′、P-GW处理S-GW发送过来的代理绑定更新请求,并且P-GW在不能成功处理该代理绑定更新请求的情况下向S-GW发送响应消息,即:代理绑定响应(Proxy Binding ACK),并且该响应消息通过原因值表示本次处理失败。
通过S-GW返回的响应消息中的节点信息,本实施例中的MME可以得知造成缺省承载建立失败的节点,在本次缺省承载建立失败时,能够及时对造成缺省承载建立失败的节点进行调整,以便在后续的流程中进行正确处理。
实施例3:
本实施例的应用环境是跟踪区域更新的过程,如图9所示,网络侧在隧道管理请求失败的情况下,其方法流程包括如下步骤:
901、用户终端向基站(eNodeB)发起跟踪区域更新请求(Tracking Area Update Request),eNodeB将该跟踪区域更新请求发送给新侧的MME。
902、新侧的MME接收到跟踪区域更新请求后,向老侧的MME获取上下文。
903、新侧的MME根据eNodeB发来的用户位置信息判断是否重新选择S-GW,如果不重新选择S-GW,则新侧的MME向老侧的S-GW发送承载更新请求(Update Bearer Request)。
904、老侧的S-GW作为隧道管理节点需要处理新侧的MME发送过来的承载更新请求,如果老侧的S-GW能够成功地处理该承载更新请求,则执行步骤905、906、907、909及其以后步骤;否则执行步骤908及其以后步骤。
905、老侧的S-GW向P-GW发送承载更新请求(Update Bearer Request)。
906、P-GW处理老侧的S-GW发送过来的承载更新请求,并且P-GW向老侧的S-GW发送响应消息(Update Bearer Response),该响应消息通过原因值表明对该承载更新请求的处理是成功还是失败,并在不能成功处理该承载更新请求的情况下表明本次处理失败的原因。
907、老侧S-GW接收到P-GW的承载更新响应消息后,向新侧的MME返回承载更新响应消息(Update Bearer Response),通过原因值表示承载更新请求的处理是成功还是失败,并在接收到的P-GW返回的承载更新响应消息中的原因值表明处理失败时,在向新侧的MME返回的响应消息中携带P-GW的节点信息,标识造成承载更新请求失败的节点。其中,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
为了使得新侧的MME能够获得更多的关于本次承载更新请求失败的信息,本实施例中还可以在本步骤返回的响应消息中携带定位附加信息,以标识造成承载更新请求失败的原因。
908、在老侧的S-GW不能成功地处理该承载更新请求时,向新侧的MME返回承载更新响应消息(Update Bearer Response),通过原因值表示承载更新请求失败的原因,并在响应消息中携带老侧的S-GW的节点信息,标识造成承载更新请求失败的节点。
909、新侧的MME收到承载更新响应(Update Bearer Response)消息后,根据响应消息中的节点信息进行相应处理。新侧的MME在发生信元方面的错误时先排查本节点的错误,再由造成发生错误的节点进行排查。
上述实施例中在进行跟踪区域更新时只是更新了MME,有时也会更新S-GW,当需要更新S-GW时,其处理过程和图9大致相同,只把图9中由老侧的S-GW完成的功能全都改成由新侧的S-GW完成,如图9中的虚线所示部分。
新侧的MME获取上下文的步骤和901及902相同,新侧的MME获取到上下文后,判断是否重新选择S-GW,如果重新选择了S-GW,则向新侧的S-GW发送承载建立请求(Create Bearer Request),如果S-GW能正确处理该承载更新请求,则向P-GW发送承载更新请求,否则向新侧MME返回承载建立响应消息(Create Bearer Response),并携带该新侧S-GW的节点信息表示由新侧的S-GW造成承载更新失败。P-GW对承载更新请求处理后,向新侧的S-GW返回承载更新响应消息(Update Bearer Response),如果P-GW对该承载更新请求的处理失败,则向新侧的S-GW返回的承载更新响应消息中携带失败原因值,新侧的S-GW同样要向新侧MME返回承载建立响应消息(Create Bearer Response),在收到P-GW的响应消息表明处理失败时,向新侧的MME返回的响应消息中携带P-GW的节点信息表示由P-GW造成承载更新失败。
在实际应用中,很多场合都可以采用上述实施例2和实施例3的类似流程,以实现隧道管理请求失败的提示,例如:路由区域更新、PDN(Packet Data Networks,分组数据网络)连接建立等。
在路由区域更新的应用场合中,用户终端请求的路由更新,可能存在如下两种情况:
第一、S-GW发生了改变,则由新侧的SGSN(Serving GPRS Support Node,服务GPRS支持节点)作为承载建立请求的发起节点,而由新侧的S-GW作为承载建立请求的隧道管理节点,同时由P-GW作为远端节点,其流程处理如图10实线所示。
用户终端向新侧的SGSN发送路由区域更新请求(Routing Area Update Request),新侧的SGSN从老侧的SGSN中获取上下文,新侧的SGSN获取到上下文后,向新侧的S-GW发送承载建立请求(Create Bearer Request),如果新侧S-GW能正确处理该承载建立请求,则向P-GW发送承载更新请求(Update Bearer Request),否则向新侧的SGSN返回承载建立响应消息(Create Bearer Response),并携带该新侧S-GW的节点信息表示由新侧的S-GW造成承载建立失败。P-GW对承载更新请求处理后,向新侧S-GW返回承载更新响应消息(Update Bearer Response),通过原因值表明处理成功或是失败,如果P-GW对该承载更新请求的处理失败,P-GW向新侧的S-GW返回表示失败的承载更新响应消息(Update Bearer Response),新侧的S-GW同样要向新侧SGSN返回承载建立响应消息(Create Bearer Response),并在P-GW返回的消息表明处理失败时,向新侧SGSN返回的消息中携带P-GW的节点信息表示由P-GW造成承载建立失败。
第二、S-GW没有发生改变,则由新侧的SGSN作为路由更新请求的发起节点,且由老侧的S-GW作为路由更新的隧道管理节点,同时由P-GW作为远端节点,其流程处理如图10虚线所示。
用户终端向新侧的SGSN发送路由区域更新请求(Routing Area Update Request),新侧的SGSN从老侧的SGSN中获取上下文,新侧的SGSN获取到上下文后,向老侧的S-GW发送承载更新请求(Update Bearer Request),如果老侧的S-GW能正确处理该承载建立请求,则向P-GW发送承载更新请求(Update Bearer Request),否则向新侧的SGSN返回承载更新响应消息(Update Bearer Response),并携带该老侧S-GW的节点信息表示由老侧的S-GW造成承载建立失败。P-GW对该承载更新请求处理后,向老侧的S-GW返回承载更新响应消息(Update Bearer Response),该消息中通过原因值表明处理成功或者失败,如果P-GW对承载更新请求的处理失败,向老侧的S-GW返回表示失败的承载更新响应消息,老侧的S-GW同样要向新侧SGSN返回承载更新响应消息(Update Bearer Response),并在P-GW返回的消息表明处理失败时,向新侧SGSN返回的消息中携带P-GW的节点信息表示由P-GW造成承载建立失败。
由上述本实施例可知,采用该方法后,可以在跟踪区域更新和路由区域更新的流程中,指示出造成跟踪区域更新失败或路由区域更新失败的节点,以便能够及时对造成跟踪区域更新或路由区域更新失败的节点进行调整,在后续的流程中进行正确处理。
实施例4:
本实施例的应用场合是E-UTRAN(演进UMTS陆地无线接入网)到UTRAN(UMTS陆地无线接入网)无线接入网络的切换,如图11所示,网络侧在隧道管理请求失败的情况下,其方法流程包括如下步骤:
1101、用户终端和需要切换到的无线接入网的目标SGSN建立下行业务报文的转发隧道,并将SRNS(Serving RNS,服务无线网络子***)上下文传递到目标SGSN。
1102、目标SGSN接收到SRNS上下文后,向目标S-GW发送承载更新请求(Update Bearer Request)。
1103、目标S-GW作为隧道管理节点需要处理目标SGSN发送过来的承载更新请求,如果目标S-GW能够成功地处理该承载更新请求,则执行步骤1104、1105、1107及其以后步骤;否则执行步骤1106、1108。
1104、目标S-GW向P-GW发送承载更新请求(Update Bearer Request)。
1105、P-GW处理目标S-GW发送过来的承载更新请求,向目标S-GW返回承载更新响应消息(Update Bearer Response),该消息通过原因值表明处理成功或是失败,P-GW在不能成功处理该承载更新请求的情况下向目标S-GW发送携带失败原因值的响应消息(Update Bearer Response),并在响应消息中携带P-GW的节点信息。
1106、在目标S-GW不能成功地处理该承载更新请求时,目标S-GW向目标SGSN返回承载更新响应消息(Update Bearer Response),通过原因值表示承载更新请求失败的原因,并在响应消息中携带目标S-GW的节点信息,标识造成承载更新请求失败的节点。
1107、目标S-GW收到P-GW返回的响应消息后,向目标SGSN返回承载更新响应消息(Update Bearer Re sponse),通过原因值表示承载更新请求处理成功还是失败,并在目标S-GW接收到的P-GW返回的响应消息中的原因值表示处理失败时,目标S-GW将从P-GW返回的响应消息中的节点信息透传到给目标SGSN,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
为了使得目标SGSN能够获得更多的关于本次承载更新请求失败的信息,本实施例中还可以在本步骤返回的响应消息中携带定位附加信息,以标识造成承载更新请求失败的具体原因。
1108、目标SGSN收到承载更新响应消息后,根据响应消息中的节点信息和定位附加信息进行相应处理。目标SGSN在发生信元方面的错误时先排查本节点的错误,在确定目标SGSN正确时,再由造成发生错误的节点进行排查,以便下次流程可以正确进行。在发生资源不足方面的错误时,如果出错节点指示显示目标S-GW出错,目标SGSN可以重新选择一个S-GW发起隧道管理流程。
由上述本实施例可知,采用该方法后,在E-UTRAN到UTRAN无线接入网络的切换时,指示出造成承载更新失败的节点是目标S-GW还是P-GW,以便目标SGSN能够及时对造成承载更新失败的节点进行调整,以便在后续的流程中进行正确处理。
实施例5:
本实施例的应用场合是PDN连接建立流程,如图12所示,在流程处理失败的时候,其方法包括如下步骤:
1201、用户终端向MME发送PDN连接建立请求(PDN Connectivity Request)。
1202、MME收到PDN连接建立请求后,向S-GW发送缺省承载建立请求(Create Default Bearer Request),以便能够建立承载。
1203、S-GW作为隧道管理节点需要处理缺省承载建立请求,如果S-GW能够成功地处理该缺省承载建立请求,则执行步骤1204至1210及1212;否则执行步骤1211及1212。
1204、S-GW向P-GW缺省承载建立请求(Create Default Bearer Request)。
1205、P-GW作为隧道管理节点需要处理缺省承载建立请求,如果P-GW能够成功地处理该缺省承载建立请求,则执行步骤1206至1208、1210及1212;否则执行步骤1209、1210及1212。
1206、P-GW与PCRF(Policy&Charging Rule Function,策略计费功能实体)之间建立IP-CAN session(IP连通性接入网络会话)。
1207、PCRF向P-GW返回响应消息,并且该响应消息通过原因值表示本次IP-CAN session建立成功还是失败。
1208、P-GW接收到PCRF的响应消息后,P-GW向S-GW返回缺省承载建立响应(Create Default Bearer Response),该响应消息通过原因值表示本次缺省承载建立请求处理成功还是失败,并在接收到的PCRF返回的响应消息中的原因值表明处理失败时,在返回给S-GW的响应消息中携带PCRF的节点信息,标识造成缺省承载建立请求失败的节点。
1209、P-GW向S-GW返回缺省承载建立响应(Create Default Bearer Response),并且该响应消息通过原因值表示本次缺省承载建立请求失败,并在响应消息中携带P-GW的节点信息,标识造成缺省承载建立请求失败的节点。
其中,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
为了使得S-GW能够获得更多的关于本次缺省承载建立请求失败的信息,本实施例中还可以在本1208和1209步骤返回的响应消息中携带定位附加信息,以标识造成缺省承载建立请求失败的原因。本实施例中的定位附加信息既可以通过业务请求隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1210、S-GW向MME返回缺省承载建立响应(Create Default Bearer Response),并且该响应消息通过原因值表示本次缺省承载建立请求失败,并在响应消息中携带节点信息,标识造成缺省承载建立请求失败的节点,所述节点信息为该从P-GW接收到的响应消息中携带的节点信息。
其中,节点信息可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。为了使得MME能够获得更多的关于本次缺省承载建立请求失败的信息,本实施例中还可以在本步骤返回的响应消息中携带定位附加信息,以标识造成缺省承载建立请求失败的具体原因,这里的定位附加信息可以是S-GW收到的响应消息中携带的定位附加信息。同样,本实施例中的定位附加信息既可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1211、S-GW向MME返回缺省承载建立响应(Create Default Bearer Response),并且该响应消息通过原因值表示本次缺省承载建立请求失败,并在响应消息中携带S-GW的节点信息,标识造成缺省承载建立请求失败的节点。
1212、MME收到缺省承载建立响应消息(Create Default Bearer Request)后,根据响应消息中的节点信息和定位附加信息进行相应处理。MME在发生信元方面的错误时先排查本节点的错误,在确定本节点实现正确时,再由造成发生错误的节点进行排查,以便下次流程可以正确进行。在发生资源不足方面的错误时,如果出错节点指示显示目标P-GW出错,MME可以重新选择一个P-GW发起隧道管理流程。通过定位附加信息可以知道具体的出错原因,如具体是哪个信元丢失,哪个信元解析出错等。
由上述本实施例可知,在PDN连接建立的流程中,本实施例能够指示出造成PDN连接建立失败的节点是S-GW、P-GW还是PCRF,以便MME能够及时对造成PDN连接建立失败的节点进行调整,以便在后续的流程中进行正确处理。
实施例6:
本实施例的应用场合是P-GW发起的承载建立,如图13所示,承载建立失败的提示方法包括如下步骤:
1301、P-GW向S-GW发送专有承载建立请求(Create Dedicated Bearer Request)。
1302、S-GW作为隧道管理节点需要处理专有承载建立请求,如果S-GW能够成功地处理该专有承载建立请求,则执行步骤1303至1310及1312;否则执行步骤1311及1312。
1303、S-GW向MME发送专有承载建立请求(Create Dedicated Bearer Request)。
1304、MME收到专有承载建立请求后,处理该专有承载建立,如果MME能够成功处理该专有承载建立请求,则执行步骤1305至1308、1310及1312;否则执行步骤1309、1310及1312。
1305、MME向用户终端所属的基站发送承载建立请求(Create Bearer Request),以便建立承载。
1306、基站和用户终端之间进行RRC(Radio Resource Connection)连接配置。
1307、基站向MME返回承载建立响应消息承载建立响应(Create Bearer Response),在RRC连接配置失败、或者基站与S-GW之间建立承载失败的情况下,基站向MME返回的响应消息中携带失败原因值。
1308、MME向S-GW返回专有承载建立响应(Create Dedicated Bearer Response),在响应消息中携带专有承载建立失败的原因值和eNodeB的节点信息,以表示由eNodeB造成专有承载建立失败。节点信息可以通过承载建立失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1309、MME向S-GW返回专有承载建立响应(Create Dedicated Bearer Response),在响应消息中携带专有承载建立失败的原因值和MME的节点信息,以表示由MME造成专有承载建立失败。节点信息可以通过承载建立失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1310、S-GW向P-GW返回专有承载建立响应(Create Dedicated Bearer Response),并且该响应消息通过原因值表示本次专有承载建立请求失败,并在响应消息中携带MME返回的节点信息,标识造成专有承载建立请求失败的节点。。节点信息可以通过专有承载建立请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1311、S-GW向P-GW返回专有承载建立响应(Create Dedicated Bearer Response),并且该响应消息通过原因值表示本次专有承载建立请求失败,并在响应消息中携带S-GW的节点信息,标识造成专有承载建立请求失败的节点。
为了使得P-GW能够获得更多的关于本次专有承载建立请求失败的信息,本实施例中还可以在本步骤返回的响应消息中携带定位附加信息,以标识造成专有承载建立请求失败的原因。同样,本实施例中的定位附加信息既可以通过隧道管理请求失败原因值中的字段来表示,也可以通过响应消息中的信元来表示。
1312、P-GW收到专有承载建立响应消息后,根据响应消息中的节点信息和定位附加信息进行相应处理。P-GW在发生信元方面的错误时先排查本节点的错误,在确定本节点实现正确时,再由造成发生错误的节点进行排查,以便下次流程可以正确进行。
由上述本实施例可知,在专有承载建立的流程中,本实施例能够指示出造成专有承载建立失败的节点是S-GW、MME还是eNodeB,以便P-GW能够及时对造成专有承载建立失败的节点进行调整,以便在后续的流程中进行正确处理。
实施例7:
对应于上述实施例2至6,本实施例提供一种隧道管理装置,如图14所示,该隧道管理装置包括:接收单元141和发送单元142。
其中,接收单元141用于接收发起节点的隧道管理请求;在发起节点发起的隧道管理请求处理失败后,发送单元142用于向发起节点发送携带有节点信息的响应消息,所述节点信息为造成隧道管理请求失败的节点的节点信息。
造成上述隧道管理请求失败的节点可能是本节点,也可以能是远端的其他节点,为了在造成隧道管理请求失败的节点为本节点的情况下,该隧道管理装置能正确处理,本实施例中的发送单元142通过判断模块1421和发送模块1422实现。
其中,判断模块1421用于判断本节点是否能完成所述的隧道管理请求;发送模块1422用于在判断模块1421判断出本节点不能完成所述的隧道管理请求时,向发起节点发送响应消息,该响应消息包含隧道管理请求失败原因值和本节点信息,所述本节点信息为造成隧道管理请求失败的节点的节点信息。
造成隧道管理请求失败的节点为远端的其他节点包括如下两种情况:
第一、造成隧道管理请求失败的节点直接与本节点相连。在本节点能够正确处理隧道管理请求时,所述发送单元142还用于将所述的隧道管理请求发送到远端节点;此时,远端节点处理完隧道管理请求后,需要向本节点返回隧道管理请求响应,该响应消息通过原因值表明处理成功或是失败;本节点的接收单元141还用于接收远端节点返回的响应消息,在远端节点处理失败时,该响应消息携带有隧道管理请求失败原因值,这样所述发送单元142向发起节点发送的响应消息携带有所述隧道管理请求失败原因值和远端节点信息,即:通过该响应消息反应所述远端节点信息为造成隧道管理请求失败的节点的节点信息。
第二、造成隧道管理请求失败的节点是远端节点,但其通过另一远端节点与本节点相连。这种情况下,所述发送单元142还用于将所述的隧道管理请求发送到另一远端节点;另一远端节点向本节点返回的响应消息中携带有隧道管理请求失败原因值和节点信息,这个节点信息就是远端节点信息,故而,本实施例中的接收单元141还用于接收另一远端节点返回的响应消息,该响应消息携带有隧道管理请求失败原因值和节点信息;则所述发送单元142向发起节点发送携带有所述隧道管理请求失败原因值和所接收到节点信息的响应消息,即:本节点将接收到的隧道管理请求失败原因值和节点信息透传到发起节点。
为了能够更好地区分造成隧道管理请求失败的具体原因,本实施例中接收单元141接收到的响应消息还可以包含定位附加信息,用来标识造成隧道管理请求失败的具体原因,例如:信元缺失和信元解析错误具体发生在哪个信元上,具体哪个必选信元缺失等;同样本实施例的发送单元142向发起节点发送的响应消息也可能包含有该定位附加信息,以便发起节点能够正确找出失败原因。
在实际运用中,很多网络设备中都可以配置本实施例中的隧道管理装置,例如:S-GW、P-GW、MME、SGSN等。
对应于上述实施例2中图8描述的MME对于隧道管理方法,本实施例还提供一种隧道管理装置,如图15所示,该装置包括:发送单元151、接收单元152、查找单元153。
其中,发送单元151用于向隧道管理节点发送隧道管理请求,隧道管理节点按照要求对隧道管理请求进行相应处理后,向该装置返回隧道管理请求响应消息,在处理失败后,向该装置返回的响应消息中携带有节点信息和定位附加信息,其中的节点信息用来标识造成隧道管理请求失败的节点,定位附加信息用来标识造成隧道管理请求失败的具体原因;接收单元152用于接收隧道管理节点返回的携带有节点信息的响应消息;查找单元153用于根据所述节点信息查找出造成隧道管理请求失败的节点,并根据所述的定位附加信息查找出造成隧道管理请求失败的具体原因,以便进行错误排查。
为了保证本实施例处理装置能够正确的进行错误排查,该隧道管理装置还包括处理单元154,所述处理单元154用于在造成隧道管理请求失败的原因为资源不足或者设备故障时,选择一个新的节点替换造成隧道管理请求失败的节点;或者,在造成隧道管理请求失败的原因为信元缺失或者信元解析错误时,排查本节点的错误或者指示造成隧道管理请求失败的节点排查错误。
如果将网络设备之间的关系划分为发起节点、中间节点和远端节点,那么图14中的隧道管理装置判断本设备能否处理的功能可以中间节点和远端节点中配置;而接收远端设备的响应消息后再向发起节点发送和上述透传出错节点指示信息的功能只在中间节点处实现;对于图15中的隧道管理装置则只需要在发起节点配置,而由于具体隧道管理请求的不同,发起节点可以是MME,也可能是P-GW、SGSN等设备。
本实施例中的中间节点在向发起节点返回响应消息时,携带节点信息,以便于发起节点找出造成本次隧道管理请求失败的节点,然后进行相应的节点调整,以便于后续流程的处理。
实施例8:
本实施例还提供一种通信***,如图16所示,该通信***包括发起节点161和隧道管理节点162,在需要进行用户面转发通道管理的时候,发起节点161用于向隧道管理节点发送隧道管理请求;隧道管理节点162用于接收发起节点发送的隧道管理请求,并判断本隧道管理节点是否能完成所述的隧道管理请求,若本隧道管理节点不能完成所述的隧道管理请求,在向发起节点发送的响应消息中包含隧道管理请求失败原因值和本隧道管理节点信息,以表示本隧道管理节点为造成隧道管理请求失败的节点。所述发起节点161还用于根据隧道管理节点返回的响应消息中节点信息查找出造成隧道管理请求失败的节点,同时可以进行相关的错误排查。
采用上述模式的通信***一般是两个网络设备之间的通信,例如:MME和S-GW之间,S-GW和P-GW之间的通信。
当通信***中存在三个网络设备时,本实施例中的通信***还包括远端节点163;
当所述隧道管理节点162能够正确处理隧道管理请求时,所述隧道管理节点将所述的隧道管理请求发送到远端节点163;远端节点163由于某种原因造成隧道管理请求失败,例如:本节点错误等。所以,所述远端节点163用于向隧道管理节点返回响应消息,该响应消息携带有隧道管理请求失败原因值;这种情况下,所述隧道管理节点162还用于向发起节点发送携带有所述隧道管理请求失败原因值和远端节点信息的响应消息,即表示所述远端节点为造成隧道管理请求失败的节点。
当然如果远端节点还连接了一个连接处理设备,并且发起节点发出的隧道管理请求需要该连接处理设备进行处理,如果最终导致隧道管理请求失败的设备就是该连接处理设备,那么该通信***的处理如下:
当所述隧道管理节点162能够正确处理隧道管理请求时,所述隧道管理节点将所述的隧道管理请求发送到远端节点163;由于远端节点163能够正常处理,则需要将相应的请求发送到连接处理设备,而连接处理设备处理失败只向远端节点返回失败原因值,故而所述远端节点163向隧道管理节点162返回的响应消息携带有隧道管理请求失败原因值和节点信息,这个节点信息就是连接处理设备的节点信息。那么本实施例中隧道管理节点还用于向发起节点发送携带有所述隧道管理请求失败原因值和所接收到节点信息的响应消息,所述接收到节点信息对应节点为造成隧道管理请求失败的节点,即连接处理设备为造成隧道管理请求失败的节点,在本实施例中,隧道管理节点162主要是将隧道管理请求失败原因值和所接收到节点信息透传到发起节点。
本实施例主要用于通信网络中,针对用户面转发通道管理时可能出现的各种失败原因,对发起节点进行提示,以便发起节点进行相应的处理。
由于发起节点接收到的响应消息中包含了节点信息,并且发起节点可以通过该节点信息查找出造成隧道管理请求失败的节点,即使隧道管理节点还需要将隧道管理请求发送到远端节点继续处理,发起节点也可以通过节点信息分辨出是隧道管理节点导致的隧道管理请求失败,还是远端节点导致的隧道管理请求失败,使得发起节点处理隧道管理请求失败能够更加方便、高效、快捷。
通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在可读取的存储介质中,如计算机的软盘,硬盘或光盘等,包括若干指令用以使得一台设备(可以是服务器,或者网络设备等)执行本发明各个实施例所述的方法。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应所述以权利要求的保护范围为准。