NEF・CAPIF — ネットワーク能力公開と共通APIフレームワーク¶
学習目標¶
この章を読み終えると、次のことができるようになります。
- ネットワーク能力公開(Network Capability Exposure) が「5GC内部の機能を外部アプリへ安全に開放する営み」であることを説明できる
- NEF(Network Exposure Function) が公開の窓口として、認可・変換・トポロジ隠蔽を担うことを説明できる
- 外部AFがNEF経由でできること(QoS要求・位置取得・イベント購読・パラメータ設定など)の代表例を挙げられる
- CAPIF(Common API Framework) が「API発見・認証認可・オンボーディングの共通枠組み」であることを説明できる
- NEF=何を公開するか、CAPIF=どう公開・発見・認可するか、という両者の役割分担を説明できる
前提知識¶
- 5GC概要(SBA) — 内部NFはSBIで相互接続される。NEFはそのSBIを外部へ橋渡しする
- AF(Application Function) — 能力公開の主な利用者。外部AFがNEF経由で5GCへ要求する
- 補助: NEF(NF自体の詳細) / N33(外部⇔NEFの参照点詳細)
この章の焦点
NEFというNF自体の詳細は NEFページ、外部AFとNEFの参照点 N33(Nnef)の詳細は N33ページ、AFの一般論は AFページ にあります。この章はそれらを踏まえ、「能力公開という営み」 と 「NEFとCAPIFの役割分担」 の概念に焦点を当てます。
Why — なぜ能力公開の仕組みが必要か¶
5GCの内部には、UEの位置・到達性、QoS制御、加入者パラメータなど、外部アプリにとって価値ある機能(=能力)が数多くあります。これらを外部のサードパーティやアプリケーション(AF)が使えれば、より高度なサービス(例: 特定フローへの帯域保証、位置連動サービス、IoTデバイス管理)が実現します。
しかし、内部NF(PCF/UDM/AMF等)のSBIをそのまま外部へ露出すると重大な問題が生じます。
- セキュリティ — 外部から内部NFへ直接アクセスされると攻撃面が広がる
- トポロジ秘匿 — 内部の構成(どのNFがどこにいるか、内部識別子)を外部に知られたくない
- 認可 — 「どの外部者が、どの能力を、どこまで使ってよいか」を厳格に管理する必要がある
そこで、外部との間に 専用の窓口 を置き、そこで仲介・認可・変換・秘匿を行う。この窓口が NEF です。
例え話: NEFは「建物の受付カウンター(API窓口)」です。外部の人を建物内部(内部NF)に直接入れず、受付が要件を聞いて適切な部署へ取り次ぎます。受付は来訪者の身元確認(認可)と、内部の座席表を見せない配慮(トポロジ隠蔽)も担います。
What — NEFとCAPIFの2つの概念¶
能力公開には、性質の異なる2つの概念が関わります。
- NEF(何を公開するか) — 5GCの内部能力を外部へ開放する 機能そのもの。窓口として個々の能力(QoS要求、位置、イベント通知…)を提供する。
- CAPIF(どう公開・発見・認可するか) — API公開の 共通の作法。API提供者と利用者の間で、API発見・認証認可・オンボーディングを標準化する枠組み。
NEF — ネットワーク能力公開の窓口¶
NEFは、外部AFの要求を受け、内部NFのSBIへ橋渡しします。単なる中継ではなく、次の役割を担います。
- 認可 — 要求元AFがその能力を使う権利を持つか判定
- 変換 — 外部向けのAPI形式と内部NF向けの形式を相互変換
- 秘匿(トポロジ隠蔽) — 内部識別子・構成を外部へ見せず、外部向けの表現へマッピング
外部AFとNEFの参照点は N33(Nnef) です(TS 23.501)。NEFの定義は TS 23.501、公開手順は TS 23.502 に規定されます。
内部NFへの橋渡し(例)
外部AFの「特定フローに帯域保証を」というQoS要求は、NEFが受けて内部の PCF へ橋渡しします。同様に、加入者パラメータ設定は UDM、位置・到達性のイベント購読は AMF など、能力に応じた内部NFへ取り次ぎます。どの能力がどの内部NFへ向かうかの詳細は NEFページ を参照。
CAPIF — 共通APIフレームワーク¶
個々のAPI(NEFのAPI、他ドメインのAPI…)ごとに、発見・認証・認可の仕組みをバラバラに作るのは非効率です。CAPIF(Common API Framework、TS 23.222) は、これを共通化する3GPP標準の枠組みです。
- API発見 — 利用者が「どんなAPIが提供されているか」を見つけられる
- 認証・認可 — 利用者がAPIを使う資格を統一的に検証する
- オンボーディング — 新しいAPI利用者を登録・受け入れる手順を標準化する
CAPIFは特定機能専用ではなく 汎用の枠組み で、3GPP北向き(Northbound)APIの共通基盤として定義されます。NEFはCAPIFのAPI提供機能(AEF: API Exposing Function)として振る舞える 位置づけです。
NEFとCAPIFは排他ではない
NEFはCAPIFの上で動く「API提供者の一例」です。NEFが公開する能力APIを、CAPIFの共通の作法(発見・認可)に乗せて外部へ届ける、という関係になります。
How — 能力公開の経路(Architecture)¶
外部AF/サードパーティは、参照点 N33 を通じて NEF へ要求し、NEFが内部NF(PCF/UDM/AMF等)へ橋渡しします。CAPIFはその上位で、API発見・認可の共通層として関わります。
graph LR
AF[外部AF / サードパーティ
API利用者] -->|N33 Nnef| NEF[NEF
公開の窓口 / AEF]
NEF -->|SBI| PCF[PCF
QoS/ポリシー]
NEF -->|SBI| UDM[UDM
加入者パラメータ]
NEF -->|SBI| AMF[AMF
位置/到達性イベント]
CAPIF[CAPIF
API発見/認証認可] -.共通の作法.-> NEF
CAPIF -.発見/認可.-> AF
図の要点は、外部AFが内部NFへ 直接触れず、必ずNEFを経由 する点です。CAPIF(点線)は特定の能力を持つのではなく、「どう見つけ・どう認可するか」という作法を提供する層として横断的に関わります。
NEFの代表的な公開機能¶
NEFが外部へ公開する能力の代表例です(網羅ではなく代表のみ。具体的なNnefサービス名・詳細値は要確認)。
| 公開機能(例) | 概要 | 主な橋渡し先(内部NF) |
|---|---|---|
| QoS要求 | 特定フローへ帯域保証等のQoSを要求する | PCF |
| イベント購読 | UEの位置・到達性など特定イベントの通知を受ける | AMF |
| パラメータ設定 | 加入者向けの外部パラメータを設定する | UDM |
| デバイス設定/管理 | IoTデバイス等の設定・監視を行う | 用途に応じた内部NF |
個別APIの正確な定義位置
上記は代表例です。具体的なNnefサービス名・オペレーション名・その正確な定義位置は版により異なるため、精密な引用時は要確認(TS 23.502 / TS 29.522系)。事業者がどの能力を実際に外部提供するかは 実装依存・事業者裁量 です。
NEFとCAPIFの役割対比¶
| 観点 | NEF | CAPIF |
|---|---|---|
| 主眼 | 何を公開するか(5GCの能力) | どう公開・発見・認可するか(共通の作法) |
| 性質 | 具体的な能力を提供する機能(NF) | 汎用のAPIフレームワーク |
| 主な役割 | 認可・変換・トポロジ隠蔽・内部NFへの橋渡し | API発見・認証認可・オンボーディングの標準化 |
| 位置づけ | CAPIF上のAPI提供機能(AEF)になり得る | NEF専用ではない汎用枠組み |
| 主な仕様 | TS 23.501(定義) / TS 23.502(手順) | TS 23.222 |
3GPP Specification¶
| 仕様 | 内容 |
|---|---|
| TS 23.501 | System architecture(NEFの定義・ネットワーク能力公開の位置づけ) |
| TS 23.502 | Procedures(能力公開に関わる手順) |
| TS 23.222 | Common API Framework for 3GPP northbound APIs(CAPIF) |
章番号の粒度
上記TS番号は本領域の主要仕様として確実です。各TS内の詳細な節番号や、個別Nnefサービスの正確な定義位置は版により異なるため、精密な引用時は要確認。
FAQ¶
Q. NEFとCAPIFはどう違うのですか?
NEFは「何を公開するか」=5GCの能力そのものを外部へ開放する窓口機能です。CAPIFは「どう公開・発見・認可するか」=API発見・認証認可・オンボーディングを標準化する共通枠組みです。NEFはCAPIFの上でAPI提供機能(AEF)として振る舞えます。両者は排他ではなく、役割が異なります。
Q. 外部アプリは内部NF(PCF等)へ直接アクセスできないのですか?
原則として直接はアクセスさせません。内部NFのSBIをそのまま外部へ露出するとセキュリティ・トポロジ秘匿・認可の面で問題があるため、必ず NEFを経由 します。NEFが認可・変換・秘匿を行い、適切な内部NFへ橋渡しします。
Summary¶
- ネットワーク能力公開 は、5GC内部の能力を外部AF/サードパーティへ安全に開放する営み
- NEF は公開の窓口。認可・変換・トポロジ隠蔽 を行い、内部NF(PCF/UDM/AMF等)へ橋渡しする。外部との参照点は N33(Nnef)
- 内部NFのSBIをそのまま外に出さず、NEFが仲介することで攻撃面と内部構成の露出を抑える
- CAPIF は API発見・認証認可・オンボーディングを標準化する 汎用の共通枠組み(TS 23.222)
- 役割分担は明快: NEF=何を公開するか、CAPIF=どう公開・発見・認可するか。NEFはCAPIF上のAEFになり得る
理解度チェック¶
Q1. NEFが単なる中継ではなく担う3つの役割を挙げてください。
認可(要求元AFがその能力を使う権利を持つか判定)、変換(外部向けAPI形式と内部NF向け形式の相互変換)、秘匿=トポロジ隠蔽(内部識別子・構成を外部へ見せず外部向け表現へマッピング)。これにより内部NFのSBIを直接露出せず安全に能力を公開できる。
Q2. NEFとCAPIFの役割分担を一言で説明してください。
NEF=何を公開するか(5GCの能力そのものを提供する窓口機能)、CAPIF=どう公開・発見・認可するか(API発見・認証認可・オンボーディングを標準化する汎用枠組み)。NEFはCAPIFのAPI提供機能(AEF)として振る舞える。
Q3. 外部AFがNEF経由で行える代表的な操作を2つ挙げ、それぞれの橋渡し先内部NFを答えてください。
例: QoS要求(特定フローへの帯域保証等)→ PCF へ橋渡し。イベント購読(UEの位置・到達性通知)→ AMF へ橋渡し。他に加入者パラメータ設定→ UDM など。参照点は N33(Nnef)。
Next Step¶
- 公開の窓口となるNFの詳細は NEF へ
- NEFが橋渡しする代表先である Policy(ポリシー制御 / PCF) へ
- 能力公開の主な利用者である AF、参照点の詳細は N33 を確認
- 課金など他の5GC手続きは Charging を参照