title: N18 — NF ⇔ UDSF（Nudsf: 非構造化データ格納の参照点） description: 任意のNFとUDSFを結ぶN18インターフェース。N2/N4と異なりSBI(Service Based Interface)であり、実体はUDSFが提供するサービスNudsf。HTTP/2+JSON over TLS上で、NFが内部状態（非構造化データ）をUDSFへ格納・取得しステートレス化する仕組みを、Why→What→Howで解説。 keywords: - N18 - Nudsf - UDSF - unstructured data - stateless NF - HTTP2 - SBI - 非構造化データ - TS 29.598 tags: - Interface - Data - Rel-15 category: Interface

N18 — NF ⇔ UDSF（Nudsf: 非構造化データ格納の参照点）¶

学習目標¶

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

• N18が SBI（Service Based Interface） であり、N2(NGAP/SCTP)やN4(PFCP/UDP)とはProtocol/Transportが根本的に異なることを説明できる。
• N18の実体が UDSF の提供するサービス Nudsf（Unstructured Data Storage, TS 29.598） であることを説明できる。
• 任意のNFが 内部状態（非構造化データ）をUDSFへ格納・取得 し、NFをステートレス化する流れを説明できる。
• 「参照点N18」と「サービスNudsf」が同じものの2つの見方であることを説明できる。
• 構造化データ用の N35/N36/N37（UDR側） との棲み分け（構造化 vs 非構造化）を説明できる。

前提知識¶

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

• SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
• N18の相手側NFと、対比となる構造化データ層 → UDSF / UDR
• Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

各NFが自分の内部状態（処理途中のコンテキスト等）を自分の中だけで抱えていると、そのNFインスタンスが落ちた瞬間に状態も失われ、他インスタンスへ引き継げません。そこで、内部状態を外部の共通ストレージ（UDSF）へ預けておくと、NFインスタンスは状態を持たない（ステートレスな）作りに近づけられ、インスタンスの追加・入れ替え・障害復旧が容易になります。

この「NFの内部状態（非構造化データ）を外部のUDSFへ預ける／取り出す」ための道がN18です。N18が無ければ、NFは状態を自分の中に抱え込むしかなく、ステートレス化の設計を取りにくくなります。

例え話: NF=荷物を持って動き回る人、UDSF=コインロッカーです。N18は、その人がロッカーに荷物（内部状態）を預けたり取り出したりするやり取りの経路にあたります。荷物を預けておけば身軽に動け、別の窓口（別インスタンス）でも同じロッカーから取り出して続きを行えます。

Overview — 概要¶

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

N18の実体は、UDSFが提供するサービス Nudsf（TS 29.598） です。利用側のNFはNudsfを通じて、非構造化データ（各NF内部の状態・コンテキスト等）を 格納・取得・更新・削除・購読／通知 します。ここでいう「非構造化」とは、3GPPが標準としてデータ構造を規定しないデータを指し、その中身の解釈は預けたNF側に委ねられます。

Basic Concept — 初心者向け説明¶

N18を、人とコインロッカーのやり取りに例えます。

あるNFが処理の途中経過や接続中の相手の情報（コンテキスト）を持っているとします。これを自分の中だけに抱えると、そのNFが壊れた瞬間に情報ごと失われます。そこでNFは、共通のロッカーであるUDSFに状態を預けます（格納）。別のインスタンスや別の場面では、同じロッカーから状態を取り出して（取得）続きを進められます。状態が変わったら書き直し（更新）、不要になれば片付ける（削除）こともできます。

このUDSFへの預け入れ・取り出しは、専用の電話回線（N2やN4のような専用プロトコル）ではなく、社内Webシステム（HTTP）でリクエストを投げて回答をもらうイメージです。これが SBI（Service Based Interface）＝NF同士がWeb API（HTTP/2）で会話する仕組みです。

Protocol / Transport¶

Architecture¶

N18が任意のNFとUDSFを結び、非構造化データを格納する構図を、構造化データ側（UDR：N35/N36/N37）と対比して示します。

flowchart LR
  NF1["NF (例: AMF/SMF 等)"]
  NF2["別インスタンス / 別NF"]
  UDSF["UDSF"]
  UDR["UDR"]

  NF1 == "N18 (Nudsf / HTTP2)" ==> UDSF
  NF2 == "N18 (Nudsf / HTTP2)" ==> UDSF
  UDM["UDM/PCF/NEF"] -- "N35/N36/N37 (Nudr)" --> UDR

  classDef store fill:#efe,stroke:#3a3,stroke-width:2px;
  class UDSF,UDR store;

図の読み方: 太い線(==>)のN18が、任意のNF（AMF/SMF等）とUDSFの連携（SBI/HTTP2）で、NFはここに非構造化データ（内部状態・コンテキスト）を預けます。状態を外部化することで、別インスタンスや別NFが同じUDSFから取り出せます。下段に対比として示したのは 構造化データ側で、UDM/PCF/NEFが N35/N36/N37（Nudr） で UDR にアクセスします。N18＝非構造化（UDSF）／N35-37＝構造化（UDR） という棲み分けに注目してください。

利用Procedure¶

N18は特定の標準手続きの主役ではなく、NFのステートレス実装を支える裏方として、状態の格納・取得の局面で使われます。

• 格納（Create/Update）: NFが自分の非構造化データ（コンテキスト等）をUDSFへ書き込む／更新する。
• 取得（Query/Get）: 別インスタンスや別場面で、預けた状態をUDSFから読み出す。
• 削除（Delete）: 不要になった状態を片付ける。
• 購読／通知（Subscribe/Notify）: 状態変化の通知を購読し、変更時に通知を受ける。

どのNFがどの非構造化データをUDSFに預けるか、その実行条件・順序・データ内容は 実装・展開依存であり、3GPP手続きとして固定的に規定されるものではありません（要確認）。UDSFの位置づけ全体は UDSF を参照してください。

主なMessage¶

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

HTTP操作の対応は概念整理です: 上表の「HTTP操作」は理解のための対応づけであり、各操作の正確なメソッド・リソースURI・呼び出し方向はTS 29.598のOpenAPI定義に従います。厳密なメソッド割り当ては要確認とします。

Packet Analysis (Wireshark)¶

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

Decodeの見どころ:

• N18は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
• 復号できれば、HTTP/2の ヘッダ（:method = GET/PUT/POST/DELETE等、:path に .../nudsf/... を含むリソースパス）で操作を識別できます。
• ボディは JSON で運ばれますが、中身の非構造化データは各NF固有であり、3GPPが構造を標準化していない点に注意します（解釈は預けたNF依存）。
• N2のNGAP（バイナリ、SCTP上）と違い、N18はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタ（sctp.port 等）は使いません。

EPCとの比較¶

4G（EPC）には、NFの内部状態（非構造化データ）を共通ストレージへ外部化する参照点として、N18に直接相当する標準インターフェースは定義されていません（要確認）。これは、非構造化データの外部格納によるNFのステートレス化が、5GのSBA志向の中で整理された考え方だからです。構造化データ側では、4Gの HSS（加入者マスタ）が 5Gで UDM＋UDR に分離され、UDR側の参照点として N35/N36/N37 が定義された流れと対をなします。

3GPP Specification¶

• 3GPP TS 29.598 — Nudsf（Unstructured Data Storage）サービス（N18の実体）。個別章番号は要確認
• 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
• 3GPP TS 23.501 §4.2 — システムアーキテクチャの参照点表現（N18=NF⇔UDSFの定義。Figure/枝番は要確認）。※UDSFの機能定義自体は §6.2系（UDSF 参照）
• 3GPP TS 33.501 — SBIのセキュリティ（TLS等）。個別章番号は要確認

注記（要確認）: N18がUDSFの参照点であること、実体が Nudsf（TS 29.598）であること、SBI共通framework が TS 29.500/29.501 系であることは、3GPPアーキテクチャの一般的整理です。各操作の細目章番号・正確なリソースURI・HTTPメソッド割り当ては Release により差異があるため個別には要確認とします。どのNFがどの非構造化データを預けるかは実装・展開依存です。

Summary¶

• N18は 任意のNF ⇔ UDSF を結ぶ参照点だが、SBI（Service Based Interface）である点がN2(NGAP/SCTP)・N4(PFCP/UDP)と根本的に異なる。
• Protocolは HTTP/2 + JSON（RESTful）over TLS、実体はUDSFのサービス Nudsf（TS 29.598）。
• NFは非構造化データ（内部状態・コンテキスト）をN18経由でUDSFへ 格納・取得 し、ステートレス化を図る。
• 参照点N18 = サービスNudsf は同じNF⇔UDSF連携の2つの見方（参照点の視点／サービスの視点）。
• N18＝非構造化データ（UDSF）／N35-37＝構造化データ（UDR） という棲み分け。どのデータを預けるかは実装・展開依存（要確認）。

Next Step¶

• UDSF — N18の相手側。非構造化データ格納NF
• UDR — 構造化データ格納層（N35/N36/N37 側との対比）
• N35 — UDM⇔UDR（構造化データ側の参照点）
• Interface辞典 — 参照点の確認