N33 — NEF ⇔ AF（Nnef Northbound API 参照点）¶

学習目標¶

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

• N33が SBI（Service Based Interface） であり、実体がNEFの提供する Nnef Northbound API（TS 29.522） であることを説明できる。
• N33が 非信頼(untrusted)な外部AF が5GCの能力を安全に利用する 窓口 であり、信頼AFが使う N5(PCF直結)とは役割が違うことを説明できる。
• NEFが 認証・認可／データ変換／内部NF隠蔽 を行い、AFの要求を内部NF(PCF/UDM/SMF等)へ橋渡しすることを説明できる。
• N33で扱う能力例（モニタリングイベント購読・デバイストリガ・AF influence・プロビジョニング）を挙げられる。
• 4G(EPC)の SCEF + T8 API（TS 29.122） との対応関係を説明できる。

前提知識¶

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

• SBA / SBI と HTTP/2・TLS の位置づけ → Protocol辞典
• N33の両端のNF/機能 → NEF / AF
• 能力公開（Exposure）とAF influence・QoS要求の使われ方 → QoS
• Interfaceと参照点の考え方 → Interface辞典

Why — なぜ必要なのか¶

5GCの外側には、事業者ネットワークが信頼していない多数の外部アプリケーション（社外のIoTプラットフォーム、コンテンツ事業者、業務アプリ提供者 等＝外部AF）が存在します。これらは「あるデバイスがオンラインになったら知りたい」「特定端末を起こしたい（トリガ）」「この映像フローに優先QoSを付けたい」といった要求を持ちます。しかし、外部の素性の知れないアプリを内部NF（PCF/UDM/SMF等）へ直接つながせるのは、セキュリティ上あり得ません。

そこで、外部AFと内部NFの間に受付・防火壁を置き、そこ越しにだけ能力を公開する道が要ります。これがN33です。外部AFはN33で NEF にだけアクセスし、NEFが身元確認（認証・認可）・データ変換・内部NFの隠蔽を行ってから、要求を内部NFへ取り次ぎます。N33が無ければ、外部AFに5GCの能力を安全に開くすべがなく、能力公開（Exposure）そのものが成立しません。

例え話: N33は、社外のアプリ業者（外部AF）が受付窓口（NEF）越しに5GCの機能を安全に使うための参照点です。受付が身元確認・翻訳・社内地図の秘匿をしてから社内（内部NF）へ取り次ぎ、業者を社内へ直接立ち入らせません。

Overview — 概要¶

N33は AF(外部・非信頼) ⇔ NEF を結ぶ参照点です。N33はSBI（Service Based Interface）であり、共通の転送として HTTP/2 + JSON（RESTful）over TLS を用います。

N33の実体は、NEFが外部に向けて提供する Nnef Northbound API（TS 29.522） です。ここでいう「Northbound（北向き）」とは、NEFから見て外部AFの側（上位）に向けたAPI、という意味です。外部AFはこのAPIを呼び出し、NEFは受けた要求を認可・変換してから、内部NF（PCF/UDM/SMF等）の対応するサービスへ橋渡しします。

重要な区別として、信頼(trusted)なAFは仲介を必要とせず N5（Npcf_PolicyAuthorization）でPCFへ直接つながります。一方、非信頼(untrusted)な外部AFは必ずN33/NEF経由でしかアクセスできません。N33は「安全な窓口」、N5は「信頼済みの直通」という役割分担です。

Basic Concept — 初心者向け説明¶

N33を、社外業者と受付窓口のやり取りに例えます。

社外のアプリ業者（外部AF）が「うちのサービスで、この端末がネットにつながったら通知が欲しい」「この端末を遠隔で起こしたい」「この映像に優先帯域を付けたい」と考えたとします。業者は5GCの社内（内部NF）へ勝手に入れませんから、まず受付窓口（NEF）に要求を出します（N33）。

受付は、まず身元確認（この業者は本当に契約済みか、この操作を頼む権限があるか＝認証・認可）を行い、次に翻訳（業者の言葉を社内フォーマットへ変換＝データ変換）し、さらに社内地図の秘匿（どの部署=内部NFが処理するかを業者に見せない＝内部NF隠蔽）をしたうえで、社内の担当（PCF/UDM/SMF等）へ取り次ぎます。担当からの回答も受付が業者へ返します。

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

Protocol / Transport¶

Architecture¶

N33が外部(非信頼)AFとNEFを結び、NEFが内部NF(PCF/UDM/SMF等)へ橋渡しする一方、信頼AFはN5でPCFへ直結する文脈を示します。

flowchart LR
  extAF["AF (外部・非信頼)"]
  NEF["NEF (能力公開GW)"]
  Core["内部NF (PCF/UDM/SMF)"]
  trustAF["AF (信頼)"]
  PCF["PCF"]

  extAF == "N33 (Nnef Northbound API)" ==> NEF
  NEF -. "Npcf/Nudm等" .-> Core
  trustAF -. "N5" .-> PCF

  classDef gw fill:#efe,stroke:#3a3,stroke-width:2px;
  class NEF gw;

図の読み方: 太い線(==>)のN33が、非信頼な外部AFとNEF（能力公開ゲートウェイ）を結ぶ窓口です。NEFは受けた要求を認可・変換して、点線のように内部NF（PCF/UDM/SMF等）へ取り次ぎます。一方、信頼AFはNEFの仲介を要さず、N5でPCFへ直結します。「非信頼AF＝N33/NEF経由」「信頼AF＝N5/PCF直結」という経路の違いに注目してください。

利用Procedure¶

N33は、外部AFが5GCの公開能力を利用したいときに、NEFへ要求を出す際に使われます。

• モニタリングイベント購読: 外部AFが「特定端末の到達可能性・位置・ロス検知等のイベントを通知してほしい」とN33でNEFへ購読要求。NEFが内部NF（UDM/AMF等）へ変換仲介し、イベント発生時にAFへ通知（notify）する。
• デバイストリガ / パラメータプロビジョニング: 外部AFが端末の起動（トリガ）や、加入者関連パラメータの設定（プロビジョニング）をN33で要求。NEFが対応する内部NFへ橋渡しする。
• AF influence（QoS/ルーティング要求）: 外部AFが特定フローへの優先QoSやトラフィックルーティングへの影響をN33で要求。NEFが認可のうえ PCF 側（AF influence / QoS要求）へ仲介する。

いずれも共通するのは、AFはNEFとしか話さず、内部NFの存在・構造はNEFに隠蔽される点です。NEFが認証・認可・データ変換・隠蔽を担い、AFの要求を内部NFへ変換仲介します。

手順の細部（メッセージシーケンス、条件、IE、正確な操作名等）はReleaseにより差異があるため、個別には要確認とします。AF influenceやQoS要求の応用文脈は QoS を参照してください。

主なMessage¶

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

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

Packet Analysis (Wireshark)¶

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

Decodeの見どころ:

• N33は TLSで暗号化されます。中身（HTTP/2ヘッダやJSONボディ）を見るには復号鍵（TLSセッションキー等）が必要です。鍵が無ければ tls の暗号化ペイロードとしてしか見えません。
• 復号できれば、HTTP/2の ヘッダ（:method = POST等、:path に .../nnef-.../... を含むリソースパス）でオペレーションを識別できます（正確なパスは実装/Release依存、要確認）。
• ボディは JSON（購読条件、通知内容、QoS要求等）で、人間に読みやすい構造で入っています。
• N2のNGAP（バイナリ、SCTP上）と違い、N33はWeb的（HTTP/JSON）である点が観察の要です。SCTP固有のフィルタは使いません。

EPCとの比較¶

• 4Gでは: 外部への能力公開は SCEF（Service Capability Exposure Function） が担い、外部のSCS/AS（≒外部AF）とは T8 API（TS 29.122） で連携しました。ただしSCEFの内部NF側（HSS/MME/PGW等）とのIFはDiameterやOMA-DM等が混在しており、外部向けのT8のみがREST的なAPIでした。
• 5Gでは: SCEFの役割を NEF が引き継ぎ、外部向けAPI（T8相当）が N33（Nnef Northbound API, TS 29.522） として SBI化・整理されました。能力公開（モニタリング・トリガ・プロビジョニング・AF influence等）の思想は継続しつつ、外部AF向けの窓口が HTTP/2 + JSON（SBI） に統一されています。

能力公開（Exposure）の思想自体は4G(SCEF/T8)から継続しています。5Gでの主な変化は、外部AF向けの窓口が SBI（HTTP/2+JSON）化 され、NEF配下で整理された点です。

3GPP Specification¶

• 3GPP TS 29.522 — Nnef Northbound API（能力公開、N33）。個別章番号は要確認
• 3GPP TS 29.500 / TS 29.501 — SBI framework（技術規約 / 設計原則・OpenAPI）。個別章番号は要確認
• 3GPP TS 23.501 §4 — システムアーキテクチャと参照点（N33/NEFの定義）
• 3GPP TS 23.502 — 手続き（Exposure関連プロシージャ）。個別章番号は要確認
• 3GPP TS 33.501 — SBIのセキュリティ（TLS、外部AF認可等）。個別章番号は要確認

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

Summary¶

• N33は AF(外部・非信頼) ⇔ NEF を結ぶ参照点で、SBI（Service Based Interface）である（HTTP/2 + JSON over TLS）。
• 実体はNEFが提供する Nnef Northbound API（TS 29.522）。参照点N33 = サービスNnef Northbound API は同じAF⇔NEF連携の2つの見方。
• N33は 非信頼な外部AF が5GC能力を安全に使う窓口。NEFが認証認可・データ変換・内部NF隠蔽をして内部NF(PCF/UDM/SMF等)へ橋渡しする。
• 公開能力の例＝モニタリングイベント購読・デバイストリガ・AF influence(QoS/ルーティング)・プロビジョニング。信頼AFは仲介不要で N5 でPCFへ直結。
• 4Gの SCEF + T8 API（TS 29.122） に相当し、5Gでは NEF配下で SBI化（TS 29.522）された。

Next Step¶

• NEF — N33の内部側。能力公開ゲートウェイ（認証認可・変換・隠蔽）
• AF — N33の外部側。信頼AF(N5直結)と非信頼AF(N33経由)の別
• N5 — 信頼AF ⇔ PCF の直通参照点。N33との役割の違いを対比
• QoS — AF influence / QoS要求の応用文脈
• Interface辞典 — 参照点の確認 / Message辞典 / Protocol辞典