NEF / N33 / Event Exposure — How Much of the 5GC to Show an External AF¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain, following TS 23.501 §6.2.5, that the NEF is not a "proxy that forwards external requests as-is" but a boundary that performs authorization, information hiding and identifier translation
• Explain the difference between N33 (AF⇔NEF) and N5 (AF⇔PCF), and what is translated along the path external AF → NEF → PCF
• Draw the call flows of AF session with required QoS and Event Exposure, and list the correlation keys of each segment (UE IP, AF Identifier, Transaction Reference ID, App Session ID, etc.)
• Isolate, by splitting into four segments, the cases "the API call returned 2xx but QoS has no effect / no notification arrives"

Prerequisites¶

• AF / N5 / Application Session — the basics of Npcf_PolicyAuthorization, with which an AF makes requests to the PCF (the chapter just before this one)
• NEF / N33 / AF / N5 — overviews of each NF and reference point
• Supplementary: NEF & CAPIF (concepts of capability exposure and CAPIF) / SUPI / SUCI / 5G-GUTI (internal identifiers) / QoS / PCF / BSF

Why — why the 5GC must not be shown "as-is" to an external AF¶

External application providers (external AFs) want to ask the 5GC for things like:

• "Prioritize this video flow of this UE" (QoS request)
• "Tell me when this IoT device comes back into coverage" (event notification)
• "I want to tell you the expected movement pattern of this device" (parameter provisioning)

However, opening the SBIs of internal NFs (PCF / UDM / AMF / SMF) directly to the outside causes the following problems.

So a NEF (Network Exposure Function) is placed at the boundary with the outside, and the external AF talks only to the NEF over N33 (TS 23.501 §5.20 / §6.2.5).

Analogy: The NEF is "a bank teller." Customers (external AFs) make requests not with account numbers but with names or membership numbers (GPSI / external ID); the teller verifies identity and authority (authorization), then translates the request into the bank's internal account number (SUPI) and the responsible department (PCF / UDM) before passing it on. The internal account numbers and the staff's extension numbers are never shown to the customer. Even when the teller says "accepted," whether the transfer actually completed must be confirmed through a separate notice.

What — the roles of the NEF (TS 23.501 §6.2.5)¶

NEF functions¶

TS 23.501 §6.2.5 (from Rel-16, §6.2.5.0 NEF functionality; sub-clause numbering to be confirmed) defines the NEF's functions roughly as follows.

Identifier translation and information hiding¶

The identifiers known by the external AF do not match the 5GC's internal identifiers. The NEF bridges this gap, but it does not return internal identifiers to the outside.

flowchart LR
    subgraph EXT["What the external AF knows"]
        E1["GPSI
(External Identifier / MSISDN)"]
        E2["UE IP address
(+ IP Domain)"]
        E3["AF Identifier
AF-Service-Identifier"]
    end
    subgraph NEF["NEF (boundary)"]
        N1["Authorization
(may this AF use this API and this UE?)"]
        N2["Identifier translation / masking"]
    end
    subgraph INT["Internal 5GC keys"]
        I1["SUPI
(mapped from GPSI by the UDM)"]
        I2["Serving PCF / PDU Session
(identified by the BSF binding)"]
        I3["DNN / S-NSSAI"]
    end
    E1 --> N1 --> N2 --> I1
    E2 --> N1
    N2 --> I2
    E3 --> N1
    N2 --> I3

• The format of an External Identifier is <Local Identifier>@<Domain Identifier> (TS 23.003 §19.7.2, to be confirmed).
• According to network policy, the NEF masks network- and user-sensitive information (TS 23.501 §6.2.5). The external-facing UE identifier is the GPSI (TS 23.501 §5.9.8). For example, the BSF response (PCF binding) may contain the SUPI, but the design does not pass it as-is to the external AF. Only information that is allowed to be exposed is returned to the external AF.

N33 / N5 / NEF⇔PCF — the difference between reference points¶

flowchart LR
    XAF["External AF
(AF the operator does not allow direct access)"] == "N33
Northbound API" ==> NEF["NEF"]
    TAF["Trusted AF
(e.g. inside the operator network)"] == "N5
Npcf_PolicyAuthorization" ==> PCF["PCF"]
    NEF -- "NEF⇔PCF
Npcf_PolicyAuthorization
(the NEF acts as an AF)" --> PCF
    NEF -- "Nbsf_Management" --> BSF["BSF"]
    NEF -- "Nudm_EventExposure etc." --> UDM["UDM"]
    UDM -- "Namf_EventExposure" --> AMF["AMF"]
    PCF -- "N7
Npcf_SMPolicyControl" --> SMF["SMF"]

TS 23.501 §6.2.10 states that AFs trusted by the operator can interact directly with relevant NFs, while AFs not allowed direct access use the external exposure framework via the NEF. The key point is that towards the PCF, the NEF calls Npcf_PolicyAuthorization "as an AF." What the PCF sees is the same Policy Authorization App Session, and from there on (PCF → SMF → gNB / UPF) the flow is the same as you learned in AF / N5 / Application Session.

Northbound APIs — the APIs used on N33¶

The N33 APIs are specified in TS 29.522 (5G System; Network Exposure Function Northbound APIs). TS 29.522 reuses and extends some of the 4G SCEF's T8 APIs (TS 29.122) and adds new APIs for 5GS (which API is defined in which specification is, in detail, to be confirmed per version). In particular, for AsSessionWithQoS and MonitoringEvent, the main body of the API definition (resources, attributes, OpenAPI) is in TS 29.122 (T8), and TS 29.522 references and reuses it. When matching a trace against the OpenAPI, look at TS 29.122.

• The resource URI basically takes the form {apiRoot}/3gpp-<API name>/v1/{scsAsId}/subscriptions (TS 29.122 / TS 29.522, version to be confirmed). {scsAsId} is the identifier of the requesting AF and is the entry point of the NEF's authorization decision.
• These are different from the internal-facing APIs that start with nnef-... (TS 29.591 NEF Southbound Services, etc.; the defining specification differs per service, e.g. Nnef_PFDManagement is in TS 29.551). When searching for :path in an N33 trace, look for 3gpp-....
• When the NEF calls internal NFs, it uses the normal internal 5GC SBIs (npcf-policyauthorization, nbsf-management, nudm-ee, namf-evts, etc.).

Where CAPIF fits¶

CAPIF (TS 23.222) is the framework that standardizes "how N33 APIs are discovered, how API consumers are onboarded, and how they are authorized." The NEF can act as an AEF (API Exposing Function) in CAPIF (TS 23.501 §6.2.5.1, to be confirmed). When CAPIF is used, the AF first goes through onboarding, API discovery and authorization at the CAPIF Core Function, and then calls the NEF's (AEF's) Northbound API. See NEF & CAPIF for the concepts.

The security of N33 itself (TLS, authorization based on OAuth 2.0) is specified in TS 33.501 §12 (security of the NEF; sub-clause numbering to be confirmed).

How — Call Flow ①: an external AF requests QoS (AF session with required QoS)¶

This is the procedure in which an external AF requests "apply the pre-agreed QoS to this flow of this UE" (TS 23.502 §4.15.6.6 Setting up an AF session with required QoS, to be confirmed). The following is a conceptual diagram of the case where the NEF identifies the PCF through the BSF and works directly with the PCF.

sequenceDiagram
    participant AF as External 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 authorization / input check
Assign Transaction Reference ID
    NEF->>BSF: Nbsf_Management_Discovery
(UE IP, DNN, S-NSSAI, etc.)
    BSF-->>NEF: PCF binding (address of the serving PCF)
    NEF->>PCF: Npcf_PolicyAuthorization_Create
(media / flow information, QoS Reference, notification target = NEF)
    PCF->>PCF: Authorize request / decide PCC Rule
    PCF-->>NEF: 201 Created (App Session ID)
    NEF-->>AF: 201 Created (Subscription = Transaction Reference ID)
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(add / modify PCC Rules)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N2 SM information, N1 SM information)
    AMF->>RAN: NGAP PDU Session Resource Modify Request (gNB)
    SMF->>RAN: N4 PFCP Session Modification Request (UPF)
    Note over SMF,RAN: Add / modify QoS Flow, RAN admission control
    PCF-->>NEF: Npcf_PolicyAuthorization_Notify
(resource allocation outcome, QoS notification, etc.)
    NEF-->>AF: Notify (to notificationDestination)

Signal flow¶

Correlation information — correlation keys per segment¶

Each time you move to the next segment AF → NEF → PCF → SMF → gNB/UPF, the identifiers in use change. Having a table of which key to follow where speeds up cross-trace analysis.

Analogy: It is like a parcel whose tracking number is replaced each time it passes to another carrier. The AF's receipt number (Transaction Reference ID) → the PCF's slip number (App Session ID) → the SMF's control numbers (PCC Rule / QFI). If you do not know which number to look at in which segment, you lose the parcel along the way.

How — Call Flow ②: Event Exposure (event subscription and notification)¶

This is an example in which an external AF subscribes to "let me know when this UE becomes reachable" (TS 23.502 §4.15.3; the information flow via the NEF is §4.15.3.2.3, to be confirmed).

Representative monitoring events¶

The list of events and the detecting NF are added to or changed by Release (to be confirmed). The enumerated values in the API (e.g., UE_REACHABILITY, LOSS_OF_CONNECTIVITY, LOCATION_REPORTING) are defined in TS 29.122 / TS 29.522.

Call flow¶

sequenceDiagram
    participant AF as External AF
    participant NEF
    participant UDM
    participant AMF
    AF->>NEF: POST 3gpp-monitoring-event
(External ID or MSISDN, monitoringType=UE_REACHABILITY,
notificationDestination, max number of reports, expiry)
    NEF->>NEF: AF authorization / input check
    NEF->>UDM: Nudm_EventExposure_Subscribe
(GPSI, event, notification target = NEF)
    UDM->>UDM: GPSI to SUPI translation / check it is allowed for the subscriber
    UDM->>AMF: Namf_EventExposure_Subscribe
(SUPI, event, notification target = NEF)
    AMF-->>UDM: 201 Created
    UDM-->>NEF: 201 Created
    NEF-->>AF: 201 Created (Subscription URI)
    Note over AMF: The UE becomes reachable via Registration / Service Request, etc.
    AMF->>NEF: Namf_EventExposure_Notify (not via the UDM)
    NEF->>NEF: Map internal subscription to the AF subscription
Translate to external-facing identifier
    NEF->>AF: Notify (to notificationDestination)

Signal flow¶

Packet Analysis (Wireshark)¶

• How N33 (Northbound API) uses HTTP follows "Usage of HTTP" in TS 29.122 / TS 29.522 (§5.2.2, to be confirmed). Because it faces external AFs, both HTTP/1.1 and HTTP/2 are possible (which is mandatory and which is optional is to be confirmed per version). Filtering only on http2.* misses N33 carried over HTTP/1.1.
• N33 with an AF outside the network is protected by TLS (TS 33.501 §12, sub-clause numbering to be confirmed).
• Internal SBIs (NEF⇔BSF / PCF / UDM, PCF⇔SMF, etc.) use HTTP/2 (TS 29.500). TLS support is mandatory, but whether it is actually used is up to the operator (TS 33.501 §13.1, to be confirmed).

To see the content of segments protected by TLS, TLS decryption keys (key log, etc.) are needed.

Display filters¶

Field names may differ depending on the Wireshark version (to be confirmed).

Decode example (conceptual)¶

The following is a conceptual representation of the display structure; all values are fictitious (IPs are documentation / private addresses; attribute names and mandatory/optional status are to be confirmed per version; capture needed). The N33 parts show the case where HTTP/2 is used. With HTTP/1.1, instead of :method / :path there is a request line (POST /3gpp-... HTTP/1.1) and a Host header.

[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": "... (not returned to the outside)" }

[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"
}

Order of checks¶

flowchart LR
    A["① AF⇔NEF
TLS / authorization
Request → 201 or 4xx"] --> B["② Inside the NEF
identifier translation, authorization
(check in logs)"]
    B --> C["③ NEF⇔internal NF
BSF / PCF or UDM / AMF
Request / Response"]
    C --> D["④ After the internal NF
PCF→SMF→N2/N4
or event detection→Notify→callback"]

Trouble Shooting¶

Split failures into four segments¶

flowchart LR
    S1["Segment 1
AF ⇔ NEF
(N33)"] --> S2["Segment 2
Inside the NEF
(authorization, translation)"]
    S2 --> S3["Segment 3
NEF ⇔ internal NF
(BSF / PCF / UDM / AMF)"]
    S3 --> S4["Segment 4
After the internal NF
(PCF→SMF→gNB/UPF,
event detection→Notify)"]

Symptoms and isolation¶

Example A: the QoS request returned 2xx but QoS has no effect¶

Is the AF→NEF request 201 Created? (segment 1)
   ↓
Did the NEF's authorization and translation succeed? (segment 2: NEF log)
   ↓
Was the serving PCF identified via NEF→BSF? Is NEF→PCF Create 201? (segment 3)
   ↓
Was Npcf_SMPolicyControl_UpdateNotify sent PCF→SMF? What is in the PCC Rule? (segment 4)
   ↓
Did SMF→gNB PDU Session Resource Modify succeed? (RAN admission)
Were PDR / QER created by SMF→UPF PFCP Session Modification?
   ↓
Does the actual traffic match the PDR's SDF filter? (direction, ports, addresses)
   ↓
Check QFI on N3, QER in the UPF, QoS in the RAN

Do not judge that QoS is guaranteed or that packet forwarding works from HTTP success alone. If the AF has subscribed to notifications of resource allocation outcome, a failure in segment 4 also shows up as a Notify to the AF.

Example B: the event subscription succeeded but no notification arrives¶

Is the AF→NEF Subscribe 201? (segment 1)
   ↓
Did the internal NEF→UDM and UDM→AMF Subscribes succeed? (segment 3)
   ↓
Did the target event actually occur? (e.g. did the UE really become reachable? AMF logs, NGAP/NAS)
   ↓
Are the expiry, maximum number of reports and target UE (External ID / MSISDN) correct?
   ↓
Was a Notify sent AMF→NEF? Was a Notify sent NEF→AF?
   ↓
Is the TLS / HTTP response at the callback URI normal? (does the AF return 2xx?)

In captures, correlate the Subscribe request / response, the internal Subscribes, the event Notify and the callback, keyed on the subscription URI and the callback URI.

Boundary between 3GPP specifications and vendor implementations¶

Authentication, authorization and rate control themselves are functions that 3GPP anticipates. "The algorithms and concrete values are implementation dependent" does not mean "authorization and throttling are out of the specification's scope."

Comparison with EPC (4G)¶

The skeleton is the same as the 4G SCEF: "show only a gateway to the outside and translate into internal protocols." In the 5GC, the internal side has also been unified into SBI (HTTP/2), and PCF identification via the BSF and combination with CAPIF have been added.

3GPP Specification¶

Summary¶

• The NEF is the boundary that exposes 5GC capabilities to external AFs and performs authorization, information hiding (masking) and identifier translation. It is not a simple proxy; where it hands requests to differs per API (TS 23.501 §6.2.5)
• N33 is external AF⇔NEF (Northbound API, TS 29.522 / TS 29.122); N5 is AF⇔PCF (Npcf_PolicyAuthorization). Towards the PCF, the NEF calls Npcf_PolicyAuthorization as an AF
• What the external AF knows is GPSI (External ID / MSISDN) and UE IP. The SUPI and the serving PCF are internal information, resolved by the UDM (GPSI⇔SUPI) and the BSF (UE IP⇔PCF), and are not returned to the outside
• QoS requests (AF session with required QoS) and Event Exposure are different procedures with different internal destinations (BSF / PCF vs UDM / AMF)
• API 2xx ≠ successful QoS application ≠ successful notification reception. Split failures into the four segments AF⇔NEF / inside the NEF / NEF⇔internal NF / after the internal NF and follow them with each segment's correlation keys
• In 4G, SCEF + T8 played the same role. In the 5GC, the internal side has also been made SBI-based and can be combined with CAPIF

Comprehension check¶

Next Step¶

• How the NEF finds the serving PCF from a UE IP → BSF / PCF Binding (next chapter)
• The App Session the PCF receives beyond the NEF → AF / N5 / Application Session / PCF / SM Policy Association / PCC Rule
• Reading SBI responses and ProblemDetails → N7 SBI analysis
• The big picture of capability exposure and CAPIF → NEF & CAPIF
• Related NFs and reference points → NEF / N33 / AF / N5 / NWDAF (Analytics Exposure)