现有分组域通信网络中，网络节点间需要建立用于转发业务数据包的转发 通道。该转发通道通过隧道管理流程来实现，网元间通过发起隧道管理请求来 新建或者更新转发通道。但是，可能由于某种原因造成隧道管理请求失败，例 如：请求消息本身出现错误，相应网络节点的资源耗尽等。现有技术中一般使 用原因值(Cause)来提示隧道管理请求的处理结果，表明对该隧道管理请求的 处理是成功还是失败，并在隧道管理请求失败时表明失败的原因。
如图1所示，在EPS(Evolved Packet System，演进分组系统)网络中， 当移动管理网元为移动性管理实体(Mobility Management Entity，MME)时， MME和报文数据网络网关(Packet Data Network Gateway，PDN-GW，P-GW)之 间的信令传送需要跨过服务网关(Serving Gateway，S-GW)。当移动终端发起 附着EPS网络、路由区域更新、跟踪区域更新、切换或新建外部数据网络连接 等包含隧道管理请求的移动性管理或会话管理信令流程时，MME发出隧道管理请 求，由S-GW和PDN-GW共同完成隧道管理请求的处理，无论隧道管理请求处理 是成功还是失败，S-GW都会向MME返回响应消息，并在响应消息中携带原因值， 以便向MME提示处理结果。
同理，当PDN-GW发起承载更新、专有承载建立等隧道管理请求时，由S-GW 和MME共同完成隧道管理请求的处理，无论隧道管理请求处理是成功还是失败， S-GW都会向PDN-GW返回响应消息，并在响应消息中携带原因值，以便向PDN-GW 提示处理结果。
如果移动管理网元为GPRS服务支撑节点(SGSN，Serving GPRS Support Node)，那么SGSN也可以向S-GW发起隧道管理请求，也可以与S-GW共同处理 PDN-GW发起隧道管理请求，其处理过程和上述处理MME发起的隧道管理请求和 PDN-GW发起的隧道管理请求的过程类似。
在上述对隧道管理的过程中，发明人发现现有技术中至少存在如下问题：
在出现隧道管理请求的处理失败后，发起隧道管理请求的节点能够接收到 响应消息，但无法根据响应消息判断出是哪个节点错误造成的隧道管理请求失 败，以至于发起隧道管理请求的节点不便于根据不同节点造成的隧道管理请求 失败进行针对性的处理。

本发明的实施例提供一种隧道管理方法、装置及通信系统，使得发起隧道 管理请求的节点能够准确判断出造成隧道管理请求失败的节点，以便进行相应 的处理。
为达到上述目的，本发明的实施例采用如下技术方案：
一种隧道管理方法，包括：
接收发起节点的隧道管理请求；
向发起节点发送响应消息，当所述隧道管理请求失败时，所述响应消息中 携带造成隧道管理请求失败的节点的节点信息。
一种隧道管理方法，包括：
向隧道管理节点发送隧道管理请求；
接收隧道管理节点返回的响应消息，当所述隧道管理请求失败时，所述响 应消息中携带有造成隧道管理请求失败的节点的节点信息；
根据所述节点信息查找出造成隧道管理请求失败的节点。
一种隧道管理装置，包括：
接收单元，用于接收发起节点的隧道管理请求；
发送单元，用于向发起节点发送响应消息，当所述隧道管理请求失败时， 所述响应消息中携带造成隧道管理请求失败的节点的节点信息。
一种隧道管理装置，包括：
发送单元，用于向隧道管理节点发送隧道管理请求；
接收单元，用于接收隧道管理节点返回的携带有节点信息的响应消息；
查找单元，用于根据所述节点信息查找出造成隧道管理请求失败的节点。
一种通信系统，包括：
发起节点，用于发送隧道管理请求；
隧道管理节点，用于接收发起节点发送的隧道管理请求，并向发起节点返 回携带有节点信息的响应消息；
所述发起节点还用于根据所述节点信息查找出造成隧道管理请求失败的节 点。
本发明实施例提供的隧道管理方法、装置及通信系统，由于发起节点接收 到的响应消息中包含了节点信息，并且发起节点可以通过该节点信息查找出造 成隧道管理请求失败的节点，即使隧道管理节点还需要将隧道管理请求发送到 远端节点继续处理，发起节点也可以通过节点信息分辨出是隧道管理节点导致 的隧道管理请求失败，还是远端节点导致的隧道管理请求失败，使得发起节点 处理隧道管理请求失败能够更加方便、高效、快捷。解决了传统通信系统中发 起节点无法判断具体是哪个节点导致的错误，而不能采取有效的处理方法的问 题。
附图说明
图1为现有技术中EPS网络的架构图；
图2为本发明实施例1中隧道管理方法的流程图；
图3为本发明实施例1中隧道管理方法的流程图；
图4为本发明实施例1中隧道管理装置的框图；
图5为本发明实施例1中隧道管理装置的框图；
图6为本发明实施例1中通信系统的架构图；
图7为本发明实施例2中用户附着的流程图；
图8为本发明实施例2中用户附着失败的隧道管理流程图；
图9为本发明实施例3中跟踪区域更新的流程图；
图10为本发明实施例3中路由区域更新的流程图；
图11为本发明实施例4中无线接入网络的切换的流程图；
图12为本发明实施例5中PDN连接建立流程图；
图13为本发明实施例6中P-GW发起的承载更新流程图；
图14为本发明实施例7中隧道管理装置的框图；
图15为本发明实施例7中隧道管理装置的框图；
图16为本发明实施例8中通信系统的架构图。

下面结合附图对本发明实施例隧道管理方法、装置及系统进行详细描述。
实施例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 Response)，通过原因值表示承载更新请求处理成功 还是失败，并在目标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主要是将隧道管理请 求失败原因值和所接收到节点信息透传到发起节点。
本实施例主要用于通信网络中，针对用户面转发通道管理时可能出现的各 种失败原因，对发起节点进行提示，以便发起节点进行相应的处理。
由于发起节点接收到的响应消息中包含了节点信息，并且发起节点可以通 过该节点信息查找出造成隧道管理请求失败的节点，即使隧道管理节点还需要 将隧道管理请求发送到远端节点继续处理，发起节点也可以通过节点信息分辨 出是隧道管理节点导致的隧道管理请求失败，还是远端节点导致的隧道管理请 求失败，使得发起节点处理隧道管理请求失败能够更加方便、高效、快捷。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发 明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但 很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质 上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算 机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包 括若干指令用以使得一台设备(可以是服务器，或者网络设备等)执行本发明 各个实施例所述的方法。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于 此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到 的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围 应所述以权利要求的保护范围为准。