Registration RequestがすでにAMFへ到達しているのに、なぜ登録処理の途中でServing AMFを変更する必要があるのでしょうか。これはgNBが最初に誤ったAMFを選択したという意味でしょうか。UEがRegistration RequestにRequested NSSAIを含めていない場合、ネットワークはどの時点でUEが本当に必要とするネットワークスライスを判断できるのでしょうか。これらの疑問は、5GC Initial Registrationの特殊な分岐であるAMF再割り当てに関係します。エンジニアリングの現場では「AMF再選択」と呼ばれることもありますが、3GPPの手順としては、登録中にAMFを再割り当てする処理と捉える方が正確です。
AMF再割り当てと通常のInitial Registrationの本質的な違いは、追加の認証処理が行われることでも、負荷分散を目的としてAMFが変更されることでもありません。Initial AMFがより完全な加入者情報とスライス情報を取得し、UEが最終的に必要とするS-NSSAIを自身では提供できないと判断したうえで、適切なAMFサービス範囲を特定するためにNSSFを呼び出し、進行中の登録手順をTarget AMFへ引き継ぎます。
このシグナリングフローを理解するうえで重要なのは、AMFが何番目のステップで変わるかを暗記することではありません。gNBが最初にAMFを選ぶ時点で何の情報を持っているのか、Initial AMFが登録処理中にどのような追加情報を得るのか、そしてNSSFが最終的にどの条件を使ってUEを新しいServing AMFへ導くのか、という3つの判断点を順に追うことが有効です。
AMF再割り当てはいつ発生するのか
AMF再割り当てを伴うInitial Registrationは、すべての5GC登録で使用される標準経路ではありません。発生条件は明確で、Network Slicingが導入されており、最初にRegistration Requestを受信したAMFが、UEが最終的に必要とするネットワークスライスを提供できない場合です。
通常の登録では、gNBが選択したInitial AMFが必要なS-NSSAIをすでにサポートしています。そのため、識別情報の処理、認証、加入者データの取得、Registration Acceptまでを同じAMF上で継続できます。
再割り当てが必要になるのは、後の処理で得られた情報から、現在のAMFがUEに許可されたスライス、または既定で利用すべきスライスと一致しないことが判明した場合だけです。処理の流れは次のように整理できます。
Registration RequestがInitial AMFへ到達
→ Initial AMFが必要な登録処理を実行
→ UEの完全な加入者情報とスライス情報を取得
→ Initial AMFが対象S-NSSAIを提供できないと判断
→ NSSFを呼び出して適切なサービス範囲を決定
→ 登録処理をTarget AMFへ移管
よくある誤解として、同じ登録トレースに2つのAMFが現れたからといって、元のAMFが障害を起こした、あるいはAMF Pool内で負荷分散が行われたとは限りません。この手順で実際のトリガーとなるのは、現在のAMFが持つスライス提供能力と、UEが最終的に必要とするネットワークスライスが一致しないことです。
なぜgNBは最初に不適切なAMFを選択することがあるのか
AMF再割り当てを初めて見ると、gNBの選択ミスだと考えがちです。異なるAMFが異なるスライスを担当しているのであれば、なぜRANは最初からUEを正しいAMFへ送らないのでしょうか。
主な理由は、gNBが最初にAMFを選択する時点で十分な情報を持っていない可能性があるためです。2つのネットワークスライスを契約した5G USIMを搭載するコネクテッドカーが、初めて電源を入れるケースを考えてみます。
eMBBスライス（S-NSSAI1）：車載インフォテインメントや一般的なデータサービスに使用。
V2Xスライス（S-NSSAI3）：V2X（車両と周辺との通信）や自動運転関連サービスに使用。
加入者のDefault S-NSSAIがV2Xスライスである一方、UEは初めて5GSへ接続し、有効な5G-GUTIを持たず、Registration RequestにもRequested NSSAIを含めていないとします。この時点では、最終的にV2Xスライスに対応するAMFがUEを担当すべきだとgNBが直接判断できる材料はありません。
通常、gNBはAMFを選択する際に、GUAMI、UEが要求したS-NSSAI、ローカルのAMF設定などを利用できます。しかしこのケースではGUAMIもRequested NSSAIも利用できないため、gNBは現時点で持っている情報とローカルの既定選択ポリシーだけを使ってInitial AMFを選ぶことになります。
gNBが最初にeMBBスライスを担当するAMF1を選択した場合、Registration RequestはNGAP Initial UE Messageに含まれてAMF1へ送られます。
このAMFがUEの最終的なスライス要件と一致しないからといって、必ずしもgNBの設定誤りではありません。より正確には、最初のAMF選択時点では、RANにはUEの最終的なスライスに対応するAMFを判断するための情報がまだ不足しているということです。
Initial AMFはどのようにスライス不一致を検出するのか
Registration RequestがInitial AMFへ到達しても、AMFはただちにNSSFへ問い合わせるわけではありません。この段階では、自身が最終的に適切なServing AMFかどうかを判断するための加入者情報がまだ不足しています。
まずAMFは通常のInitial Registrationの流れに従い、UEの識別情報処理、AUSF選択、5G-AKA Authentication、関連するNASセキュリティ処理など、必要な手順を実行します。
この段階の重要な結果の一つは、AMFがUEの識別情報を確認しSUPIを取得することです。SUPIが得られると、Initial AMFは適切なUDMを特定し、UEのAccess and Mobility Subscription Dataを取得できます。
この時点で、ネットワークはRegistration Requestが最初に届いたときよりもはるかに多くの情報を持っています。UDMから返される加入者データには、Subscribed NSSAIやDefault S-NSSAIが含まれる場合があります。
コネクテッドカーの例を続けると、Initial AMFはeMBBサービス領域に属していますが、加入者データを見るとUEはeMBBとV2Xの両方を契約しており、Default S-NSSAIはV2X、つまりS-NSSAI3を指しています。
ここでInitial AMFは、先ほどgNBにはできなかった判断を行えます。Initial Registrationを受信して処理を開始することはできたものの、UEの既定V2Xスライスを継続的に提供するAMFとしては適切ではありません。この判断がAMF再割り当てのトリガーになります。
gNB段階：利用できるのは限定的なアクセス情報のみ
→ Initial AMF段階：UEの識別情報を確認
→ UDM段階：実際に契約されているNSSAI情報を取得
→ 現在のAMFが対象スライスと互換性を持たないことを確認
したがってAMF再割り当ては、登録途中で恣意的に判断を変える処理ではありません。加入者の識別情報とスライス情報が揃ったことで、コアネットワークがより正確なServing AMFを選べるようになった結果です。
NSSFはどのように新しいServing AMFを特定するのか
Initial AMFが対象スライスを提供できないと判断しても、自分で別のAMFを適当に選ぶわけではありません。Network Slice Selection Function、つまりNSSFを呼び出します。
Initial AMFはNnssf_NSSelectionサービスを使用してNetwork Slice Selectionを要求します。入力にはUEが契約しているS-NSSAI、現在のAMFに関する情報、UEの現在のTAIなどを含めることができます。目的は、現在の登録エリアで許可されるスライスと、どのAMFセットがサービスを提供すべきかを判断することです。
NSSFから返されるAuthorized Network Slice Informationには、次の情報が含まれる場合があります。
Allowed NSSAI：現在の条件でUEが利用を許可されているネットワークスライス。
Configured NSSAI：必要に応じてUEへ提供できるスライス設定。
Target AMF Set：該当するネットワークスライスを提供できるAMFの集合。
Rejected NSSAI：現在のTAまたは関連条件では受け入れられないスライス。
Target AMF SetとTarget AMFは区別する必要があります。NSSFの最初の役割は、どのAMFセットが適切かを判断することです。つまり、特定のAMFのアドレスを直接返すのではなく、スライス条件と位置条件に基づいて候補範囲を絞り込みます。
Target AMF Setを取得した後、Initial AMFはNRFに登録されたNFインスタンス情報を利用し、そのセット内のAMFのアドレス、能力、重み、稼働状態を取得できます。そのうえで、どのTarget AMFがRegistrationを引き継ぐかを決定します。
各ネットワーク機能の関係は次のように整理できます。
UDM：UEのスライス契約情報を提供
→ Initial AMF：自身のサービス能力が要件と一致しないと判断
→ NSSF：許可スライスとTarget AMF Setを決定
→ NRF：セット内で利用可能なAMFインスタンス情報を提供
→ Initial AMF：Target AMFを選択
この手順におけるNSSFの役割は、一般的な負荷分散ではありません。スライス要件を、その要件に対応できるAMFサービス範囲へ対応付けることです。
Registration RequestはどのようにTarget AMFへ転送されるのか
Target AMFが決まった後、UEが完全に新しいRegistration Requestを送り直す必要はありません。ネットワークは、すでに進行中の登録手順と必要なコンテキストを新しいAMFへ移し、処理を継続させます。
転送方法は2種類あります。gNBを経由する間接転送と、Initial AMFからTarget AMFへの直接転送です。
gNBを経由する間接転送
間接転送では、Initial AMFがgNBへNGAP Reroute NAS Requestを送信します。このメッセージには元のInitial UE Messageに関連する情報とTarget AMF Set IDが含まれ、NG-RANに対して現在のNAS Registrationメッセージを再ルーティングするよう指示します。
その後gNBは、元のRegistration Request NAS-PDUを含む新しいInitial UE MessageをTarget AMFへ送信します。制御プレーン上の経路は次のように表せます。
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
UEがRRCアクセスをやり直す必要はありません。NG-RANは既存のRegistration NASメッセージを適切なAMFへ再ルーティングするだけです。
AMF間の直接転送
直接転送では、Initial AMFはメッセージをgNBへ戻しません。代わりに、5GCのサービスベースインターフェースを介してN1メッセージとRegistration ContextをTarget AMFへ直接転送します。
Initial AMFはNamf_Communication_N1MessageNotifyを呼び出し、完全なRegistration RequestとRegistration Context ContainerをTarget AMFへ送信します。
転送される情報は1つのNASメッセージだけではありません。Registration Contextには、UE Context、Access Type、gNB情報、User Location、Allowed NSSAI、Configured NSSAI、Rejected NSSAIのほか、登録処理を継続するために必要な情報を含めることができます。
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
シグナリング経路は異なりますが、目的は同じです。Target AMFが、Initial Registration全体を最初からやり直すことなくRegistrationを継続するために必要なNASメッセージとコンテキストを受け取ることです。
引き継ぎ後、Target AMFは残りの登録処理を完了し、UEへRegistration Acceptを返します。この応答にはスライス選択とAMF再割り当ての結果が反映され、Allowed NSSAI、Configured NSSAI、Rejected NSSAI、新たに割り当てられた5G-GUTIなどが含まれる場合があります。
UEから見て重要なのは登録が正常に完了し、現在のエリアで利用可能なスライスと新しい5GSモビリティコンテキストがネットワークから提供されることです。内部でServing AMFが変更されたことは、UEにはほぼ透過的です。
シグナリングトレースでAMF再割り当てを確認する方法
AMF再割り当てを伴うInitial Registrationは、異常な登録ルーティングや最初のAMF選択失敗と誤認されやすい処理です。効果的なトラブルシューティングでは、メッセージ番号を一つずつ比較するよりも、スライスの決定とコンテキスト転送という2つの流れを追います。
正常なシグナリングシーケンスであれば、エンジニアは次の質問に答えられるはずです。
なぜRegistration Requestは最初にこのInitial AMFへ到達したのか？
→ Initial AMFはUEのSubscribed / Default NSSAIをどこから取得したのか？
→ 何が原因でAMFはUEへのサービスを継続できないと判断したのか？
→ NSSFはどのTarget AMF Setを返したのか？
→ 最終的にどのTarget AMFが選択されたのか？
→ Registration Contextはどの経路で転送されたのか？
Initial AMFがスライス契約情報をすでに取得し、自身ではUEへのサービスを継続できないと判断しているのにNSSF選択手順が続かない場合は、NSSF Discovery、Nnssf_NSSelection要求、および関連するスライス設定を確認します。
NSSFがTarget AMF Setを返しているにもかかわらず、具体的なTarget AMFを特定できない場合は、AMF Set設定、NRF内のNF Profiles、AMFインスタンスの状態と能力情報を確認します。
NGAP Reroute NAS Requestが存在するのにTarget AMFが新しいInitial UE Messageを受信していない場合、トラブルシューティングの焦点はスライス選択から、gNBでのNAS再ルーティングとTarget AMFまでのN2到達性へ移ります。
直接転送が使用されている場合は、その経路には現れないReroute NAS Requestを待つのではなく、Namf_Communication_N1MessageNotifyとRegistration Contextをトレース上で確認します。
手順全体を見ると、AMF再割り当ては明確な問題を解決しています。最初のAMF選択時には情報が不完全であり、その後コアネットワークが完全な加入者識別情報とスライス契約情報を取得してから、Serving AMFの選択を修正します。
UEが最初にネットワークへ入る時点では、gNBが持つのは限定的なGUAMI情報、Requested NSSAI情報、または既定のAMF設定だけかもしれません。認証と加入者情報取得が完了すると、5GCはようやく加入者がどのスライスを利用できるか判断できます。NSSFはそのSlice RequirementをTarget AMF Setへ変換し、NRFはRegistrationを継続できる実際のAMFインスタンスを特定するのに役立ちます。
したがって、このシグナリングフローを分析する際に最も有効な問いは、「なぜ登録途中でAMFが変わったのか」ではなく、ネットワークはどの時点で、どのAMFがUEを継続して担当すべきか判断するために十分な情報を得たのかということです。
よくある質問
AMF再割り当てはAMF Poolの負荷分散と同じか
いいえ。AMF Poolの負荷分散は通常、複数のAMFインスタンス間の容量、重み付け、高可用性分散を重視します。一方、この手順のAMF再割り当ては、Initial AMFがUEの最終的に必要とするネットワークスライスを提供できないことが原因です。どちらも結果的に別のServing AMFを使用する可能性がありますが、トリガー条件とシグナリングロジックは根本的に異なります。
Network Slicing環境では必ずNSSF選択とAMF再割り当てが必要か
いいえ。Network Slicingが導入されていても、gNBが最初に選択したAMFがUEの最終的に必要なスライスをすでに提供できる場合、AMF再割り当ては不要です。再割り当ては登録処理の条件分岐であり、すべてのスライスを利用するネットワークに必須の手順ではありません。
登録中にAMFが変わったことをUEが直接検出できるか
UEの観点で重要なのは、Registrationが成功したかどうかと、ネットワークからどのAllowed NSSAI、Configured NSSAI、Rejected NSSAI、5G-GUTIが返されるかです。AMF再割り当てとRegistration Contextの転送は5GC内部の制御手順であり、UEからはほぼ透過的です。
間接転送と直接転送のどちらが常に多いのか
手順定義だけから一般的な結論を出すことはできません。使用される方式は、5GCの導入アーキテクチャ、ベンダー実装、AMF間のサービスベース通信機能、RANおよびコアネットワークの設定に依存します。実際のトラブルシューティングでは、稼働中のネットワークで観測されたシグナリング経路に従う必要があります。
