概要
このドキュメントでは、Serving GPRS Supporting Node(SGSN)がGGSNから送信されたGPRS Tunneling Protocol(GTP)エコー要求に応答しない場合の、Gateway General Packet Radio Service(GPRS)Supporting Node(GGSN)の)ののの動作について説明します。
背景説明
GGSNでGTPエコー要求にSGSNが応答しない期間に、高いパケットデータプロトコル(PDP)のアクティベーション障害が発生する可能性があります。このシナリオで発生する可能性のある質問を次に示します。
- SGSNからのCreate PDP要求またはUpdate PDP要求はGGSNに到達しますか。
- GGSNからSGSNへのGTPエコー要求が失敗した場合、GGSNから送信されるUpdate PDPコンテキストが応答を受信しない場合、GGSNはどのように動作しますか?
- GGSNは、PDPに対してGTPエコー応答またはSGSNから到着した非エコー要求メッセージに対する応答を受信しない場合、どのようにPDPに失敗しますか。
- 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制御メッセージ(update PDP context requestなど)がある場合、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はCause Code 192(存在しない)でそれを拒否する可能性があります。
TS 29.060から取得したセクションを次に示します。
- Gprs Supporting Node(GSN)が、送信側ノードが存在すると考えているPDPコンテキストに関するアクションを要求するGPRS Tunneling Protocol-Control plane(GTP-C)メッセージを受信ノードが認識しない場合は、適切な原因値(「Non-exist」またはcontext not found")。 応答メッセージで使用されるTunnel Endpoint Identifier(TEI)は、すべて0に設定する必要があります。
- SGSNが原因値「Non-existent」のPDPコンテキスト応答を受信すると、 これは、 PDPコンテキストの削除.
原因コード192エラー
原因コード192(または存在しない)は、GnインターフェイスのGSNによって送信されるエラーです。これは、「Cause of GTP messages」情報要素に入力されます。
原因コード192エラーが発生する可能性のあるGTPメッセージを次に示します。
- Update_PDP_Context_Response
- Delete_PDP_Context_Response
注:このエラーを含むメッセージで使用されるTunnel End Identifier(TEID)は0になります。詳細はTS 29.060を参照してください。
このエラーは、GSNによって送信され、他のGSNによって送信されたコンテキストに対応するコンテキストがない場合に、前述のメッセージに表示される可能性があります。このエラーを受信すると、GSNはPDPコンテキストを削除します。
シナリオ例
このセクションでは、原因コード192エラーが発生する4つのシナリオについて説明します。
- シナリオ1:GSN間でGTP-Cパス障害が発生します。
- シナリオ2:GSN間でエコー要求/応答障害が発生します。
- シナリオ3:エラーの原因となるGTPバージョン1(GTPv1)からGTPバージョン0(GTPv0)へのハンドオフの問題があります。次に、このシナリオのコールフローの例を示します。
- GTPv1とのPDPコンテキスト作成要求が確立される。
- GTPv1からGTPv0へのハンドオフが発生します。
- GGSNのコールがGTPv0になります。
- GGSNは、ゼロ以外のヘッダーTEIDを持つ更新PDPコンテキスト要求を受信し、エラー(存在しない)が原因でそれを拒否します。
注:コールがGTPv0に移動したため、SGSNはTEIDを忘れたはずです(GTPv0にはフローラベルのみが存在し、TEIDは存在しません)。 これは、GTPv0へのハンドオフ後もGTPv1コールに対してSGSNが保留されたことを示します。
- シナリオ4:同期されていないTEID効果が乗算されます。以下が一例です。
- UE1はPDPコンテキストを確立します。SGSNは、Control-TEID-1(C-TEID-1)を制御TEIDとしてsgsn-UE1-ctxtコンテキストのGGSNに割り当てます。SGSNに向かうGGSN上のすべてのメッセージの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には、Gn C-TEIDとしてC-TEID-1を使用する2つのコンテキストがあります。GGSNは、同じTEIDがすでに存在するかどうかをチェックしません。次に、GGSNはSGSNに向けてUE1のPDPコンテキスト(DPC)の削除を開始します。
- SGSNでは、C-TEID-1とそのコンテキスト(sgsn-UE2-Ctxt)が見つかります。そのコンテキストを削除し、GGSNに応答するために試行されます。
- 他のコンテキストに対してGGSNが開始した要求(PDPの更新/削除)がある場合、SGSNはContext not found原因で応答します。
- GGSNは、UE2に対するDPC要求を送信しないため、UE2に対するDPC応答をドロップします。
- GGSNには、SGSNのどのコンテキストにも対応しない2つ目のコンテキストがあります。
- 同じ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 Restartカウンタを揮発性メモリに保持し、SGSNが接続されている各GGSNに関連する不揮発性メモリSGSN Restartカウンタを保持します。SGSN再起動カウンタが増加し、SGSNの再起動後すぐにGGSN再起動カウンタがすべてクリアされます。 再起動カウンタはすべてのGGSNに共通であるか、または各GGSNに対して個別のカウンタが存在する場合があります。
GGSNは、GGSNが接触しているSGSNに対してポーリング機能(エコー要求およびエコー応答)を実行する。エコー応答にはSGSN Restartカウンタを含める必要があります。GGSNで受信した値が、そのSGSNに保存されている値と異なる場合、GGSNはSGSNが再起動したと見なします(3GPP TS 29.060を参照)。 GGSN再起動カウンタは、SGSNの再起動後に各GGSNから受信される最初のエコーメッセージで受信された値に更新されます。
GGSNは、PDPコンテキストがアクティブになっているSGSNで再起動を検出すると、これらすべてのPDPコンテキストを削除します。 また、再起動されたSGSNからのエコー応答で受信したSGSN Restartカウンタの新しい値は、GGSNで更新されます。