A 5G device can remain connected while its authorized service changes. An application may need different QoS treatment, a subscription update may change an aggregate rate limit, or the radio network may report that an existing QoS Flow can no longer receive its authorized resources. The engineering question is which parts of the existing session must change, and how to prove that they changed consistently.
PDU Session Modification updates an existing PDU Session. The SMF coordinates the affected UE parameters, access resources and user-plane rules. A policy decision, a successful service API response and a working data connection are different observations: none alone proves that the complete intended change has taken effect.
Scope: an existing session, with conditional resource updates
The session must already exist, but its user-plane connection need not be active at the start of every modification. UE connection state and reachability affect delivery. For example, a UE in CM-IDLE may first need a Service Request before sending its session-management request. Network-initiated handling also depends on the applicable reachability procedure.
The scope below is the non-roaming and local-breakout procedure in 3GPP TS 23.502 Release 18, clause 4.3.3.2. Home-routed roaming, intermediate SMFs, multi-access operation and other extensions introduce additional paths. A trace should be compared with the release and architecture actually deployed.
Modification can change QoS rules or flow parameters, add or remove QoS Flows, and carry certain other session updates. It is distinct from PDU Session Establishment, which creates session context, and PDU Session Release, which removes it. A routine QoS change should therefore be investigated against the existing session context rather than treated as a new registration problem.
Identify the event that triggered the modification
Start with the earliest causal event, not merely the first Modification Command visible in a partial capture. A downstream command shows that the SMF has initiated delivery; it does not explain why the policy changed.
| Trigger | What to look for | Important boundary |
|---|---|---|
| UE request | A PDU SESSION MODIFICATION REQUEST and its requested changes, forwarded through the AMF. | The request is subject to network authorization; an application does not automatically obtain its preferred QoS. |
| PCF policy change | A policy-association notification carrying revised decisions for the relevant session. | Receiving a policy notification is separate from enforcing its contents. |
| UDM subscription update | A subscription-data notification and the SMF's resulting decision. | A data update does not imply that every UE, RAN and UPF parameter changes. |
| SMF decision | Local policy, session state or another documented procedure that requires an update. | Dynamic PCC is conditional; some deployments use local policy. |
| RAN-related event | N2 session information relayed by the AMF, such as released resources or applicable QoS notifications. | The gNB does not directly invoke a session-management API on the SMF. |
Record the session identifier and relevant context references alongside timestamps. In a busy network, two similar policy events for different sessions can otherwise appear to form one procedure. AMF-related triggers and specialized Release 18 features also exist; the table identifies common diagnostic starting points rather than an exhaustive trigger list.
UE-initiated modification: request, authorization and delivery
Consider an illustrative existing PDU Session with ID 5. The UE requests different handling for selected traffic, including the applicable packet-filter operation and requested QoS information. The session ID is an example, not a reserved identifier. The request does not establish a new session or demonstrate that the radio network can admit the requested resources.
Receive the request. The UE's session-management message is conveyed through the access network and AMF. The AMF invokes Nsmf_PDUSession_UpdateSMContext for the existing SM context.
Determine the authorized change. The SMF evaluates the request using subscription information, applicable policy and the deployment's control procedures. It interacts with the PCF when required by the dynamic-policy procedure.
Prepare the affected updates. The SMF determines whether UE QoS information, access resources and UPF rules need modification. A requested value and the final authorized value must remain distinguishable in the record.
Deliver and reconcile results. The AMF conveys the applicable N1 and N2 information. The SMF processes the returned results and performs any necessary follow-up updates.
For service-interface trace inspection, TS 29.502 defines the following modification resource beneath the Nsmf_PDUSession API root. It is a path template, not a complete executable request; the API version, authority, authorization and request body depend on the deployment.
POST {apiRoot}/nsmf-pdusession/{apiVersion}/sm-contexts/{smContextRef}/modifyWhen the network sends a PDU SESSION MODIFICATION COMMAND, an accepting UE responds with PDU SESSION MODIFICATION COMPLETE. TS 23.502's stage-2 diagram uses a descriptive “Command Ack” label; packet decoding should use the actual 5GSM NAS message type specified in TS 24.501. An HTTP response from the context-update service is not a replacement for that NAS evidence.
PCF-triggered modification: define what a rate limit means
A network policy change can start without a UE request. For example, an operator policy might reduce the authorized downlink Session-AMBR to 10 Mbps after a usage condition is met. This is a hypothetical policy example, not a default 3GPP value or a measured network result. The usage-detection and reporting arrangement must be established separately.
The PCF communicates its decision to the SMF through the existing policy association. The SMF then translates it into the applicable session parameters and enforcement rules. Before checking packets, identify the exact parameter: “reduce the rate to 10 Mbps” is incomplete without direction, scope and traffic class.
| Item | Meaning in a modification investigation | Common mistake |
|---|---|---|
| QFI | Identifies a QoS Flow within a PDU Session. | Treating the identifier itself as a priority or bitrate. |
| 5QI | Identifies a set of QoS characteristics. | Reading a 5QI value as a numerical throughput limit. |
| GFBR and MFBR | Directional flow bitrate parameters for GBR QoS Flows. | Applying them indiscriminately to every non-GBR flow. |
| Session-AMBR | An aggregate limit across the session's non-GBR QoS Flows, with separate uplink and downlink values. | Treating it as a separate allowance for every flow, or including GBR traffic in the same comparison. |
| QER | A PFCP rule used by the UPF for applicable QoS enforcement. | Assuming a QER ID is a QFI or that one changed QER automatically covers all intended traffic. |
For the example, compare the authorized downlink Session-AMBR with the relevant installed enforcement and the aggregate non-GBR downlink traffic. An isolated application's speed display is insufficient evidence. Packet classification, other traffic in the session, averaging behavior and the measurement point all affect the comparison.
The SMF reports policy-enforcement outcomes through the applicable policy-control procedure. An acknowledgement that a notification was received should never be recorded as proof that the UE, RAN and UPF have all applied the decision.
Read N1, N2 and N4 as separate execution paths
N1: UE session-management parameters
N1 is the UE–AMF reference point; session-management NAS content is handled by the UE and SMF and relayed by the AMF. Inspect the actual QoS-rule operations and flow descriptions in the command, followed by the UE's response. A diagram showing an SMF-to-UE arrow usually represents logical session-management communication rather than a direct transport connection.
N2: access-network resources
N2 connects the AMF and access network. The SMF supplies session-related information for the AMF to convey. Where access resources change, examine the relevant NGAP procedure and its accepted or rejected QFIs. A successful result for one flow must not hide rejection of another. If the whole N2 request fails, handling differs from partial success; follow the cause and the SMF's subsequent actions.
N4: UPF rules
N4 uses PFCP between the SMF and UPF. Inspect the requested rule changes and the PFCP response Cause, including rejection or partial acceptance where applicable. A useful investigation follows the traffic's packet-detection rule and its associated enforcement and forwarding rules rather than checking an unrelated QER in isolation.
PFCP Session Modification and PDU Session Modification are different procedures. An N4 rule update may participate in a wider session change, but it can also occur for other user-plane control reasons. Not every modification requires a new exchange on all three paths. TS 23.502 includes conditional updates and multiple possible N4 update points; the simplified order “N4, then N2, then N1” is not a universal sequence.
Verify the result with a correlated trace and traffic test
A session may still pass data after an incomplete QoS update. Continued connectivity therefore tells you little about whether the new policy was installed correctly. Capture the expected before-and-after values first, then identify the earliest divergence between intention and execution.
| Checkpoint | Evidence to retain | Next investigation if inconsistent |
|---|---|---|
| Trigger and authorization | Originating request or notification; session reference; requested and authorized values. | Wrong policy association, stale subscription information or rejected authorization. |
| SMF translation | Which UE, RAN and UPF parameters the SMF intended to change. | Missing translation, incorrect scope or an expected update that was never generated. |
| UPF execution, if required | PFCP transaction and Cause; affected rule IDs; installed classification and enforcement. | Rejected rule update, wrong UPF, unmatched traffic or incorrect rule associations. |
| Access execution, if required | NGAP result and accepted/rejected QFIs with causes. | Admission/resource limitations or incomplete handling of partial failure. |
| UE synchronization, if required | Delivered command, NAS response, retransmissions and resulting UE context. | Delivery failure, rejected parameters or unresolved context differences. |
| Observed service | Controlled traffic before and after the change, with direction, classification, load and timing recorded. | A measurement mismatch, another bottleneck or policy enforcement on a different traffic set. |
For a rate-limit test, generate sufficient offered load and document how traffic was counted. Separate GBR and non-GBR traffic, avoid combining unrelated sessions, and use an observation interval suitable for the applicable rate-control behavior. A brief burst above a target and a sustained aggregate excess are different findings. Equally, a low throughput result under poor radio conditions does not prove that the intended limiter is active.
When the RAN rejects some QFIs, inspect how the SMF aligns the remaining session and UE context. Do not treat partial failure as automatic failure of the entire PDU Session, or treat a generic success indication as acceptance of every requested flow. Preserve the transaction evidence before retrying so that a recovery attempt does not obscure the original fault.
FAQs
Does a routine QoS modification require a new IP address?
A change confined to QoS rules or bitrate parameters does not itself require assigning a new IP address to the existing IP PDU Session. If an address changes, investigate whether another procedure, such as re-establishment or a session-continuity operation, also occurred.
Does an authorized 5QI guarantee an application's response time?
No. The QoS characteristics describe treatment across the relevant 5G path. Application processing and networks beyond the UPF can add delay. If the session change is verified but the application remains slow, measure those additional segments rather than repeatedly changing the flow's QoS.
How should a test handle several policy updates close together?
Retain each intended value and its effective transaction timeline. A later decision may supersede the value that an earlier test expected. In a controlled reproduction, isolate one change where practical, then repeat the agreed overlapping-update scenario. Do not compare a current traffic result with an outdated policy snapshot.
Standards references
3GPP TS 23.502 V18.9.0, Release 18: clauses 4.3.3.1–4.3.3.2, session-modification scope and conditional procedure.
3GPP TS 23.501 V18.8.0, Release 18: clause 5.7, QoS model and rate-parameter scope.
3GPP TS 29.244 V18.7.0, Release 18: clauses 7.5.4–7.5.5, PFCP Session Modification request and response.
