PCF / SM Policy Association / PCC Rule — How Policy Reaches the UE, gNB and UPF¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that an SM Policy Association is a per-PDU-Session relationship between the SMF and the PCF, established with Npcf_SMPolicyControl_Create
• List the inputs to PCF decisions (input from the SMF / Policy Data in the UDR / AF requests, etc.)
• Explain the components of a PCC Rule (SDF template, precedence, QoS parameters, charging, gate status)
• Explain with a diagram that the PCF does not configure the UE, gNB or UPF directly, and that the SMF translates PCC Rules into QoS Rules (N1) / QoS Flow Level QoS Parameters (N2) / PDR, QER, URR (N4)
• Explain the flow from PCF-initiated SM Policy Association Modification to Network requested PDU Session Modification
• Isolate "the policy does not arrive", "the PCF is correct but the UPF is wrong" and "only the RAN is wrong" by looking across interfaces

Prerequisites¶

• GFBR / MFBR / AMBR / ARP / QoS Flow / QFI / 5QI — the QoS contents a PCC Rule specifies
• PFCP and PDR / FAR / QER / URR / PDR / PDI / SDF Filter / Precedence — how the result of the SMF's translation is used in the UPF
• PDU Session Establishment deep dive — how the AMF carries N1 SM / N2 SM information
• Supplementary: Policy / PCF / N7 / QoS / PDU Session Modification / Release

Why — the one who decides the QoS "values" is not the one who executes them¶

Up to the previous chapter, we looked at QoS values such as 5QI, GFBR, MFBR, Session-AMBR and ARP. So for a given flow of a given subscriber, who decides those values, and who configures them in each node?

• Deciding the values requires looking at the subscription (UDR), the destination (DNN / S-NSSAI), application requirements (AF) and operator policy as a whole. This is more consistent when concentrated in a dedicated policy NF rather than in individual nodes → the PCF.
• On the other hand, the UE, gNB and UPF are each configured with a different protocol (NAS / NGAP / PFCP) and a different information format. The one that can talk to all three is the SMF, which manages the PDU Session.

5GC therefore uses a division of labor in which the PCF decides (Policy Decision) and the SMF translates and deploys it (control of policy enforcement) (TS 23.503 §4.2 / §6.2.1, to be confirmed).

Analogy: The PCF is "the pricing and service planning department at head office", and the SMF is "the on-site construction manager". The planning department writes a policy document (PCC Rule) saying "this customer's video is capped at 10 Mbps", but it does no wiring. The construction manager reads the policy document and rewrites it into a manual for the handset (QoS Rule), an instruction sheet for the base station (QoS Profile) and settings for the switch (PDR / QER), and hands each one out.

What — SM Policy Association¶

Types of Policy Association held by the PCF¶

The PCF holds a Policy Association per peer NF. This chapter deals with the SM Policy Association.

One SM Policy Association is created per PDU Session; it is born with PDU Session establishment and ends with its release (TS 23.502 §4.16.4 / §4.16.6).

Lifecycle of an SM Policy Association¶

What — what does the PCF base its policy on?¶

The inputs the PCF can use for PCC decisions are listed in TS 23.503 §6.2.1.2 (Input for PCC decisions, to be confirmed). The representative ones are organized below by where they come from.

flowchart LR
    SMF["SMF
Npcf_SMPolicyControl_Create / Update"] -->|"SUPI, DNN, S-NSSAI,
RAT/Access Type, ULI,
UE IP, subscribed Session-AMBR,
subscribed default QoS"| PCF["PCF
Policy Decision"]
    UDR["UDR
Policy Data"] -->|"N36 / Nudr
SM Policy Data,
Usage Monitoring Data"| PCF
    AF["AF
(direct or via NEF)"] -->|"N5 / Npcf_PolicyAuthorization
media and application info"| PCF
    CHF["CHF"] -->|"N28 Spending Limit
(policy counter status)"| PCF
    OP["Operator policy
(PCF local configuration)"] --> PCF
    PCF -->|"SmPolicyDecision
PCC Rule / Session Rule / PCRT"| SMF

The important point here is that the subscriber's "subscribed" Session-AMBR / default QoS are passed UDM → SMF → PCF, and the PCF returns them to the SMF as "authorized" values (TS 23.503 §6.4, to be confirmed). In deployments with a PCF, what the SMF ultimately uses are the values the PCF authorized.

What — the PCF's output: SmPolicyDecision¶

On N7, the PCF's decision is passed to the SMF in a data structure called SmPolicyDecision (TS 29.512 §5.6.2.4, to be confirmed). Its contents fall broadly into three kinds.

Structure of a PCC Rule (TS 23.503 §6.3.1)¶

The table in TS 23.503 §6.3.1 (PCC rule information, to be confirmed) is summarized below by purpose.

PCC Rule
├─ Rule identifier                 ← unique within the PDU Session
├─ Service data flow detection     ← which traffic
│   ├─ Precedence                  ← evaluation order when rules overlap
│   └─ SDF template                ← one of the following
│       ├─ List of SDF filters      ← set of packet filters (IP 5-tuple, etc.)
│       └─ Application identifier  ← detect by application ID
├─ Policy control                  ← how to handle it
│   ├─ Gate status                 ← pass / block
│   ├─ 5QI / ARP                   ← QoS class and priority / pre-emption
│   ├─ UL / DL Maximum bitrate     ← per-SDF cap
│   ├─ UL / DL Guaranteed bitrate  ← for GBR
│   └─ QoS Notification Control, etc.
├─ Charging                        ← how to charge
│   ├─ Charging key (Rating Group)
│   ├─ Service identifier
│   ├─ Charging method / Measurement method
│   └─ ...
├─ Usage monitoring control        ← usage monitoring
└─ Traffic steering related (AF influence, etc.)

How — establishing the SM Policy Association¶

Call Flow (inside PDU Session Establishment)¶

In TS 23.502 §4.3.2.2.1, the SMF establishes the SM Policy Association after PCF selection (steps 7a / 7b), and supplements the information with an SMF-initiated Modification after UE IP address allocation (step 9). Step numbers differ by release in both cases (to be confirmed). Simplified together with the contents of §4.16.4, it looks like this.

sequenceDiagram
    participant UE
    participant AMF
    participant SMF
    participant PCF
    participant UDR
    participant UPF
    UE->>AMF: PDU Session Establishment Request (N1)
    AMF->>SMF: Nsmf_PDUSession_CreateSMContext
    Note over SMF: Get SM subscription data from UDM
(subscribed Session-AMBR / default QoS)
    Note over SMF: PCF Selection (NRF Discovery, etc.)
    SMF->>PCF: Npcf_SMPolicyControl_Create
(SUPI, DNN, S-NSSAI, RAT, ULI, subscribed QoS, etc.)
    PCF->>UDR: Nudr_DM_Query (SM Policy Data)
    UDR-->>PCF: Policy Data
    PCF->>UDR: Nudr_DM_Subscribe (subscribe to change notifications)
    Note over PCF: Policy Decision
    PCF-->>SMF: 201 Created + SmPolicyDecision
(Session Rule, PCC Rule, PCRT)
    Note over SMF: UPF Selection and UE IP allocation
    SMF->>PCF: Npcf_SMPolicyControl_Update
(PCRT condition met, e.g. UE IP allocated)
    PCF-->>SMF: Updated policy (if any)
    Note over SMF: QoS Flow binding and QFI allocation
(translate PCC Rules)
    SMF->>UPF: PFCP Session Establishment
(PDR / FAR / QER / URR)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: QoS Rules etc. / N2: QoS Flow info)

Signal Flow¶

If a BSF is deployed, the PCF registers binding information for the SM Policy Association in the BSF (Nbsf_Management_Register; TS 23.502 §5.2.13.2.2. The trigger for registration (when the UE IP / MAC is determined; §4.16.4 / §4.16.5.1) is to be confirmed). This is the mechanism by which an AF finds "the PCF serving this UE's session"; details are covered in BSF / PCF Binding.

How — the most important diagram: the PCF does not configure directly; the SMF translates¶

The PCF does not send PFCP to the UPF, does not send NGAP to the gNB, and does not send 5GSM messages to the UE. The PCF's output is only the SmPolicyDecision on N7; translating it into each node's language is the SMF's job.

flowchart TD
    PCF["PCF
SmPolicyDecision
PCC Rule + Session Rule"] -->|"N7
Npcf_SMPolicyControl"| SMF["SMF = translator
QoS Flow binding
QFI allocation"]
    SMF -->|"N4 PFCP
PDR / QER / URR / FAR"| UPF["UPF
detection, gate, rate, metering"]
    SMF -->|"Namf_Communication_N1N2MessageTransfer
N1 SM container + N2 SM information"| AMF["AMF
relay only"]
    AMF -->|"NAS 5GSM
QoS Rules / QoS Flow Descriptions / Session-AMBR"| UE["UE
UL packet → QFI"]
    AMF -->|"NGAP
QFI + QoS Flow Level QoS Parameters"| GNB["gNB
QoS Flow → DRB"]

PCF ──X──► UPF     does not speak PFCP (the controlling side of N4 is the SMF)
PCF ──X──► gNB     does not speak NGAP (the N2 peer is the AMF)
PCF ──X──► UE      does not send SM QoS Rules (the N1 SM peer is the SMF)

What is the SMF doing — QoS Flow binding and translation¶

TS 23.501 §5.7.1.5 (QoS Flow mapping, to be confirmed) organizes the SMF's role as follows.

1. QoS Flow binding: decide, for each PCC Rule, whether to put it into an existing QoS Flow or create a new QoS Flow. The binding parameters used are 5QI and ARP (plus QNC, Priority Level, Averaging Window and MDBV if set) (TS 23.503 §6.1.3.2.4, to be confirmed). PCC Rules with the same binding parameters are grouped into the same QoS Flow.
2. QFI allocation: the SMF allocates a QFI per QoS Flow.
3. Translation: decompose the QoS Flow / PCC Rule information into the form each of the UE, gNB and UPF needs.

(N1: TS 24.501 §9.11.4.12 QoS flow descriptions / §9.11.4.13 QoS rules / §9.11.4.14 Session-AMBR; N2: TS 38.413 §9.3.1.12 QoS Flow Level QoS Parameters; N4: TS 29.244 §7.5.2.2 / §7.5.2.5. All clause numbers to be confirmed.)

Analogy: Even for the same policy "video capped at 10 Mbps", the manual for the handset says "attach this number tag (QFI) to packets for this destination", the instruction sheet for the base station says "parcels with tag x get this priority", and the settings for the switch say "throttle packets matching this condition to 10 Mbps and count the volume" — each recipient gets only the words it understands.

How — policy changes even after the session is established¶

PCF-initiated SM Policy Association Modification (TS 23.502 §4.16.5.2)¶

The PCF can change the policy of an established SM Policy Association. Representative triggers are as follows (TS 23.502 §4.16.5.2, to be confirmed).

Network requested PDU Session Modification (TS 23.502 §4.3.3.2)¶

On receiving an UpdateNotify from the PCF, the SMF initiates a PDU Session Modification as needed. In TS 23.502 §4.3.3.2, the PCF-initiated case is positioned as step 1b (step numbers to be confirmed).

sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant PCF
    participant UPF
    Note over PCF: Trigger: AF request / Policy Data change, etc.
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(add / modify / remove PCC Rules)
    SMF-->>PCF: 204 No Content, etc.
    Note over SMF: Re-evaluate QoS Flow binding
add to existing Flow or create new Flow
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
(N1: PDU Session Modification Command
N2: PDU Session Resource Modify Request Transfer)
    AMF->>gNB: NGAP PDU Session Resource Modify Request
    gNB->>UE: RRC Reconfiguration (NAS: Modification Command)
    gNB-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM info)
    SMF->>UPF: PFCP Session Modification
(Create/Update PDR, QER, URR)
    UPF-->>SMF: PFCP Session Modification Response
    UE->>AMF: PDU Session Modification Complete (N1)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N1 SM info)
    Note over SMF: Update the UPF again if needed and
report the result to the PCF (Npcf_SMPolicyControl_Update)

• If the UE is in CM-IDLE, a Network Triggered Service Request (Paging) is needed before N1/N2 can be delivered (TS 23.502 §4.2.3.3; the conditions within §4.3.3.2 are to be confirmed).
• The diagram is a representative example following the basic flow of TS 23.502 §4.3.3.2 (N4 is updated after the N2 response is received; step numbers to be confirmed). Some implementations pre-configure N4 first (implementation dependent). See PDU Session Modification / Release for the full picture.
• When the change is completed in the UPF alone (pattern A below), the SMF may not send N1 / N2 at all. How far it goes depends on the change and on the SMF implementation.
• The NAS side of PDU Session Modification is TS 24.501 §6.3.2 (Network-requested PDU session modification, to be confirmed), and the NGAP side is TS 38.413 §8.2.3 (PDU Session Resource Modify).

SMF-initiated and PCRTs¶

The opposite direction, SMF-initiated SM Policy Association Modification (TS 23.502 §4.16.5.1), is used when a Policy Control Request Trigger condition specified in advance by the PCF is met — for example "report when the RAT Type changes" or "report when a UE IP is allocated". On receiving the report, the PCF can review the policy and return new PCC Rules in the response.

How — practical example: bandwidth control for video only¶

Consider the requirement "limit only the traffic of a particular video streaming service to a DL maximum of 10 Mbps". Note that the scope the SMF updates changes depending on how the PCC Rule is built.

Pattern A: put it into the existing Non-GBR QoS Flow and throttle per SDF¶

PCC Rule "video-limit"
├─ Precedence: 100 (takes priority over the default rule)
├─ SDF template: DL  from 203.0.113.0/24 port 443 to UE   ← fictitious example
│                UL  from UE to 203.0.113.0/24 port 443
├─ 5QI / ARP: same values as the default QoS Flow (Non-GBR)
└─ DL Maximum bitrate: 10 Mbps

• Because the binding parameters (5QI / ARP) are the same as those of the default QoS Flow, no new QoS Flow is created, and the rule is grouped under the existing QFI (TS 23.503 §6.1.3.2.4, to be confirmed).
• The SMF adds to the UPF a PDR with an SDF Filter (Precedence 100) and a QER with DL MBR = 10 Mbps.
• Because the gNB's QoS Flow parameters do not change, nothing may flow on N2. Whether to add a QoS Rule for the UE (whether the UL classification needs to change) is the SMF's decision (implementation dependent / to be confirmed).

Pattern B: create a dedicated GBR QoS Flow¶

When a dedicated QoS Flow with GBR is created in response to an AF request (e.g., guaranteeing live-streaming quality), the binding parameters (5QI / ARP) differ, so a new QFI is allocated and all of N4, N2 and N1 are updated.

flowchart LR
    A["PCC Rule added"] --> B{"binding parameters
(5QI, ARP, etc.) same as
an existing Flow?"}
    B -- "Yes (pattern A)" --> C["Bind to existing QFI
mainly only N4 updated
(N1 at SMF discretion)"]
    B -- "No (pattern B)" --> D["Allocate new QFI
update N4 + N2 + N1
(PDU Session Modification)"]

In real commercial networks, video may be identified not only by IP 5-tuple but also by Application identifier (application detection in the UPF; PFDs may be provided via the NEF; TS 23.502 §4.18, to be confirmed), and the detection accuracy and method are implementation dependent.

How — when an AF is involved (outline)¶

When the application side requests QoS, the AF sends a request to the PCF, and the PCF converts it into PCC Rules.

AF ──N5: Npcf_PolicyAuthorization_Create──► PCF
                                             │ (approve / modify / reject against subscriber and operator policy)
                                             ▼
                          Npcf_SMPolicyControl_UpdateNotify
                                             ▼
                                            SMF ──► N4 / N2 / N1

• An AF request is a "request" and is not necessarily granted as is (Policy).
• The AF uses the BSF to find the PCF serving the target UE's session (BSF / PCF Binding).
• Details of N5 are covered two chapters ahead in AF / N5 / Application Session, and external AFs via the NEF in NEF / N33.

Packet Analysis (Wireshark)¶

Policy problems cannot be solved by looking at a single interface. Traverse N7 → N4 → N2 → N1 → N3 for the same PDU Session.

Display filters¶

TLS support is mandatory for the SBI, but whether it is applied within a PLMN is up to the operator (TS 33.501 §13.1, to be confirmed). Labs such as Open5GS / free5GC are sometimes configured with cleartext HTTP/2 (configuration dependent). How to read HTTP/2 / JSON in detail is covered in the next chapter, N7 SBI analysis.

Decode example (conceptual)¶

The following is a conceptual representation following the OpenAPI definitions of TS 29.512; attribute names are to be confirmed and values are fictitious (capture needed).

POST /npcf-smpolicycontrol/v1/sm-policies  →  201 Created
SmPolicyDecision
├─ sessRules
│   └─ "sess-1"
│       ├─ authSessAmbr: { uplink: "100 Mbps", downlink: "200 Mbps" }
│       └─ authDefQos:   { 5qi: <Non-GBR value>, arp: { ... } }
├─ pccRules
│   └─ "video-limit"
│       ├─ pccRuleId:  "video-limit"
│       ├─ precedence: 100
│       ├─ flowInfos:
│       │   └─ flowDescription: "permit out 6 from 203.0.113.0/24 443 to assigned"
│       │      flowDirection:   BIDIRECTIONAL
│       └─ refQosData: [ "qos-video" ]
├─ qosDecs
│   └─ "qos-video"
│       ├─ 5qi:    <same value as the default QoS Flow>
│       └─ maxbrDl: "10 Mbps"
└─ policyCtrlReqTriggers: [ ... ]

• flowDescription reuses the IPFilterRule format of RFC 6733 (TS 29.512 refers to the Flow-Description AVP of TS 29.214 §5.4.2, to be confirmed).
• A PCC Rule does not hold QoS values directly; it references qosDecs via refQosData. In a trace, follow the reference to its target.

The corresponding N4 side (conceptual, capture needed):

PFCP Session Modification Request
├─ Create PDR
│   ├─ PDR ID: 10
│   ├─ Precedence: 100
│   ├─ PDI: Source Interface = Core, UE IP Address, SDF Filter (203.0.113.0/24 443)
│   ├─ FAR ID: 2
│   └─ QER ID: 10, 1           ← QER for the SDF and QER for Session-AMBR
└─ Create QER
    ├─ QER ID: 10
    ├─ Gate Status: UL OPEN / DL OPEN
    ├─ MBR: DL 10 Mbps
    └─ QFI: (same as the default QoS Flow)

Order of checks¶

flowchart LR
    A["① N7
Create / UpdateNotify
PCC Rule and qosDecs"] --> B["② N4
PDR SDF Filter and Precedence
QER MBR, Gate, QFI"]
    B --> C["③ N2
QFI and
QoS Flow Level QoS Parameters"]
    C --> D["④ N1
QoS Rules and
QoS Flow Descriptions"]
    D --> E["⑤ N3
QFI in GTP-U"]

Build a comparison table¶

Note that the PCF does not know the QFI (the SMF allocates it). The primary key to correlate N7 and N4 is the SDF (packet filters). Because the SMF may convert precedence values (e.g., the N1 QoS rule precedence is one octet; the conversion is implementation dependent), compare precedence by relative order rather than by exact value.

Trouble Shooting¶

① The policy does not arrive (the QoS is not as expected)¶

Before looking at the UPF, check from upstream in order.

① Did PCF selection succeed? (NRF Discovery, the SMF's PCF configuration)
② Did Npcf_SMPolicyControl_Create return 201 Created? (not 4xx / 5xx?)
③ Does the SmPolicyDecision contain the expected PCC Rules / Session Rules?
④ If a PCC Rule is Predefined (Rule ID only), is a rule with the same name configured in the SMF (and also in the UPF when Activate Predefined Rules is used)?
⑤ Did the SMF accept the PCC Rule? (SMF logs, failure reports in Update)
⑥ Was it deployed correctly to N4 / N2 / N1?

② The PCF is correct but the UPF is wrong¶

Line up the SmPolicyDecision on N7 and the Create / Update QER and PDR on N4, keyed by SDF, comparing precedence by relative order. If they differ, the cause is either the SMF's translation (binding, unit conversion, rule merging) or the UPF not accepting the request (PFCP Cause).

③ The UPF is correct but only the RAN is wrong¶

Check the QoS Flow Setup Request List / QoS Flow Add or Modify Request List in the N2 PDU Session Resource Setup / Modify Request Transfer, and within it the QFI and QoS Flow Level QoS Parameters (TS 38.413 §9.3.4.1 / §9.3.4.3, to be confirmed). Because N2 carries no SDF information, "the UPF treats each SDF differently but the gNB sees one QoS Flow" is normal for pattern A binding.

Boundary between 3GPP specifications and vendor implementations¶

"Which Pod / DB in the SMF caches the policy received from the PCF" is outside the scope of 3GPP.

Comparison with EPC (4G)¶

The concept of a PCC Rule is inherited from TS 23.203 §6.3 (to be confirmed). However, thinking of it as a simple one-to-one substitution PCRF = PCF, PGW = SMF leads to misunderstanding. In 4G, the PCEF inside the PGW handled everything from "receive" to "enforce"; in 5G, the structure is split so that the SMF translates and the UPF, gNB and UE each enforce. Gx bearer binding is TS 23.203 §6.1.1.4 (to be confirmed).

3GPP Specification¶

Summary¶

• An SM Policy Association is the per-PDU-Session relationship between the SMF and the PCF. Established with Create, modified with Update (SMF-initiated) / UpdateNotify (PCF-initiated), and ended with Delete
• The PCF decides based on input from the SMF (DNN, S-NSSAI, RAT, location, subscribed QoS), Policy Data in the UDR, AF requests and CHF status
• Its output is Session Rules (Session-AMBR, default QoS), PCC Rules (SDF template, precedence, QoS, gate, charging) and PCRTs
• The PCF does not configure the UE, gNB or UPF directly. The SMF performs QoS Flow binding and QFI allocation and translates into QoS Rules (N1) / QoS Flow Level QoS Parameters (N2) / PDR, QER, URR (N4)
• The gNB does not know about SDFs. Correlate N7 and N4 by SDF (precedence by relative order), and N4 with N2 / N1 by QFI
• Policy changes after establishment go PCF-initiated Modification (§4.16.5.2) → Network requested PDU Session Modification (§4.3.3.2). Depending on the binding, only N4, or N4 + N2 + N1, are updated

Comprehension check¶

Next Step¶

• Analyze N7 at the level of HTTP/2, JSON and ProblemDetails → N7 SBI analysis
• How an AF influences policy → AF / N5 / Application Session / NEF / N33
• How an AF finds the serving PCF → BSF / PCF Binding
• The UPF side of what the SMF translated → PFCP and PDR / FAR / QER / URR / PDR / PDI / SDF Filter / Precedence
• The procedure that applies policy changes → PDU Session Modification / Release
• Review the big picture → Policy / PCF / N7 / QoS / Charging