Description
QoS Notification Control (QNC) is a mechanism defined within the 5G System (5GS) that enables the network to inform a User Equipment (UE) about modifications to its authorized Quality of Service (QoS) parameters for an existing Protocol Data Unit (PDU) Session or QoS Flow. Unlike static QoS provisioning, QNC allows for dynamic adjustments after a session is established. This notification is crucial for aligning the UE's understanding of its available resources with the network's current policy decisions or operational state.
The QNC procedure is primarily driven by the Policy Control Function (PCF). When the PCF decides that a change in authorized QoS is required—for reasons such as policy updates, network congestion, slice-specific management, or application request—it sends a policy update to the Session Management Function (SMF). The SMF, which is responsible for PDU session management, then initiates the notification process towards the UE. This involves the SMF communicating with the Access and Mobility Management Function (AMF) and ultimately the Radio Access Network (RAN) to deliver the QoS notification message to the UE.
Upon receiving the notification, the UE is expected to adapt its uplink traffic behavior accordingly. For example, if the authorized bitrate for a QoS Flow is reduced, the UE should limit its transmission rate to the new value. The notification typically contains updated QoS parameters such as the 5G QoS Identifier (5QI), Aggregate Bit Rate (ABR), Guaranteed Flow Bit Rate (GFBR), or Maximum Flow Bit Rate (MFBR). QNC operates within the framework of the UE policy framework and is distinct from QoS rule provisioning; it does not install new rules but modifies the authorization associated with existing rules or flows. This mechanism is integral to achieving closed-loop QoS management, where the network can respond in near real-time to changing conditions and maintain service-level agreements (SLAs), especially in complex environments like network slicing.
Purpose & Motivation
QNC was introduced in 5G (Rel-15) to address the limitations of static QoS management prevalent in previous generations. In 4G/LTE, QoS parameters were largely established during bearer setup and could only be modified through complex bearer modification procedures, which were not optimized for rapid, policy-driven changes. The advent of 5G brought about diverse service requirements, network slicing, and dynamic policy control, necessitating a more agile method to communicate QoS changes to the end device.
The primary problem QNC solves is the synchronization of QoS state between the network's policy decision point (PCF) and the UE. Without QNC, a UE might continue transmitting at a rate that the network can no longer support due to congestion, slice re-prioritization, or a change in user subscription, leading to packet drops, inefficiency, or violation of SLAs. QNC enables efficient network resource utilization by allowing the network to downgrade (or occasionally upgrade) QoS authorizations on-the-fly. This is particularly important for network slicing, where resources are shared and must be allocated elastically, and for service continuity when a user moves between different slice instances or when application requirements change mid-session. It provides the granular control needed for advanced 5G use cases like industrial IoT, ultra-reliable low-latency communication (URLLC), and enhanced mobile broadband (eMBB).
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (33 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 15, the QNC function was newly introduced to enable spending limit control, with the PCF initiating procedures like the Initial Spending Limit Report based on indications from the UDR. This included defining the Nchf service for Spending Limit Control consumed by the PCF and specifying notification mechanisms for policy counter status changes. The release also introduced corrections to the AM policy control and UE policy control procedures, formalizing the PCF's ability to subscribe to UDR notifications for policy updates.
In Release 16, the QNC function was enhanced to support new notification procedures, including subscription to notification of a change of access type and subscription to notification of signalling path status at IMS registration. It also introduced the BDT (Background Data Transfer) notification procedure and refined mechanisms for policy control, such as DN authorization data for policy control. Furthermore, alignment of the notification URI name and HTTP response code was specified to ensure consistent service operation.
- BDT notification procedure TS 29.513CR0081
- Annex B, IMS Session Modification, gate control TS 29.513CR0114
- Annex B, Subscription to Notification of Change of Access Type TS 29.513CR0118
- Subscription to Notification of Signalling Path Status at IMS Registration TS 29.513CR0130
- Subscription to Notification of change of PLMN Identifier at initial IMS Registration TS 29.513CR0133
- DN Authorization data for Policy Control TS 29.513CR0060
+ 1 more changes
In Release 17, the QNC function was enhanced with new notification procedures, including the PCF's ability to receive notifications on the outcome of UE Policies delivery and on PDU session establishment or termination. It also introduced support for the PCF to control MPS for DTS and to be notified of PDUID changes via the BSF, alongside corrections to notification handling and URI discovery mechanisms.
- Procedure of PUSH notification TS 29.513CR0205
- Procedure of notification push update TS 29.513CR0219
- PCF control of MPS for DTS TS 29.513CR0257
- BSF support for the PCF notification of PDUID changes TS 29.513CR0289
- Notification on the outcome of UE Policies delivery due to service specific parameter provisioning TS 29.513CR0295
- Same PCF discovery for the control of data rate per network slice TS 29.513CR0314
+ 6 more changes
In Release 18, the QNC function was enhanced with new procedures for Per-DNN Per-Slice QoS (PDTQ) policy negotiation and warning notification, including corrections to these warning notification procedures. It also introduced support for Policy Control for Low Latency, Low Loss, Scalable throughput (L4S) and integrated UE Policy Control inputs for Access Network Discovery and Selection Policy (ANDSP) determination. Furthermore, the release added the RSLPP interface in call flows of Policy Control and introduced a User Plane path change notification for High Reliability - Service Based Operation (HR-SBO).
- Considering UE Policy Control inputs for ANDSP determination TS 29.513CR0412
- Support of PDTQ warning notification procedure TS 29.513CR0459
- Policy Control for L4S TS 29.513CR0474
- Update the procedures for PDTQ policy negotiation and warning notification TS 29.513CR0487
- Add RSLPP in call flows of Policy Control TS 29.513CR0494
- Resolve the Editor's Note for PDTQ warning notification procedure TS 29.513CR0524
+ 5 more changes
In Release 19, the QNC function was enhanced to enable the PCF to control the establishment of an Access and Mobility (AM) Policy Association based on subscription data from the UDM. This is governed by a new AM Policy Association Indicator, which, when set to enabled, allows the PCF to manage the association as specified in the service-based interface procedures. This provides a more dynamic and subscription-driven policy control mechanism for the 5G core network.
- UE and AM Policy Association control based on UDM Subscription Data TS 29.513CR0562
Explore further
Broader topics and technologies where QNC plays a role.
Defining Specifications
3GPP specifications that define or reference QNC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 29.513 vj40 | 5G PCC Signalling Flows & QoS Mapping | Rel-19 |
| TS 29.890 vg00 | CT3 5G System Technical Report | Rel-16 |