NEF / N33 / Event Exposure — 外部AFに5GCをどこまで見せるか¶

学習目標¶

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

• NEF が「外部要求をそのまま転送するProxy」ではなく、認可・情報隠蔽・識別子変換 を行う境界であることを、TS 23.501 §6.2.5 に沿って説明できる
• N33（AF⇔NEF） と N5（AF⇔PCF） の違いと、外部AF → NEF → PCF の経路で何が変換されるかを説明できる
• AF session with required QoS と Event Exposure の Call Flow を描き、区間ごとの 相関キー（UE IP、AF Identifier、Transaction Reference ID、App Session ID 等）を挙げられる
• 「API呼び出しは2xxで成功したのにQoSが効かない／通知が来ない」事象を、4つの区間 に分けて切り分けられる

前提知識¶

• AF / N5 / Application Session — AFがPCFへ要求する Npcf_PolicyAuthorization の基本（この章の直前の章）
• NEF / N33 / AF / N5 — 各NF・参照点の概要
• 補助: NEF・CAPIF（能力公開とCAPIFの概念） / SUPI / SUCI / 5G-GUTI（内部識別子） / QoS / PCF / BSF

Why — 外部AFに5GCを「そのまま」見せてはいけない理由¶

外部のアプリケーション事業者（外部AF）は、次のようなことを5GCに頼みたいと考えます。

• 「このUEの、この映像フローを優先してほしい」（QoS要求）
• 「このIoT端末が圏内に戻ったら教えてほしい」（イベント通知）
• 「この端末の想定移動パターンを伝えておきたい」（パラメータ提供）

しかし、内部NF（PCF / UDM / AMF / SMF）のSBIを外部へ直接開くと、次の問題が起きます。

そこで、外部との境界に NEF（Network Exposure Function） を置き、外部AFは N33 でNEFとだけ話す形にします（TS 23.501 §5.20 / §6.2.5）。

例え話: NEFは「銀行の窓口係」です。お客さん（外部AF）は口座番号ではなく名前や会員番号（GPSI / 外部ID）で依頼し、窓口係が本人確認と権限確認（認可）をしてから、行内の口座番号（SUPI）や担当部署（PCF / UDM）に翻訳して取り次ぎます。行内の口座番号や担当者の内線番号は、お客さんには見せません。窓口で「受け付けました」と言われても、振込が実際に完了したかは別の通知で確認する必要があります。

What — NEFの役割（TS 23.501 §6.2.5）¶

NEFの機能¶

TS 23.501 §6.2.5（Rel-16以降は §6.2.5.0 NEF functionality、枝番は要確認）は、NEFの機能をおおむね次のように定めています。

識別子変換と情報隠蔽¶

外部AFが知っている識別子と、5GC内部の識別子は一致しません。NEFはこの差を埋めますが、内部識別子を外部へ返すわけではありません。

flowchart LR
    subgraph EXT["外部AFが知っているもの"]
        E1["GPSI
(External Identifier / MSISDN)"]
        E2["UE IPアドレス
(+ IP Domain)"]
        E3["AF Identifier
AF-Service-Identifier"]
    end
    subgraph NEF["NEF（境界）"]
        N1["認可
(このAFはこのAPI・このUEを扱えるか)"]
        N2["識別子変換・マスキング"]
    end
    subgraph INT["5GC内部の鍵"]
        I1["SUPI
(UDMがGPSIと対応付け)"]
        I2["担当PCF / PDU Session
(BSFのBindingで特定)"]
        I3["DNN / S-NSSAI"]
    end
    E1 --> N1 --> N2 --> I1
    E2 --> N1
    N2 --> I2
    E3 --> N1
    N2 --> I3

• External Identifier の形式は <Local Identifier>@<Domain Identifier> です（TS 23.003 §19.7.2、要確認）。
• NEFは網ポリシーに従い、網情報・ユーザ情報のうち機微な部分を マスキング します（TS 23.501 §6.2.5）。外部向けのUE識別子は GPSI です（TS 23.501 §5.9.8）。たとえばBSFの応答（PCF Binding）にはSUPIが含まれ得ますが、それをそのまま外部AFへ渡す設計にはしません。外部AFへ返すのは 公開が許可された情報だけ です。

N33 / N5 / NEF⇔PCF — 参照点の違い¶

flowchart LR
    XAF["外部AF
(オペレータが直接アクセスを許可しないAF)"] == "N33
Northbound API" ==> NEF["NEF"]
    TAF["信頼されたAF
(オペレータ網内など)"] == "N5
Npcf_PolicyAuthorization" ==> PCF["PCF"]
    NEF -- "NEF⇔PCF
Npcf_PolicyAuthorization
(NEFがAFとして振る舞う)" --> PCF
    NEF -- "Nbsf_Management" --> BSF["BSF"]
    NEF -- "Nudm_EventExposure 等" --> UDM["UDM"]
    UDM -- "Namf_EventExposure" --> AMF["AMF"]
    PCF -- "N7
Npcf_SMPolicyControl" --> SMF["SMF"]

TS 23.501 §6.2.10 は、オペレータが信頼するAFは関連NFと直接やり取りでき、直接アクセスを許可されないAFはNEF経由の外部Exposureフレームワークを使う と定めています。ポイントは、NEFはPCFに対しては「AFとして」Npcf_PolicyAuthorizationを呼ぶ ことです。PCFから見えるのは同じ Policy Authorization の App Session であり、その先（PCF → SMF → gNB / UPF）は AF / N5 / Application Session で学んだ流れと同じです。

Northbound API — N33で使われるAPI¶

N33のAPIは TS 29.522（5G System; Network Exposure Function Northbound APIs）で規定されます。TS 29.522 は、4G SCEFの T8 API（TS 29.122） の一部を再利用・拡張し、5GS向けの新しいAPIを追加する構成です（どのAPIがどちらの仕様で定義されるかの詳細は版により要確認）。特に AsSessionWithQoS と MonitoringEvent は、API定義（リソース・属性・OpenAPI）の本体が TS 29.122（T8） にあり、TS 29.522 から参照・再利用される形です。TraceをOpenAPIと照合するときは TS 29.122 側を見ます。

• リソースURIは {apiRoot}/3gpp-<API名>/v1/{scsAsId}/subscriptions の形が基本です（TS 29.122 / TS 29.522、版は要確認）。{scsAsId} は 要求元AFの識別子 で、NEFの認可判定の入口になります。
• 内部向けの nnef-... で始まるAPI（TS 29.591 NEF Southbound Services など。サービスごとに定義仕様が異なり、例えば Nnef_PFDManagement は TS 29.551）とは別物です。N33のTraceで :path を探すときは 3gpp-... を目印にします。
• NEFが内部NFを呼ぶ際は、通常の5GC内部SBI（npcf-policyauthorization、nbsf-management、nudm-ee、namf-evts 等）になります。

CAPIFの位置づけ¶

N33のAPIを「どう発見させ、どうオンボーディングし、どう認可するか」を共通化する枠組みが CAPIF（TS 23.222）です。NEFはCAPIFにおける AEF（API Exposing Function） として振る舞えます（TS 23.501 §6.2.5.1、要確認）。CAPIFを使う場合、AFはまずCAPIF Core Functionでオンボーディング・API発見・認可を経てから、NEF（AEF）のNorthbound APIを呼びます。概念は NEF・CAPIF を参照してください。

N33自体のセキュリティ（TLS、OAuth 2.0に基づく認可）は TS 33.501 §12（NEFのセキュリティ、枝番は要確認）で規定されます。

How — Call Flow①：外部AFがQoSを要求する（AF session with required QoS）¶

外部AFが「このUEのこのフローに、事前合意したQoSを付けてほしい」と要求する手続きです（TS 23.502 §4.15.6.6 Setting up an AF session with required QoS、要確認）。以下はNEFがBSFでPCFを特定し、PCFと直接連携するケースの概念図です。

sequenceDiagram
    participant AF as 外部AF
    participant NEF
    participant BSF
    participant PCF
    participant SMF
    participant AMF
    participant RAN as gNB / UPF
    AF->>NEF: POST 3gpp-as-session-with-qos
(UE IP, Flow description, QoS Reference, notificationDestination)
    NEF->>NEF: AF認可 / 入力チェック
Transaction Reference ID 割当
    NEF->>BSF: Nbsf_Management_Discovery
(UE IP, DNN, S-NSSAI 等)
    BSF-->>NEF: PCF Binding（担当PCFのアドレス）
    NEF->>PCF: Npcf_PolicyAuthorization_Create
(Media / Flow情報, QoS Reference, 通知先=NEF)
    PCF->>PCF: 要求の認可 / PCC Rule 決定
    PCF-->>NEF: 201 Created（App Session ID）
    NEF-->>AF: 201 Created（Subscription = Transaction Reference ID）
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(PCC Rule 追加・変更)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N2 SM情報, N1 SM情報)
    AMF->>RAN: NGAP PDU Session Resource Modify Request（gNB）
    SMF->>RAN: N4 PFCP Session Modification Request（UPF）
    Note over SMF,RAN: QoS Flow の追加・変更、RANのAdmission Control
    PCF-->>NEF: Npcf_PolicyAuthorization_Notify
(リソース割当の成否、QoS通知 等)
    NEF-->>AF: Notify（notificationDestination 宛）

Signal Flow¶

Correlation 情報 — 区間ごとの相関キー¶

AF→NEF→PCF→SMF→gNB/UPF と区間を進むたびに、使われる識別子が入れ替わります。どこで何をキーに追うかを表にしておくと、Traceの横断が速くなります。

例え話: 荷物の追跡番号が、運送会社をまたぐたびに付け替えられるイメージです。AFの受付番号（Transaction Reference ID）→ PCFの伝票番号（App Session ID）→ SMFの管理番号（PCC Rule / QFI）。どの区間でどの番号を見るかを知らないと、途中で荷物を見失います。

How — Call Flow②：Event Exposure（イベント購読と通知）¶

外部AFが「このUEが到達可能になったら知らせてほしい」と購読する例です（TS 23.502 §4.15.3、NEF経由の情報フローは §4.15.3.2.3、要確認）。

代表的な Monitoring Event¶

イベント一覧と検出NFの対応は Release により追加・変更があります（要確認）。API上の列挙値（例: UE_REACHABILITY、LOSS_OF_CONNECTIVITY、LOCATION_REPORTING）は TS 29.122 / TS 29.522 で定義されます。

Call Flow¶

sequenceDiagram
    participant AF as 外部AF
    participant NEF
    participant UDM
    participant AMF
    AF->>NEF: POST 3gpp-monitoring-event
(External ID または MSISDN, monitoringType=UE_REACHABILITY,
notificationDestination, 最大報告数, 期限)
    NEF->>NEF: AF認可 / 入力チェック
    NEF->>UDM: Nudm_EventExposure_Subscribe
(GPSI, イベント, 通知先=NEF)
    UDM->>UDM: GPSI→SUPI 変換 / 加入者として許可されるか確認
    UDM->>AMF: Namf_EventExposure_Subscribe
(SUPI, イベント, 通知先=NEF)
    AMF-->>UDM: 201 Created
    UDM-->>NEF: 201 Created
    NEF-->>AF: 201 Created（Subscription URI）
    Note over AMF: UEがRegistration / Service Request 等で到達可能になる
    AMF->>NEF: Namf_EventExposure_Notify（UDMを経由しない）
    NEF->>NEF: 内部の購読とAFのSubscriptionを対応付け
外部向け識別子に変換
    NEF->>AF: Notify（notificationDestination 宛）

Signal Flow¶

Packet Analysis (Wireshark)¶

• N33（Northbound API） のHTTPの使い方は TS 29.122 / TS 29.522 の「Usage of HTTP」（§5.2.2、要確認）に従います。外部AF向けのため HTTP/1.1 と HTTP/2 の両方があり得ます（どちらが必須・任意かは版により要確認）。http2.* だけでフィルタすると HTTP/1.1 で流れるN33を取りこぼします。
• 網外のAFとのN33は TLS で保護されます（TS 33.501 §12、枝番要確認）。
• 内部SBI（NEF⇔BSF / PCF / UDM、PCF⇔SMF 等）は HTTP/2 です（TS 29.500）。TLSのサポートは必須ですが、実際に使うかどうかは事業者の判断です（TS 33.501 §13.1、要確認）。

TLSで保護されている区間の中身を見るには、TLSの復号鍵（キーログ等）が必要です。

Display Filter¶

フィールド名はWiresharkの版により異なる場合があります（要確認）。

Decode例（概念表現）¶

以下は表示構造の概念表現で、値はすべて架空例です（IPは文書用アドレス / プライベートアドレス、属性名と必須・任意は版により要確認、要キャプチャ）。N33部分は HTTP/2 で流れた場合の表現です。HTTP/1.1 の場合は :method / :path の代わりにリクエスト行（POST /3gpp-... HTTP/1.1）と Host ヘッダになります。

[N33] AF -> NEF
HEADERS  :method: POST
         :path: /3gpp-as-session-with-qos/v1/af-video-01/subscriptions
DATA (JSON)
{
  "notificationDestination": "https://af.example.com/qos-notify/123",
  "ueIpv4Addr": "10.45.0.23",
  "flowInfo": [
    { "flowId": 1,
      "flowDescriptions": [ "permit out 17 from 198.51.100.10 to 10.45.0.23" ] }
  ],
  "qosReference": "video-premium",
  "events": [ "SUCCESSFUL_RESOURCES_ALLOCATION", "FAILED_RESOURCES_ALLOCATION" ]
}

[N33] NEF -> AF
HEADERS  :status: 201
         location: https://nef.example.net/3gpp-as-session-with-qos/v1/af-video-01/subscriptions/sub-0001

[NEF -> BSF]
HEADERS  :method: GET
         :path: /nbsf-management/v1/pcfBindings?ipv4Addr=10.45.0.23
  -> 200 OK  { "dnn": "internet", "pcfFqdn": "pcf-2.example.net", "supi": "...（外部へは返さない）" }

[NEF -> PCF]
HEADERS  :method: POST
         :path: /npcf-policyauthorization/v1/app-sessions
  -> 201 Created  location: .../app-sessions/as-77

[N33] AF -> NEF
HEADERS  :method: POST
         :path: /3gpp-monitoring-event/v1/af-iot-02/subscriptions
DATA (JSON)
{
  "externalId": "[email protected]",
  "monitoringType": "UE_REACHABILITY",
  "reachabilityType": "DATA",
  "notificationDestination": "https://af.example.com/mon-notify/9",
  "maximumNumberOfReports": 1,
  "monitorExpireTime": "2026-10-19T00:00:00Z"
}

見る順番¶

flowchart LR
    A["① AF⇔NEF
TLS / 認可
Request → 201 or 4xx"] --> B["② NEF内部
識別子変換・認可
(ログで確認)"]
    B --> C["③ NEF⇔内部NF
BSF / PCF または UDM / AMF
のRequest / Response"]
    C --> D["④ 内部NF以降
PCF→SMF→N2/N4
または Event検出→Notify→Callback"]

Trouble Shooting¶

障害を4区間に分ける¶

flowchart LR
    S1["区間1
AF ⇔ NEF
(N33)"] --> S2["区間2
NEF内部
(認可・変換)"]
    S2 --> S3["区間3
NEF ⇔ 内部NF
(BSF / PCF / UDM / AMF)"]
    S3 --> S4["区間4
内部NF以降
(PCF→SMF→gNB/UPF、
Event検出→Notify)"]

症状と切り分け¶

例A：QoS Request は 2xx なのに QoS が効かない¶

AF→NEF の Request は 201 Created か？（区間1）
   ↓
NEFの認可・変換は成功したか？（区間2：NEFログ）
   ↓
NEF→BSF で担当PCFを特定できたか？ NEF→PCF の Create は 201 か？（区間3）
   ↓
PCF→SMF に Npcf_SMPolicyControl_UpdateNotify が出たか？ PCC Rule の内容は？（区間4）
   ↓
SMF→gNB の PDU Session Resource Modify は成功したか？（RAN Admission）
SMF→UPF の PFCP Session Modification で PDR / QER は作られたか？
   ↓
実トラフィックが PDR の SDF Filter にマッチしているか？（方向・ポート・アドレス）
   ↓
N3 の QFI、UPF の QER、RAN の QoS を確認

HTTPの成功だけで、QoS保証やパケット転送が成立したとは判断しません。リソース割当の成否通知をAFが購読していれば、区間4の失敗はAFへの Notify としても現れます。

例B：Event Subscription は成功したのに通知が来ない¶

AF→NEF の Subscribe は 201 か？（区間1）
   ↓
NEF→UDM、UDM→AMF の内部 Subscribe は成功しているか？（区間3）
   ↓
対象イベントは実際に起きたか？（例: UEが本当に到達可能になったか、AMFのログ・NGAP/NAS）
   ↓
購読の期限・最大報告数・対象UE（External ID / MSISDN）の指定は正しいか？
   ↓
AMF→NEF の Notify は出ているか？ NEF→AF の Notify は出ているか？
   ↓
Callback URI への TLS / HTTP 応答は正常か？（AF側が 2xx を返しているか）

Captureでは、Subscribe Request / Response、内部Subscribe、Event Notify、Callback を、Subscription URI と Callback URI をキーに相関させます。

3GPP仕様とVendor実装の境界¶

認証・認可や流量制御そのものは3GPPが想定する機能です。「アルゴリズムや具体値は実装依存」であって、「認可やthrottlingが仕様外」という意味ではありません。

EPC（4G）との比較¶

骨格は4GのSCEFと同じく「外部には窓口だけを見せ、内部プロトコルへ翻訳する」です。5GCでは内部側もSBI（HTTP/2）に統一され、BSFによるPCF特定やCAPIFとの組合せが加わりました。

3GPP Specification¶

Summary¶

• NEF は外部AFに5GCの能力を公開する境界で、認可・情報隠蔽（マスキング）・識別子変換 を担う。単純なProxyではなく、APIごとに取次先が異なる（TS 23.501 §6.2.5）
• N33 は外部AF⇔NEF（Northbound API、TS 29.522 / TS 29.122）、N5 はAF⇔PCF（Npcf_PolicyAuthorization）。NEFはPCFに対して AFとして Npcf_PolicyAuthorization を呼ぶ
• 外部AFが知るのは GPSI（External ID / MSISDN）・UE IP。SUPIや担当PCFは内部の情報で、UDM（GPSI⇔SUPI）やBSF（UE IP⇔PCF）で解決し、外部へは返さない
• QoS要求（AF session with required QoS）と Event Exposure は別の手続きで、内部の接続先も異なる（BSF / PCF と UDM / AMF）
• API の 2xx ≠ QoS 適用成功 ≠ 通知受信成功。障害は AF⇔NEF / NEF内部 / NEF⇔内部NF / 内部NF以降 の4区間に分け、区間ごとの相関キーで追う
• 4Gでは SCEF + T8 が同じ役割を担っていた。5GCでは内部もSBI化され、CAPIFと組み合わせられる

理解度チェック¶

Next Step¶

• NEFがUE IPから担当PCFを見つける仕組み → BSF / PCF Binding（次章）
• NEFの先でPCFが受け取るApp Session → AF / N5 / Application Session / PCF / SM Policy Association / PCC Rule
• SBIの応答とProblemDetailsの読み方 → N7 SBI解析
• 能力公開とCAPIFの全体像 → NEF・CAPIF
• 関連NF・参照点 → NEF / N33 / AF / N5 / NWDAF（Analytics Exposure）