UEが動画アプリを起動すると、実際のユーザートラフィックはデータネットワークへ到達する前に、gNBからUPFへ転送される必要があります。制御プレーンはPDU Sessionを確立し、アドレスを割り当て、転送ルールを設定しますが、5Gのアクセス網およびコア網のユーザープレーン上でユーザーIPパケットを実際に運ぶプロトコルはGTP-Uです。GTP-Uを理解するには、「UDPポート2152」と「TEID」だけを覚えるだけでは不十分です。5Gでは、1本のN3トンネルで複数のQoS Flowを運ぶことができ、さらにパス監視、不明なトンネルの処理、モビリティイベント後のユーザープレーン経路の整理にもGTP-U管理メッセージが利用されます。プロトコルスタック、トンネル、TEID、QFI、管理手順を一つの連続したユーザープレーン経路として捉えると、5Gトラフィックが実際にどのようにUPFへ到達するのかを理解しやすくなります。

GTP-Uは5Gアーキテクチャのどこに位置するのか？

GTP-UはGPRS Tunnelling Protocol for the User Planeの略です。5Gのユーザープレーンアーキテクチャでは、主に上位レイヤーのユーザートラフィックをカプセル化し、ユーザープレーンノード間で転送するために使用されます。

5G Coreの観点では、GTP-Uを使用する代表的なインターフェースはN3とN9です。N3はgNBとUPFを接続し、無線アクセスネットワークと5G Coreの間でユーザートラフィックを運びます。N9はUPF間で使用されます。またRAN内では、gNB間のXn-UでもGTP-Uを使用できます。

これは5Gの制御プレーンアーキテクチャとは大きく異なります。AMFやSMFなどのネットワーク機能は、主にHTTP/2を利用するサービスベースインターフェースを使用します。一方、ユーザープレーン経路では、加入者の実データを運ぶために引き続きGTP-Uが使用されます。5GがService-Based Architectureへ移行したからといって、ユーザープレーン自体がHTTPへ移行したわけではありません。

GTP-UはUDP上で動作し、引き続きUDPポート2152を使用します。ユーザーのアプリケーションパケットから下位レイヤーへ向かってプロトコルスタックを見ると、次のように理解できます。

アプリケーショントラフィックはまずTCPまたはUDPパケットとなり、その後UEに属するIPパケットになります。5Gユーザープレーンへ入ると、その元のユーザーパケットがGTP-U内にカプセル化されます。さらに、GTP-Uエンドポイント間で転送するために、外側のUDPヘッダー、外側のIPヘッダー、下位レイヤーのEthernetフレームが追加されます。

このため、パケットキャプチャには2組の異なるIPアドレスが含まれる場合があります。内側のIPアドレスはUEとデータネットワーク上のアプリケーションサーバー間の通信を表し、外側のIPアドレスはgNBやUPFなどのGTP-Uトンネルエンドポイント間で使用されます。N3トラフィックをトラブルシューティングする際、内側と外側のIPヘッダーを混同することはよくある原因の一つです。

GTP Path、Tunnel、TEIDの違いは何か？

GTP Path、GTP Tunnel、Tunnel Endpoint、TEIDは密接に関連する用語ですが、GTP-U転送モデルの異なる階層を表します。

GTP Pathは、2つのGTPトンネルエンドポイント間にあるコネクションレスな通信経路と考えることができます。gNBとUPFがIPネットワーク経由でGTP-Uパケットを交換できる場合、そのエンドポイント間にはGTP Pathが存在します。複数のGTP-Uトンネルが同じPathを共有できます。

GTP Tunnelは、より具体的な論理ユーザープレーントンネルを表します。GTP-Uトンネルは、TEID、IPアドレス、UDP転送情報の組み合わせで識別されます。一方、トンネルエンドポイント自体はノードのIPアドレスとUDPポートで識別されます。

TEID（Tunnel Endpoint Identifier）は、GTP-Uで最も重要なフィールドの一つです。GTPv1-Uの基本ヘッダーでは、TEIDは4バイト長です。GTP-Uパケットが受信ノードへ到達すると、受信側はTEIDとローカルのトンネルコンテキストを使って、そのパケットがどのユーザープレーントンネルに属するか、またどのPDU Sessionまたは転送コンテキストで処理すべきかを判断します。

このため、TEIDを単独で解釈してはいけません。同じ数値のTEIDが異なるトンネルコンテキストで使われることがあります。パケットが異なるGTPエンドポイントや異なる方向に属している場合、必ずしも同じトンネルの一部とは限りません。

ペイロード自体を見るときには、さらに2つの用語が役立ちます。T-PDUは元の上位レイヤーのユーザーデータで、G-PDUはT-PDUにGTP-Uヘッダーを付加したものです。したがってN3上を運ばれるのはUEの生のIPパケットだけではなく、GTP-Uでカプセル化されたG-PDUです。

GTP-Uはユーザーデータの転送だけに限定されません。独自の管理メッセージも持っています。そのため、パケットキャプチャでUDPポート2152が見えても、そのパケットがユーザーアプリケーショントラフィックであるとは限りません。Echo Request、Echo Response、Error Indication、End MarkerなどのGTP-Uメッセージも同じプロトコル枠組みを使用します。

TEIDがあるのに、なぜ5GではQFIが必要なのか？

4Gの視点からGTP-Uを学ぶと、TEIDを特定すればベアラも特定できると考えがちです。しかし5Gでは、その理解だけでは不十分です。

4GのQoSアーキテクチャはEPS Bearersを基盤としています。異なるベアラはそれぞれ独自のユーザープレーン転送コンテキストとGTP-Uトンネルを持つため、トンネルとTEIDによってベアラごとのトラフィックを自然に区別できます。

5GではQoSモデルがPDU Session + QoS Flowへ変わります。1つのPDU Sessionには1つ以上のQoS Flowを含めることができ、1つのDRBも1つ以上のQoS Flowを運べます。ただしN3では、同じPDU Session内のQoS Flowごとに個別のGTP-Uトンネルを作るわけではありません。

つまり、TEIDはPDU Sessionに関連付けられたGTP-Uトンネルを識別できますが、複数のQoS Flowが同じトンネルを共有する場合があります。

そこで次の疑問が生じます。受信ノードは、個々のパケットがどのQoS Flowに属するのかをどのように判断するのでしょうか。

その主な理由の一つが、拡張ヘッダーのPDU Session Containerです。5GではこのGTP-U拡張ヘッダーを使って、PDU Sessionに関連するユーザープレーン情報を運びます。その中にはQFI（QoS Flow Identifier）も含まれます。

QFIはQoS Flowを識別する6ビットの識別子です。したがって5G N3トラフィックを解析する際には、TEIDとQFIを次の2つの異なるレベルで理解できます。

TEIDはGTP-UトンネルまたはPDU Sessionコンテキストを識別し、QFIはそのトンネル内で運ばれる特定のQoS Flowを識別します。

ダウンリンクのPDU Session ContainerにはRQIやPPIなどの情報も格納できます。RQIはReflective QoSに関するシグナリングに使用され、PPIはPaging Policy Differentiationに関連し、同じPDU Session内のトラフィック種別に応じて異なるページング処理を行うために利用できます。

GTP-U基本ヘッダーのEビットは、後続にExtension Headerがあるかどうかを示します。つまり、すべてのGTP-Uパケットが同じ拡張ヘッダーを持つわけではありません。PDU Session Containerが存在するかどうかは、パケットと実行される機能によって異なります。

N3のユーザーパケットは実際にどう処理されるのか？

これまでの概念は、実際のアップリンクパケットフローに当てはめると理解しやすくなります。

UEがオンライン動画サービスへアクセスしていると仮定します。UEはまずアプリケーショントラフィックを生成し、それがTCPまたはUDPで運ばれ、通常のIPパケットに格納されます。この内側IPヘッダーでは、送信元アドレスがUEに割り当てられたIPアドレス、宛先アドレスがインターネット上のアプリケーションサーバーのアドレスになります。

パケットがgNBへ到達すると、gNBはUEのIPパケットをそのままUPFへ直接転送するのではなく、現在のPDU Sessionのユーザープレーンコンテキストに基づいてGTP-Uカプセル化を行います。

GTP-Uヘッダーには対応するTEIDが含まれます。特定のQoS Flowを識別する必要がある場合、PDU Session ContainerにQFIを含めることもできます。その後gNBは、宛先ポート2152のUDPヘッダーを追加し、さらに外側IPヘッダーを付加します。

この時点で外側IPアドレスはUEとインターネット間の通信を表していません。外側IPはgNBのN3インターフェースとUPFのN3インターフェース間の転送関係を表します。

パケットがUPFに到達すると、逆の処理が行われます。UPFは外側の転送情報に基づいてパケットを受信し、TEIDを読み取って正しいユーザープレーントンネルコンテキストを特定します。必要に応じてQFIやその他の拡張情報を処理し、GTP-Uカプセル化を外したうえで、元のUE IPパケットをデータネットワークへ転送します。

Wiresharkなどのパケット解析ツールでN3トラフィックを調査する場合、外側から内側へ確認する方法が有効です。まず外側のgNBとUPFのIPアドレスを確認し、次にUDPポート2152、TEID、存在する場合はPDU Session ContainerとQFIを確認し、その後でユーザーの内側IP、TCPまたはUDP、アプリケーション層トラフィックを調べます。

この方法は、アプリケーションパケットから分析を始めるより有効なことが多くあります。N3の障害は、ユーザーアプリケーションそのものではなく、トンネルコンテキスト、TEID、エンドポイントの問題によって発生することが多いためです。

なぜGTP-Uには独自の管理メッセージが必要なのか？

GTP-Uはユーザープレーンプロトコルですが、G-PDUのユーザーデータメッセージだけに限定されません。ユーザープレーン転送を正常に維持するためのパス管理メッセージやトンネル管理メッセージも定義しています。

Echo RequestとEcho Responseでパスの到達性を確認する

Echo Requestは、GTP Pathと対向GTPノードが到達可能で正常に動作しているかを確認するために使用されます。対向ノードはEcho Responseを返します。

これらのメッセージは、2つのGTPエンドポイント間の基本的な関係を確認します。gNBがUPFからEcho Responseを繰り返し受信できない場合、問題は1台のUEや1つのPDU Sessionに限定されず、GTP Path自体または対向ノードの障害を示している可能性があります。

GTP-UにはSupported Extension Headers Notificationメッセージも定義されており、ノードがサポートするGTP拡張ヘッダーを相手に通知できます。PDU Session Containerのような拡張ヘッダーに5Gユーザープレーン機能が依存する場合に重要です。

Error Indicationは不明なTEIDを処理する

GTPエンドポイントがG-PDUを受信したものの、受信したTEIDに対応するローカルのEPS BearerまたはPDU Sessionコンテキストを見つけられず、かつTEIDが0ではない場合、対向ノードへError Indicationを送信できます。

これにより送信ノードは、受信側ですでに認識されていないユーザープレーントンネルへデータを送っていることを知ることができます。

トラブルシューティング中にError Indicationが繰り返し現れる場合、まず両エンドポイントのTEID状態が一致しているか、PDU Session更新、モビリティ手順、ユーザープレーンパス変更によって双方の状態がずれていないかを確認します。

End Markerでユーザープレーンのパス切り替えを完了する

End Markerは、主にモビリティとユーザープレーンのパス切り替えに関連します。旧GTP-Uパス上の最後のG-PDUが送信済みであり、以降のユーザートラフィックはその旧パスを通るべきではないことを示します。

例えば、UEが送信元gNBから移動先gNBへ移動すると、コアネットワーク側のユーザープレーン経路も変更されることがあります。トラフィックが旧パスを無期限に流れ続けると、新旧パスが重複し、パケット順序や転送に問題が生じる可能性があります。

したがってEnd Markerは、単なる「トンネル削除」通知ではありません。旧ユーザープレーン経路の境界マーカーとして機能し、その経路上の最後のパケットがすでに到達済みであることを受信側へ伝えます。

これらの仕組みをまとめて見ると、GTP-Uの役割がより明確になります。GTP-Uは、ユーザーIPパケットの前にTEIDを付加するだけのプロトコルではありません。ネットワーク状態の変化に応じて識別、監視、管理、更新できる、包括的なユーザープレーントンネリングの枠組みを提供します。

5G GTP-Uの実践的なトラブルシューティング手順は、まずGTPエンドポイントとPathが正常かを確認し、次にTEIDとTunnelコンテキストを確認し、必要に応じてPDU Session ContainerとQFIを調べ、最後に元のユーザートラフィックへ内側に進むことです。モビリティやパス更新中に問題が発生している場合は、Error IndicationとEnd Markerも確認します。

この順序で確認すると、大量のUDP 2152パケットが並ぶN3パケットキャプチャを、レイヤーごとに再構築できるユーザープレーン転送経路として読み解けるようになります。

よくある質問

UDPポート2152のすべてのパケットがユーザートラフィックを運ぶのか？

いいえ。G-PDUメッセージはGTP-UとUDPポート2152でユーザープレーンデータを運びますが、Echo Request、Echo Response、Error Indication、End Marker、Supported Extension Headers NotificationなどのGTP-U管理メッセージも同じプロトコル枠組みを使用します。実際に何を表すパケットか判断するにはGTP-U Message Typeを確認する必要があります。

TEIDは5Gネットワーク全体でグローバルに一意でなければならないのか？

いいえ。TEIDはネットワーク全体でグローバルに一意な識別子として扱うべきではありません。GTP-Uトンネルの識別には、トンネルエンドポイント、IPアドレス、転送情報、方向も関係します。そのためトラブルシューティングでは、TEIDの値だけを比較するのではなく、トンネル全体のコンテキストを確認する必要があります。

すべての5G GTP-UパケットにPDU Session Containerが含まれるのか？

いいえ。PDU Session ContainerはGTP-U拡張ヘッダーの一つであり、含まれるかどうかはパケットと実行される機能によって異なります。GTP-U基本ヘッダーのEビットは追加のExtension Headerが続くかどうかを示すため、すべてのN3パケットが同じヘッダー構造になるわけではありません。

End MarkerはPDU Session全体が解放されたことを意味するのか？

必ずしもそうではありません。End Markerは主に、特定のGTP-Uユーザープレーン経路上のトラフィックが終了したことを示し、モビリティイベント後のパス切り替えでよく見られます。これはそのパス上のトラフィック終了を示すものであり、PDU Session全体の解放手順を表すものではありません。