コンテンツにスキップ

N14 — AMF ⇔ AMF（AMF間UEコンテキスト移送）

難易度: 中級 ／ 想定学習時間: 15分 ／ 接続点: AMF ⇔ AMF（旧⇔新） ／ Protocol: HTTP/2 + JSON (SBI) ／ 関連Interface: N1, N2, N8, N11

学習目標

このページを読み終えると、次のことができるようになります。

  • N14が 同じNFタイプ(AMF)同士 を結ぶ SBI（Service Based Interface） であることを説明できる。
  • N14が、UEが別のAMFのサービング領域へ移動した際に 旧AMF(source/old)→新AMF(target/new)へUEコンテキストを移送 するためのものだと説明できる。
  • 移送されるUEコンテキスト（登録状態・5Gセキュリティコンテキスト(KAMF等)・PDUセッション参照・許可NSSAI等）の中身を説明できる。
  • N14の実体がAMFの提供するサービス Namf_Communication（TS 29.518） のAMF間連携オペレーションであることを説明できる。
  • 4G(EPC)の S10（MME ⇔ MME, GTP-C） のUE Context移送との対応関係を説明できる。

前提知識

先に以下を理解しておくとスムーズです。

  • SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
  • N14の両端のNF（同じAMF） → AMF
  • UEコンテキスト・5Gセキュリティコンテキスト・モビリティの考え方 → Registration / Security
  • Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか

UEは移動します。ある地域を担当するAMFのサービング領域から、別のAMFが担当する領域へ移ることがあります（モビリティ登録更新、AMF再割当、N2ハンドオーバでターゲットAMFが変わる等）。このとき、新しくサービングするAMF（新AMF）は、そのUEが誰で、どんな状態で、どんなセキュリティで通信していたかを知りません。

もし何も引き継がなければ、新AMFはUEを一から扱い直すことになります。認証をやり直し、登録状態を再構築し、進行中のPDUセッションの参照も失われかねません。これはUEにも網にも大きな負担です。

そこで、旧AMF(source/old)が持っていたUEコンテキストを、新AMF(target/new)へそのまま引き継ぐ道が要ります。これがN14です。新AMFはN14で旧AMFにコンテキストを要求し、旧AMFは登録状態・5Gセキュリティコンテキスト(KAMF等)・PDUセッション参照・許可NSSAI等を返します。これにより新AMFは、認証の再実行を省ける場合があるなど、UEの手続きをスムーズに引き継げます。N14が無ければ、AMFをまたぐ移動のたびに手続きを最初からやり直す羽目になります。

例え話: N14は、引越しに伴う役所間の住民票の引継ぎです。旧担当窓口（旧AMF）から新担当窓口（新AMF）へ本人の記録一式を引き継ぐので、新窓口で一から手続きし直さずに済みます。

Overview — 概要

N14は AMF ⇔ AMF、つまり 同じNFタイプ(AMF)同士 を結ぶ参照点です。他の多くのInterfaceが異なるNF間（例: SMF⇔PCF）を結ぶのに対し、N14はAMFとAMFという同種のNFを結ぶ点が特徴です。そしてN14はSBI（Service Based Interface）であり、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N14が使われるのは、UEが別のAMFがサービングする領域へ移動したときです。契機は主に、モビリティ登録更新、AMF再割当、N2ハンドオーバでターゲットAMFが変わるケース等です。このとき 旧AMF(source/old)→新AMF(target/new) の向きで UEコンテキスト が移送されます。移送物には、登録状態・5Gセキュリティコンテキスト(KAMF等)・PDUセッション参照・許可NSSAI等が含まれます。新AMFは移送されたコンテキストを使うことで、認証の再実行を省ける場合があります。

N14の実体は、AMFが提供するサービス Namf_Communication（TS 29.518） のうち、AMF間連携に相当するオペレーションです。

参照点N14とサービスNamf_Communicationは同じものの2つの見方

3GPPのアーキテクチャ図では 参照点として N14（AMF⇔AMF） が示されますが、SBA（サービス化）ではこれが実体として AMFのサービス Namf_Communication として実装されます。つまり「N14」と「Namf_Communication（のAMF間連携）」は、同じ旧AMF⇔新AMF間の連携を、参照点の視点／サービスの視点で見たものです。どちらも指しているものは同一で、呼び方（視点）が違うだけ、と捉えてください。

Basic Concept — 初心者向け説明

N14を、役所間の住民票の引継ぎに例えます。

あなたがスマホを持って別の地域へ移動すると、そのエリアを担当するAMF（新AMF）が新たにサービングを始めます。ところが新AMFは、あなたがそれまでどんな登録状態で、どんなセキュリティ鍵で、どのPDUセッションを張っていたかを知りません。そこで新AMFは、それまで担当していた旧AMFに「この人の記録一式をください」と頼みます。旧AMFは、登録状態・セキュリティコンテキスト・進行中セッションの参照などをまとめて渡します。これがN14でのUEコンテキスト移送です。

記録を引き継げるおかげで、新AMFは一から手続きし直す必要がありません。本人確認（認証）を省ける場合もあり、あなたは移動しても通信を続けられます。

このAMF同士のやり取りは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みで、要求も応答も、人間に読みやすい JSON という書式でやり取りされます。

Protocol / Transport

項目 内容
Protocol HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス Namf_Communication（AMFが提供）— TS 29.518。N14はそのAMF間連携オペレーション
SBI framework TS 29.500 / TS 29.501 系（SBIの共通規約・OpenAPI定義）
下位Transport TCP、TLS で保護（機密性・完全性・認証）— TS 33.501
ポート SBIの待受ポートは実装依存（NRF登録のエンドポイントで解決）。特定番号は断定しない
特徴 専用L4プロトコルではなくWeb技術ベース。HTTPメソッド＋リソースURIで操作。RESTful

N2/N4のような専用L4ではなくWeb技術ベース

N2は NGAP over SCTP:38412、N4は PFCP over UDP という専用の下位プロトコルを持ちますが、N14にはそれらは一切当てはまりません。N14はSBIなので、他のSBI（N8/N11/N12 等）と同じく HTTP/2 over TLS を共通の土台として使います。したがってN14の解析にSCTP固有のフィルタやPFCP固有のフィルタを流用してはいけません。

Architecture

N14が旧AMF(source)と新AMF(target)を結び、UEがgNB経由でN2をたどりながらサービングAMFが切り替わる文脈を示します。

flowchart LR
  UE["UE"]
  gNB["gNB"]
  oAMF["旧AMF (source)"]
  nAMF["新AMF (target)"]

  UE --> gNB
  oAMF =="N14 (Namf: UEContext移送)"==> nAMF
  gNB -."N2".- nAMF

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class oAMF,nAMF ctrl;

図の読み方: UEはgNB経由で網につながります。UEが別のAMF領域へ移動すると、サービングは 旧AMF(source)→新AMF(target) へ切り替わります。このとき太い線(==>)の N14 で、旧AMFから新AMFへ UEコンテキスト が移送されます（実体はNamf_Communicationのオペレーション）。点線の N2 は、gNBと（新）AMFを結ぶ制御面の参照点です。N14はあくまで AMF同士 の連携である点に注目してください。

利用Procedure

N14は モビリティ（UEの移動）に伴い、サービングAMFが切り替わる場面で使われます。代表例が モビリティ登録更新 です。

  • UEが新AMF配下のエリアへ移動し、新AMFへ Registration Request（Mobility Registration Update） を送る。
  • 新AMFは、UEが提示する識別子（旧AMF情報を含む）を手がかりに、旧AMFへN14でUEコンテキストを要求する。
  • 旧AMFは、登録状態・5Gセキュリティコンテキスト(KAMF等)・PDUセッション参照・許可NSSAI等を含む UEコンテキストを応答 する。
  • 新AMFは移送されたコンテキストを用いて登録を完了する（認証の再実行を省ける場合がある）。

このほか、AMF再割当や、N2ハンドオーバでターゲットAMFが変わるケースでも、AMF間のコンテキスト連携にN14が用いられます。

手順の詳細な流れ（メッセージシーケンス、条件、IE、成否時の分岐等）は Mobility Registration Update に集約されています。手順の細部（オペレーション名・呼出方向・章番号枝番）はそちらを参照してください（細部は要確認）。

主なMessage

N14はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。実体は Namf_Communication のオペレーションです。代表的なもの（例示・要確認）は次のとおりです。

サービスオペレーション（例） 用途
Namf_Communication_UEContextTransfer（要確認） 新AMFが旧AMFへUEコンテキストを要求・取得
Namf_Communication_RegistrationCompleteNotify / RegistrationStatusUpdate（要確認） 新AMFが旧AMFへ登録完了/状態を通知（旧側コンテキストの扱いを更新）
Namf_Communication_N1MessageNotify（要確認） AMF間でN1メッセージ等を受け渡す通知

オペレーション名・メソッド割当は要確認です: 上表の細かいサブオペレーション名（UEContextTransfer / RegistrationStatusUpdate 等）や正確なHTTPメソッド・リソースURI・呼び出し方向は、Namf_Communication（TS 29.518）のOpenAPI定義に従い、Releaseにより差異があります。ここでは例示に留め、厳密な割り当ては要確認とします。各メッセージの詳細は Message辞典 を参照してください。

Packet Analysis (Wireshark)

N14はSBIなので、キャプチャ上は HTTP/2 として観測されます（NGAP/SCTPやPFCPのようなL4専用プロトコルは現れません）。

目的 Display Filter
HTTP/2メッセージを抽出 http2
ヘッダのパスで絞る（概念） http2.headers.path（:path に namf-comm を含む）
JSONボディを見る json（復号後）

Decodeの見どころ:

  • N14は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
  • 復号できれば、HTTP/2の ヘッダ（:method、:path に .../namf-communication/... を含むリソースパス）でオペレーションを識別できます。
  • ボディは JSON（UEコンテキスト、セキュリティコンテキスト参照、PDUセッション参照等）で表現されます。
  • N14は AMF同士のSBI です。SCTP（NGAP）やPFCP（N4）は無関係であり、sctp.port や pfcp 系のフィルタは使いません。

EPCとの比較

  • 4Gでは: UEが別のMMEがサービングする領域へ移動する際、MME ⇔ MME 間で S10 インターフェース（GTP-Cベース、TS 29.274）を用いて UE Context を移送していました。
  • 5Gでは: MMEの制御面の役割を AMF が引き継ぎ、S10相当のAMF間UEコンテキスト移送が N14（Namf_Communication） に SBI化されました。GTP-Cから HTTP/2 + JSON（SBI） へ置き換わっています（TS 29.518）。
4G (EPC) 5G (5GC)
S10（MME ⇔ MME） N14（AMF ⇔ AMF）
GTP-C（専用L4上） SBI: HTTP/2 + JSON over TLS
TS 29.274（GTP-C / S10） TS 29.518（Namf_Communication）
MME間のUE Context移送 AMF間のUEコンテキスト移送

4Gの S10（MME間UEコンテキスト移送） が、5Gで N14（AMF間UEコンテキスト移送） に相当します。主な変化は、GTP-Cベースの専用IFから SBI（HTTP/2+JSON）化された点です。

3GPP Specification

  • 3GPP TS 29.518 — Namf_Communication サービス（AMF間UEコンテキスト移送を含む、N14）。個別章番号は要確認
  • 3GPP TS 23.502 §4.2.2 — モビリティ登録更新でのAMF間手順（AMF変更時のコンテキスト連携）。章番号枝番は要確認
  • 3GPP TS 23.501 §6.2.1 / §4 — AMFの定義とシステムアーキテクチャ・参照点（N14の定義）
  • 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
  • 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N14の実体が Namf_Communication（TS 29.518）のAMF間連携であること、参照点N14とサービスNamfが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI・サブオペレーション名はReleaseにより差異があるため個別には要確認とします。

Summary

  • N14は AMF ⇔ AMF、つまり 同じNFタイプ(AMF)同士 を結ぶ SBI（Service Based Interface） である。
  • 用途は、UEが別のAMFがサービングする領域へ移動した際の 旧AMF→新AMFへのUEコンテキスト移送（登録状態・5Gセキュリティコンテキスト(KAMF等)・PDUセッション参照・許可NSSAI等）。
  • 契機は モビリティ登録更新・AMF再割当・N2ハンドオーバでのAMF変更 等。新AMFは移送コンテキストで 認証の再実行を省ける場合 がある。
  • 実体はAMFのサービス Namf_Communication（TS 29.518） のAMF間連携（参照点N14＝サービスNamfの2つの見方 → AMF）。
  • 4Gの S10（MME ⇔ MME, GTP-C, TS 29.274） のUE Context移送に相当し、5Gでは SBI化（TS 29.518）された。

Next Step

  • AMF — N14の両端。UEコンテキスト・モビリティ管理の中枢
  • Mobility Registration Update — AMF間コンテキスト移送を伴う手順（詳細）
  • Handover — N2ハンドオーバでターゲットAMFが変わるケース
  • N8 — AMF⇔UDMの参照点（登録・加入者データ連携）
  • Interface辞典 — 参照点・SBIの一覧確認