N3 — (R)AN ⇔ UPF（GTP-U 参照点）¶

学習目標¶

このページを読み終えると、次のことができるようになります。

• N3が基地局(gNB)とUPFを結ぶユーザプレーンインターフェースであることを説明できる。
• N3のProtocol（GTP-U）と、その下位Transport（UDP/IP）を言える。
• TEID がGTP-Uトンネルを識別し、QFI がQoS Flowを識別する役割を区別できる。
• N3が制御プレーン(N2)と分離されたデータ経路であることを説明できる。
• 4G(EPC)のS1-U（GTP-U）との対応関係を説明できる。

前提知識¶

先に以下を理解しておくとスムーズです。

• GTP-U と UDP/IP の位置づけ → Protocol辞典
• N3を終端するコア側NF → UPF
• 対になる制御プレーン → N2
• N3上のトンネルが確立される手続き → PDU Session確立
• Interfaceの考え方 → Interface辞典

Why — なぜ必要なのか¶

制御メッセージ（N2）で「このUEを登録した」「セッションを張った」と合意しても、それだけでは実際のユーザデータ（Webページ、動画、音声パケット）はまだ1バイトも流れていません。ユーザが本当に使うのは、この実データを高速に運ぶ土管の方です。

しかも1台の基地局(gNB)には多数のUEがぶら下がり、1台のUPFは多数のgNBを収容します。膨大なパケットが混ざって流れる中で「これはどのUEの、どのフローのパケットか」を確実に見分ける仕組みが要ります。この「制御とは別に、実ユーザデータをトンネルで運び、フローを識別する道」がN3です。N3が無ければ、セッションを張っても実データを運ぶ経路が存在しません。

例え話をすると、N2が「誰をどう通すか」を決める管制塔の無線連絡なら、N3は車が実際に走る高速道路の専用レーンです。管制で許可が出ても、走る道そのものが無ければ移動できません。

Overview — 概要¶

N3は (R)AN(gNB) ⇔ UPF を結ぶユーザプレーンインターフェースです。上を流れるProtocolは GTP-U（GPRS Tunneling Protocol - User plane）、その下は UDP over IP です。

N3はユーザデータを GTP-Uトンネル でカプセル化して運びます。識別には2つの鍵があります。

制御シグナリングはN2、ユーザデータはN3、という制御/ユーザ分離がここでも貫かれています。

Basic Concept — 初心者向け説明¶

N3を荷物を運ぶ宅配便に例えます。Why節では高速道路に例えましたが、パケット1個1個に着目すると宅配便の封筒が分かりやすいでしょう。

UEが送りたいデータ（元のIPパケット）を、そのまま裸で流すのではなく、封筒(GTP-U)で包んで運びます。

• 封筒（GTP-Uトンネル） = 元のパケットを丸ごと包む外装。中身（ユーザのIPパケット）はそのまま。
• 宛先ラベル（TEID） = 封筒の表に貼る番号。UPFやgNBは、このラベルを見て「どのトンネルの荷物か＝どこへ届けるか」を判断します。
• 優先度シール（QFI） = 封筒に貼る「速達」「普通」の区別。同じセッションでも、動画は優先、バックグラウンド更新は後回し、といったQoSの違いを示します。

そして道は上り・下りの2方向です。UE→gNB→UPF→インターネットが上り(Uplink)、その逆が下り(Downlink)。上りと下りではラベル(TEID)が別々に付けられ、gNB側の端点とUPF側の端点がそれぞれ自分宛のTEIDを持ちます。TEIDは各端点が「自分が受け取るときに使う番号」を相手に伝え合う方式なので、上り用と下り用で別番号になります。

Protocol / Transport¶

Architecture¶

N3がgNBとUPFを結び、制御プレーン(N2)とは別経路でユーザデータを運ぶ様子を示します。

flowchart LR
  UE(("UE"))
  gNB["gNB (基地局)"]
  AMF["AMF"]
  UPF["UPF"]
  UPF2["UPF (アンカ)"]
  DN["DN (データ網)"]

  UE -- "無線" --> gNB
  gNB == "N3 (GTP-U / UDP:2152)" ==> UPF
  UPF -- "N9 (GTP-U)" --> UPF2
  UPF2 -- "N6" --> DN
  gNB -. "N2 (NGAP) 制御は別線" .-> AMF

  classDef uplane fill:#eef,stroke:#66f,stroke-width:2px;
  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class gNB,UPF,UPF2 uplane;
  class AMF ctrl;

図の読み方: 太い線(==>)がN3のユーザデータ経路（GTP-Uトンネル）。点線(-.->)のN2制御は完全に別線で流れる制御/ユーザ分離に注目してください。UPFが複数段になる場合、UPF間は N9（こちらもGTP-U）でつながれます。

利用Procedure¶

N3のトンネルは、PDU Session確立の中でU-Plane（ユーザプレーン）として確立されます。

• U-Plane確立: PDU Session確立の一環として、gNBとUPFがそれぞれの端点で使う TEIDとトランスポートアドレス（IP）を交換します。これによりN3のGTP-Uトンネルが上り・下りの2本ができあがります（TEIDの受け渡し自体はN2/N4などの制御で行われます）。
• ハンドオーバ: UEが別のgNBへ移ると、UPF側から見た下りトンネルの端点（gNBのTEID/アドレス）が切り替わり、N3パスが新gNBへ張り替えられます。

手続きの詳細な流れは重複を避けるため PDU Session確立 を参照してください。ここでは「N3＝そのセッションで確立されるユーザデータの土管」という位置づけを押さえれば十分です。

主なMessage¶

GTP-Uは土管に徹するProtocolのため、制御メッセージは少なめです。大半は実データを運ぶG-PDUです。

各メッセージの詳細は Message辞典 を参照してください。

Packet Analysis (Wireshark)¶

N3はGTP-U、その下はUDPとして観測されます。

Decodeの見どころ:

• GTP-Uヘッダの TEID で、どのトンネル（≒どのUEのどのセッション）かを識別できます。上り・下りでTEIDが異なる点に注目してください。
• 拡張ヘッダ（PDU Session Container, TS 38.415） に載る QFI で、そのパケットがどのQoS Flowに属するかが分かります。
• G-PDUでは、GTP-Uヘッダの内側に内包されたユーザのIPパケットがさらにデコードされます。この「GTP-Uの中にユーザIPが入れ子」という二段構造がN3理解の要です（N2でNGAPの中にNASが入れ子だったのと相似形）。

EPCとの比較¶

• 4Gでは: 基地局(eNB)とSGWを結ぶ S1-U、SGW⇔PGW間の S5/S8 上を GTP-U（TS 29.281）が流れました。ユーザデータをTEIDでトンネル識別する点は同じです。
• 5Gでは: gNBとUPFを結ぶ N3、UPF間の N9 上を GTP-U（TS 29.281、同じProtocol）が流れます。QoS識別が QFI ベースになり、GTP-U拡張ヘッダ(PDU Session Container)で搬送される点が加わりました。

3GPP Specification¶

• 3GPP TS 29.281 — GTP-U（GPRS Tunneling Protocol - User plane）。個別章番号は要確認
• 3GPP TS 38.415 — PDU Session User Plane Protocol（PDU Session ContainerによるQFI搬送）。個別章番号は要確認
• 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N3の定義）

Summary¶

• N3は (R)AN(gNB) ⇔ UPF を結ぶユーザプレーンインターフェースで、ProtocolはGTP-U。
• 下位Transportは UDP over IP、ポートは 2152。
• TEID でGTP-Uトンネルを、QFI でQoS Flowを識別する（QFIはGTP-U拡張ヘッダ/PDU Session Container, TS 38.415で搬送）。
• 制御はN2、データはN3という制御/ユーザ分離が貫かれる。UPF間はN9（同じくGTP-U）。
• 4GのS1-U（GTP-U, TS 29.281）に相当し、5Gでは同じGTP-UにQFI拡張が加わった。

Next Step¶

• UPF — N3を終端するコア側のNF
• N2 — N3と対になる制御プレーン（NGAP/SCTP）
• PDU Session確立 — N3のU-Planeトンネルが確立される手続き
• Interface辞典 — N9など未整備の参照点の確認
• Message辞典 — GTP-Uメッセージの確認