A common issue appears during 5G Core user-plane troubleshooting: the UE is registered normally, the PDU Session has been established, the PDR correctly identifies the traffic, and the FAR forwards packets along the expected path, yet the usage counters visible to the SMF remain unchanged. Charging events may not be triggered, or quota control may not respond when expected. In many cases, packet forwarding itself is working correctly. What is missing is a mechanism that tells the UPF how to measure user-plane usage and when to report the result to the control plane. That mechanism is the URR (Usage Reporting Rule) on the N4 interface.

URR does not determine where packets should be forwarded, and it does not directly enforce bandwidth limits. Instead, it tells the UPF which matched traffic should be measured, how that usage should be measured, and under what conditions the measurement result should be reported to the control plane. URR therefore turns user-plane traffic from something that is merely forwarded into something that can also be measured. The UPF performs the actual measurement, the SMF provisions the reporting conditions through PFCP, and the resulting Usage Reports form a continuous feedback loop between the user plane and the control plane.

What Problem Does URR Solve in the N4 Rule Framework?

The easiest way to understand URR is to separate its responsibility from those of PDR, FAR and QER. When the UPF receives a packet, the PDR first determines what traffic it belongs to. Once the packet has been classified, the FAR decides how it should be handled and where it should be forwarded. QER applies the required QoS treatment. URR answers a different question: how much of this traffic has actually been used?

The main PFCP rule types can be summarized as follows:

PDR: What traffic is this?
FAR: How should the packet be handled, and where should it go?
QER: What QoS treatment should be applied to this traffic?
URR: How much of this traffic has been used, and when should that usage be reported?

A URR needs to be associated with the relevant PDR. The reason is straightforward: the UPF cannot meaningfully measure "how much a user has consumed" without first knowing which packets belong to that UE, service or traffic flow. Once the PDR identifies the traffic, the associated URR can measure the usage of those matched packets. If a PDU Session contains multiple PDRs, different URRs can also be used to create more granular usage-measurement relationships.

For this reason, the first question during URR troubleshooting is usually not "Was the URR provisioned?" but rather "Which PDR is matching the traffic being measured, and which URR ID does that PDR reference?" If that association is missing or incorrect, the later measurement and reporting stages cannot work as expected.

How Does URR Define What the UPF Measures?

A URR is more than a simple traffic counter. One of the first elements defined in a Create URR is the Measurement Method, which tells the UPF what kind of usage should be measured. Depending on the service requirements, measurement can be based on traffic volume, time or events.

For common packet-data services, volume-based measurement is often the easiest to observe. The UPF can measure uplink, downlink and total traffic volume, while the relevant fields in Volume Measurement indicate which statistics are included. Traffic volume is accumulated in bytes, so a URR can measure total usage or distinguish between UL and DL traffic depending on the configuration.

If the required capability is enabled, the measurement can also include packet counts. For example, the MNOP flag in Measurement Information can request the UPF to measure the uplink, downlink and total number of packets. In that case, the operator does not only see how many bytes were transferred, but also how many packets were processed during the measurement interval.

Time-based measurement focuses on service duration. Depending on the configuration, it can involve parameters such as Time Threshold, Time Quota, Inactivity Detection Time and the applicable time-measurement mechanism. Event-based measurement can instead count specific service events and report when a defined number of events has occurred.

Measurement Method therefore answers the most fundamental URR question: what does "usage" mean for this rule? If this is not established first, it is easy to confuse Threshold, Quota and Reporting Trigger when analyzing PFCP messages. The selected measurement method directly affects the type of counters maintained by the UPF, the format of the Usage Report, and how the SMF interprets the result.

Reporting Trigger Determines When the UPF Must Send a Report

A measurement method alone is not sufficient. If the UPF simply continues accumulating counters without any reporting condition, the SMF has no defined point at which it should receive the result. This makes Reporting Triggers another core part of the URR mechanism.

These triggers can be combined according to the network policy. PERIO can be used for periodic reporting. VOLTH indicates that a report should be generated when a volume threshold is reached. TIMTH applies to a time threshold. START and STOPT can trigger Usage Reports when the UPF detects the start or stop of traffic.

Another group of triggers is more closely related to quota control. VOLQU is associated with volume quota conditions, TIMQU with time quota conditions, and EVEQU with event quota conditions. Quota Holding Time can also be used when quota has been granted but the subscriber generates no user-plane traffic for a defined period.

It is particularly important to distinguish between Threshold and Quota, because they serve different purposes in PFCP and are often confused during trace analysis:

A Threshold is mainly about when a measurement result should be reported, while a Quota is closer to how much resource remains available for use. If a PFCP trace only shows that VOLTH or VOLQU is set but the engineer does not inspect the corresponding Threshold or Quota parameter, it is easy to misunderstand the actual service logic.

For example, if VOLTH is configured but the corresponding Volume Threshold is not properly defined, the UPF has no meaningful traffic boundary at which to trigger the expected report.

How Does the UPF Send Usage Results to the SMF?

The URR mechanism forms a complete feedback loop through the PFCP Session Report procedure. Once a reporting condition defined by a URR is satisfied, the UPF does not necessarily need to wait for the SMF to query the counters. It can send a PFCP Session Report Request to the SMF.

When the Report Type indicates that the message contains a Usage Report, the SMF can identify the event as a user-usage report. Several fields are particularly important during analysis. URR ID identifies which rule generated the report. UR-SEQN identifies the sequence of the Usage Report for that URR. Usage Report Trigger explains why the report was generated.

The actual measurement values then appear in fields that correspond to the Measurement Method. For volume-based measurement, Volume Measurement can contain total, uplink and downlink usage values. For time-based measurement, Duration Measurement becomes more important. Fields such as Start Time, End Time, Time of First Packet and Time of Last Packet can also help determine the exact measurement interval covered by the report.

Receiving the Usage Report does not necessarily end the process. Depending on the service logic, the SMF can continue by sending a PFCP Session Modification to update the URR, for example by changing the reporting threshold, assigning a new quota or modifying the conditions for the next report.

The complete URR workflow can therefore be summarized as:

SMF provisions URR → UPF measures the matched traffic → Reporting Trigger condition is met → UPF sends a Usage Report → SMF processes the usage result → URR is updated if required.

Usage reporting is therefore not simply a matter of the UPF uploading a counter. It is a dynamic process in which the control plane defines the measurement policy, the user plane performs the measurement, and the result is continuously fed back to the control plane. A problem at any stage can lead to inaccurate usage values or missing reports.

How Does a Volume Threshold Trigger an Actual Usage Report?

The URR logic becomes easier to understand when placed in a concrete traffic scenario. Assume that the SMF creates a URR during PFCP Session Establishment and instructs the UPF to use volume-based measurement for traffic matched by a specific PDR. VOLTH is enabled as the Reporting Trigger.

If the Volume Threshold is configured for TOVOL with a value of 10240 bytes, the rule does not mean that the user is allowed to consume no more than 10240 bytes. Instead, it means: when the measured total uplink and downlink volume reaches this threshold, the UPF should generate a Usage Report.

As the UE begins generating traffic, the UPF continues forwarding packets normally while also accumulating the usage counters defined by the URR. Once the accumulated volume reaches the reporting threshold, the UPF sends a PFCP Session Report Request. The Usage Report identifies VOLTH as the trigger reason, while Volume Measurement contains the actual total usage and the applicable uplink and downlink values.

The final reported value does not have to stop exactly at 10240 bytes. The UPF evaluates the threshold while processing real packets, and a complete packet may move the accumulated usage directly from below the threshold to above it. Therefore, seeing a Usage Report value slightly higher than the configured Threshold is not contradictory.

This leads to an important principle when analyzing URR behavior: a Threshold is a reporting boundary, not a mechanism that truncates the measured value to an exact number. If a Quota is configured at the same time, quota exhaustion may trigger additional control behavior, but that should be analyzed as a separate control path rather than being confused with a simple threshold-based report.

URR Troubleshooting Should Follow Four Layers: Association, Measurement, Trigger and Reporting

URR problems can be difficult to notice because the user-plane service itself may appear completely normal. The UE can access the network, the PDR matches correctly, and the FAR continues forwarding packets, while the usage counters seen by the backend remain incorrect, no Usage Report is generated, or the expected control-plane event never occurs after a threshold is reached.

For this reason, URR troubleshooting should not begin with the question "Can the user access the network?" It should follow the complete usage-measurement chain.

First Confirm the PDR-to-URR Association

Start by identifying the PDR that actually matches the traffic and then confirm the URR ID associated with it. A PFCP Session may contain multiple PDRs and multiple URRs. Analyzing the wrong URR will not explain the current usage results even if all of that URR's parameters appear correct.

A typical problem is that the PDR matching condition has changed while the URR remains associated with an earlier PDR ID. In that case, the measurement target itself has shifted away from the actual traffic.

Then Verify the Measurement Method and Direction

Check whether the URR is configured for Volume, Duration or Event measurement. If volume-based measurement is used, verify whether the rule measures Total, UL, DL or packet counts as well.

This step is particularly important when the uplink and downlink statistics do not match expectations. Some apparent failures occur simply because the URR measures only one direction while the test traffic is flowing in the other direction, leaving the expected counter unchanged.

Check the Reporting Trigger and Its Corresponding Threshold

If the UPF does not generate a report, confirm which trigger the control plane actually requested. Configuring VOLTH without a suitable Volume Threshold, or expecting periodic reports when PERIO is not enabled, can produce results that differ from the intended service behavior.

Similarly, time-based reporting should be interpreted together with the related time-measurement parameters and monitoring conditions rather than by inspecting a single trigger flag in isolation.

Finally Trace the PFCP Session Report

Once the trigger condition is met, verify whether the UPF sends the expected Usage Report. Check the Report Type, URR ID, UR-SEQN and Usage Report Trigger against the current PFCP Session.

If the UPF has already generated the report but no new quota, threshold or follow-up control action appears, troubleshooting should move toward the SMF and the subsequent control-plane logic instead of remaining focused on the UPF counter.

If the issue involves measurement before or after QoS enforcement, the relevant flags in Measurement Information and Usage Information should also be examined. URR does not represent just one isolated number. The measurement time window, the traffic being measured and the processing stage at which measurement occurs all affect how the final usage value should be interpreted.

Many cases where "the usage does not match" are not caused by an incorrect UPF counter, but by a mismatch between the actual measurement scope and the expected accounting scope.

URR Turns User-Plane Traffic into Measurable Information for the Control Plane

PDR, FAR and QER mainly describe how packets are identified, forwarded and subjected to QoS treatment inside the UPF. URR adds another essential capability: it allows the control plane to know how much user-plane traffic has actually been consumed.

URR uses Measurement Method to define the measurement scope, Reporting Trigger to determine when a report is required, and parameters such as Threshold, Quota and Monitoring Time to control different stages of usage measurement. Once the required condition is met, the UPF sends the result back to the SMF in a PFCP Usage Report, after which the control plane can update the URR or take another policy action if necessary.

The most practical way to understand URR is therefore not to memorize dozens of Information Elements, but to follow one complete chain:

PDR selects the traffic to be measured → URR defines the measurement method → UPF continuously measures usage → Reporting Trigger determines when to report → Usage Report returns the result to the SMF → SMF updates the control policy as required.

Once this chain is clear, parameters such as Volume Threshold, Volume Quota, Measurement Period, Monitoring Time and the various Reporting Triggers stop looking like isolated PFCP fields. They become different control points within the same 5G usage-measurement and reporting mechanism.

For services that require usage-based charging, real-time quota management or policy adjustment based on consumption, this mechanism provides the foundation that makes the 5G user plane not only capable of forwarding traffic, but also measurable and controllable.

FAQ