5Gコアネットワークでは、AMFプールは高可用性や負荷分散のために利用されますが、複数のAMFインスタンスを配置するだけでは十分ではありません。gNBがAMFプールに接続する際には、どのAMFがオンラインかだけでなく、各AMFが提供するGUAMI、対応するPLMNやスライス、相対容量、さらに保守のためにAMFがサービスから外れる際にトラフィックをどのように切り替えるべきかを把握する必要があります。
N2インターフェースは、これらの情報交換を行うための制御プレーン経路を提供します。SCTP上で動作し、NGAPシグナリングを使用してgNBとAMFの間で能力情報を交換し、状態を同期します。ネットワークの初期セットアップでは、まずSCTPアソシエーションを確立し、その後にNG Setup手順を実行します。運用中にAMFの容量、GUAMI情報、またはSCTPエンドポイントが変更された場合は、設定更新手順を通じてgNBへ通知する必要があります。計画保守の前には、AMFが利用不可になるGUAMIを示し、バックアップAMFに関する情報を提供することもできます。
したがって、AMFプールにおけるN2インターフェースは、一度設定して固定する接続ではなく、継続的に維持される制御関係として捉えるべきです。この観点で見ると、確立、更新、再選択の各手順を一連の管理プロセスとして理解しやすくなります。
AMFプールでは、接続が確立しただけではなぜ不十分なのか
基本的な接続性だけを見れば、gNBとAMFの間でSCTPアソシエーションが確立されると、両ノードはNGAPメッセージを交換できます。しかしAMFプールでは、接続できることだけでは不十分です。
1つのサービスエリアにAMF1、AMF2、AMF3など複数のAMFインスタンスが存在する場合があります。gNBは、それらのAMFに到達できるかだけでなく、対応するGUAMI、PLMN、スライス、さらに各AMFが現在どの程度の相対負荷を担うのに適しているかを把握する必要があります。こうした情報がなければ、すべてのSCTPアソシエーションがUP状態であっても、gNBには、新しいUEに対して適切なAMFを選択するための情報が不足する可能性があります。
N2インターフェース管理は、主に次の3段階に分けられます。
| 手順 | 代表的なトリガー | 主な目的 |
|---|---|---|
| N2セットアップ | サイトの初回起動、ネットワーク起動、またはAMFとの初回アソシエーション | SCTPアソシエーションを確立し、NG Setupを通じてgNBとAMFのパラメータを交換する |
| AMF Configuration Update | 相対容量、GUAMI情報、またはSCTPエンドポイントの変更 | gNBを最新のAMF設定と同期させ、以後のUE分配を支援する |
| AMF Status Indication | ソフトウェアアップグレード、計画保守、またはAMFの一部を一時的に利用不可にするその他の状態 | 特定のGUAMIが利用不可であることをgNBに通知し、必要に応じてAMF再選択を支援する |
これら3つの手順は、AMFとの関係のライフサイクルにおける異なる3段階、すなわち初期検出、能力または設定の変更、一時的なサービス離脱に対応します。まとめて見ることで、AMFプールが複数のコアネットワークノード間で負荷分散と計画保守をどのように実現するかを理解しやすくなります。
N2確立時にSCTPとNG Setupはそれぞれ何を行うのか?
エンジニアリングの会話では、この一連の段階をまとめて「N2セットアップ」と呼ぶことがよくあります。ただしプロトコルレベルでは、まずSCTPアソシエーションを確立し、その後にNGAPのNG Setup手順を実行する、連続した2つのステップで構成されます。
gNBはまず、AMF側N2インターフェースのSCTPエンドポイントアドレスを取得する必要があります。アドレスは静的に設定することも、適切なアドレス解決メカニズムで取得することもできます。その後、gNBはAMFとのSCTPアソシエーションを確立します。
一般的なSCTPアソシエーションの確立は、INIT、INIT ACK、COOKIE ECHO、COOKIE ACKの4つの交換で構成されます。これらが完了すると、トランスポート層はNGAPシグナリングを運べる状態になります。ただしgNBはまだ必要なAMFサービス情報をすべて取得していないため、続いてNG Setup手順を実行します。
gNBはNG Setup Requestを送信します。このメッセージには、Global gNB ID、Supported TA List、RAN Node Name、Default Paging DRXなどの情報を含めることができます。実務上は、どのRANノードが接続しているか、そのノードがどのトラッキングエリアをサポートしているか、基本動作パラメータは何かをAMFに通知するメッセージです。
要求を受信すると、AMFはNG Setup Responseを返します。応答には、AMF Name、Served GUAMI List、対応PLMN情報、RelativeAMFCapacityなど、AMF側の重要な情報が含まれます。
RelativeAMFCapacityはAMFプールで特に重要です。これはAMFがサポートできる加入者数の上限をそのまま示す値ではありません。複数のAMFを比較し、以後のUEに対するAMF選択や負荷分散を行う際にgNBが利用できる相対容量の指標です。
プールにAMF1、AMF2、AMF3が含まれている場合、gNBは同じ手順で各AMFとのN2アソシエーションを確立し、それぞれのノードからサービス情報と相対容量情報を取得できます。これにより、複数のAMFは孤立した制御プレーンノードではなく、連携するプールとして動作できます。
パケットキャプチャでも、この順序は明確に確認できます。まずSCTPハンドシェイクが現れ、その後にNG Setup RequestとNG Setup Responseが続きます。基本的なN2アソシエーションが確立されると、UE関連の登録やモビリティシグナリングは、この制御プレーン経路を利用できます。
AMFの能力が変わったとき、なぜgNBを更新する必要があるのか?
AMFプールの運用状態は固定ではありません。クラウド型5Gコアでは、加入者需要の増加に応じてAMFをスケールさせることがあり、GUAMI情報、サービスエリア、エンドポイントアドレス、処理能力などが変更される場合もあります。
gNBが初回起動時に取得したパラメータを使い続けると、RAN側のAMF選択ロジックがコアネットワークの実際の能力を反映しなくなる可能性があります。そこで重要になるのがAMF Configuration Update手順です。
この手順は特定のUEに対するものではありません。AMF自身の設定変更をNG-RANに通知するための手順です。たとえばAMFをスケールアップした後に相対処理能力が向上した場合、新しいRelativeAMFCapacity値をgNBへ通知できます。GUAMI情報の変更や、SCTPエンドポイントアドレスの追加・削除も同じ手順で同期できます。
たとえば、オーケストレーションまたは管理システムがAMF1で処理するユーザー数の大幅な増加を検出し、処理リソースを自動的に拡張したとします。拡張後、AMF1は制御プレーン負荷のより大きな割合を処理できるため、容量値もそれに応じて調整されます。
その後、AMF1はgNBへAMF CONFIGURATION UPDATEを送信します。このメッセージには、更新されたGUAMI情報、新しいRelativeAMFCapacity値、SCTPエンドポイントの変更を含めることができます。gNBは更新を適用した後、AMF CONFIGURATION UPDATE ACKNOWLEDGEを返します。
以後、新しいUEが到着した場合や、gNBが新たにAMFを選択する必要がある場合には、ネットワーク初回起動時に取得した値ではなく、更新後の情報を使用できます。
これはAMFプール運用の重要な原則を示しています。負荷分散はネットワーク起動時に一度だけ決まるものではなく、コアネットワークのリソース変化に応じて調整できます。
この点はクラウドネイティブ5Gコアで特に重要です。計算リソースは動的にスケールできますが、計算能力を増やしただけではRAN側のAMF選択動作は自動的に変わりません。更新された制御プレーンパラメータもgNBへ通知する必要があります。AMF Configuration Updateは、コアネットワークのリソース変更とRAN側の選択動作の変更を結び付けるシグナリングメカニズムです。
保守前にgNBはAMF再選択へどのように備えるのか?
スケーリングは容量を増やします。保守では逆に、ソフトウェアアップグレード、計画保守、その他の運用作業により、AMFを一時的に利用不可にする必要が生じる場合があります。
AMFがNG-RANへ通知せずにそのままオフラインになると、障害が発生するまでgNBが以前保存した情報に基づいてそのAMFを選択し続ける可能性があります。AMFプールでは、特定のAMF識別子がまもなく利用不可になることを、あらかじめgNBへ通知する方が適切です。
NGAPのAMF Status Indication手順は、この種のAMF管理シナリオで使用されます。
AMF1でソフトウェアアップグレードが必要な場合を考えます。保守開始前にAMF1はgNBへAMF STATUS INDICATIONを送信し、利用不可になるGUAMIを示すことができます。メッセージにAMF2などのBackup AMF Nameも含まれ、対応機能がサポートされている場合、gNBは以後の再選択でそのAMFを考慮できます。
gNBはステータス通知を受信すると、示されたGUAMIを利用不可として扱い、それに応じて以後のAMF選択と再選択を調整します。
これは、既存のすべてのUEコンテキストが同じ瞬間にAMF1からAMF2へ機械的に移されるという意味ではありません。目的は、後にAMF選択または再選択が必要になった際、サービスから外れつつあるAMFをNG-RANが選び続けないようにすることです。
たとえば、後からUEがモビリティ登録更新を開始した場合、gNBは該当シグナリングを別のAMFへルーティングできます。新しいAMFはモビリティ管理機能を継続し、手順上必要であればUEへ新しい5G-GUTIを割り当てます。
運用の観点では、AMF Status Indicationは計画的なサービス離脱のための仕組みです。「AMF1が保守に入る」といった運用イベントを、AMFが実際に利用不可になる前にNG-RANが理解して利用できるプロトコルレベルの状態情報へ変換します。
AMFプールはこれら3つの手順で実際に何を管理しているのか?
NG Setup、AMF Configuration Update、AMF Status Indicationを個別に学ぶと、互いに関係のない3つのNGAP手順に見えがちです。しかしAMFプールのライフサイクル全体で見ると、それぞれの関係が明確になります。
NG Setupは初期関係を確立します。 gNBが最初にAMFへ接続する際には、どのAMFと通信しているか、そのAMFがどのサービスを提供するか、プール内での相対処理能力がどの程度かを把握する必要があります。
AMF Configuration Updateは能力や設定の変更を処理します。 AMF自体は利用可能なままですが、GUAMI情報、相対容量、またはトランスポートエンドポイントが変わったため、NG-RANは保存している情報を更新する必要があります。
AMF Status Indicationは可用性の変更を処理します。 AMFが保守や一時的なサービス離脱に入る場合、gNBは該当GUAMIを利用不可として扱い、以後のAMF再選択に備える必要があります。
これらの手順によって、gNBは重要な運用ビューを維持できます。すなわち、どのAMFが利用可能か、どのサービスを提供しているか、どの程度の相対負荷を担うのに適しているか、そしてどのAMFがサービスから離脱しつつあるかという情報です。
したがって、AMFプールは複数のAMFインスタンスを配置しただけで高可用性を実現できるわけではありません。gNBがAMFの能力と状態に関する最新情報を継続的に維持し、選択時にその情報を使用する必要があります。これによって初めて、複数AMFの構成で負荷分散、弾力的なスケーリング、計画保守を効果的に支援できます。
同じ考え方はトラブルシューティングにも役立ちます。まずSCTPアソシエーションが正常か確認し、次にNG Setupが正常に完了しているかを確認します。接続が有効なまま負荷分配に異常がある場合は、AMF Configuration UpdateシグナリングとRelativeAMFCapacityを確認します。サービスから外れつつあるAMFへトラフィックが引き続き送られる場合は、AMF Status Indication、GUAMIの可用性情報、AMF再選択動作を確認します。
よくある質問
パケットキャプチャでSCTP障害とNGAP障害を素早く見分けるには?
まずSCTPアソシエーションが正常に確立されたかを確認します。INIT、INIT ACK、COOKIE ECHO、COOKIE ACKの交換が完了していない場合、問題はまだトランスポート層にあります。SCTPが確立されているにもかかわらずNG Setup Responseを受信していない場合、またはNGAPレベルのエラーが返されている場合は、NGAPパラメータ、TA設定、PLMN情報、AMF側設定を確認します。
RelativeAMFCapacityはAMFがサポートできるUEの最大数を表すのか?
いいえ。RelativeAMFCapacityは、AMFプール内で使用される相対容量の指標として理解するのが適切です。NG-RANが選択時に各AMFの相対処理能力を比較するために使用するもので、絶対的な加入者数の上限として直接解釈すべきではありません。
GUAMI情報が変わったとき、AMFのローカル設定変更だけではなぜ不十分なのか?
gNBはすでにN2インターフェースを通じて取得したAMFサービス情報を保存しています。AMFがNG-RANへ通知せずにGUAMI設定を変更すると、AMFの識別情報やサービス可用性に関する両者の認識が一致しなくなる可能性があります。そのため、更新された情報は該当するNGAP管理手順で同期する必要があります。
AMF Status Indicationには常にBackup AMF Nameを含める必要があるのか?
いいえ。Backup AMF Nameはオプションです。含まれていない場合でも、NG-RANは利用不可として示されたGUAMIを処理し、適切なAMF管理と再選択動作を行う必要があります。Backup AMF Nameが含まれ、NG-RANが対応手順をサポートしている場合は、再選択時に指定されたバックアップAMFを考慮できます。