title: N8 — AMF ⇔ UDM（Nudm: UECM / SDM 参照点） description: AMFとUDMを結ぶN8インターフェース。N2/N4と異なりSBI(Service Based Interface)であり、実体はUDMが提供するサービスNudm(UECM/SDM)。HTTP/2+JSON over TLS上で、AMFがサービングAMFを登録(UECM)し加入者データを取得(SDM)する仕組みを、Why→What→Howで解説。 keywords: - N8 - Nudm - UECM - SDM - UDM - AMF - HTTP2 - SBI - 加入者データ - TS 29.503 tags: - Interface - Data - Rel-15 category: Interface

N8 — AMF ⇔ UDM（Nudm: UECM / SDM 参照点）¶

難易度: 中級／想定学習時間: 15分／接続点: AMF ⇔ UDM ／ Protocol: HTTP/2 + JSON (SBI) ／関連Interface: N10, N13

学習目標¶

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

N8が SBI（Service Based Interface） であり、N2(NGAP/SCTP)やN4(PFCP/UDP)とはProtocol/Transportが根本的に異なることを説明できる。
N8の実体がUDMの提供するサービス Nudm（UECM: UE Context Management / SDM: Subscriber Data Management, TS 29.503） であることを説明できる。
AMFが サービングAMFとしてUDMに登録（UECM） し、加入者データを取得（SDM） する流れを説明できる。
「参照点N8」と「サービスNudm」が同じものの2つの見方であることを説明できる。
4G(EPC)の S6a（MME ⇔ HSS, Diameter） の加入者データ取得・位置登録部分との対応関係を説明できる。

前提知識¶

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

SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
N8の両端のNF → AMF / UDM
加入者データ取得・サービングAMF登録が使われる手続き → Registration
Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

AMFはUEの登録（Registration）と移動管理（モビリティ）を担いますが、「このUEはどんなスライスを契約しているか」「どのエリアへの移動が許可/制限されているか」といった加入者情報を自分では持っていません。これらは加入者データの元締めである UDM が保持します。したがってAMFには、UDMへ加入者データを問い合わせる道が必要です。

さらに、UEがどこかで通信し始めると「このUEは今どのAMFが面倒を見ているか」を、後から他NF（例: 着信のためのSMS配送やUDM主導の処理）が知れるようにしておく必要があります。そこでAMFはUDMに対し「このUEのサービングAMFは私です」と登録します。この加入者データ照会とサービングAMF登録を担う参照点がN8です。N8が無ければ、AMFは契約スライスや移動制限を知らずにUEを扱えず、UDM側も現在のサービングAMFを把握できません。

例え話: AMF=フロアの受付窓口、UDM=本社の会員名簿（マスタDB）です。N8は、窓口が本社名簿を照会して「この客の契約内容は?」と尋ね、同時に「この客の担当窓口はここ（私）です」と名簿へ登録するホットラインにあたります。

Overview — 概要¶

N8は AMF ⇔ UDM を結ぶ参照点です。ただしN8はSBI（Service Based Interface）である点が、N2(NGAP/SCTP)やN4(PFCP/UDP)と決定的に異なります。SBIとはNF同士がWeb API（HTTP）でサービスを呼び合う仕組みで、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N8の実体は、UDMが提供するサービス Nudm（TS 29.503） です。Nudmには主に2つの側面があります。

UECM（UE Context Management）: AMFが自分をサービングAMFとしてUDMに登録/登録解除する。
SDM（Subscriber Data Management）: AMFがアクセス&モビリティ加入データ（許可スライス=Subscribed S-NSSAI、RFSP index、移動制限等）を取得し、その変更通知を購読する。

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

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

Basic Concept — 初心者向け説明¶

N8を、受付窓口と本社会員名簿のやり取りに例えます。

あなたがネットワークに登録（Registration）しようとすると、受付担当のAMFが動きます。AMFは、あなたの契約内容（どのスライスが使えるか、どこまで移動してよいか）を自分では知らないので、本社の会員名簿であるUDMに問い合わせます（SDM_Get＝加入者データ取得）。同時にAMFは名簿へ「このお客様の担当は私（このAMF）です」と書き込みます（UECM_Registration＝サービングAMF登録）。契約内容が後で変わったときに知らせてもらえるよう、「変更があったら通知して」とお願いもします（SDM_Subscribe）。

このUDMへの問い合わせは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みです。要求も応答も、人間に読みやすい JSON という書式でやり取りされます。操作対象（加入データやAMF登録などのリソース）に「住所（URI）」を与え、そこにHTTP操作を投げて取得・作成・購読する作法をRESTfulと呼びます。

Protocol / Transport¶

項目	内容
Protocol	HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス	Nudm（UECM / SDM）（UDMが提供）— TS 29.503
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 という専用の下位プロトコルを持ちますが、N8にはそれらは一切当てはまりません。N8はSBIなので、他のSBI（N7/N10/N11/N13 等）と同じく HTTP/2 over TLS を共通の土台として使います。したがってN8の解析にSCTP/PFCP固有のフィルタやポート番号を流用してはいけません。

Architecture¶

N8がAMFとUDMを結び、UDMが背後でUDRから加入データを取り出し、認証面ではAUSFがN13でUDMと連携する文脈を示します。

flowchart LR
  AMF["AMF"]
  UDM["UDM"]
  UDR[("UDR (加入データ)")]
  AUSF["AUSF"]

  AMF == "N8 (Nudm: UECM / SDM / HTTP2)" ==> UDM
  UDM -- "Nudr (加入データ取得)" --> UDR
  AUSF -. "N13 (Nudm_UEAuthentication)" .-> UDM

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

図の読み方: 太い線(==>)のN8がAMF⇔UDMの連携（SBI/HTTP2）で、AMFはここでサービングAMF登録（UECM）と加入者データ取得（SDM）を行います。UDMは自身でデータを保持せず、背後の UDRからNudrで加入データを取り出す（実装によりUDMとUDRが一体の場合もある）。破線のN13は認証に関するAUSF⇔UDMの連携で、加入者データ取得のN8とは役割が別です。N8は「登録と加入データ取得」、N13は「認証情報（認証ベクトル）」という区別に注目してください。

利用Procedure¶

N8は Registration（登録手続き） の中で、AMFがUDMへサービングAMFを登録し加入者データを取得する際に使われます。

UECM_Registration（サービングAMF登録）: UEの登録時、AMFがUDMへ「このUEのサービングAMFは私」と登録する。
SDM_Get（加入データ取得）: AMFがアクセス&モビリティ加入データ（許可スライス=Subscribed S-NSSAI、RFSP、移動制限等）を取得する。
SDM_Subscribe（変更通知購読）: 加入データが変わったらUDMから通知してもらうよう購読する。以後、変更があればUDMが SDM_Notify でAMFへ通知する。
De-registration時: UEの登録解放時に、AMFは UECM_Deregistration でサービングAMF登録を解除する。

これらの実行条件・順序・IE等の細部は Release や構成に依存するため要確認です。手順の詳細な流れ（メッセージシーケンス、条件）は Registration に集約されています。手順の細部はそちらを参照してください。

主なMessage¶

N8はSBIなので、メッセージはHTTPメソッド + リソース操作の形を取ります（NGAPのようなprocedureCodeではなくRESTful操作）。代表的なサービスオペレーションは次のとおりです。

サービスオペレーション	HTTP操作(概念例)	用途
Nudm_UECM_Registration	PUT（リソース登録）	AMFをサービングAMFとしてUDMに登録
Nudm_UECM_Deregistration	DELETE（リソース削除）	サービングAMF登録の解除
Nudm_SDM_Get	GET（リソース取得）	アクセス&モビリティ加入データの取得
Nudm_SDM_Subscribe	POST（購読リソース生成）	加入データ変更通知の購読
Nudm_SDM_Unsubscribe	DELETE（購読削除）	変更通知購読の解除
Nudm_SDM_Notify	POST（UDM→AMFへ通知callback）	加入データ変更のAMFへの通知

HTTP操作の対応は概念整理です: 上表の「HTTP操作」は理解のための対応づけであり、各オペレーションの正確なメソッド・リソースURI・呼び出し方向はTS 29.503のOpenAPI定義に従います。厳密なメソッド割り当ては要確認とします。各メッセージの詳細は Message辞典を参照してください。

Packet Analysis (Wireshark)¶

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

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

Decodeの見どころ:

N8は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
復号できれば、HTTP/2の ヘッダ（:method = GET/PUT/POST等、:path に .../nudm-uecm/... や .../nudm-sdm/... を含むリソースパス）でオペレーションを識別できます。
ボディは JSON（加入データ、許可スライス、移動制限、AMF登録情報等）で、人間に読みやすい構造で入っています。
N2のNGAP（バイナリ、SCTP上）と違い、N8はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4Gでは: 加入者データの取得と位置登録（MMEがどのUEを担当しているかの登録）は、MME ⇔ HSS 間の S6a インターフェース（Diameterベース, TS 29.272）で行われていました。HSSが加入者マスタデータを保持し、MMEはS6aで加入データ取得・位置更新（Update Location）を行います。
5Gでは: HSSの加入者データ管理の役割を UDM（背後にUDR）が引き継ぎ、S6a相当のうち加入データ取得・位置登録（サービングAMF登録）の部分が N8（Nudm: UECM / SDM） に SBI化されました。DiameterからHTTP/2 + JSON（SBI）へ置き換わっています（TS 29.503）。

4G (EPC)	5G (5GC)
S6a（MME ⇔ HSS の該当部分）	N8（AMF ⇔ UDM）
Diameter（専用L4上）	SBI: HTTP/2 + JSON over TLS
TS 29.272（S6a）	TS 29.503（Nudm: UECM / SDM）
HSS（加入者マスタ）	UDM（＋背後にUDR）

S6aの一部はN13へ: S6aは加入者データ取得・位置登録に加え、認証ベクトルの取得も担っていました。5Gではその認証部分は N13（AUSF ⇔ UDM, Nudm_UEAuthentication） 側に切り出されており、N8（加入データ取得・登録）とは役割が分かれています。

3GPP Specification¶

3GPP TS 29.503 — Nudm サービス（UECM: UE Context Management / SDM: Subscriber Data Management, N8）。個別章番号は要確認
3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N8の定義）
3GPP TS 23.502 — 手続き（Registration手続きでのN8利用）。個別章番号は要確認
3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N8の実体が Nudm（UECM/SDM, TS 29.503）であること、SBI共通framework が TS 29.500/29.501 系であること、参照点N8とサービスNudmが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI・HTTPメソッド割り当ては Release により差異があるため個別には要確認とします。

Summary¶

N8は AMF ⇔ UDM を結ぶ参照点だが、SBI（Service Based Interface）である点がN2(NGAP/SCTP)・N4(PFCP/UDP)と根本的に異なる。
Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はUDMのサービス Nudm（UECM / SDM, TS 29.503）。
AMFは UECM で自分をサービングAMFとしてUDMに登録し、SDM で加入者データ（許可スライス・移動制限等）を取得・変更購読する。
参照点N8 = サービスNudm は同じAMF⇔UDM連携の2つの見方（参照点の視点／サービスの視点）。
4Gの S6a（MME ⇔ HSS, Diameter, TS 29.272） の加入データ取得・位置登録部分に相当し、5Gでは SBI化（TS 29.503）された（認証部分はN13へ分離）。

Next Step¶

UDM — N8の相手側。加入者データ管理の中枢
AMF — N8を利用してサービングAMF登録・加入データ取得を行うNF
Registration — UECM登録・SDM取得が行われる手続き（詳細）
N10 — SMF⇔UDM（SMFが同じくNudmで加入データを取得）
N13 — AUSF⇔UDM（認証情報取得。S6aのうち認証部分に相当）
Interface辞典 — 参照点の確認