このUEはどの加入者に属しているのか？
現在のネットワークへのアクセスは許可されているのか？
再利用できる以前のモビリティ・コンテキストは残っているのか？
どのネットワークスライスとアクセス能力を契約しており、どのAMFがこのUEを担当すべきなのか？
5G端末の電源が入ると、ユーザーデータサービスを確立する前に、コアネットワークはこれらの基本的な問いに答える必要があります。これを処理するのが5G初期登録です。シグナリングトレースの観点では、この手順は単なる「登録要求を送り、登録が成功する」という流れではありません。UEがRegistration Requestを送信してから最終的にRegistration Completeを返すまでの間に、ネットワークは識別情報の処理、旧AMFコンテキストの取得、5G-AKA認証、NASセキュリティの確立、UDM登録、加入者データの取得、アクセス・ポリシー処理などを実行する場合があります。
この手順を学ぶ際によくある誤りは、すべてのメッセージを順番どおりに暗記しようとすることです。より実践的なのは、各段階でAMFが何を解決しようとしているかを見ることです。シグナリング全体は、要求元UEを識別し、信頼できるアイデンティティを確立し、必要な加入者コンテキストを完成させ、その後に登録を完了する流れとして理解できます。
初期登録はUEがネットワークへアクセスする権利を確立する
5GSの登録は単一の手順ではありません。トリガーに応じて、UEはInitial Registration、Mobility Registration Update、Periodic Registration Update、またはEmergency Registrationを実行します。UEはRegistration Request内の5GS registration typeフィールドによって、該当する手順を示します。
Initial Registrationは通常、UEの電源投入後に5GSへ入るときに行われます。学習上はLTE/EPCのAttach手順と比較されることがありますが、両者を同一視すべきではありません。5G Coreのサービスベース・アーキテクチャでは、モビリティ管理、認証、加入者データ、ポリシー制御がAMF、AUSF、UDM、PCFなどのネットワーク機能に分散されています。そのため、1回の登録手順の中で複数のネットワーク機能間のサービスベース通信が発生することがあります。
さらに重要なのは、Initial Registrationが主に確立するのはアクセスおよびモビリティ管理の状態であり、ユーザーデータセッションではないことです。ネットワークはUEを識別し、モビリティ・コンテキストを作成し、許可されるNSSAIと適用されるエリア制限を決定し、後続シグナリングに必要なセキュリティ関係を確立する必要があります。これらが整って初めて、UEはPDU Sessionを要求するための前提を得ます。
したがって、Registration Acceptを受信したからといって、加入者がすでにインターネットへアクセスできるとは限りません。登録とPDU Session確立は、5G Coreでは別々の段階です。
Registration RequestがUEを5G Coreの登録処理へ導く
コアネットワークの登録手順はNAS Registration Requestから始まります。UEはまず無線インターフェースを介してNASメッセージをgNBへ送信し、gNBはNGAP Initial UE Messageの中にNAS-PDUを格納してAMFへ転送します。コアネットワークのエンジニアにとって、このメッセージが登録手順全体の入口です。
Initial UE MessageはRegistration Requestを運ぶだけでなく、NR-CGIやTAIなどのアクセス位置情報もAMFに提供します。NASメッセージ自体には、5GS registration type、5GS mobile identity、UE Security Capability、Requested NSSAIなどのパラメータが含まれる場合があります。
これらは単なるUE能力の一覧ではありません。AMFはそれらを使って登録をどのように進めるか判断します。Registration TypeはUEがInitial Registrationを実行しているのか、別の登録更新なのかを示します。mobile identityは既存の加入者コンテキストをUEに関連付けられるかを判断する材料になります。Requested NSSAIはUEが要求するネットワークスライスを示し、UE Security Capabilityは後続のNASセキュリティ・アルゴリズム選択に使用されます。
誤解されやすい点があります。Initial Registrationを実行するUEが、以前の5G情報を一切持っていないとは限りません。UEが以前に割り当てられた5G-GUTIを保持している場合、新しいInitial Registration Requestにその識別子を含めることがあります。その識別子に関連する情報をネットワークが再利用できるかどうかで、その後の手順が変わります。
新しいAMFがUEの識別情報と以前のコンテキストを解決する
あるUEが以前、広州の5GSに登録されていたとします。その後電源を切って北京へ移動し、北京のgNB経由で再び電源を入れました。現在は新しいAMFがUEを担当していますが、UEには広州のAMFから以前割り当てられた5G-GUTIが残っている可能性があります。
5G-GUTIに含まれるGUAMIは、以前のAMFを特定するための情報を提供できます。新しいAMFが旧ネットワーク機能に有用なUEコンテキストが残っていると判断した場合、AMF間通信によってUE Context Transferを要求し、SUPI、GPSI、PEIやモビリティ管理コンテキストの一部などを取得できます。
ここで重要なのは、「Initial」は現在の登録手順の種類を表すのであり、その加入者が初めて5Gネットワークに入ることを意味しないという点です。UEは以前に割り当てられた5G識別子を保持している可能性があり、新しいAMFは旧AMFのコンテキストを再利用できる場合があります。
すべてのInitial Registrationで旧AMFとの通信が必要になるわけではありません。新しいAMFが必要な識別情報をすでに持っている場合や、利用できる以前のUEコンテキストが存在しない場合は、シグナリング経路が異なります。AMFがUEのSUCIを必要とする場合はIdentity Requestを送信し、UEはIdentity Responseで要求された識別情報を返します。
そのため、パケットトレースにIdentity RequestやUE Context Transferが存在しないことだけで、登録失敗とは判断できません。まず確認すべきなのは、AMFがすでにどの識別情報とコンテキスト情報を持っているかです。
5G-AKAが申告された識別情報を信頼できる加入者へと変える
UEが誰であると名乗っているかを知るだけでは、ネットワークはそのUEを信頼できません。そこで手順は、最も重要なセキュリティ段階の一つである認証へ進みます。
AMFは加入者を認証できるAUSFを特定する必要があります。サービスベースの5G Coreでは、通常NRFを介したネットワーク機能探索が関与します。AMFは必要なサービスと加入者関連情報に基づいて適切なAUSFインスタンスを選択し、認証要求を送信します。
AUSFはその後、ホームネットワークのUDMに関連する認証機能と連携します。SUCIを使用する場合、ホームネットワークは対応するSUPIを復元し、5G-AKAに必要な認証データを準備できます。続いてAMFはNAS Authentication RequestでRANDやAUTNなどのパラメータをUEへ送信します。UEはUSIMに保存された認証情報を使用して認証計算を行い、RES*を含むAuthentication Responseを返します。
認証は、一つのネットワーク機能が一度だけ比較して終わる処理ではありません。サービングネットワーク側とホームネットワーク側がそれぞれ検証を行います。AMFはUEから受信した応答からHRES*を導出し、HXRES*と比較します。AUSFは返されたRES*を期待値XRES*と照合します。必要な検証が成功して初めて、ネットワークは加入者識別情報が認証されたと判断します。
認証後、ネットワークは通常NAS Security Contextを確立または更新します。AMFはUE Security Capabilityなどの情報に基づいて適切な完全性保護および暗号化アルゴリズムを選択し、Security Mode手順によって後続の重要なNASシグナリングを保護します。
エンジニアリングの観点では、この段階が明確なセキュリティ境界になります。認証前、ネットワークが扱っているのはアクセスを要求する端末です。認証とNASセキュリティが正常に確立された後、AMFは信頼され保護されたUE制御プレーン・コンテキストを持つことになります。
加入者データとポリシーデータがUEコンテキストを完成させる
認証が成功すると「加入者の識別情報は本物か」という問いには答えられます。しかしAMFは、その加入者が実際にネットワーク内で何を許可されているかも知る必要があります。次の段階では、認証済みの識別情報を、実際に利用できるアクセスおよびモビリティ・コンテキストへと仕上げます。
AMFは適切なUDMを選択し、3GPPアクセスにおいて現在そのSUPIを担当するAMFとして自身を登録します。この登録は重要です。UDMは、その加入者に関する今後のモビリティ通知、登録解除イベント、加入者データ変更をどのAMFへ送るべきか把握しておく必要があるからです。
次にAMFはAccess and Mobility Subscription Dataを取得します。加入者プロファイルに応じて、Subscribed NSSAI、UE-AMBR、周期登録パラメータ、RAT制限、エリア制限などが含まれます。認証が「識別情報が正しいか」を確認するのに対し、加入者データは別の問い、すなわちこの正当な加入者が現在のネットワークで何を許可されているかに答えます。
AMFは、後のSMF選択に使う加入者データを取得する場合もあります。これにはS-NSSAI、DNN、デフォルトDNNに関連する情報が含まれます。シグナリングトレースではここが混乱しやすい点です。登録中にすでにSMF Selection Subscription Dataが現れているなら、SMFはすでにこの手順に参加しているのでしょうか。
必ずしもそうではありません。この段階でAMFが取得しているのは、将来のSMF選択で必要になる可能性がある情報だけです。Initial Registrationでは同時にPDU Sessionを確立する必要はないため、AMFはSM Contextを作成したり、実際のSMFのセッション管理手順を開始したりせずに、この加入者データを取得できます。
アクセス・ポリシーについては、AMFがPCFを選択してAM Policy Associationを確立する場合もあります。PCFから返されるポリシーは、特定エリアのアクセス制限などに影響します。この時点でAMFが保持するUEコンテキストは、単純な識別情報から、識別、セキュリティ、加入、スライス、位置、ポリシー情報を組み合わせた状態へ発展しています。
Registration Acceptが登録結果をUEとgNBへ反映する
ここまでの処理の大半はコアネットワーク内部で行われますが、最終結果はアクセスネットワークとUEへ届ける必要があります。必要な条件が満たされると、AMFはgNBへInitial Context Setup Requestを送信し、UEコンテキストの確立に必要な情報を渡すとともに、NAS Registration AcceptをUEへ配送します。
Registration Acceptには、新しく割り当てられた5G-GUTI、Allowed NSSAI、周期登録タイマーT3512、適用されるTracking Areaリストなどが含まれる場合があります。これらのパラメータは、UEが5GSでどのように登録状態を維持するか、現在どのスライスを使用できるか、そして後でいつPeriodic Registration Updateを行う必要があるかを決定します。
同時に、gNBはInitial Context Setup手順で対応するUEコンテキストを確立します。処理を完了すると、gNBはInitial Context Setup Responseを返します。その後UEはNAS Registration CompleteをAMFへ送信し、登録結果を確認します。
したがって、Registration AcceptとRegistration Completeは単なる成功通知ではありません。コアネットワーク内部で作られた登録結果をUEとRANの両方へ反映し、ネットワーク、gNB、端末を整合した5GS登録状態にします。
登録とPDU Session確立は別々のシグナリング経路である
シグナリング全体を解析するとき、この区別は非常に重要です。5GS Initial Registrationが完了すると、AMFは加入者が誰か、UEがどこにいるか、どのアクセスエリアとスライスが許可されているか、どのセキュリティおよびモビリティ・コンテキストが適用されるかを把握しています。しかし、これらの処理だけではユーザープレーンのデータ経路は自動的に確立されません。
インターネットや企業データネットワークへアクセスするには、UEはさらにPDU Session Establishmentを実行する必要があります。この段階でSMFがセッション管理を担当し、UPFを選択または制御し、N4経由でPDR、FAR、QER、URRなどのユーザープレーン・ルールを設定します。gNBとUPFの間のN3リソースも、セッション確立処理の一部として準備されます。
運用時のトラブルシューティングでは、ここから二つのまったく異なる障害カテゴリが生まれます。
登録失敗：UEの識別情報、認証、NASセキュリティ、UDM加入者データ、NSSAI、エリア制限、AMFのポリシー処理を確認します。
登録は成功しているがデータサービスが動作しない：Registration RequestやRegistration Acceptを繰り返し確認するのではなく、PDU Session確立、SMF、UPF、N3/N4シグナリング、ユーザープレーン転送へ調査対象を移します。
この境界を明確にすると、5GCのトラブルシューティング時間を大幅に短縮できます。端末に5G表示が出ていることは、無線アクセスと登録が一定の状態まで進んだことを示すだけです。実際のデータ接続が確立されているかどうかは、セッション管理とユーザープレーンの手順に依存します。
トレースはメッセージ一覧ではなく状態遷移として読む
標準のシグナリング図は、異なる事業者、ローミングシナリオ、アクセス方式、オプションのネットワーク機能を網羅するため、意図的に包括的に作られています。しかし実ネットワークのトレースに、参照手順のすべてのステップが必ず現れるわけではありません。旧AMFとの通信がない場合も、Identity Requestが不要な場合も、EIRを使用しない場合もあります。また通常のNRアクセス手順には、他のアクセス方式だけに適用されるネットワーク機能は含まれません。
Initial Registrationをトラブルシューティングする際は、UEの状態がどのように変化するかを追う方が有効です。
Registration RequestがAMFに到達
→ UEの識別情報と以前のコンテキストを解決
→ 認証とNASセキュリティを確立
→ UDMから加入者データを取得
→ PCFから適用されるアクセス・ポリシーを取得
→ AMFが登録コンテキストを完成
→ Registration Acceptを配送
→ UEがRegistration Completeを返送
Registration RequestがAMFへ到達しているのに認証が開始されない場合は、まず識別情報処理とネットワーク機能選択を確認します。認証が成功しているのにRegistration Acceptが返らない場合は、UDMデータ、NSSAI、アクセス制限、ポリシー処理を続けて確認します。Registration Acceptまで完了していてユーザーデータだけが動作しない場合は、速やかにPDU Sessionのシグナリング経路へ調査を移すべきです。
5G Initial Registrationを理解するうえで重要なのは、何十ものメッセージを暗記することではなく、AMF内のUEコンテキストがどのように段階的に完成していくかを追うことです。アクセス要求を受け取り、加入者が誰かを把握し、その識別情報が信頼できることを証明し、最後にその加入者がどの条件で5GSに登録し続けられるかを確定するという流れです。
よくある質問
Registration Accept内のT3512は何をするのですか？
T3512は登録後のUEの周期登録更新動作を制御します。UEが定期的なモビリティ管理のやり取りなしに無期限に登録状態を維持するわけではありません。ネットワークはこのタイマーを使って、UEがPeriodic Registration Updateを実行すべきタイミングを定義できます。
一部の商用5G登録トレースでEIRが見当たらないのはなぜですか？
端末識別情報の確認はオプションです。EIRを配備するかどうか、またどの条件で端末識別情報チェックを実行するかは、事業者のアーキテクチャと運用ポリシーによって異なります。そのため、それ以外は正常なInitial RegistrationでEIRシグナリングがないことだけでは、障害の根拠にはなりません。
標準的な5G NR登録でN3IWFが通常現れないのはなぜですか？
N3IWFは主に、5G Coreへの一部のWi-Fiアクセスなど、信頼されていないnon-3GPPアクセスで使用されます。UEが標準の3GPP NRアクセスを使ってgNBへ直接接続する場合、アクセス経路はNG-RANが提供するため、N3IWFは通常登録シグナリングには含まれません。
ベンダーごとのトレースでNRF経由のネットワーク機能探索の回数が異なるのはなぜですか？
実際の5G Core実装では、ネットワーク機能探索のキャッシュ、静的設定、SCPの配備モデル、ベンダー固有のサービスルーティング動作によって差が生じます。そのため、すべてのサービス操作の前に完全なNRF経由のネットワーク機能探索が現れる必要はありません。トレース解析では、NRFメッセージの数だけで手順を判断するのではなく、選択されたNFインスタンスと後続のサービス要求を対応付けて確認する必要があります。
