5Gネットワークでよくあるトラブルシューティング例は、一見すると単純です。UEは正常に登録され、PDU Sessionも確立され、IPアドレスも正しく割り当てられているのに、Webアクセスができず、基本的なPingさえ通りません。パケットキャプチャではN3経由でUPFにトラフィックが到達しているのに、期待する経路から対応するパケットが出ていない場合があります。AMFシグナリングとPDU Session確立結果だけに注目していると、実際の原因を切り分けにくくなります。
PDU Sessionが正常に確立していても、ユーザープレーンの転送経路が自動的に利用可能になるわけではありません。UPFはパケットを受信すると、まずPDRでトラフィックを識別し、その後、関連付けられた FAR（Forwarding Action Rule：転送アクションルール） を適用して、次に何をするかを決定します。具体的には、転送、破棄、バッファリング、またはパケットの複製です。FARは宛先インターフェースや、外側のGTP-Uトンネルヘッダーを作成する必要があるかどうかも定義できます。
トラブルシューティングでは、この役割分担が重要です。PDRは 「このパケットはどのセッション、どのトラフィックフローに属するか？」に答え、FARは 「パケットを識別した後、UPFはそれをどう処理するか？」 に答えます。制御プレーンの処理が正常に見えるのにユーザートラフィックが流れない場合、N4インターフェース上のFARは重要な確認ポイントになります。
なぜPDU Sessionが正常に確立してもユーザープレーン接続が保証されないのか？
PDU Session Establishmentの完了は、必要な制御プレーンのセッションリソースが初期化されたことを確認するだけです。実際のアプリケーショントラフィックは、gNB、N3、UPF、N6で構成される完全なユーザープレーン経路に依存します。
一般的なInternet PDU Sessionでは、アップリンクトラフィックはUEからgNBへ進み、GTP-Uトンネルでカプセル化され、N3経由でUPFへ到達します。UPFは適用される外側のトンネルヘッダーを削除し、トラフィックを識別して、元のパケットをデータネットワークへ転送する必要があります。ダウンリンクでは逆で、トラフィックがN6からUPFに入り、UPFが対応するPDU Sessionを識別し、gNBのユーザープレーントンネル情報を取得し、必要なGTP-U外部ヘッダーを付加して、N3経由でgNBへ送信します。
この転送動作は、PDU Sessionが作成されたという理由だけで利用可能になるわけではありません。SMFはN4経由で適切なPFCPルールをUPFへ設定する必要があります。PDRは一致するトラフィックを識別し、FARは分類後に適用する転送アクションを定義します。正しいユーザープレーン処理には両方のルールが必要です。
制御プレーンのシグナリングがすべて正常に見えるのにサービスが利用できない場合、問題は次の2つの質問に分けられます。
PDRは現在のトラフィックを正しく識別しているか？
パケット識別後、関連するFARに正しい処理・転送パラメータが含まれているか？
PDRとFARの関係に注目する方が、PDU Session確立手順全体を最初から何度も見直すより効率的な場合が多くあります。
FARは実際にUPFへ何を指示するのか？
FARはPFCPフレームワーク内の転送ルールです。SMFからN4経由でUPFに設定され、PDRが参照するFAR IDによってトラフィックと関連付けられます。パケットがそのPDRに一致すると、UPFは参照されたFARで定義された処理動作を実行します。
FARには複数のInformation Elementを含めることができます。ユーザープレーンのトラブルシューティングでは、次の項目が特に重要です。
| FARパラメータ | 主な機能 |
|---|---|
| FAR ID | FARインスタンスを一意に識別し、PDRが正しい転送ルールを参照できるようにする |
| Apply Action | 転送、破棄、バッファリング、複製など、パケットに対する基本動作を定義する |
| Forwarding Parameters | 転送が必要な場合の宛先、Network Instance、トンネルカプセル化、その他のパラメータを定義する |
| Duplicating Parameters | トラフィック複製が有効な場合に、複製パケットをどのように転送するかを定義する |
| BAR ID | パケットのバッファリング動作を制御するBuffering Action Ruleを参照する |
実際には、Apply ActionとForwarding Parametersが最も混同されやすい2つの要素です。Apply Actionは 「どの動作を実行するか？」に答え、Forwarding Parametersは 「転送する場合、どのように、どこへ送るか？」
に答えます。Apply ActionにFORWフラグがあるだけでは、ダウンリンク経路が完成しているとはいえません。Destination Interface、Network Instance、Outer Header Creation情報、その他の転送パラメータも正しくなければなりません。
Apply Actionは最初のパケット処理ステップをどのように決めるのか？
Apply Actionは、UPFが一致したパケットに適用する基本処理を示すビットフラグの集合です。これらは単純な排他的選択肢ではなく、PFCPセッションとサービスシナリオの文脈で意味を解釈する必要があります。
DROP: 一致したパケットを破棄する。
FORW: 適用されるForwarding Parametersに従ってパケットを転送する。
BUFF: パケットを直ちに転送せず、バッファリングする。
NOCP: バッファリングが必要なダウンリンクデータが到着した際に、制御プレーンへ通知するためにバッファリングシナリオで使用する。
DUPL: パケットの複製を作成し、その複製をDuplicating Parametersに従って処理する。
なぜBUFFとNOCPが必要なのか？
代表的なケースは、UEがIdle状態で、すぐに利用できるダウンリンクのユーザープレーン経路がない場合です。ダウンリンクトラフィックはすでにUPFへ到達していても、まだUEへ届けられないことがあります。UPFはパケットをバッファリングし、必要に応じて関連する制御プレーン通知動作を使用して、ページングやユーザープレーン経路の復旧など後続手順を開始できます。
BUFFはバッファリングが必要であることだけを示します。実際のバッファリング方法の詳細はBARに関連付けられるため、トラブルシューティングでBUFFフラグだけに依存してはいけません。
なぜDUPLは単に「もう一度パケットを転送する」だけではないのか？
DUPLは独立したパケットコピーを作成します。元のパケットは通常の処理経路を継続し、複製側はDuplicating Parametersによって独立して制御されます。複製は異なるDestination Interface、外部ヘッダー設定、Transport Level Marking、またはForwarding Policyを使用する場合があります。
そのため、ミラーまたは複製されたトラフィックが元のサービストラフィックと同じ経路を通ると自動的に判断してはいけません。複製パラメータは別途確認する必要があります。
Forwarding Parametersはパケットの実際の転送先をどのように決めるのか？
Apply ActionにFORWが含まれる場合、Forwarding Parametersが実際の転送経路を決定します。ユーザープレーン障害を調べる際には、特に重要な項目がいくつかあります。
Destination Interface
Destination Interfaceは、処理後にUPFがパケットを送るべき論理インターフェースを定義します。一般的なダウンリンクではAccessに設定され、パケットをgNB側へ転送することを意味します。アップリンクトラフィックは通常Core側へ転送されます。
Destination Interfaceが誤っていると、検出しにくい障害が発生します。PDRは正しく一致しているのに、パケットが誤った論理インターフェースへ送られ、制御プレーンには明確なエラーが出ない場合があります。
Network Instance
Network Instanceは、転送に使用する論理ネットワークコンテキストを識別します。複数のDNN、スライス、データネットワークが存在し、トラフィックを分離する必要がある環境で特に重要です。
N6接続やプライベートネットワークサービスを調査する場合、物理的な到達性だけを確認しても不十分です。FARのNetwork Instanceも対応するUPF設定と一致している必要があります。不一致があると、トラフィックを想定するネットワークコンテキストへルーティングできない場合があります。
Outer Header Creation
Outer Header Creationは、N3上のダウンリンク転送における重要なパラメータの1つです。N6からUPFへ入るパケットには元のUEペイロードが含まれています。そのパケットをN3経由でgNBへ送る前に、UPFは必要なGTP-U/UDP/IP外部カプセル化を追加する必要があります。
Outer Header Creationは、この処理に必要な情報として、gNBユーザープレーンアドレス、N3トンネルTEID、外部ヘッダータイプを提供します。
ダウンリンクトラフィックがUPFまで到達しているのにN3上に対応パケットが現れないケースの多くは、FARのこの部分に情報がない、または誤っていることが原因です。例えばTEIDやgNBアドレスの誤りです。
その他のForwarding Parameters
Forwarding Parametersには、Redirect Information、Transport Level Marking、Forwarding Policy、Header Enrichment、Linked Traffic Endpoint ID、Proxying、Destination Interface Typeなどのオプション情報を含めることもできます。
Transport Level Markingは、転送パケットへ必要なDSCPマーキングを適用するために使用できます。Forwarding PolicyはUPFにローカル設定された転送ポリシーを参照できます。Header Enrichmentは対象サービスで追加ヘッダー処理をサポートします。すべてのFARがこれらのInformation Elementをすべて含むわけではなく、実際の内容はPFCPシグナリングとサービス要件によって異なります。
なぜセッション確立後にダウンリンクFARが更新されることがあるのか？
最初のPDU Session Establishment手順では、SMFはUPFに最初のPDRとFARを作成できます。ただし、その時点ではgNBがダウンリンクN3ユーザープレーンリソースの割り当てを完了していない場合があります。そのため、最終的なトンネルTEIDとgNBユーザープレーンアドレスがSMFにまだ提供されていないことがあります。
gNBがそれらのリソースを割り当て、対応するN3ユーザープレーン情報がSMFで利用可能になると、SMFは PFCP Session Modification を送信し、UPF内の既存FARを必要なダウンリンクトンネルパラメータで更新できます。
更新されたダウンリンクFARには、次の主要な転送情報を含めることができます。
Destination Interface = Access。アクセス側への転送を示す。
適用される Network Instance。
Outer Header Creation = GTP-U/UDP/IPv4 、またはその他の適用可能な外部ヘッダータイプ。
gNB N3ユーザープレーンIPアドレスと、割り当てられたトンネルTEID。
このため、トラブルシューティングではPFCP Session Establishment Requestだけを確認して終わってはいけません。初期FARには基本的な転送アクションしか含まれておらず、実際のN3ダウンリンクトンネル構築に必要な情報が後からPFCP Session Modificationによって追加される場合があります。
後続の更新を分析で見落とすと、正常な段階的ルール設定を、FAR設定の欠落または不完全と誤認しやすくなります。
FARはダウンリンクトラフィックをどのようにN3トンネルへ戻すのか？
ダウンリンクパケットの完全な経路を追うと、FARの役割を理解しやすくなります。
外部サーバーからのパケットがN6経由でUPFへ到達します。UPFはPDRを使ってトラフィックを識別し、正しいPDU Sessionと関連付けます。その後、そのPDRが参照するFARを読み取ります。
Apply ActionにFORWが含まれる場合、UPFはForwarding Parametersを評価します。Destination InterfaceがAccessなら、パケットを無線アクセス側へ送ることを意味します。Outer Header CreationにはGTP-U外部ヘッダーを構築するために必要なgNBトンネルアドレスとTEIDが含まれます。UPFは元のパケットをカプセル化し、N3経由でgNBへ送信します。
完全な経路は次のようにまとめられます。
ダウンリンクパケットがN6へ到着 → PDRがUEトラフィックを識別 → FARがFORWを適用 → UPFがgNB N3トンネルパラメータを取得 → UPFがGTP-U外部ヘッダーを作成 → パケットをN3経由でgNBへ送信。
これによりFARとGTP-Uの違いも明確になります。GTP-Uはユーザーデータを運ぶトンネルプロトコルであり、FARはUPFの判断ルールとして 外部トンネルヘッダーを作成するか、どのトンネル情報を使用するか、どの論理インターフェースへパケットを送るかを制御します。
したがって、N3パケットキャプチャで誤ったTEIDが見えるのは表面的な症状にすぎません。調査は制御プレーンまで遡る必要があります。gNBは正しいユーザープレーン情報を割り当てたか？ SMFは正しく受信したか？ その後N4更新によって適切なFARへ書き込まれたか？
確立済みのPDU Sessionにデータ接続がない場合、FARを使ってどのようにトラブルシューティングするのか？
UE登録が正常でPDU Sessionも確立しているのにサービスが動作しない場合、登録手順全体を最初から再確認する代わりに、UPFの実際のパケット処理順序に沿ってトラブルシューティングできます。
実用的なFAR確認手順は次のとおりです。
パケットがUPFへ到達していることを確認する。 N3またはN6にパケットが到達していない場合、問題はFARより上流にあり、まずUE、gNB、またはトランスポート経路を確認する。
PDRがパケットに一致していることを確認する。 関連PDRが先にパケットを識別しなければ、FARには処理対象のトラフィックが存在しない。
PDRが参照するFAR IDを確認する。 正しく一致したパケットが誤った転送ルールに関連付けられていないことを確認する。
Apply Actionを確認する。 設定動作がFORW、DROP、BUFF、または適用可能なフラグの組み合わせかを確認する。
Destination InterfaceとNetwork Instanceを確認する。 パケットが正しい論理方向とネットワークコンテキストへ送られていることを確認する。
Outer Header Creationを確認する。 N3ダウンリンクトラフィックでは、gNBアドレス、TEID、外部ヘッダータイプを確認する。
PFCP Session Modificationメッセージを確認する。 初期Create FARだけを確認しない。gNBトンネル情報が後からUPFへ更新されていることを確認する。
N3とN6のパケットキャプチャを照合する。 PFCPルールから期待される動作と、UPFが実際に送信したパケットを比較する。
この方法の主な利点は、制御プレーンのルールとユーザープレーンのパケットキャプチャを相互に検証できることです。PFCPシグナリングは、UPFがパケットをどのように転送 すべきか を示し、N3とN6のキャプチャはUPFが 実際に 何をしたかを示します。
この2つが一致しない場合、障害範囲は通常、N4ルール設定の誤り、UPFによるルール実行の誤り、またはユーザープレーントランスポート経路の問題という3つの領域に絞れます。方向性なく5G Core全体を調べるよりはるかに効率的です。
FAQ
FARとPDRの主な違いは何か？
PDRはパケット検出と分類を行い、パケットがどのセッションやトラフィックフローに属するかを判断します。FARは一致後に何を行うかを定義し、パケットの処理方法や転送先を指定します。PDRはFAR IDを通じて対応するFARを参照します。
Apply ActionにFORWが含まれていても転送が失敗するのはなぜか？
FORWは転送を実行することを示すだけです。転送成功には関連するForwarding Parametersも正しく設定されている必要があります。Destination Interface、Network Instance、Outer Header Creation情報が誤っていれば、パケットは期待する宛先へ届きません。誤ったN3 TEIDやgNBユーザープレーンアドレスが典型例です。
最初のPFCP Session EstablishmentのFARに完全なN3トンネル情報がないことがあるのはなぜか？
PDU Session確立は複数ステップの手順です。初期PFCPセッション作成時点では、gNBが最終的なダウンリンクN3ユーザープレーンリソースをまだ割り当てていない場合があります。gNBのトンネルアドレスとTEIDが利用可能になると、SMFはPFCP Session ModificationでFARを更新できます。そのためトラブルシューティングでは、初期確立メッセージだけでなく、その後のN4交換も追跡する必要があります。
Outer Header CreationとPDR Outer Header Removalはどのように関係するのか？
両者はトンネル処理の逆方向に適用されます。N3から到着するアップリンクトラフィックでは、Outer Header Removalで該当するGTP-U外部ヘッダーを削除します。UPFからN3へ出ていくダウンリンクトラフィックでは、FARのOuter Header Creationが新しいGTP-U外部ヘッダーを構築するための情報を提供します。これらにより、ユーザープレーントンネルのカプセル化とデカプセル化を双方向で実現します。
N3のTEIDが誤っている場合、GTP-Uだけを調べればよいのか？
いいえ。N3パケットキャプチャで分かるのは、使用中のTEIDが誤っているという事実だけです。トンネル情報はgNBで生成され、SMFで処理され、N4経由でFARへ設定されます。実際の原因を特定するには、gNBの割り当て、SMFが受信した情報、PFCP Session ModificationによるFAR更新まで追跡する必要があります。
