UDR — Unified Data Repository¶

難易度: 中級／想定学習時間: 20分／関連NF: UDM, PCF, NEF（フロントエンド）／関連Interface: N35（UDM⇔UDR）, N36（PCF⇔UDR）, N37（NEF⇔UDR）, SBI

学習目標¶

UDRが5GCにおける「データ格納層（永続層）」であり、それ自体は機能ロジックを持たないバックエンドであることを理解する。
UDM/PCF/NEFが「フロントエンド」としてUDRのデータへアクセスする、フロント／バックの分業関係を説明できる。
UDRが格納するデータ種別（加入者データ、ポリシーデータ、構造化データ、アプリデータ、認証データ等）を整理できる。
4GのHSSが機能とデータを一体で持っていたのに対し、5GではUDM（機能）とUDR（データ格納）に分離された進化の意義を理解する。

前提知識¶

UDM/PCFの基礎 → UDM／PCF
SBA（サービスベースアーキテクチャ）／SBI（サービスベースインターフェース）の考え方 → カリキュラム
NF間インターフェースの命名と役割 → Interface辞典

この章で学べること¶

Why（なぜUDRが必要か）→ What（UDRとは何か）→ How（どう使われるか）の順で学びます。本章では特に、加入者・ポリシーデータを扱う「機能ロジック（UDM/PCF/NEF）」と、そのデータを実際に格納する「永続層（UDR）」の分業を主題として掘り下げます。この分業こそがUDRを理解する鍵です。

Why — なぜ必要なのか¶

加入者データやポリシーデータを「扱う機能ロジック」と「永続的に格納する層」を分離すると、格納層を複数の機能で共有しながら、機能側を独立にスケール・共通化できます。データの持ち主を一箇所に集約することで、重複や不整合を避けられます。

例え話: UDRは図書館の「書庫」です。利用者（他NF）への対応を行うのが「司書」にあたるUDM/PCF/NEF（フロントエンド）で、本そのものを保管しておくのが「書庫」であるUDR（バックエンド）です。司書は窓口業務に専念し、書庫は本の保管に専念します。もし書庫が無く、各司書が自分の手元にバラバラに本を抱えていたら、同じ本の重複や版の食い違い（データ不整合）が起きてしまいます。UDRはこの「共通の書庫」の役割を担います。

Overview — 概要¶

UDRは、5GCにおける構造化データの統合格納庫です。加入者データを扱うUDM、ポリシーデータを扱うPCF、外部公開向けデータを扱うNEFといった各フロントエンドが、Nudrサービスを通じてUDRのデータにアクセスします。UDR自体は判断ロジックを持たず、データの格納・取得・更新・削除・購読／通知を提供する永続層に徹します。

なお、構造化データはUDRが担いますが、非構造化データ（unstructured data）は別途UDSF（Unstructured Data Storage Function）が担うとされています（詳細な役割分担は要確認）。

Basic Concept — 初心者向け説明¶

UDRは「窓口」と「倉庫」でいえば倉庫（バック）の側です。利用者からの問い合わせを受け付けたり、条件に応じて何を渡すか判断したりするのは窓口担当（UDM/PCF/NEFといったフロントエンド）の仕事で、UDRはその奥にあってデータを黙々と保管し、頼まれた通りに出し入れする役割を果たします。

窓口（フロント）と倉庫（バック）を分けておくと、窓口の数を増やしたり種類を変えたりしても、倉庫は一つの共通の在庫を保ち続けられます。これがフロント／バック分離の利点です。

Network Function 詳細¶

項目	内容
役割	構造化データの統合的な永続格納層（データリポジトリ）。機能ロジックは持たず、各フロントエンドにデータの格納・取得を提供するバックエンド。
保持情報	加入者データ（subscription data）、ポリシーデータ（policy data）、構造化データ、アプリケーションデータ（application data）、認証データ等の格納。
利用する主なAPI	基本的には被アクセス側（他NFから呼ばれる側）であり、他NFのサービスを能動的に利用する立場ではない。
提供するAPI	Nudr_DataRepository（Query／Create／Update／Delete／Subscribe／Notify）。TS 29.504／29.505。
関連Interface	N35（UDM⇔UDR）、N36（PCF⇔UDR）、N37（NEF⇔UDR）、SBI（Nudr）。
障害時の影響	加入者データやポリシーデータの取得が不可となり、登録・セッション確立・課金など広範な手続きに波及する。影響は重大。

Architecture¶

flowchart TD
    UDM["UDM (加入者フロント)"] -->|N35 / Nudr| UDR["UDR (データ格納庫)"]
    PCF["PCF (ポリシーフロント)"] -->|N36 / Nudr| UDR
    NEF["NEF (公開データフロント)"] -->|N37 / Nudr| UDR
    UDR --- STORE["構造化データ (加入者 / ポリシー / アプリ / 認証)"]

図の読み方: UDM・PCF・NEFはそれぞれ役割の異なる「フロントエンド」であり、いずれも同じバックエンドであるUDRへNudrサービス（N35/N36/N37）でアクセスします。UDMは加入者データ、PCFはポリシーデータ、NEFは公開／アプリデータというように扱う対象は分業されていますが、その実データはすべてUDRという共通の格納庫に集約されます。フロントエンドが機能ロジックを担い、UDRが永続格納を担うという「フロントエンド→バックエンド」の構図が要点です。

Interface¶

Interface	接続	役割
N35	UDM ⇔ UDR	加入者データへのアクセス
N36	PCF ⇔ UDR	ポリシーデータへのアクセス
N37	NEF ⇔ UDR	公開／アプリケーションデータへのアクセス
SBI（Nudr）	各フロント ⇔ UDR	データ操作（格納・取得・更新・削除・購読／通知）

詳細はInterface辞典を参照してください。

Procedure での登場¶

UDRは手続きの表舞台には直接現れず、UDMやPCFといったフロントエンド経由で「裏方」として関与します。

Registration／認証時: UDMがUDRから加入者データ（および認証関連データ）を取得します。→ Registration／Authentication
PDUセッション確立時: SM Policy取得の際に、PCFがUDRからポリシーデータを取得します。

いずれの場合もUDR自身は直接手続きシーケンスの主役としては現れず、UDM/PCF経由でデータを供給する立場です。

EPCとの比較¶

4Gでは、HSS（Home Subscriber Server）が機能ロジックとデータ格納を一体で担っていました。5Gではこれを分離し、機能ロジックをUDM、データ格納をUDRが担う構成になりました。さらに非構造化データはUDSFが分担します。

世代	構成
4G（EPC）	HSS（機能＋データを一体で保持）
5G（5GC）	UDM（機能ロジック）＋ UDR（データ格納）※非構造化はUDSF

分離の意義: データ格納層を共通化しつつ、機能側（UDM/PCF/NEF）を独立にスケール・共通化できるようになり、データの重複や不整合を避けやすくなります。

Release差分¶

Rel-15: UDM/UDR分離アーキテクチャが確立され、UDRが構造化データの統合格納庫として定義された。
Rel-16／Rel-17: 機能拡張が行われている（具体的な拡張内容は要確認）。

3GPP Specification¶

TS 23.501 §6.2.11: UDRの機能定義。
TS 29.504: Nudr（DataRepository）サービス定義。
TS 29.505: UDRが扱うデータ構造の定義（個別の章番号は要確認）。
TS 23.502: 関連手続き（該当箇所は要確認）。

Summary¶

UDRは5GCにおける構造化データの統合格納庫（データ格納層・永続層）であり、機能ロジックを持たないバックエンドである。
UDM（加入者）／PCF（ポリシー）／NEF（公開データ）がフロントエンドとして、NudrサービスでUDR（バックエンド）のデータにアクセスする分業構造をとる。
格納データは加入者データ、ポリシーデータ、構造化データ、アプリデータ、認証データ等で、非構造化データはUDSFが別途担う（要確認）。
4Gでは機能＋データ一体だったHSSが、5GではUDM（機能）とUDR（データ格納）に分離され、共有と独立スケールが両立した。
UDR障害は加入者・ポリシーデータ取得不可を招き、登録・セッション・課金など広範に影響する重大なもの。

Next Step¶

UDM — 加入者データを扱うフロントエンド
PCF — ポリシーデータを扱うフロントエンド
NEF — 外部公開／アプリデータを扱うフロントエンド
NF辞典
Interface辞典