AF / N5 / Application Session — How an Application Request Becomes a QoS Flow¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain that N5 = Npcf_PolicyAuthorization (TS 29.514), with the AF as Service Consumer and the PCF as Service Producer
• Explain the Application Session Context (app-sessions resource) and how Create / Update / Delete / Subscribe / Unsubscribe / Notify look on HTTP
• Explain how the PCF associates an Application Session with an SM Policy Association (Session Binding), and why a BSF is needed in multi-PCF deployments
• Draw how a Media Component / Media Sub-Component / Flow Description becomes, via the SDF template of a PCC Rule, a QoS Rule (N1), QoS Flow (N2) and PDR / QER (N4)
• Isolate, segment by segment, the cases "the AF request does not reach the PCF", "the PCF succeeds but no QoS Flow is created" and "traffic does not match the PDR"

Prerequisites¶

• PCF / SM Policy Association / PCC Rule — structure of a PCC Rule and how the SMF translates it to N1 / N2 / N4
• N7 SBI Analysis — reading SBI HTTP/2, JSON and ProblemDetails
• N5 / AF / PCF — overview of the reference point and NFs
• Supporting: PDR / PDI / SDF Filter / QoS Flow / QFI / 5QI / GFBR / MFBR / AMBR / ARP / VoNR / Policy

Why — an application cannot create a QoS Flow directly¶

Applications such as VoNR calls, cloud gaming and live video have requirements like "this media needs this bandwidth and this latency". However, the party that knows those requirements is the application side (AF), while the parties that actually apply QoS are the UE, gNB and UPF.

• The AF knows neither the PDU Session ID, nor the QFI, nor the SEID. What it usually knows is the UE's IP address and the media destination, ports, codecs and bandwidth.
• Only the SMF can configure the UE, gNB and UPF, and it is the PCF that gives the SMF the QoS policy (PCC Rule) (PCF / PCC).

So we need an entry point where the PCF receives the application's language (media, flows, bandwidth) and translates it into the 5GC's language (PCC Rules). That is N5 / Npcf_PolicyAuthorization (TS 23.501 §6.2.10, TS 29.514 §4.1 (to be confirmed)).

Analogy: The AF is an "event organizer", the PCF is the "road authority", and the SMF is the "on-site traffic controller". The organizer applies, saying "from 7 p.m., about this many cars will travel between this venue and this parking lot" (Application Session). The authority reviews the application and issues a permit saying "make this section a priority lane under these conditions" (PCC Rule). The one who actually places the cones and creates the lane (QoS Flow / PDR / QER) is the on-site controller. The organizer cannot place the cones itself.

What — N5 and Npcf_PolicyAuthorization¶

Reference point and service¶

For notifications (Notify) the direction is reversed: the PCF POSTs to the AF's callback URI (notifUri). Only in this case are the HTTP client and server swapped.

Trusted AF and untrusted AF¶

TS 23.501 §6.2.10 specifies that an AF trusted by the operator can interact directly with the relevant NFs, while an AF that is not allowed direct access uses the external exposure framework via the NEF.

flowchart LR
    TAF["Trusted AF
e.g. IMS P-CSCF"] == "N5
Npcf_PolicyAuthorization" ==> PCF["PCF"]
    XAF["Untrusted AF
external application provider"] -- "N33
AsSessionWithQoS etc." --> NEF["NEF"]
    NEF -- "Npcf_PolicyAuthorization
(NEF acts as the AF)" --> PCF
    PCF == "N7
Npcf_SMPolicyControl" ==> SMF["SMF"]

From the PCF's point of view, both are the same Application Session. The difference lies in the authorization and identifier translation in front of it, which is covered in NEF / N33.

What — Application Session Context¶

Resource structure¶

The core of N5 is the Application Session Context (also called an "App Session") that the AF creates on the PCF (TS 29.514 §5.3, to be confirmed).

{apiRoot}/npcf-policyauthorization/v1
└─ /app-sessions                              ← Application Sessions (collection)
    └─ /{appSessionId}                        ← Individual Application Session Context
        ├─ /delete                            ← custom operation for deletion (POST)
        └─ /events-subscription               ← Events Subscription (individual resource)

{notifUri} (callback specified by the AF)
├─ /notify                                    ← event notification (PCF → AF)
└─ /terminate                                 ← termination request (PCF → AF)

Service operations¶

(The clause numbers of the operations, how each status code is used, and why /delete is defined as a custom operation (POST) rather than the DELETE method are to be confirmed in TS 29.514 §4.2 / §5.3 of the target Release. Stage 2 is TS 23.502 §5.2.5.3, to be confirmed.)

Main attributes of AppSessionContextReqData¶

The body of Create is an AppSessionContext, and the request is carried in its ascReqData (AppSessionContextReqData) (TS 29.514 §5.6.2.2 / §5.6.2.3, to be confirmed).

This is an excerpt of the main attributes, not an exhaustive list. Check TS 29.514 §5.6 for the mandatory / optional / conditional classification and attributes added per Release (to be confirmed).

Media Component / Media Sub-Component / Flow Description¶

The unit in which the AF requests QoS is the Media Component (one media stream, e.g. audio), which contains per-flow Media Sub-Components.

medComponents (map)
└─ "1": MediaComponent                     ← e.g. the 1st m= line of the SDP (audio)
    ├─ medCompN: 1                         ← Media Component Number (mandatory)
    ├─ medType: AUDIO                      ← AUDIO / VIDEO / DATA / CONTROL etc.
    ├─ codecs: [...]                       ← SDP codec information (built by the AF from the SDP)
    ├─ marBwUl / marBwDl: "41 Kbps"        ← Maximum Requested Bandwidth (UL / DL)
    ├─ mirBwUl / mirBwDl                   ← Minimum Requested Bandwidth (optional)
    ├─ fStatus: ENABLED                    ← Flow Status (gate)
    └─ medSubComps (map)
        ├─ "1": MediaSubComponent          ← e.g. RTP
        │   ├─ fNum: 1                     ← Flow Number (mandatory)
        │   ├─ fDescs: [ for UL, for DL ]  ← Flow Description (up to 2)
        │   └─ flowUsage: NO_INFO
        └─ "2": MediaSubComponent          ← e.g. RTCP
            ├─ fNum: 2
            ├─ fDescs: [ ... ]
            └─ flowUsage: RTCP             ← RTCP / AF_SIGNALLING / NO_INFO

The Flow Description format is the IPFilterRule format inherited from the Rx Flow-Description AVP (TS 29.514 §5.6.3; the encoding is the Flow-Description AVP of TS 29.212 §5.4.2, originally defined in Rx TS 29.214 §5.3.8; all to be confirmed; the same references as PDR / PDI / SDF Filter).

permit out 17 from 198.51.100.20 40000 to 10.45.0.2 50000    ← DL (peer → UE)
permit out 17 from 10.45.0.2 50000 to 198.51.100.20 40000    ← UL (UE → peer)
         │   │   └ source address port      └ destination address port
         │   └ protocol number (17 = UDP)
         └ direction keyword

Under the convention inherited from Rx, the direction keyword is fixed to out, and UL and DL are distinguished by whether the source or the destination address is the UE (TS 29.212 §5.4.2 / TS 29.214 §5.3.8, to be confirmed). Because this "way of writing direction" is interpreted again at every conversion, N5 → N7 (flowDirection of flowInfos) → N4 (SDF Filter), inconsistencies between implementations can cause PDR mismatches (see Trouble Shooting below).

What — the relationship between N5 and N7 (Session Binding)¶

How does the PCF know "which PDU Session"?¶

Creating an App Session alone does not determine which PDU Session of which UE it should apply to. The PCF ties the App Session to one of the SM Policy Associations (N7) it holds. This is called Session Binding (TS 23.503 §6.1.3.2, to be confirmed).

flowchart LR
    AF["AF
App Session
ueIpv4=10.45.0.2
dnn=ims"] -- "N5" --> PCF["PCF"]
    SMF["SMF
PDU Session
UE IP=10.45.0.2
DNN=ims, S-NSSAI"] -- "N7
SM Policy Association" --> PCF
    PCF --> B{"Session Binding
UE address + DNN etc. match?"}
    B -- "match" --> R["Create PCC Rule and
UpdateNotify that SM Policy"]
    B -- "no match" --> X["Reject App Session
e.g. PDU_SESSION_NOT_AVAILABLE"]

The binding mechanism in TS 23.503 §6.1.3.2 can be organized roughly into the following three stages (sub-clause numbers to be confirmed).

The key point is that the last stage, QoS Flow binding, is the SMF's job. The PCF does not order "create a new QoS Flow"; the PCF passes the PCC Rule, and the SMF decides whether to create a new QoS Flow by looking at the binding parameters (PCF / PCC).

Multi-PCF deployments and the BSF¶

In a network with multiple PCFs, the AF must create the App Session on the PCF that holds the SM Policy Association of that PDU Session. If it reaches a different PCF, Session Binding fails.

SMF ──N7── PCF-B   ← holds the SM Policy Association for UE IP 10.45.0.2
AF  ──N5── PCF-A ✗ ← does not know the target session → reject
AF  ──N5── PCF-B ✓ ← binding succeeds

The ways in which the AF finds the serving PCF include Nbsf_Management_Discovery to the BSF (searching for the serving PCF keyed by UE IP, DNN and S-NSSAI), Delegated Discovery via an SCP, the BSF acting as a Diameter proxy / redirect for an AF that uses Rx, and local configuration; which one is used is deployment-dependent (TS 23.503 §6.1.1.2, to be confirmed). For details see BSF / PCF Binding and SBI Communication Model.

How — from AF request to QoS Flow (end-to-end)¶

Call Flow¶

A representative example combining TS 23.502 §4.16.5.2 (PCF-initiated SM Policy Association Modification) and §4.3.3.2 (network-requested PDU Session Modification) (step numbers and order differ between versions, so to be confirmed).

sequenceDiagram
    participant AF
    participant BSF
    participant PCF
    participant SMF
    participant AMF
    participant gNB
    participant UPF
    AF->>BSF: Nbsf_Management_Discovery
(UE IP, DNN, S-NSSAI)
    BSF-->>AF: 200 OK (serving PCF)
    AF->>PCF: Npcf_PolicyAuthorization_Create
POST app-sessions (medComponents, notifUri, evSubsc)
    PCF->>PCF: Session Binding
PCC Rule authorization and generation
    PCF-->>AF: 201 Created (Location: app-sessions/ID)
    PCF->>SMF: Npcf_SMPolicyControl_UpdateNotify
(add PCC Rule)
    SMF-->>PCF: 200 OK / 204 No Content
    Note over SMF: QoS Flow binding
new QFI or existing QoS 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-->>AMF: PDU Session Resource Modify Response
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (N2 SM information)
    SMF->>UPF: PFCP Session Modification Request
(Create PDR / QER)
    UPF-->>SMF: PFCP Session Modification Response
    Note over SMF: After receiving the UE Modification Complete
report the PCC Rule outcome
    SMF->>PCF: Npcf_SMPolicyControl_Update
(rule outcome report)
    PCF->>AF: Npcf_PolicyAuthorization_Notify
POST notifUri/notify (SUCCESSFUL_RESOURCES_ALLOCATION etc.)

• In TS 23.502 §4.3.3.2, N4 Session Modification appears conditionally in several steps (after the N2 response, after the UE's Complete, etc.; step numbers to be confirmed), so there are options for when N4 is updated. Which timing is actually used is implementation-dependent. If the UE is CM-IDLE, paging is needed before N1/N2 can be delivered (TS 23.502 §4.2.3.3).
• Whether the PCF returns its response to the AF before or after UpdateNotify should be checked against both the specified order and the implementation (to be confirmed).

Signal Flow¶

The conversion chain — from Flow Description to PDR¶

[N5] AF: MediaComponent
     ├─ medType=AUDIO, codecs, marBwUl/Dl ─────┐
     ├─ fStatus=ENABLED ──────────────┐        │  PCF: QoS mapping (TS 29.513 §7.3)
     └─ medSubComp.fDescs ──┐         │        │       + subscriber / operator policy
                            ▼         ▼        ▼
[N7] PCF: PccRule ── flowInfos(SDF template) / precedence
          ├─ refTcData → TrafficControlData.flowStatus (gate)
          └─ refQosData → QosData (5qi, arp, maxbrUl/Dl, gbrUl/Dl)
                            │
                            ▼ SMF: QoS Flow binding (5QI / ARP etc.) → QFI assignment
        ┌───────────────────┼─────────────────────────┐
        ▼                   ▼                         ▼
[N1] QoS Rule          [N2] QoS Flow Level        [N4] PDR (PDI: SDF Filter, QFI etc.)
     (UL Packet Filter,      QoS Parameters             + QER (QFI, MBR/GBR, Gate Status)
      Precedence, QFI)       (QFI, 5QI, ARP, GFBR/MFBR)

(Attribute names are conceptual. TS 29.512 §5.6.2, TS 24.501 §9.11.4.12 / §9.11.4.13, TS 38.413 §9.3.1.12, TS 29.244 §8.2.5 (SDF Filter). All clause numbers to be confirmed.)

• Whether PCC Rules are created per Media Component or per Media Sub-Component (flow) is PCF implementation-dependent.
• Mappings such as AUDIO → 5QI=1 are determined by the TS 29.513 §7.3 mapping and operator policy; the AF does not specify the 5QI directly (exceptions such as the QoS Reference from Rel-16 onwards are to be confirmed).

How — seen through the VoNR P-CSCF¶

In VoNR, the IMS P-CSCF uses N5 as a trusted AF. Building Media Components from the SIP SDP is the P-CSCF's job.

sequenceDiagram
    participant UE
    participant PCSCF as P-CSCF (AF)
    participant PCF
    participant SMF
    UE->>PCSCF: SIP INVITE (SDP offer)
    Note over PCSCF: Receives the SDP answer from the far end
(e.g. 183 Session Progress)
    PCSCF->>PCF: Npcf_PolicyAuthorization_Create
(ueIpv4, dnn=ims, AUDIO, fDescs RTP/RTCP)
    PCF-->>PCSCF: 201 Created
    PCF->>SMF: UpdateNotify (PCC Rule with 5QI=1 GBR)
    Note over SMF: Adds a new QoS Flow (5QI=1)
updates N1 / N2 / N4
    PCF->>PCSCF: Notify (SUCCESSFUL_RESOURCES_ALLOCATION)
    PCSCF->>UE: Call proceeds with SIP 183 / UPDATE etc.
    Note over UE,PCSCF: Call ends (BYE)
    PCSCF->>PCF: POST app-sessions/ID/delete
    PCF->>SMF: UpdateNotify (remove PCC Rule)
    Note over SMF: Releases the 5QI=1 QoS Flow

(The rules for converting SDP to Media Components are in TS 29.513 §7.2 etc.; the timing at which the P-CSCF issues the N5 request (on the SDP offer or the answer) depends on TS 29.513 / TS 23.228 and the P-CSCF configuration. All to be confirmed.)

Packet Analysis (Wireshark)¶

N5 / N7 are SBI, so they are HTTP/2. In SBI, TLS support is mandatory, but whether it is actually applied within the PLMN is the operator's decision (TS 33.501 §13.1, to be confirmed). If TLS is applied, decryption keys (key log etc.) are needed. Lab setups such as Open5GS / free5GC are sometimes configured with plaintext HTTP/2 (h2c) (configuration-dependent). Note that N33 (Northbound API) used by external AFs may use either HTTP/1.1 or HTTP/2 (TS 29.122 §5.2.2, to be confirmed; see NEF / N33).

Display filters¶

Field names may differ between Wireshark versions (to be confirmed).

Decode example (conceptual)¶

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

[N5] POST /npcf-policyauthorization/v1/app-sessions
AppSessionContext
└─ ascReqData
    ├─ ueIpv4: 10.45.0.2
    ├─ dnn: ims
    ├─ notifUri: https://pcscf.example/n5cb/abc123
    ├─ suppFeat: "..."
    ├─ evSubsc
    │   └─ events: [ SUCCESSFUL_RESOURCES_ALLOCATION, FAILED_RESOURCES_ALLOCATION ]
    └─ medComponents
        └─ "1"
            ├─ medCompN: 1, medType: AUDIO
            ├─ marBwUl: "41 Kbps", marBwDl: "41 Kbps"
            ├─ fStatus: ENABLED
            └─ medSubComps
                ├─ "1": fNum 1
                │   fDescs: [ "permit out 17 from 198.51.100.20 40000 to 10.45.0.2 50000",
                │             "permit out 17 from 10.45.0.2 50000 to 198.51.100.20 40000" ]
                └─ "2": fNum 2, flowUsage: RTCP, fDescs: [ ...40001 / 50001... ]
→ 201 Created
  Location: https://pcf-b.example/npcf-policyauthorization/v1/app-sessions/7f3c...

[N7] POST {SMF notificationUri}/update      ← UpdateNotify
SmPolicyNotification
└─ smPolicyDecision
    ├─ pccRules
    │   └─ "voice-1": flowInfos [ {flowDescription, flowDirection: DOWNLINK}, {..., UPLINK} ]
    │                 precedence: 50, refQosData: ["qos-voice"], refTcData: ["tc-voice"]
    ├─ qosDecs
    │   └─ "qos-voice": 5qi 1, gbrUl/gbrDl, maxbrUl/maxbrDl, arp {priorityLevel, preemptCap, preemptVuln}
    └─ traffContDecs
        └─ "tc-voice": flowStatus ENABLED

[N4] PFCP Session Modification Request
├─ Create PDR (UL): PDI { Source Interface: Access, Local F-TEID, QFI 2, SDF Filter } → QER 2
├─ Create PDR (DL): PDI { Source Interface: Core, UE IP 10.45.0.2, SDF Filter } → QER 2
└─ Create QER 2: QFI 2, Gate Status OPEN, MBR / GBR

Order of checks¶

flowchart LR
    A["1. N5
Create response
201 / 4xx / 5xx"] --> B["2. N7
Is there an UpdateNotify
PCC Rule contents"]
    B --> C["3. N2 / N1
Modify Request / Response
Modification Command"]
    C --> D["4. N4
Create PDR / QER
SDF Filter and Precedence"]
    D --> E["5. N3
5-tuple and QFI
of actual traffic"]
    E --> F["6. N5 Notify
success / failure event"]

Note that the correlation key changes from segment to segment.

Trouble Shooting¶

AF request does not reach the PCF — from the bottom up¶

1. Is the AF sending the request? (AF log, capture on the sending side)
2. Is the destination PCF correct? (BSF Discovery 200 / 204, SCP routing, local configuration)
3. Are TCP / TLS established? (TLS alert, certificates)
4. Does it arrive as HTTP/2? (is :path /npcf-policyauthorization/v1/app-sessions, API version)
5. What does the PCF respond? (201 / 400 / 403 / 404 / 5xx and ProblemDetails)

The PCF succeeds but no QoS Flow is created¶

What to look at after 201 Created is the N7 UpdateNotify.

AF ──201──► success       ← do not relax here
PCF ──UpdateNotify──► SMF ← was it sent? are the PCC Rule's 5QI, ARP and flowInfos as expected?
SMF ──► N2 / N1 / N4      ← was a new QFI assigned, or was it bound to an existing flow?
SMF ──Update(ruleReports)──► PCF  ← has a failure report arrived?
PCF ──Notify──► AF        ← has FAILED_RESOURCES_ALLOCATION arrived?

Traffic does not match the PDR — build a comparison table¶

(Values are fictitious. Capture required.) In UL, the UE marks the QFI according to the packet filters of the QoS Rule. If the UL PDR also uses the QFI as a condition, a misclassification on the UE side means the packet will not match the UPF's PDR. For details of PDR matching rules see PDR / PDI / SDF Filter.

Boundary between 3GPP specifications and vendor implementations¶

Comparison with EPC (4G)¶

N5 is the SBI version of 4G Rx (AF ⇔ PCRF, Diameter, TS 29.214).

(The mapping is this chapter's own organization. Rx AVP definitions are in TS 29.214 §5.3 and Diameter commands in §5.6 (to be confirmed).)

3GPP Specification¶

Summary¶

• N5 = Npcf_PolicyAuthorization (TS 29.514). The AF is the consumer and the PCF the producer. Only Notify is a PCF → AF callback
• The AF creates an Application Session Context (app-sessions/{appSessionId}) on the PCF and manages it with Update (PATCH), Delete (POST .../delete) and Subscribe (PUT events-subscription)
• What the AF passes is the application's language: Media Component / Flow Description / bandwidth. The PCF ties it to a PDU Session by Session Binding, translates it into a PCC Rule, and passes it to the SMF with an N7 UpdateNotify
• Whether to create a new QoS Flow is decided by the SMF's QoS Flow binding. The SMF expands it into N1 (QoS Rule), N2 (QoS Flow) and N4 (PDR / QER)
• In multi-PCF deployments, the AF must reach the serving PCF → BSF. External AFs go via the NEF
• 201 Created does not mean QoS has been applied. Follow it through UpdateNotify → N2 / N1 / N4 → actual traffic on N3 → Notify

Comprehension check¶

Next Step¶

• How an external AF creates the same App Session via the NEF → NEF / N33 / Event Exposure
• How the AF finds the serving PCF → BSF / PCF Binding / SBI Communication Model
• Details of how a PCC Rule is translated into N1 / N2 / N4 → PCF / SM Policy Association / PCC Rule / N7 SBI Analysis
• SDF Filter and PDR matching → PDR / PDI / SDF Filter / QoS Flow / QFI / 5QI
• A representative example with the P-CSCF as the AF → VoNR / PDU Session Modification
• Overview pages → AF / N5 / Policy