title: N7 SBI Analysis — Isolating URI / HTTP/2 / ProblemDetails Issues in Four Layers description: A deep-dive chapter on reading N7 (Npcf_SMPolicyControl) between the SMF and the PCF at the packet level. Covers Service Consumer / Producer, the 3GPP API URI structure (apiRoot / apiName / apiVersion / resource), Create / Update / Delete on sm-policies, HTTP status codes, SmPolicyContextData / SmPolicyDecision, HTTP/2 Stream IDs and HPACK, TLS decryption and ProblemDetails, and isolates an "N7 failure" in four layers: IP/TCP/TLS → HTTP/2 → 3GPP API → Policy Logic. keywords: - N7 - SBI - Npcf_SMPolicyControl - sm-policies - HTTP/2 - Stream ID - HPACK - TLS - ProblemDetails - SmPolicyContextData - SmPolicyDecision - NRF - PCF - SMF - 5GC tags: - Level ∞ - Policy - SBI - Troubleshooting category: Deep Dive

N7 SBI Analysis — Isolating URI / HTTP/2 / ProblemDetails Issues in Four Layers¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain the Service Consumer (SMF) / Service Producer (PCF) relationship on N7 and the direction of HTTP client / server
• Read from the 3GPP API URI structure ({apiRoot}/{apiName}/{apiVersion}/{resource}) which NF and which service a request targets
• Explain which method, URI and status code the Create / Update / Delete operations of Npcf_SMPolicyControl use
• Match requests and responses using the HTTP/2 Stream ID, and distinguish "invisible" content caused by HPACK from that caused by TLS
• Read status / cause / invalidParams in ProblemDetails, and break down an "N7 failure" into the four layers plus the stages before and after them
• Correlate N7 → N4 → N2 by SUPI, PDU Session ID and time, and identify where a policy value changed

Prerequisites¶

• PCF / SM Policy Association / PCC Rule — the SM Policy Association and the contents of PCC rules
• N7 — N7 is an SBI and is realized by Npcf_SMPolicyControl
• Supplementary: 5GC overview (SBA / SBI / NRF) / PCF / NRF / HTTP API Dictionary / Packet analysis tips / PFCP and PDR / FAR / QER / URR

Why — "It's an N7 failure" tells you nothing¶

When a fault report only says "N7 failure," the candidate causes are very different:

• The SMF does not know where the PCF is (an NRF discovery problem)
• TCP / TLS cannot be established (a transport problem)
• An HTTP/2 stream was reset (an HTTP/2 problem)
• The PCF returned 4xx (a 3GPP API problem)
• 201 Created came back, but the 5QI is not what was expected (a policy logic problem)

N7 is not a dedicated protocol like N2 (NGAP over SCTP) or N4 (PFCP over UDP); it is an SBI that stacks web technologies (TCP / TLS / HTTP/2 / JSON) (N7). Because there are many layers, unless you can say in which layer the failure happened, you cannot decide who should fix it.

Analogy: N7 is like "a field officer (SMF) asking the rules department (PCF) through the company's internal web system." When no answer comes back, the cause is one of: "cannot reach the internal network," "the system returned an error page," "the request form was filled in wrongly," or "an answer came back but not the expected one." If you are only told "the inquiry failed," you do not know whether to talk to IT, the rules department or the requester.

What — Service Consumer and Service Producer¶

The SMF is the consumer, the PCF is the producer¶

In the SBA, the NF that provides a service is called the NF Service Producer and the NF that uses it the NF Service Consumer (TS 23.501 §7.1, to be confirmed). For Npcf_SMPolicyControl the relationship is as follows (TS 23.502 §5.2.5.4, to be confirmed).

For notifications (UpdateNotify) the direction is reversed¶

When the PCF changes a policy on its own (for example, on a request from an AF or a change in subscription data), the PCF sends Npcf_SMPolicyControl_UpdateNotify to the SMF. In HTTP terms the PCF is the client and the SMF is the server. The target is the notificationUri (callback URI) that the SMF supplied at Create time.

flowchart LR
    SMF["SMF
Consumer"] -- "Create / Update / Delete
SMF = HTTP Client" --> PCF["PCF
Producer"]
    PCF -- "UpdateNotify / Terminate notification
PCF = HTTP Client" --> SMF

What — The URI structure of 3GPP APIs¶

{apiRoot}/{apiName}/{apiVersion}/{resource}¶

3GPP SBI APIs share a common resource URI structure (TS 29.501 §4.4.1, to be confirmed).

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

Example (conceptual):
https://pcf1.example.net:443/npcf-smpolicycontrol/v1/sm-policies/abc123
└────────── apiRoot ────────┘└──── apiName ──────┘└v1┘└── resource ──────┘

In a capture these appear split into the HTTP/2 :authority (the authority part of apiRoot) and :path (including the apiPrefix if there is one, then apiName onwards) (RFC 9113 §8.3.1). If :path contains npcf-smpolicycontrol, you can conclude it is a request to the PCF's SM Policy Control service.

Resources and operations of Npcf_SMPolicyControl¶

TS 29.512 represents an SM Policy Association as an individual resource under the sm-policies collection, and defines Update / Delete as custom operations (verb-like URIs invoked with POST) under the individual resource (TS 29.512 §5.3, sub-clauses to be confirmed).

Create returns the smPolicyId in Location¶

SMF → PCF   POST /npcf-smpolicycontrol/v1/sm-policies
            Body: SmPolicyContextData (supi, pduSessionId, dnn, sliceInfo, notificationUri, ...)

PCF → SMF   201 Created
            location: https://pcf1.example.net/npcf-smpolicycontrol/v1/sm-policies/abc123
            Body: SmPolicyDecision (sessRules, pccRules, qosDecs, ...)

Subsequent Update / Delete URIs only contain the smPolicyId (e.g. abc123). SUPI and PDU Session ID are not necessarily in every body, so to link later transactions to a subscriber it is important to note the Location header of the Create. The format of smPolicyId is chosen by the PCF and is implementation-dependent.

What — The meaning of methods and status codes¶

Do not infer the operation from the method alone¶

In Npcf_SMPolicyControl, Create / Update / Delete are all POST. "It's a POST, so it's a Create" does not hold; look at method + :path + body together. PATCH is used in other SBI APIs (for example NF profile update in Nnrf_NFManagement, TS 29.510 §5.2.2.3, to be confirmed), but does not appear in the main operations of Npcf_SMPolicyControl (to be confirmed).

Reading status codes¶

The general rules for status codes used in the SBI are in TS 29.500 §5.2.7 (to be confirmed).

What — Main attributes of the JSON body¶

Attribute names are checked in TS 29.512 §5.6 (data model, sub-clauses to be confirmed) and in the OpenAPI definition published by 3GPP (TS29512_Npcf_SMPolicyControl.yaml). The following is an excerpt of the main attributes and is not exhaustive. Whether an attribute is mandatory or optional may differ by release, so this page does not assert it (to be confirmed).

SmPolicyContextData (Create request: SMF → PCF)¶

SmPolicyDecision (Create / Update response: PCF → SMF)¶

A PCC rule refers to QoS data in qosDecs by ID through refQosData. Note that in a capture "the 5QI is not written directly in the PCC rule"; you read it by looking up the referenced QoS data.

How — Call Flow¶

The SM Policy Association during PDU Session establishment¶

When dynamic PCC is used, the SMF establishes the SM Policy Association during PDU Session Establishment (TS 23.502 §4.3.2.2.1, §4.16.4).

sequenceDiagram
    participant AMF
    participant SMF
    participant NRF
    participant PCF
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext Request
    opt PCF address unknown
        SMF->>NRF: Nnrf_NFDiscovery Request
target-nf-type=PCF
        NRF-->>SMF: 200 OK (list of PCF NF profiles)
    end
    Note over SMF,PCF: TCP / TLS / HTTP/2 connection (reused if it exists)
    SMF->>PCF: POST sm-policies
SmPolicyContextData
    PCF->>PCF: Policy decision using subscriber policy from UDR, etc.
    PCF-->>SMF: 201 Created + Location
SmPolicyDecision
    Note over SMF: N4 Session Establishment (SMF⇔UPF) follows but is omitted here
    Note over SMF: Map the policy to N1 QoS rules / N2 QoS profile / N4 QER
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer

Signal flow table¶

As procedures, SM Policy Association Establishment / Modification / Termination are specified in TS 23.502 §4.16.4 / §4.16.5 / §4.16.6 (sub-clauses to be confirmed).

PCF selection and the NRF¶

Which PCF the SMF uses is determined by PCF information passed from the AMF, NRF discovery, local configuration, and so on (TS 23.501 §6.3.7.1, to be confirmed). Which takes priority is configuration- and implementation-dependent. Because apiRoot is built from the NF profile in the NRF discovery result (FQDN / IP endpoint / apiPrefix / supported API versions), if the information registered in the NRF is stale or wrong, you get 404s or connection failures even though the PCF is healthy.

How — Isolating in four layers¶

flowchart TD
    L0["⓪ Destination
NRF Discovery / PCF Selection"] --> L1["① IP / TCP / TLS
Reachability, handshake, certificates"]
    L1 --> L2["② HTTP/2
Connection preface, SETTINGS, streams, GOAWAY"]
    L2 --> L3["③ 3GPP API
Method, path, status, ProblemDetails"]
    L3 --> L4["④ Policy Logic
SmPolicyContextData and SmPolicyDecision"]
    L4 --> L5["⑤ Mapping by the SMF
N1 QoS rules, N2 QoS profile, N4 QER"]

The subject of this chapter is the four layers ① to ④, but in practice adding ⓪ (NRF) before and ⑤ (mapping by the SMF) after leaves no gaps.

Layer 1: IP / TCP / TLS¶

The use of TLS on the SBI is specified in TS 33.501, but the operating conditions within a trusted domain (whether TLS is used, or protection is by NDS/IP, etc.) depend on operator policy (to be confirmed). The listening port is also resolved via NRF registration and is not a fixed value (N7).

Layer 2: HTTP/2¶

HTTP/2 multiplexes multiple streams over one TCP connection (RFC 9113 §5).

TCP connection (SMF → PCF)
├─ Stream 1   POST sm-policies             (Create for UE-A)
├─ Stream 3   POST sm-policies/aaa/update  (Update for UE-B)
├─ Stream 5   POST sm-policies             (Create for UE-C)
└─ The response on stream 1 may arrive after the one on stream 3

HPACK — invisible headers are not necessarily the network's fault¶

HTTP/2 headers are compressed with HPACK, and the encoder and decoder keep an independent dynamic table for each direction of the connection (RFC 7541 §2.2 / §2.3.2). If you start capturing in the middle of a connection, headers registered in the dynamic table before that point cannot be referenced, and Wireshark may fail to display :path or :status correctly.

"Unknown header / decoding error" does not necessarily mean the NF sent broken headers. First suspect whether the capture includes the start of the connection (the connection preface and the first SETTINGS).

TLS — you need keys to see the contents¶

N7 protected by TLS is visible only as tls application data without keys.

• To decrypt in Wireshark you must obtain the TLS session keys (key log file) from the NF or the TLS termination point and load them. With TLS 1.3 or (EC)DHE, the server's private key alone is not enough to decrypt.
• Whether keys can be exported and where TLS is terminated (the NF itself, a sidecar, an LB, etc.) are implementation-dependent.
• In test environments without TLS (cleartext HTTP/2), if the listening port differs from Wireshark's defaults it will not be recognized as HTTP/2, so specify HTTP2 with "Decode As" (a Wireshark operation, version-dependent).

Layer 3: 3GPP API¶

If HTTP/2 is healthy, check whether the request / response is correct as Npcf_SMPolicyControl.

ProblemDetails¶

An SBI error response basically carries ProblemDetails in the body (TS 29.500 §5.2.7.1, to be confirmed). The data type is defined in TS 29.571 §5.2.4.1 (to be confirmed) and is the IETF Problem Details format with 3GPP-specific attributes added.

ProblemDetails (main attributes)
├─ type / title / instance   ← from IETF Problem Details
├─ status                    ← same value as the HTTP status code
├─ detail                    ← human-readable explanation (implementation-dependent wording)
├─ cause                     ← 3GPP application error (used for machine decisions)
├─ invalidParams             ← which attribute is invalid (param / reason)
└─ supportedFeatures, etc.

There are two families of cause values.

The wording of detail is implementation-dependent. Use status and cause for decisions, and invalidParams to locate the cause.

Typical 403 and 404¶

With OAuth 2.0, an invalid token typically gives 401 and insufficient scope 403 (RFC 6750 §3.1; use in the SBI per TS 29.500 §6.7.3 / TS 33.501 §13.4.1, all to be confirmed).

Layer 4: Policy Logic¶

Only when the API succeeded do you finally look at the contents of the policy.

flowchart TD
    W["5QI / bit rate differs from expectation"] --> Q1{"Are DNN, S-NSSAI, RAT etc. in
SmPolicyContextData correct?"}
    Q1 -- "No" --> S["SMF-side problem
context generation, subscription data"]
    Q1 -- "Yes" --> Q2{"Are qosDecs and sessRules in
SmPolicyDecision as expected?"}
    Q2 -- "No" --> P["PCF-side problem
policy configuration, policy data in UDR"]
    Q2 -- "Yes" --> E["Suspect the SMF mapping onwards
compare with N1, N2, N4"]

Wrong policy does not necessarily mean a PCF bug. The PCF decides based on the context it received, so always look at the request and the response as a pair.

Also, if the SMF could not apply a PCC rule it received, the SMF can report it to the PCF in an Update as a rule report (ruleReports, with the reason for failure) (TS 29.512 §4.2.4, attribute names and values to be confirmed). "The PCF returned it correctly, but the SMF could not apply it" shows up here.

Breaking down an "N7 failure"¶

In a report, identify at least which of the following it is.

Simply reporting at this granularity greatly speeds up isolation among the teams involved.

Packet Analysis (Wireshark)¶

Display Filter¶

Field names may differ between Wireshark versions (to be confirmed). Note also that responses have no :path, so filtering on :path drops the responses (pick them up again by Stream ID).

Decode example (conceptual)¶

The following is a conceptual representation of the display structure; the values are fictitious examples using the test PLMN (001-01) (capture needed).

Stream 21  HEADERS  (SMF → PCF)
 ├─ :method: POST
 ├─ :scheme: https
 ├─ :authority: pcf1.example.net
 ├─ :path: /npcf-smpolicycontrol/v1/sm-policies
 └─ content-type: application/json
Stream 21  DATA
 └─ JSON: SmPolicyContextData
     ├─ supi: imsi-001010000000001
     ├─ pduSessionId: 1
     ├─ dnn: internet
     ├─ sliceInfo: { sst: 1, sd: 010203 }
     ├─ pduSessionType: IPV4
     ├─ ratType: NR
     └─ notificationUri: https://smf1.example.net/cb/pdu-1

Stream 21  HEADERS  (PCF → SMF)
 ├─ :status: 201
 ├─ location: https://pcf1.example.net/npcf-smpolicycontrol/v1/sm-policies/abc123
 └─ content-type: application/json
Stream 21  DATA
 └─ JSON: SmPolicyDecision
     ├─ sessRules: { sr1: { authSessAmbr: { uplink: 100 Mbps, downlink: 200 Mbps },
     │                      authDefQos: { 5qi: 9, arp: { priorityLevel: 8, ... } } } }
     ├─ pccRules:  { pcc1: { flowInfos: [...], precedence: 100, refQosData: [ qos1 ] } }
     └─ qosDecs:   { qos1: { 5qi: 7, maxbrUl: 10 Mbps, maxbrDl: 10 Mbps } }

Error example (conceptual):

Stream 23  HEADERS  (PCF → SMF)
 ├─ :status: 400
 └─ content-type: application/problem+json
Stream 23  DATA
 └─ JSON: ProblemDetails
     ├─ status: 400
     ├─ cause: MANDATORY_IE_MISSING
     ├─ detail: (implementation-dependent wording)
     └─ invalidParams: [ { param: /sliceInfo, reason: ... } ]

Order of inspection¶

flowchart LR
    A["① Src / Dst
SMF→PCF?"] --> B["② tcp.stream and
Stream ID"]
    B --> C["③ :method
④ :path"]
    C --> D["⑤ :status"]
    D --> E["⑥ Request JSON
⑦ Response JSON"]
    E --> F["⑧ ProblemDetails
status, cause"]

Then link to other interfaces using whatever correlation keys are available, such as SUPI, PDU Session ID, DNN and S-NSSAI.

Correlating N7 → N4 → N2¶

Since the SUPI normally does not appear on N4, it is practical to identify the PFCP session (F-SEID) by time + UE IP address + SMF logs. Subscriber information may be carried in, for example, the PFCP User ID IE, but whether it is used is configuration-dependent (TS 29.244 §8.2.101, to be confirmed).

If the N7 values differ from the N4 / N2 values, you can focus your suspicion after the PCF (on the SMF's policy processing). For reading N4 and N2, see PFCP and PDR / FAR / QER / URR and PDU Session Establishment deep dive.

Trouble Shooting¶

How many times and at what interval the SMF retries when the PCF returns HTTP 500, and whether it switches to another PCF, are implementation-dependent (for choosing an alternative PCF and the NF Set concept, see NF Set / Binding Indication).

Boundary between 3GPP specifications and vendor implementations¶

When a problem occurs on N7, separate a problem in 3GPP API behavior / a transport or platform problem / a vendor implementation problem.

Comparison with EPC (4G)¶

The mapping of Gx Diameter messages is a conceptual correspondence (procedures in TS 29.212 §4.5 and message definitions in §5.6, both to be confirmed). The biggest differences are that result evaluation now has two levels, "HTTP status" and "3GPP cause", and that the destination is determined dynamically through the NRF.

3GPP Specification¶

Summary¶

• N7 is realized by Npcf_SMPolicyControl. SMF = consumer (HTTP client), PCF = producer (HTTP server). For notifications (UpdateNotify) the direction is reversed and the connection is also different
• The URI is {apiRoot}/npcf-smpolicycontrol/v1/sm-policies.... Create is POST → 201 + Location; Update / Delete are POST custom operations (/update, /delete)
• Subsequent transactions can only be identified by the smPolicyId, so note the Location of the Create
• HTTP 2xx ≠ correct policy. Look at the request (SmPolicyContextData) and the response (SmPolicyDecision) as a pair
• Isolate in the order ⓪ NRF → ① IP/TCP/TLS → ② HTTP/2 → ③ 3GPP API → ④ Policy Logic → ⑤ mapping by the SMF
• Match requests and responses by TCP connection + Stream ID. When headers are invisible, suspect the HPACK context and the TLS keys
• Judge errors by status and cause, and locate them with invalidParams. 403 / 404 do not mean "PCF down"
• Correlate N7 → N4 → N2 by SUPI, PDU Session ID and time, and compare values with units aligned

Check your understanding¶

Next Step¶

• How an AF requests QoS from the PCF → AF / N5 / Application Session
• The contents of the policy the PCF returns → PCF / SM Policy Association / PCC Rule / QoS Flow / QFI / 5QI / GFBR / MFBR / AMBR / ARP
• Where the policy ends up in the UPF / gNB → PFCP and PDR / FAR / QER / URR / PDU Session Establishment deep dive
• How a PCF is chosen and made redundant → BSF / PCF Binding / NF Set / Binding Indication / SBI Communication Model
• Reviewing the basics → N7 / PCF / NRF / HTTP API Dictionary / Packet analysis tips