GTP' (GTP プライム) は、GSM および UMTS ネットワーク内で使用される IP ベースのプロトコルです。UDP または TCPで使用できます。GTP 'はGTP ( GTP-C、GTP-U)と同じメッセージ構造を使用しますが、大部分は別のプロトコルです。GTP' は登録済みのUDP/TCP ポート 3386 を使用します。
GTP は、GSM または UMTS ネットワークの「課金データ機能」(CDF) から「課金ゲートウェイ機能」(CGF) に課金データを運ぶために使用できます。ほとんどの場合、これは、GGSN などの多数の個別のネットワーク要素から中央コンピュータに課金データを運ぶことを意味し、中央コンピュータは課金データをネットワーク オペレータの課金センターに、より便利に配信します。
GTP は、3GPP GPRS コア ネットワーク定義内の Ga インターフェイスで使用されます。
GTP' は GTP の側面を再利用しますが、3GPP TS 32.295 を引用すると、「GTP のシグナリング プレーンのみが部分的に再利用されます」。[1] GTP' は、CGF またはSGSN / GGSNの障害時にCDR が失われたり重複したりしないように、異なるヘッダー、追加のメッセージ、フィールド値、および同期プロトコルを定義します。転送された CDR は、3GPP 標準に従う場合、 ASN.1でエンコードされます。
ヘッダ
GTP v1およびv2ヘッダーには次のフィールドが含まれています
- バージョン
- GTP'パケットの最初のヘッダー フィールドは、3 ビットのバージョン フィールドです。GTP' v2 の場合、この値は 2 です (そのため、GTP' v2 という名前が付けられています)。
- プロトコルタイプ (PT)
- GTP' (値 0) と GTP (値 1) を区別する 1 ビットの値。
- 予約済み
- 3 ビットの予約フィールド (1 である必要があります)。
- ヘッダーの長さ (Hdr len)
- GTP バージョン 0 の場合、20 バイト ヘッダー (値 0) ( GTPに従って) を使用するか、この 6 バイト ヘッダーを使用するかを示す 1 ビットの値。このビットは、後続の GTP バージョンでは設定解除 (値 0) する必要があり、これらのバージョンではヘッダーの長さは示されず、ヘッダーの長さは常に 6 バイトである必要があります。
- メッセージタイプ
- メッセージ タイプを示す 8 ビット フィールド。可能な値:
- 長さ
- GTP' によってカプセル化されるパケットの長さを示す 16 ビットのフィールド (GTP' ヘッダー自体は含まれません)。
- シーケンス番号
- このパケットを一意に識別し、損失や重複の検出を可能にする16ビットのフィールド
メッセージの種類
GTP'は、GTPバージョン未サポート、エコー要求、エコー応答メッセージをそのまま使用しますが、次のメッセージを追加します。
- ノードアライブリクエスト
- ノードアライブ応答
- リダイレクトリクエスト
- リダイレクト応答
- データレコード転送リクエスト
- データレコード転送応答
ノードアライブ要求/応答
Node Alive メッセージは、ノードがサービスを開始したことを他のネットワーク コンポーネントに通知するために使用されます。要求は開始ノードから送信されるため、エコー要求/応答を使用したポーリングよりも高速にサービスを再度有効にすることができます。このメッセージは、他のノードがサービスに復帰したことを通知したり、(GTP バージョン 2 では) CGF の IPv6アドレスを通知したりするためにも使用できます。
リダイレクト要求/応答
リダイレクト メッセージは次の目的で使用されます。
- 送信者がサービスから削除されるとき(メンテナンス/障害のため)、CDR のフローを CDF(SGSN / GGSN )から別の CGF に転送します。
- CGFが下流システムとの接続を失ったことを通知します
どちらの場合でも、CDF がエコー要求メッセージを使用してポーリングしている場合よりも、CDF には、差し迫った障害または即時の障害に関する詳細な情報が提供されます。
このメッセージには、原因に関する詳細と、オプションで代替 CGF のアドレスが含まれます。
データレコード転送要求/応答
データ レコード転送メッセージは、CDR を生成ポイント ( SGSN / GGSN ) から CGF 内の不揮発性ストレージに確実に転送するために使用されます。
データレコード転送リクエスト
各データ レコード転送要求メッセージには、次の 4 つのタイプのいずれかのメッセージが含まれます。
- 送信データ レコード パケット - このメッセージには 0 個以上の CDR が含まれます。CDR は、 BERまたは、あまり一般的ではないがPER を使用してASN.1でエンコードされる場合があります。
- 重複している可能性のあるデータ レコード パケットを送信します - このメッセージには 1 つ以上の CDR が含まれており、このメッセージは以前に別の CGF に送信されています。
- データ レコード パケットのキャンセル - このメッセージは、CGF に、CGF の「重複している可能性のある」保留キューから 1 つ以上のデータ レコード パケットを削除するように指示します。
- データ レコード パケットの解放 - このメッセージは、CGF に、CGF の「重複している可能性のある」保留キューから 1 つ以上のデータ レコード パケットの内容を書き込むように指示します。
重複した CDR の紛失や書き込みを回避するためのメカニズムがあります。これは 3GPP TS 32.295 で詳しく説明されています。基本的な前提は、すべてのパケットが順序付けられ、個別に確認応答されない場合は、CGF によって確認応答されるまで再送信されることです。通常のデータ レコード パケットはすぐに不揮発性ストレージ (ディスクなど) に書き込まれますが、再送信されたパケットは「重複している可能性がある」とマークされ、すぐには不揮発性ストレージに書き込まれない特別なキューに入ります。CDF からの 2 回目の確認が必要です。
ゼロの CDR を含むデータ レコード転送要求を送信する機能は、CGF がそのシーケンス番号に割り当てられたレコードを既に書き込んだかどうかの成功または失敗を検出するためのテストとして使用され、上記のメカニズムの重要な部分です。
データレコード転送応答
データ レコード転送応答は、1 つ以上のデータ レコード転送メッセージの受信を確認します。応答は効率上の理由からグループ化できますが、送信 CDF のタイムアウトよりも頻繁に送信する必要があります。
確認には理由が含まれており、含まれているレコードの拒否となる場合があります。
参考文献
- ^ 3GPP TS 32.295
外部リンク
- 番号付き3GPP仕様への直接アクセス
- オープンソースの課金ゲートウェイ機能 (CGF)
