简介
本文档介绍当服务GPRS支持节点(SGSN)不响应从GGSN发送的GPRS隧道协议(GTP)回应请求时网关一般分组无线业务(GPRS)支持节点(GGSN)的行为。
背景信息
在GGSN不响应GTP回应请求的时间段内，您可能会在GGSN中遇到高数据包数据协议(PDP)激活失败。以下是在此场景中可能出现的一些问题：
- 来自SGSN的创建PDP或更新PDP请求是否到达GGSN?
- 当GGSN到SGSN的GTP回应请求失败时，如果从GGSN发送的更新PDP环境未收到响应，GGSN应该如何运行？
- 如果PDP未收到GTP回应响应或从SGSN到达的非回应请求消息的响应，GGSN如何使其失败？
- GTP回声/非回声响应的缺失如何直接影响PDP激活失败？
GGSN行为
如果消息未到达GGSN，则SGSN会触发路径故障警报并以静默方式丢弃它们。此外，如果GGSN发起的回应请求没有收到回应响应，则表明对等体已关闭，因此GGSN在本地清除与该对等体相关的呼叫。
在show support details命令输出或show gtpc statistics verbose命令输出中，您可以查看GGSN Req Timeout计数器：
#show gtpc statistics verbose
SGSN Restart: Timeout:
Create PDP Req: 5 GTPC Echo Timeout: 149160
Update PDP Req: 0 GTPU Echo Timeout: 0
Echo Response: 312 GGSN Req Timeout: 24182
Path Management Messages:
Echo Request RX: 34006780 Echo Response TX: 34006780
Echo Request TX: 29603851 Echo Response RX: 29537123
如果检查从GGSN传输到SGSN的回应请求消息，则GGSN似乎未收到回应响应。您必须确保消息不会因网络上的路由问题而丢弃或SGSN不可用。
最常见的问题是控制路径故障，这会导致大量漫游SGSN无法访问。
如果GGSN中有任何GTP控制消息(如更新PDP环境请求)在所有尝试都用尽后未收到响应，则GGSN认为对等体不可达，并且仅断开该特定会话将原因报告为路径故障。GGSN上的PDP环境被删除，但SGSN不会通知。此计数通过以下统计信息标识：
SGSN Restart: Timeout:
Create PDP Req: 5 GTPC Echo Timeout: 149160
Update PDP Req: 0 GTPU Echo Timeout: 0
Echo Response: 312 GGSN Req Timeout: 24182
Update PDP Context Denied:
No Resources: 500 No Memory: 0
System Failure: 0 Non-existent: 55460
GGSN现在会断开PDP环境会话，并且从不通知SGSN或用户设备(UE)。 SGSN或UE可能触发更新PDP环境请求，而GGSN可能使用原因代码192(不存在)拒绝该请求。
以下是TS 29.060中的部分:
- 如果GPRS支持节点(GSN)收到与发送节点认为存在但接收节点无法识别的PDP环境相关的GPRS隧道协议控制平面(GTP-C)消息，请求与该PDP环境相关的动作，则接收节点应发送回该消息源，并给出相应的原因值（“不存在”或“找不到环境”）)。 响应消息中使用的隧道终端标识符应设置为所有零。
- 如果SGSN收到更新PDP环境响应，其原因值为“不存在”， 它 应删除PDP环境。
原因代码192错误
原因代码192(或不存在)是GSN在Gn接口上发送的错误。它填充在“GTP消息的原因”信息元素中。
以下是可能出现Cause Code 192错误的GTP消息：
- Update_PDP_Context_Response
- Delete_PDP_Context_Response
注意：包含此错误的消息中使用的隧道结束标识符(TEID)将为零。有关详细信息，请参阅TS 29.060。
当此错误由GSN发送，并且它没有与另一个GSN发送的上下文对应的上下文时，该错误会出现在上述消息中。收到此错误时，GSN会删除PDP环境。
示例情景
本节介绍发生原因代码192错误的四种情况。
- 场景1 - GSN之间发生GTP-C路径故障。
- 场景2 - GSN之间发生回应请求/响应故障。
- 场景3 — 存在GTP版本1(GTPv1)到GTP版本0(GTPv0)的切换问题，导致错误。以下是此场景的呼叫流示例：
- 建立了使用GTPv1创建PDP环境请求。
- GTPv1到GTPv0的切换发生。
- GGSN上的呼叫现在位于GTPv0。
- GGSN接收具有非零报头TEID的更新PDP上下文请求，并由于错误（不存在）而拒绝该请求。
注意：SGSN应该忘记TEID，因为呼叫已移至GTPv0（GTPv0仅存在流标签，而不存在TEID）。 这表示即使切换到GTPv0后，SGSN仍保留到GTPv1呼叫。
- 场景4 — 不同步的TEID效应被乘以。示例如下：
- UE1建立PDP环境；SGSN允许Control-TEID-1(C-TEID-1)作为其针对sgsn-UE1-ctxt上下文上的GGSN的控制TEID。GGSN上指向SGSN的所有消息的C-TEID都有C-TEID-1。
- SGSN上的信令消息（非回声）超时，SGSN在本地清理该sgsn-UE1-ctxt上下文。它还通知无线网络控制器(RNC)进行清理。它不通知GGSN，因为它将GGSN视为关闭。现在，SGSN上没有UE1的PDP环境，而GGSN上存在具有C-TEID-1的相同UE1的PDP环境。C-TEID-1返回空闲列表的尾部。
- 然后，UE2希望建立到同一APN的PDP环境，并通过同一SGSN和GGSN。在SGSN上，分配TEID，并将sgsn-UE2-ctxt上下文发送到GGSN。如果空闲TEID的数量较少，则将最近释放的TEID重新分配到新的PDP环境。在本例中，C-TEID-1重新分配给UE2。
- 在GGSN上，有两个情景，C-TEID-1作为Gn C-TEID。GGSN不检查是否已存在TEID。然后，GGSN向SGSN发起UE1的删除PDP环境(DPC)。
- 在SGSN上，找到C-TEID-1及其上下文，即sgsn-UE2-Ctxt。尝试删除该上下文并响应GGSN。
- 如果有GGSN发起的请求（更新/删除PDP）用于其他环境，则SGSN会以未找到的情景作出响应。
- GGSN丢弃UE2的DPC响应，因为它从未发送UE2的DPC请求。
- 现在，GGSN上存在与SGSN上的任何情景不对应的第二个情景。
- 如果将同一C-TEID-1分配给另一个UE，则问题会重复并加剧问题。
以下是TS 29.060中的部分:
回应响应
消息应作为对收到的回应请求的响应发送。
从对等GSN接收回声响应的GSN应将收到的重新启动计数器值与该对等GSN存储的先前重新启动计数器值进行比较。如果未存储以前的值，则应为对等GSN存储在回声响应中收到的重新启动计数器值。
先前为对等GSN存储的重新启动计数器的值可能与该对等GSN的回应响应中收到的重新启动计数器值不同。在这种情况下，发送回声响应的GSN应视为由收到回声响应的GSN重新启动。接收实体应存储收到的新重启计数器值，以替换之前为发送GSN存储的值。
如果发送GSN是GGSN，而接收GSN是SGSN，则SGSN应将使用GGSN的所有PDP环境视为非活动环境。有关SGSN的进一步操作，请参阅第3代合作伙伴计划(3GPP)技术规格(TS)23.007 [3]。
如果发送GSN是SGSN，而接收GSN是GGSN，则GGSN应将使用SGSN的所有PDP环境视为非活动环境。有关GGSN的进一步操作，请参阅3GPP TS 23.007 [3]。
以下是3GPP TS 23.007 V8.0节:
恢复SGSN中的数据
重新启动SGSN
在SGSN重新启动后，SGSN将删除所有移动管理(MM)、PDP、多媒体广播组播服务(MBMS)UE和受重启影响的MBMS承载环境。除此子子句中指定外，SGSN数据存储是易失性的。SGSN在易失性存储器中为与SGSN接触的每个GGSN维护GGSN重启计数器，并在与与SGSN接触的每个GGSN相关的非易失性存储器SGSN重启计数器中维护GGSN重启计数器。SGSN重启计数器应递增，所有GGSN重启计数器在SGSN重启后立即清除。 重新启动计数器可能对所有GGSN都是通用的，或者每个GGSN可能有单独的计数器。
GGSN对GGSN与之联系的SGSN执行轮询功能（回应请求和回应响应）。SGSN重启计数器应包括在回声响应中。如果GGSN中收到的值与该SGSN存储的值不同，GGSN将认为SGSN已重新启动（请参阅3GPP TS 29.060）。 在SGSN中，GGSN重启计数器应更新为在SGSN重启后从每个GGSN收到的第一个回声消息中收到的值。
当GGSN在其激活PDP环境的SGSN中检测到重新启动时，它应删除所有这些PDP环境。 此外，在从SGSN重新启动的回声响应中收到的SGSN重新启动计数器的新值应在GGSN中更新。
反馈