スマートフォンにすでに5Gアイコンが表示されていても、Webページがまったく読み込めないことがあります。このような場合、最初に確認しがちなのがRegistration手順です。5G-AKAは完了したか、Registration Acceptを受信したか、T3512はタイムアウトしていないか。これらを確認するとRegistration手順自体は完全に正常に見えるのに、データ通信だけが利用できない場合があります。
多くの場合、問題はRegistrationではなくPDU Sessionにあります。Registrationが答えるのは「UEは5GSへ登録できるか」という問いです。PDU Session Establishmentが答えるのは次の問い、すなわち「UEは実際にデータネットワークへ到達できるか」です。ここではPDUセッション確立手順を最初から最後まで追い、UEがどのようにセッションを要求し、AMFがどのようにSMFを選択し、SMFが加入者情報とポリシー情報を取得し、UPFがどのように設定され、最終的にN3トンネルがどのように完成するかを説明します。
UEが5GS Registrationを完了すると、AMFにはすでにユーザー識別情報、モビリティ、セキュリティ、関連する加入者コンテキストがあります。しかし、Registrationが成功したからといって、ユーザープレーンの経路がすでに存在するわけではありません。UEにはまだインターネットや企業データネットワークへの有効な経路がない可能性があります。
PDU Session Establishmentによって、UEは「登録済み」の状態から「アプリケーション通信を転送できる」状態へ移行します。UEがセッションを要求し、ネットワークがSMFとUPFを選択し、DNNおよびS-NSSAIに対応する加入者データを取得し、セッションポリシーを取得し、UPFへPFCPルールを設定し、gNBと連携してN3トンネルを確立します。手順の完了時には、UEはIPアドレス、QoSルール、およびData Networkまでのユーザープレーン経路を持ちます。
この手順は、単独のNASメッセージとして見るよりも、複数の処理が同時に進むものとして捉えると理解しやすくなります。実際には、セッション管理、ポリシー制御、ユーザープレーンリソース設定の3つが並行して進み、最終的に利用可能なPDU Sessionへ収束します。
PDUセッションと5GS登録の機能上の境界
5GCでは、RegistrationとPDU Sessionの役割は明確に分かれています。前者はネットワークへの登録を確立し、後者はデータ接続を確立します。
RegistrationはUEが5GSへ参加できるかを決定します。AMFはUEの識別情報を確認し、認証を実行し、NASセキュリティを確立し、モビリティ関連の加入者データを取得し、RM（Registration Management）およびCM（Connection Management）に必要なコンテキストを作成します。これらが完了すると、UEとコアネットワークの管理関係が確立します。
PDU Sessionは実際のデータサービスに関係します。UEがインターネットアクセス、IMS接続、企業プライベートネットワークを必要とする場合、Registrationだけでは不十分です。ネットワークはさらに、使用するDNN、適用するS-NSSAI、セッションを制御するSMF、ユーザープレーンを担うUPF、許可されるQoSおよび帯域幅パラメータを決定する必要があります。
EPCと比較すると違いを覚えやすくなります。LTEではPDN ConnectionとEPS Bearerという概念が使われます。5GCではこのモデルがPDU Session + QoS Flowに置き換えられます。PDU Sessionが確立されると、ネットワークはLTE型のDefault EPS Bearerではなく、QoSルールとQoS Flowリソースを作成します。
もう一つ重要なのは、PDU Sessionが初回Registrationと同時に必ず確立されるわけではないという点です。UEはRegistrationを完了した後、アプリケーションが実際にデータ通信を必要とするまでPDU Sessionを持たずに待機できます。たとえば、端末は電源投入時に登録し、ユーザーが30分後に動画アプリを開いた時点で初めてPDU Sessionが作成される場合があります。
この違いはトレース解析で重要です。Registrationが正常に完了しているのにPDU Session Establishmentが完了していない場合、5G-AKA、Registration Accept、T3512を繰り返し確認しても、通常はデータ通信障害の解決にはつながりません。調査対象の手順がずれているためです。
PDUセッション要求に含まれるDNN、S-NSSAI、リクエスト種別
PDU Session Establishmentは、UEが送信するNASメッセージから始まります。PDU Session Establishment Requestは、コアネットワークに単に「データアクセスが必要」と伝えるだけのものではありません。要求に含まれる情報要素は、その後のNF選択やセッション設定に影響します。
一般的な初回要求には、PDU Session ID、Request Type、PDU Session Type、SSC Mode、DNN、S-NSSAIが含まれる場合があります。
PDU Session IDは、同一UEに属する複数のセッションを識別するために使用されます。1台のUEは、たとえばインターネットアクセス用と企業プライベートネットワーク用など、複数のPDU Sessionsを同時に維持できます。SUPIは加入者を識別しますが、それだけでは現在処理中の個別PDU Sessionまでは識別できません。
DNNはUEが到達したいData Networkを識別します。通信事業者のインターネットアクセス、IMS、企業ネットワークでは異なるDNNが使われる場合があります。DNNは後続のSMF選択、UPF選択、ポリシー判断にも関与します。
S-NSSAIはセッションを特定のNetwork Sliceに関連付けます。AMFとSMFは、要求されたスライスがユーザーの加入契約、要求されたDNN、展開済みネットワークの機能と整合するかを判断する必要があります。
Request Typeは要求の文脈を示します。新しいPDU Sessionだけでなく、既存セッション、アクセス変更、緊急サービスのシナリオに関連する場合もあります。したがってトレース解析では、PDU Session Establishment Requestがあるからといって、毎回同じシナリオだと決めつけてはいけません。
最も一般的なのはInitial Requestです。UEはすでにRegistrationを完了しており、特定のDNN向けに新しいPDU Sessionを作成します。SMF選択、UDMからの加入者データ取得、PCFによるポリシー制御、UPFリソース確立は、このセッションコンテキストに基づいて進みます。
AMFによるSMF選択とSM Context作成
UEのNASセッション管理メッセージはまずgNBに到達し、その後NR-CGIやTAIなどのアクセス関連情報とともにNGAP経由でAMFへ転送されます。gNBはPDU Sessionの制御判断を行わず、NAS情報をコアネットワークへ運びます。
要求を受信したAMFは、要求されたS-NSSAIとDNNを提供できるSMFを特定する必要があります。
サービスベースの5GCアーキテクチャでは、AMFはNF DiscoveryのためにNRFを利用できます。検索条件には、対象NFタイプ、必要なNsmf_PDUSessionサービス、S-NSSAI、DNN、Serving PLMNなどが含まれます。NRFが候補SMFインスタンスを返し、その後AMFがネットワークポリシーに従って実際にサービスを担当するSMFを選択します。
次にAMFはSMFのPDU Sessionサービスを呼び出し、SM Contextを作成します。SUPI、PDU Session ID、DNN、S-NSSAIに加えて、UEが送信した元のPDU Session Establishment RequestもN1 SM informationとして要求に含まれます。
ここからセッション制御の中心はAMFからSMFへ移ります。AMFは引き続きアクセスとモビリティを管理し、UEとSMFの間でN1 SMシグナリングを転送しますが、PDU Sessionをどのように作成するか、どのUPFを選択するか、どのポリシーを適用するか、ユーザープレーンルールをどう設定するかはSMFが決定します。
トラブルシューティングでは実装上の違いにも注意が必要です。商用ネットワークで確認できるNRFトランザクション数が、参照シグナリング図と完全に一致するとは限りません。NF Discoveryの結果がキャッシュされている場合、静的設定が使われる場合、SCPがサービスルーティングを提供する場合があります。重要なのは特定のNRFクエリがトレースに存在するかではなく、選択されたSMFが必要なDNN、S-NSSAI、サービス機能を実際にサポートしているかです。
UDM加入者データとPCFセッションポリシー処理
SMFがUEの要求しているセッション種別を把握しても、すぐにユーザープレーンを作成できるわけではありません。まず、その加入者にどのようなPDU Sessionの確立が実際に許可されているかを確認する必要があります。
一般的な手順では、SMFが適切なUDMを特定し、そのSUPIとPDU Sessionを担当するSMFとして自身を登録し、要求されたS-NSSAIとDNNに対応するSession Management Subscription Dataを取得します。
加入者データには、許可されたPDU Session Type、SSC Mode、Session-AMBR、デフォルトQoS関連設定などが含まれる場合があります。これらの値が加入者単位でのセッション上限を定義します。たとえばUEがIPv4 PDU Sessionを要求した場合でも、SMFはそのDNNで該当PDU Session Typeが許可されているか、要求されたSSC Modeが許可されているかを確認する必要があります。
SMFはSM加入者データの変更を購読することもできます。関連するセッション管理の加入者情報が後からUDMで変更された場合、UDMは登録済みのCallback URIを使用して担当SMFへ通知できます。
動的なSM Policy Controlを使用する構成では、SMFがPCFを選択し、SM Policy Associationを確立します。SMFはSUPI、PDU Session ID、DNN、S-NSSAI、UE位置、加入済みQoSパラメータなどのコンテキストを提供します。PCFは認可されたセッションポリシーを返し、そこにはSession-AMBR、デフォルトQoS、その他適用されるポリシールールが含まれる場合があります。
この段階は、セッションパラメータが集約される過程として捉えられます。
UEのサービス要求 → UDMの加入者制限 → PCFのポリシー認可 → SMFが最終的なセッション制御パラメータを決定
後の段階でUPFに設定されるQoSルールや転送ルールは、これらの結果に基づきます。
N4セッション確立とUPFへのユーザープレーンルール設定
セッションパラメータが決まると、SMFは要求されたDNN、S-NSSAI、UE位置を提供できるUPFを選択し、N4インターフェース上でPFCP Sessionを確立します。
PFCP Session Establishment Requestは、PDU Session Establishment手順の中でも特に重要なポイントです。ここまではネットワークが主に抽象的なサービス要件を扱ってきました。N4では、それらの要件が実際のユーザーパケットに対してUPFが実行できるルールへ変換されます。
SMFはUPFにPDR、FAR、QER、URRルールを設定できます。
PDR：そのPDU Sessionまたは特定のトラフィックフローに属するパケットをUPFがどのように識別するかを定義します。
FAR：一致したパケットに対して、転送、破棄、バッファリングなど、どの処理を行うかを定義します。
QER：UPFで必要なQoS制御を適用します。
URR：ユーザープレーンの利用量測定とレポート要件を定義します。
これらのルールは互いに無関係な4機能として扱うべきではありません。組み合わせることでUPFのトラフィック処理を定義します。PDRがパケットフローを識別し、適用するFAR、QER、URRを参照することで、UPFはパケットの転送先、適用するQoS制御、利用量測定の要否を判断できます。
UPFがPFCP Session Establishmentを受け入れると、自身のF-SEIDと作成したユーザープレーンパラメータを返します。特に重要なのが、N3で使用するUPF側ユーザープレーンアドレスとTEIDです。
ただし、この時点ではgNB側のN3リソース割り当てがまだ完了していないため、ダウンリンク経路が完成していない場合があります。そのためPDU Session Establishmentは1回のPFCP要求では完了せず、RAN側のユーザープレーン設定が終わるまで処理が続きます。
N1/N2シグナリングによるN3トンネルとQoS Flow設定の完了
UPF側のリソースが準備されると、SMFはAMFを介して2種類の情報を返す必要があります。
1つ目はN1 SM informationで、最終的にUEへ届けられます。PDU Session Establishment Acceptに加えて、セッション確立後にUEが必要とするPDU Session Type、SSC Mode、DNN、S-NSSAI、UEのIPアドレス、Session-AMBR、デフォルトQoS Ruleなどが含まれます。
2つ目はN2 SM informationで、gNB向けの情報です。RANに対して、どのPDU Sessionを作成するか、どのQoS Flowsが関係するか、N3でどのUPF IPアドレスとTEIDを使うかを通知します。
AMFはNGAPを介してgNBへPDU Session Resource Setup Requestを送信します。gNBは必要な無線リソースとN3リソースを割り当て、PDU Session Establishment AcceptをUEへ転送します。
リソース設定後、gNBはPDU Session Resource Setup Responseを返します。この応答にはgNB自身のN3ユーザープレーンアドレスとTEID、正常に確立されたQoS Flowsの情報が含まれます。
ここには重要なタイミング上のポイントがあります。SMFが最初にPFCP Sessionを確立した時点では、UPF側のN3情報はすでに分かっていますが、最終的なgNB側トンネル情報はまだ分からないことがあります。gNBがN3アドレスとTEIDを返すと、AMFがその情報をSMFへ転送します。その後SMFはPFCP Session Modificationを使ってUPF内の該当FARを更新し、ダウンリンクパケットをgNB向けの正しいGTP-Uトンネルへカプセル化できるようにします。
この時点で、アップリンクとダウンリンクのユーザープレーン経路が完成します。
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
したがって、PDU Session Establishment Acceptを受信しただけでは、ユーザープレーンのすべての要素が正しいことの証明にはなりません。N3トンネルパラメータ、PFCP Session Modification、最終的なUPFルールを、実際のパケット転送と照合して確認する必要があります。
PDUセッション確立時のシグナリングトラブルシューティング
PDU Session Establishmentには多数のネットワーク機能が関係します。最初のパケットからすべてのメッセージを順番に比較して障害解析しようとすると、すぐに複雑になります。より効率的なのは、処理をいくつかのチェックポイントに分け、障害範囲を段階的に絞り込む方法です。
セッション要求がAMFへ正しく到達しているか確認する
まずUEが必要な5GS Registrationを完了していることを確認します。次にPDU Session Establishment Requestを調べ、PDU Session ID、Request Type、DNN、S-NSSAI、PDU Session Type、SSC Modeが適切か確認します。入口の段階ですでに無効なパラメータが含まれている場合、SMFやUPFが正常でも期待したセッションは作成できません。
SMFが有効なSM Contextを作成しているか確認する
次に、AMFが適切なSMFを選択し、Create SM Contextが成功していることを確認します。目的は単にトレース内でNRFメッセージを見つけることではなく、選択されたSMFが必要なDNN、S-NSSAI、サービス機能をサポートしていることを確認することです。
さらに、UDMから返されたSM加入者データで要求したPDU Sessionが許可されているか、PCFポリシーが想定するQoS設定と整合しているかを確認します。
UPFとN3のリソースが完全か確認する
コントロールプレーンがすでにPDU Session Establishment Acceptを返しているにもかかわらずUEがデータを通せない場合は、調査対象をN4とN3へ移します。
次の順序で確認します。
PFCP Session Establishmentが成功し、UPFに対応するセッションが作成されているか。
PDR、FAR、QERなどのルールが想定するトラフィック方向と一致しているか。
gNBがN3ユーザープレーンIPアドレスとTEIDを正常に返しているか。
SMFがPFCP Session Modificationを介してgNBのトンネル情報をUPFへ更新しているか。
想定したTEIDを使用するGTP-Uパケットが実際にN3上へ出ているか。
UPFがN6を介して対象Data Networkとの間で正常にトラフィックを送受信できるか。
この順序で確認すれば、5GC全体を一つの曖昧な障害範囲として扱うのではなく、問題をNAS、SBI、N4、N3、またはUPFのパケット転送まで段階的に絞り込めます。
よくある質問
UEが5G登録を完了してもインターネットへアクセスできないのはなぜですか？
RegistrationはUEと5GCの間にアクセス、識別、セキュリティ、モビリティのコンテキストを確立しますが、ユーザーデータ経路を自動的に作成するわけではありません。UEがインターネットや他のData Networkへアクセスするには、SMFがセッションパラメータ、UPFリソース、N3ユーザープレーンを設定するためのPDU Sessionが必要です。
UEの電源投入時にPDU Sessionは必ず確立されますか？
いいえ。PDU SessionはRegistrationの前後で確立される場合もあれば、UEが実際にデータサービスを必要とする時点で後から開始される場合もあります。5GSではUEがアクティブなPDU Sessionを持たないまま登録状態を維持できるため、Registration完了とPDU Session Establishmentを同一イベントとして扱うべきではありません。
PDU Session Establishmentの成功はUEがインターネットへアクセスできることを保証しますか？
いいえ。NASレイヤーでPDU Session Establishment Acceptを受信しただけでは、データ接続が成功した証拠としては不十分です。実際のユーザートラフィックは、gNBとUPF間のN3トンネル、UPF内のPDR/FAR/QERルール、N6接続、対象Data Networkにも依存します。UEがIPアドレスを取得していても、ユーザープレーン転送が誤っている場合があります。
PFCP Session Establishmentの後にPFCP Session Modificationが行われるのはなぜですか？
UPFに最初のPFCP Sessionを作成する時点では、gNBがまだN3リソースの割り当てを完了していない場合があり、SMFは最終的なgNBユーザープレーンIPアドレスとTEIDをまだ把握できないことがあります。gNBがPDU Session Resource Setup Responseでこれらの値を返した後、SMFはPFCP Session Modificationを介して対応するUPFルールを更新し、ダウンリンクトラフィックを正しいN3 GTP-Uトンネルへ送信できるようにします。
PDU SessionのQFIとN4インターフェースのQERは同じ概念ですか？
いいえ。QFIは5GS内のQoS Flowを識別する値であり、QERはSMFがN4を介してUPFに設定するQoS Enforcement Ruleです。QERはQoS適用に使用され、必要に応じてQFIと関連付けられますが、QFI自体がQERというわけではなく、両者を同一の概念として扱うことはできません。
