簡介
本檔案介紹當服務GPRS支援節點(SGSN)不回應從GGSN傳送的GPRS通道通訊協定(GTP)回應要求時，閘道通用封包無線服務(GPRS)支援節點(GGSN)的行為。
背景資訊
在SGSN不響應GTP回顯請求的一段時間內，您可能會遇到GGSN中的高資料包資料協定(PDP)啟用故障。在此案例中可能會出現以下問題：
- 來自SGSN的建立PDP或更新PDP請求是否到達GGSN?
- 當GTP回應請求從GGSN失敗到SGSN時，如果從GGSN傳送的更新PDP上下文沒有收到響應，GGSN應該如何操作？
- 如果GGSN沒有收到該PDP的GTP回應響應或從SGSN到達的非回應請求消息的響應，它將如何失敗？
- GTP回應/非回應回應的缺失會如何直接影響PDP啟用失敗？
GGSN行為
如果消息未到達GGSN，則SGSN會觸發路徑故障警報並以靜默方式丟棄這些消息。此外，如果GGSN發起的回應請求沒有收到回應響應，則表示對等體已關閉，因此GGSN在本地清除與該對等體相關的呼叫。
在show support details命令輸出或show gtpc statistics verbose命令輸出中，您可以檢視GGSN請求超時計數器：
#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)操作的消息，接收節點應將具有適當原因值的響應（「不存在」或「找不到上下文」）傳送回消息的源。 響應消息中使用的隧道端點識別符號應設定為全零。
- 如果SGSN收到原因值為「不存在」的更新PDP上下文響應， 它 刪除PDP上下文.
原因代碼192錯誤
原因代碼192(或不存在)是由Gn介面上的GSN傳送的錯誤。它填充在Cause of GTP messages information元素中。
以下是可能有原因代碼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（僅存在流標籤，而非TEID）。 這表示SGSN即使在切換到GTPv0之後仍保持對GTPv1呼叫的控制。
- 案例4 — 不同步TEID效果將成倍增長。以下是範例：
- UE1建立PDP上下文；sgsn將Control-TEID-1(C-TEID-1)作為它的控制TEID分配給sgsn-UE1-ctxt上下文上的GGSN。GGSN上發往SGSN的所有消息的C-TEID都是C-TEID-1。
- SGSN上的信令消息（非回應）超時，並且SGSN在本地清除該sgsn-UE1-ctxt上下文。它還會通知無線網路控制器(RNC)進行清除。它不會通知GGSN，因為它將GGSN視為關閉。現在SGSN上的UE1沒有PDP上下文，而同一UE1的PDP上下文在具有C-TEID-1的GGSN上存在。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的進一步操作，請參閱第三代合作夥伴計畫(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重啟計數器。SGSN重新啟動計數器將遞增，並且在SGSN重新啟動後立即清除所有GGSN重新啟動計數器。 重啟計數器可為所有GGSN公用或者可為每個GGSN具有單獨的計數器。
GGSN對與GGSN聯絡的SGSN執行輪詢功能（回應要求和回應要求響應）。SGSN Restart計數器應包括在響應中。如果GGSN中收到的值與為該SGSN儲存的值不同，則GGSN將認為SGSN已重新啟動（請參見3GPP TS 29.060）。 在SGSN重新啟動後，GGSN重新啟動計數器應更新為從每個GGSN發出的第一個回應消息中收到的值。
當GGSN檢測到其啟用了PDP上下文的SGSN中的重啟時，它應刪除所有這些PDP上下文。 此外，從SGSN重新啟動的響應中接收到的SGSN Restart計數器的新值應在GGSN中更新。
意見