UMTS-GPRSトンネリングプロトコル
GPRSトンネリングプロトコル（GTP）の生成は事実上不可能でしたが、新しいシステムにそれを与えることも望ましくありませんが、一方で、相互作用できるようにするために改善も必要であることは非常に理解できます。従来のPSの世界でスムーズに、最新のシステムに必要な機能をサポートします。
GPRSトンネリングプロトコル（GTP）
GTPプロトコルは、GPRSでのデータユニットと制御メッセージのトンネリングとカプセル化のために設計されています。1990年代後半の設計以来、大規模に展開され、確かな経験が積まれてきました。
Evolved 3GPPシステムのGTPには、コントロールプレーンとユーザープレーンの2つのバリエーションがあります。GTP-Cはコントロールプレーンシグナリングを管理し、ユーザーの純度に関するデータ転送プロトコルに加えて、GTP-Uが必要です。これはユーザープレーンと呼ばれます。EPSに適した現在のバージョンは、GTPv1USおよびGTPv2-Cです。
GTPの特徴は、プライマリGTPトンネルホルダー内のトラフィックの分離、つまり、トラフィックをグループ化してキャリアを処理する機能をサポートすることです。GTPトンネルの終わりは、TEID（トンネルエンドポイント識別子）によって識別されます。それらは、ピアエンティティによってアップリンクとダウンリンクのローカルレベルに割り当てられ、それらの間で横方向に報告されます。TEIDは、S5とS8のPDN接続の例、およびS3 / S4 / S10 / S11インターフェイスのEUによって、さまざまな粒度で使用されます。
GPRSトンネリングプロトコルのコントロールプレーン
GTPv2-Cは、EPCシグナリングインターフェイス（少なくともRel。8のSGSNを含む）で使用されます。例-
- S3（SGSNとMMEの間）、
- S4（SGSNとServing GWの間）、
- S5とS8（ServingGWとPDNGWの間）、
- S10（2つのMME間）、および
- S11（MMEとServing GWの間）。
これに対応して、上の図に示すような典型的なGTPv2-Cプロトコルデータユニットでは、特定の部分GTPの前にIPヘッダーとUDPヘッダーがあり、ヘッダーGTPv2-Cと情報GTPv2-C変数を含む部分で構成されています。メッセージのタイプに応じて、長さと形式。エコーとプロトコルバージョンの通知はサポートされていないため、TEID情報は存在しません。このバージョンのプロトコルでは、バージョンは明らかに2にしっかりと設定されています。
GTPには複雑なレガシー拡張ヘッダーメカニズムがありました。ほとんどのGTPv2-Cでは使用されていません。メッセージタイプは2番目のバイトで定義されます（したがって、将来の拡張のために最大256のメッセージを定義できます）。以下の表は、現在GTPv2-Cで定義されているメッセージの概要を示しています。メッセージの長さはバイト3と4でコード化されます（バイトで測定され、最初の4バイト自体は含まれません）。
TEIDは、トンネルエンドポイントのIDであり、反対側/受信側の単一の値です。これにより、GTPトンネルを介した非常に頻繁なケースで、一方の端でトンネルの多重化と逆多重化を区別できます。
| メッセージタイプ | メッセージ | 追加の説明 |
|---|---|---|
| 0 | 予約済み | 決して使用しないでください（明示的な設定を強制するために、プロトコルから意図的に除外されています） |
| 1/2 | エコー要求/応答 | 送信ノードでサポートされているGTPバージョンかどうかを調べるために使用されます。 |
| 3 | サポートされていないバージョン表示 | 送信ノードをサポートする最新のGTPバージョンが含まれています。 |
| 4/5 | 直接転送の要求/応答 | HRPDアクセスではなくMME間で、最適化されたハンドオーバーのためにS101インターフェイスでシグナリングメッセージをトンネリングするために使用されます |
| 6/7 | 通知要求/応答 | HRPDアクセスノードとMME間のS101でのトンネリング通知に使用されます |
| 25/26 | SRVCCPSからCSへの要求 | SGSN / MMEとMSCサーバー間のSRVCC開始をトリガーおよび確認するために使用されます |
| 27/28 | SRVCCPSからCSへの完全な通知 | MSCサーバーとSGSN / MME間のSRVCCの完了を示して確認するために使用されます |
| 32/33 | セッションリクエストの作成 | 2つのノード間の接続を確立するために使用されます |
| 34/35 | ベアラリクエストの変更 | 単一または複数のベアラのプロパティを変更するために使用され、ベアラコンテキスト情報が含まれます |
| 36/37 | セッションリクエストの削除 | GTP制御セッションをティアダウン |
| 38/39 | 変更通知リクエスト | 位置情報のレポートに使用されます |
| 66/67 | ベアラコマンド/失敗表示の削除 | ベアラを削除して確認するようにノードに指示します |
| 68/69 | ベアラリソースコマンド/障害表示 | リソースの割り当てまたは変更に使用されます |
| 73 | ページング表示を停止します | SGWからMMEまたはSGSNに送信されます |
| 95/96 | ベアラ要求/応答を作成する | ベアラをインストールするようにノードに指示し、確認します |
| 97/98 | ベアラリクエストの更新 | ベアラの変更についてユーザープレーンからコントロールプレーンノードに通知するために使用されます |
強化されたGTPv1-U
GTP-Uには、わずかではあるが効果的な改善のみが適用されたため、プロトコルバージョンの数を強化する必要はないと考えられました。したがって、GTPv1-Uは引き続き期待されますが、少なくとも最新のRelです。8.8。
プロトコルスタックは基本的にGTPv2-Cの場合と同じですが、レイヤーの名前とそれに応じてプロトコルが置き換えられているだけです。拡張ヘッダーメカニズムはそのまま維持されます。必要に応じて2つの要素を挿入できます。
トリガーメッセージのUDP送信元ポート（2オクテット）。
PDCPPDU番号-損失のない特性転送に関連します。この場合、データパケットにはEPCで番号を付ける必要があります（2オクテット）。
改善点は、ユーザープレーンで「エンドマーケット」を送信する機能です。これは、eNodeB間ハンドオーバー手順で使用され、データパケットの直後にパスウェイがアクティブ化されたことを示します。たとえば、GTP-Uが無線アクセスで終了しなかったため、Rel.8より前の機能は必要ありません。ノード（つまり、BSまたはNodeBにない）には、いくつかのメッセージしか存在しません。GTPv1-U、およびそれらは上の表にリストされています。
実際、GTPv1-U（エコーメカニズムとエンドラベリング）を介して可能なシグナリングの種類は非常に限られていることは明らかです。実際のユーザーデータの転送がタイプ255であるという唯一のメッセージ、いわゆるG-PDUメッセージ。ヘッダーの後に保持される唯一の情報は、ユーザーまたは外部PDN機器からの元のデータパケットです。
GTP-Uトンネルのすべてのインスタンスがリファレンスアーキテクチャにリストされているわけではありません（アソシエーションをキャプチャすることを目的としており、ネットワークノード間に存在しなくなりました）。一時的なトンネルが可能です-
サービスがGWに移動された場合、S1に基づく転送に適用可能な2つのサービングGW間。
2つのSGSN間で、前のケースに対応しますが、レガシーPSネットワーク内です。
3G PSネットワークでのRNCの再配置に適用可能な2つのRNC間（EPCとは関係ありません。ここでは、完全を期すために説明します）。