5Gコアの「司令塔」：AMFを理解せずして、モビリティ管理は語れない
ネットワークエンジニア諸君、今日もパケットの海を泳いでいることだろう。4Gから5Gへの移行が進み、NSA（Non-Standalone）からSA（Standalone）構成へ舵を切るプロジェクトも増えてきた。
現場で「5Gは速い」と喜んでいるユーザーの裏側で、我々インフラ屋が直面するのは、かつてのMME（Mobility Management Entity）がより洗練され、かつ複雑化した「AMF (Access and Mobility Management Function)」という難物だ。
今日は、API設計者やインフラエンジニアが避けて通れない、このAMFの真の役割と、端末（UE）がネットワークに繋がるその瞬間の「泥臭いシグナリング」について、現場の視点から紐解いていこう。
—
AMFとは何か？— 5Gの「交通整理官」
AMFは、5Gコアネットワーク（5GC）において、端末との通信路を確立し、認証やモビリティ（移動）を管理する、いわば「玄関番兼司令塔」だ。
4GのMMEと比較して特筆すべきは、NAS（Non-Access Stratum）シグナリングの終端処理を一手に引き受ける点にある。端末がネットワークに「私はここにいるぞ！」と叫ぶとき、その声を受け止めるのがAMFだ。
AMFが担う4つの柱
1. 登録管理 (Registration Management): 端末がネットワークに在圏していることを記録する。
2. 接続管理 (Connection Management): RRC（無線制御）とNAS層の接続状態を管理する。
3. 到達可能性管理 (Reachability Management): スリープ状態の端末を呼び起こす「ページング」のトリガーを引く。
4. NASシグナリングの終端: N1インターフェースを通じて送られてくる制御信号を解析し、適切なNF（Network Function）へ振り分ける。
—
現場で役立つNASシグナリングの可視化
インフラ運用において、端末が「Registration Reject」を食らうケースは日常茶飯事だ。ここで重要なのは、AMFが返している5GMM Causeの値だ。
もし自社で開発しているWeb APIやインフラが5G端末の挙動に依存しているなら、curlでN1/N2相当のシミュレーションをするような感覚で、パケットの中身を解像度高く見る必要がある。
登録リクエストの解剖
端末がAMFへ送るRegistration Requestには、以下のような重要なパラメーターが含まれている。
5G-GUTI: 端末を匿名化して識別するID。個人情報保護の観点から、平文のSUCI（隠蔽化された加入者識別子）ではなく、これを使うのが基本だ。Registration Type: 「Initial Registration（初期）」か「Mobility Registration（移動）」か。
もし、あなたがPython等で5Gコアのシミュレータを叩く場合、以下のような構造のJSON（あるいはバイナリパケット）を扱うことになるだろう。
# 5G Registration Requestの概念モデル（Python形式）
registration_request = {
"header": {
"protocol_discriminator": "5GMM", # 5G Mobility Management
"message_type": "RegistrationRequest"
},
"payload": {
"registration_type": "initial",
"5G-GUTI": "0x4705001234567890", # AMFが割り当てた端末識別子
"requested_nssai": ["eMBB", "URLLC"], # 要求するスライス情報
"capability": {
"s1_mode_supported": False,
"n1_mode_supported": True # 5Gモードでの接続を明示
}
}
}
# 運用上のTips:
# 接続エラーが発生した際、この'requested_nssai'がAMFの許可リストと
# 不一致になっていないかチェックするのが、トラブルシューティングの第一歩だ。—
AMFとAPI連携の現場感覚
現代のインフラでは、AMFは単独で動かない。Nudm（Unified Data Management）APIを叩いて加入者情報を取得したり、Nsmf（Session Management Function）と連携してPDUセッションを確立したりと、ネットワーク内はまるでマイクロサービスアーキテクチャそのものだ。
APIエンジニアが留意すべきは、AMFが発行するAccess Tokenのライフサイクルだ。OAuth 2.0をベースとしたNnrf（Network Repository Function）との認証フローは、Web開発の知識がそのまま活きる領域である。
# 現場でAMF-NRF間の通信をデバッグする際のイメージ
curl -X POST https://nrf-service.5gc.internal/nnrf-nfm/v1/nf-instances \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <AMF_TOKEN>" \
-d '{
"nfType": "AMF",
"ipv4Addresses": ["10.0.1.50"],
"priority": 1,
"capacity": 100
}'
# この際、もしステータスコード 403 Forbidden が返ってきたら、
# AMFに紐付くOAuthスコープの設定ミスを疑え。—
トラブルシューティングの極意：パケットは嘘をつかない
最後に一つ、現場のシニアとしてアドバイスを送る。
「AMFが反応しない」という事象の多くは、無線区間の問題ではなく、AMFとUPF間のN3トンネル設定や、DNS解決の失敗にある。
1. NASシグナリングをWiresharkで覗け: ngapやnas-5gsプロトコルでフィルタリングする。
2. Registration Rejectの理由を特定せよ: Cause #11（PLMN不許可）なのか、Cause #15（認証失敗）なのか。これだけで復旧までの時間は半分になる。
3. AMFのログをJSON形式で集約せよ: Fluentd等でパケットのイベントを構造化しておけば、特定の端末ID（SUPI）で追跡が可能になる。
AMFは、単なる通信のゲートウェイではなく、5Gという巨大なシステムの「心臓」だ。その鼓動（シグナリング）を読み解くことができれば、君はもう、5Gインフラ運用の現場で誰よりも信頼されるエンジニアになっているはずだ。
次は、このAMFがどのようにUPF（User Plane Function）へトラフィックを誘導するのか、その「パケットのルーティング制御」について深掘りしていこう。また現場で会おう。
コメント