コンテンツにスキップ

title: N10 — SMF ⇔ UDM（Nudm_SDM: SM加入データ取得 参照点） description: SMFとUDMを結ぶN10インターフェース。N4(PFCP)と異なりSBI(Service Based Interface)であり、実体はUDMが提供するサービスNudm（SDM: Subscriber Data Management）。SMFがHTTP/2+JSON over TLS上でセッション管理加入データ（許可DNN・既定QoS等）を取得し、PDUセッション確立の判断に使う仕組みを、Why→What→Howで解説。 keywords: - N10 - Nudm - SDM - UDM - SMF - HTTP2 - SBI - SM加入データ - DNN - TS 29.503 tags: - Interface - Data - Rel-15 category: Interface

N10 — SMF ⇔ UDM（Nudm_SDM: SM加入データ取得 参照点）

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

学習目標

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

  • N10が SBI（Service Based Interface） であり、N4(PFCP/UDP)とはProtocol/Transportが根本的に異なることを説明できる。
  • N10の実体がUDMの提供するサービス Nudm_SDM（Subscriber Data Management, TS 29.503） であることを説明できる。
  • SMFがUDMから セッション管理加入データ（Session Management Subscription Data／許可DNN・既定QoS等） を取得し、PDUセッション確立の判断に使う流れを説明できる。
  • 「参照点N10」と「サービスNudm_SDM」が同じものの2つの見方であることを説明できる。
  • 4G(EPC)の S6a/Gr（MME/SGSN ⇔ HSS, Diameter/MAP） のSM関連加入者プロファイル取得との対応関係を説明できる。

前提知識

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

  • SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
  • N10の両端のNF → SMF / UDM
  • PDUセッション確立で加入データがどう使われるか → PDU Session
  • Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか

SMFはPDUセッションを張る際、「このUEはどのDNN（4GのAPN相当）を使えるのか」「そのDNNの既定のQoS（5QI/ARP）やSession-AMBRは何か」「静的IPを割り当てる契約か」を知らなければなりません。しかしこれらは加入者ごとの契約情報であり、SMF自身が持っているわけではありません。これらは事業者の加入者プロファイルの元締めである UDM（背後のUDRに実データ）にあります。

そこで、SMFがUDMへ「このUEのセッション管理加入データを下さい」と問い合わせる道が要ります。これがN10です。SMFはN10でUDMからSM加入データを取得し、それに基づいて許可DNN・既定QoS・AMBR等を判断してセッションを組み立てます。N10が無ければ、SMFは加入者ごとの契約に沿ったセッション制御ができません。

例え話: N10は、セッション担当（SMF）が本社の会員名簿（UDM）に契約プランを照会するホットラインです。担当は「この客はどのプラン（許可DNN）で、既定の品質（QoS/AMBR）は何か」を専用回線で問い合わせ、その回答に従って回線を張ります。モビリティ担当（AMF）向けの照会窓口が N8 なら、セッション担当（SMF）向けの照会窓口がN10です。

Overview — 概要

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

N10の実体は、UDMが提供するサービス Nudm_SDM（Subscriber Data Management, TS 29.503） です。SMFはこのサービスを呼び出して セッション管理加入データ（Session Management Subscription Data） を取得します。さらに SDM_Subscribe/Notify により、その加入データが変更された場合の変更通知を購読できます。

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

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

Basic Concept — 初心者向け説明

N10を、セッション担当と会員名簿の契約プラン照会に例えます。

あなたのスマホがデータ通信（PDUセッション）を始めようとすると、セッション担当のSMFが動きます。SMFは「この客はどのDNN（接続先）を使ってよくて、既定の品質（QoS）や速度上限（AMBR）はどうか」を自分では持っていないので、会員名簿のUDMに問い合わせます。UDMは契約情報（背後のUDRにある加入データ）を返します。SMFはこの契約情報どおりに、許可されたDNN・既定QoSでセッションを構築します。

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

このWeb APIでは、加入データ（リソース）に「住所（URI）」を与え、そこにGET等のHTTP操作を投げて取得します。さらに「この加入データが変わったら教えて」という購読（Subscribe）を登録しておけば、UDM側から変更通知（Notify）が飛んできます。この作法をRESTfulと呼びます。

Protocol / Transport

項目 内容
Protocol HTTP/2 + JSON（RESTful）— SBI（Service Based Interface）の共通スタック
サービス Nudm_SDM（Subscriber Data Management, 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メソッド(GET/POST/DELETE)＋リソースURIで操作。RESTful

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

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

Architecture

N10がSMFとUDMを結び、UDMが背後のUDR(Nudr)から実データを取り、SMFがN7でPCF・N4でUPFとも連携する文脈を示します。

flowchart LR
  SMF["SMF"]
  UDM["UDM"]
  PCF["PCF"]
  UPF["UPF (転送)"]
  UDR[("UDR (加入データ)")]

  SMF == "N10 (Nudm_SDM / HTTP2)" ==> UDM
  UDM -- "Nudr (加入データ取得)" --> UDR
  SMF -. "N7 (Npcf_SMPolicyControl)" .-> PCF
  SMF == "N4 (PFCP)" ==> UPF

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

図の読み方: 太い線(==>)のN10がSMF⇔UDMのSM加入データ取得（SBI/HTTP2）です。UDMは自らデータを抱えるのではなく、背後の UDR から Nudr で加入データを取り出します。SMFはN10で得た許可DNN・既定QoS等を判断材料に、必要なら N7(Npcf) でPCFへポリシーを問い合わせ、N4(PFCP)でUPFへ転送規則を反映します（右の太線）。N10は「セッションを張るための契約情報の取得」に位置づけられる点に注目してください。

利用Procedure

N10は PDU Session Establishment（PDUセッション確立） の中で、SMFがUDMからSM加入データを取得する際に使われます。

  • SM加入データ取得（Nudm_SDM_Get）: PDU Session確立時、SMFがUDMへ問い合わせ、セッション管理加入データ（許可DNNリスト・DNNごとの既定5QI/ARP・Session-AMBR・静的IP割当有無・UE-AMBR等）を取得する。
  • 変更通知の購読（Nudm_SDM_Subscribe）: 必要に応じて、SMFはその加入データが変わった場合の変更通知（Notify）を購読する。以後、UDM側で加入データが変わると通知が飛ぶ。
  • 判断とその後の連携: 取得した許可DNN・既定QoSに基づき、SMFはセッションを許可/構築するかを判断し、必要なら N7(Npcf)でPCFへポリシー連携、N4(PFCP)でUPFへ転送規則を設定する。

手順の詳細な流れ（メッセージシーケンス、条件、IE等）は PDU Session に集約されています。手順の細部はそちらを参照してください。各オペレーションの正確なメソッド・URI・呼び出し順は要確認とします。

主なMessage

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

サービスオペレーション HTTP操作(概念例) 用途
Nudm_SDM_Get GET（リソース取得） SM加入データ（許可DNN・既定QoS/AMBR等）の取得
Nudm_SDM_Subscribe POST（購読リソース生成） 加入データ変更通知の購読登録
Nudm_SDM_Unsubscribe DELETE（購読リソース削除） 変更通知購読の解除
Nudm_SDM_Notify POST（UDM→SMFへ通知callback） 加入データ変更のSMFへの通知

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

Packet Analysis (Wireshark)

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

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

Decodeの見どころ:

  • N10は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
  • 復号できれば、HTTP/2の ヘッダ（:method = GET等、:path に .../nudm-sdm/... を含むリソースパス）でオペレーションを識別できます。
  • ボディは JSON（SM加入データ、DNN構成、QoS/AMBR情報等）で、人間に読みやすい構造で入っています。
  • N4のPFCP（バイナリ、UDP上）と違い、N10はWeb的（HTTP/JSON）である点が観察の要です。SCTP/PFCP固有のフィルタは使いません。

EPCとの比較

  • 4Gでは: SM関連の加入者プロファイル（APN契約・APNごとの既定QoS・AMBR等）は HSS（Home Subscriber Server） が保持し、MME/SGSN が S6a/Gr（S6aはDiameterベース、TS 29.272）で取得していました。すなわち、モビリティ管理ノード側が加入者プロファイルをまとめて取得し、その中にSM関連の加入情報も含まれていました。
  • 5Gでは: HSSの役割を UDM（実データはUDR）が引き継ぎ、SM加入データの取得は セッション担当のSMFが N10（Nudm_SDM）で直接 行う形に SBI化されました。加入データの取得思想は継続しつつ、Diameterから HTTP/2 + JSON（SBI） へ置き換わっています（TS 29.503）。
4G (EPC) 5G (5GC)
S6a（MME ⇔ HSS）のSM加入部 N10（SMF ⇔ UDM）
Diameter（専用L4上） SBI: HTTP/2 + JSON over TLS
TS 29.272（S6a/S6d） TS 29.503（Nudm_SDM）
APN契約・既定QoS等の加入者プロファイル DNN契約・既定QoS等のSM加入データ

認証ベクトル（AKA）取得はSM加入データとは別系統で、5Gでは N13（UDM⇔AUSF, Nudm_UEAU） 側の話です。N10はあくまでSM加入データ（許可DNN・QoS等）の取得に位置づけられます。

3GPP Specification

  • 3GPP TS 29.503 — Nudm サービス群（Nudm_SDM: Subscriber Data Management, N10）。個別章番号は要確認
  • 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
  • 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N10の定義）
  • 3GPP TS 23.502 — PDUセッション確立等の手順におけるN10（Nudm_SDM）の利用
  • 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N10の実体が Nudm_SDM（TS 29.503）であること、SBI共通framework が TS 29.500/29.501 系であること、参照点N10とサービスNudmが同じ連携の2つの見方であることは、3GPPアーキテクチャの一般的整理です。各サービスオペレーションの細目章番号・正確なリソースURI、およびSM加入データに含まれる具体値（5QI/AMBR等）は Release により差異があるため個別には要確認とします。

Summary

  • N10は SMF ⇔ UDM を結ぶ参照点だが、SBI（Service Based Interface）である点がN4(PFCP/UDP)と根本的に異なる。
  • Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はUDMのサービス Nudm_SDM（Subscriber Data Management, TS 29.503）。
  • SMFはN10で セッション管理加入データ（許可DNN・DNNごとの既定QoS/AMBR等） を取得し、PDUセッション確立の判断に使う。変更通知は SDM_Subscribe/Notify で購読する。
  • 参照点N10 = サービスNudm_SDM は同じSMF⇔UDM連携の2つの見方（本サイトの参照点／サービスの二重性 → UDM）。
  • 4Gの S6a/Gr（MME/SGSN ⇔ HSS, Diameter, TS 29.272） のSM加入部に相当し、5Gでは SBI化（TS 29.503）された。

Next Step

  • UDM — N10の相手側。加入データ管理の中枢（実データはUDR）
  • SMF — N10でSM加入データを取得し、PDUセッションを構築するNF
  • PDU Session — SM加入データを使うPDUセッション確立の手順（詳細）
  • N8 — AMF⇔UDM。モビリティ担当向けの加入データ取得（N10と対の関係）
  • N7 — SMF⇔PCF。取得した加入情報を踏まえたポリシー連携
  • Interface辞典 — N11/N13 ほか参照点の確認