5G Coreの制御プレーンでは、AMFがUEアクセス管理、モビリティ管理、NASシグナリングなどの主要機能を担います。そのため、AMFアーキテクチャの信頼性はサービス全体の継続性に直接影響します。従来型の構成では、gNBが特定のAMFに静的に関連付けられる場合があります。ネットワーク規模が小さいうちは比較的単純ですが、加入者数が増加し、トラフィック分布が動的になり、クラウド型展開が一般化するにつれて限界が明確になります。繁華な商業地区を担当するAMFはピーク時間帯に高負荷となる一方、隣接するリソースが十分に利用されないことがあります。単一AMFにソフトウェアまたはハードウェア障害が発生すると、そのサービスエリア内のユーザーに影響が及ぶ可能性があります。また、ソフトウェア更新や設定変更などの日常運用でも、慎重に計画したメンテナンス時間帯が必要になります。
3GPPアーキテクチャでAMF Setとして表現されるAMF Poolは、複数AMFを共有して展開することでこれらの問題に対応します。複数のAMFが1つの論理サービスグループを構成し、gNBはプール内のAMFとN2接続を確立できます。階層型GUAMI識別構造、重み付きAMF選択、UEコンテキスト継続性を組み合わせることで、負荷分散、障害時の冗長性、移動時のシグナリング削減、柔軟な保守を実現します。制御プレーンノードのプール化は5G特有の考え方ではありません。GPRSのSGSN Poolや4GのMME Poolにも同様の概念があり、固定的なノード結合を共有ネットワークリソースへ置き換えるという原則に基づいています。5GではAMF Poolingがクラウドネイティブ展開と弾力的なリソース管理をさらに補完します。
AMF Poolingが重要な理由
AMF Poolを導入する主な理由の1つは、変化する加入者分布と固定されたノード容量の不一致を解消することです。モバイルトラフィックは本質的に動的です。勤務時間帯には多くの加入者が商業地区に集中し、夜間には住宅地へトラフィックが移ります。コンサート、スポーツイベント、休暇シーズンの移動でも、一時的な急激なトラフィック増加が発生します。特定地域が少数の静的割当AMFだけに依存していると、一部ノードが高負荷になる一方で、他のノードが十分に利用されない状況が生じます。
複数のAMFが同じプール内で動作する場合、gNBは関連するすべてのAMFインスタンスとの接続を維持でき、新規UEは設定されたAMF重みに従って分散できます。例えば、同じ処理能力を持つ3台のAMFが同一エリアを担当する場合、同等の重みを設定することで、新しいUE登録やモビリティコンテキストを比較的均等に分配し、全体のリソース利用率を高められます。
2つ目の大きな利点は耐障害性です。1台のAMFでソフトウェア障害やハードウェア故障が発生しても、プール内の他のAMFは引き続き後続のアクセス要求やモビリティ要求を処理できます。5G Core制御プレーンにとって、このマルチノード方式は単一AMFへの過度な依存を避け、高可用性運用の基盤を強化します。
プール化は運用上の柔軟性も高めます。ソフトウェア更新、設定変更、AMFインスタンスの拡張を行う前に、運用者は対象ノードのアクティブ負荷を減らしたり移行したりし、プール内の他AMFに新規または再分配されたトラフィックを引き継がせることができます。対象AMFがアクティブユーザーを保持しなくなってから保守を行えば、稼働中サービスへの影響を抑えつつ、メンテナンス時間帯をより柔軟に選択できます。
プール内のモビリティ最適化
AMF Poolの価値はマルチノード冗長性だけではありません。重要な利点の1つは、UEがネットワーク内を移動する際のシグナリングを削減できることです。1つのプールは複数のTracking Areaをカバーでき、そのサービスドメイン内のgNBは同じAMF Setに属するAMFとのN2接続を維持します。
例えば、UEが最初にTA1で登録し、AMF1がUEコンテキストを作成したとします。その後UEが同じプール内のTA2へ移動した場合でも、新しいgNBはAMF1を引き続き選択し、そのUEのNASシグナリングを処理できます。UEが同一AMF Poolのサービス範囲内にいる限り、ネットワークは元のAMF関連付けを維持しようとします。
この設計により不要なモビリティシグナリングを削減できます。プール化がなければ、サービスエリア間の移動によりServing AMFの変更が必要となり、追加のコンテキスト転送や登録関連手順が発生する可能性があります。プール化は無線側の位置変化と制御プレーンノードの必須変更を分離し、UEがgNBやTracking Area間を移動しても、自動的にServing AMFを変更する必要をなくします。
エンジニアリングの観点では、プールはAMFコンテキストを安定して維持できる地理的範囲を事実上拡大します。UEが対象AMF Setのサービスエリア内に留まる限り、複数のgNBやTAを移動しても同じAMFアンカーを保持できます。これにより制御プレーンの相互作用が減り、モビリティ管理の継続性が向上します。
3GPPアーキテクチャでは、このロジックは階層構造として表現されます。AMF Setには、定義されたエリアを担当し、同一のNetwork Sliceまたは複数のスライスをサポートする複数のAMFが含まれます。1つのAMF Region内に複数のAMF Setを配置でき、大規模ネットワークでは制御プレーンを管理しやすいサービスドメインへ分割できます。
GUAMIがAMFを識別する仕組み
制御プレーンが単一ノードからプール型アーキテクチャへ移行すると、ネットワークにはリージョン、セット、個別AMFインスタンスを体系的に識別する方法が必要になります。GUAMI（Globally Unique AMF Identifier）は、この階層を提供します。
GUAMIはMCC、MNC、AMF Region ID、AMF Set ID、AMF Pointerで構成されます。これらのフィールドにより、PLMN、AMF Region、AMF Set、個別AMFインスタンスまでを表す階層型アドレッシングモデルが形成されます。AMF Region IDはより広いAMF Regionを識別し、AMF Set IDはそのリージョン内の特定AMF Setを識別し、AMF Pointerはセット内の個別AMFを区別します。
同じ階層はUEの一時識別子にも現れます。5G-GUTIはGUAMIと5G-TMSIで構成されるため、UEの一時識別情報から以前そのUEを担当したAMFを示すことができます。5G-S-TMSIにはAMF Set ID、AMF Pointer、5G-TMSIが含まれ、Pagingなどの手順で利用される情報を提供します。
このためGUAMIはAMF選択に直接影響します。UEがRRC確立時に以前のServing AMFを識別できる情報を提供した場合、gNBは完全に新しい負荷ベース選択を必ずしも行う必要はありません。代わりに元のAMFを選択し、既存のサービス関係を維持することを試みられます。
バイナリ識別子に加えて、AMFの発見にはFQDNとDNSの仕組みも利用できます。gNBはAMF Set-FQDNを生成し、DNSへ問い合わせて特定セットに属するAMF情報を取得し、その後のN2アソシエーション確立に利用できます。AMF Instance-FQDNは個別AMFインスタンスを識別し、該当するモビリティやインターワークのシナリオで以前のServing AMFを見つけるのに役立ちます。
gNBはどのようにAMFを選択するか
AMF Poolが稼働すると、gNBは本質的に異なる2種類のUE状況に対応します。1つは以前のServing AMFに関する利用可能な情報を持たない新規UE、もう1つは以前のAMFを識別する情報を持つUEです。この2つでは選択優先順位が異なります。
UEがRRC確立時にGUAMIや以前のAMFを識別できる情報を提供しない場合、gNBは設定された重み値を使ってAMF SetからAMFを選択します。各AMFには通常、その処理能力に応じて0～255の重みを設定できます。処理能力の高いAMFには高い重みを設定してより多くの新規ユーザーを受け入れさせ、能力の低いインスタンスには低い重みを設定できます。
例えば、3台のAMFに100、50、50の重みを設定した場合、その他の条件が同等なら、最初のAMFは新規割当ユーザーのおよそ半分を受け取ることができます。重みは固定である必要はありません。AMFの拡張、縮小、その他の容量変化があった場合、更新された重み情報をN2 Configuration Update手順によって接続済みgNBへ通知し、その後のUE割当を新しい容量分布に合わせることができます。
一方、UEが有効なGUAMIを提供する場合は選択目標が変わります。gNBはUEを別のAMFへ直ちに再分散するのではなく、以前のServing AMFを特定して選択しようとします。元のAMFを維持することでコンテキスト継続性が保たれ、不要な制御プレーン変更を回避できます。
したがって、プール内のAMF選択は2つの原則に要約できます。過去のAMF関連付けがない場合は負荷分散を優先し、以前のAMF関連付けが分かっている場合はサービス継続性を優先する。前者はリソース利用率を高め、後者はモビリティシグナリングを削減します。効率的なAMF Poolは、すべてのUEを常に最も負荷の低いAMFへ移動させるのではなく、リソース分散とコンテキスト安定性を両立させます。
初期導入から弾力的なスケーリングまで
AMF Setをサービスインするには複数の段階があります。まずMANOオーケストレーションシステムまたはネットワーク管理プラットフォームを通じて複数のAMFインスタンスを作成し、N2接続に必要なSCTPアソシエーションアドレスを設定します。
次にgNBはプール内のAMFとSCTPアソシエーションを確立し、各関連AMFとN2 Setup手順を実行します。N2 Setupは単に接続を確立するだけではありません。相対容量や重み、サポートするスライス、サービスエリア情報など、AMFの動作や選択に関するパラメータをgNBが取得できるようにします。これらの関係が確立されると、AMF SetはUEへサービスを提供できる状態になります。
新しいUEが到着すると、gNBは以前のAMF関連付けを維持するか、利用可能なプール情報と設定重みに基づいてAMFを選択するかを判断します。すべてのAMFが同程度の処理能力と同じ重みを持つ場合、時間の経過とともに加入者負荷は比較的均等な分布へ近づくはずです。
アーキテクチャ上、AMF Poolは従来のactive-standby方式とみなすべきではありません。active-standby構成では、障害が起きるまでバックアップノードがほぼアイドル状態にとどまることがあります。AMF Poolでは複数のAMFが同時にアクティブにユーザーへサービスできます。耐障害性はプール化の効果の1つですが、より大きな目的は複数のAMFインスタンスを1つの論理サービスグループとして動作させることです。
この特性により、AMF Poolingはクラウド型5GC展開の重要な基盤にもなります。クラウドネイティブ環境では、オーケストレーションによってAMFインスタンスをスケールできます。インスタンス数、処理能力、選択重みは時間とともに変化しても、gNBやUEから見える論理AMF Setは安定したままです。したがってプール化は、動的に変化するコアネットワークリソース上に一貫したサービス境界を提供し、クラウド指向5G Coreに求められる弾力的な動作を支えます。
よくある質問
1つのAMF Regionに複数のAMF Setを含められますか？
はい。1つのAMF Regionには複数のAMF Setを含められます。異なるセットは異なるエリアを担当でき、同じセット内のAMFはそのセットで必要な同一のNetwork Sliceまたは複数のスライスをサポートします。
1つのTracking Areaは1つのgNBだけに対応しますか？
いいえ。Tracking AreaとgNBの間に1対1の関係はありません。1つのTAには複数のセルを含められ、1つのgNBにも複数のセルが含まれ、それらは1つまたは複数のTracking Areaに属する場合があります。
AMF PointerとAMF Set IDの違いは何ですか？
AMF Set IDはAMF Setを識別し、AMF Pointerはそのセット内の特定AMFインスタンスを区別します。AMF Region IDと合わせて、GUAMIに含まれる階層型アドレッシング情報の重要な要素を構成します。
AMFの重みを変更するとすべてのN2接続を再確立する必要がありますか？
いいえ。AMF容量が変化した場合、更新された重みまたは相対容量情報を、該当するN2 Configuration Update手順を通じて既に接続済みのgNBへ通知できます。更新値は既存N2接続を再構築することなく、その後の新規UE割当に反映できます。
