The operator faces a similar problem across the entire network. During congestion at peak hours or at large events, the core sends out updated profiles with reduced bandwidth, lowering speeds for all subscribers at once. All services then compete indiscriminately for the remaining capacity. Video and calls, which subscribers use to judge network quality, degrade first, and it’s hard for the operator to quickly reallocate bandwidth between services.
The problem isn’t equipment failure or the configuration of a particular network. The 3GPP (3rd Generation Partnership Project) standard describes mechanisms for limiting bandwidth per subscriber and per service, but it doesn’t define which service gets bandwidth first when there isn’t enough for everyone. In this article, we’ll look at where this gap in the standard lies and how VAS Experts PCEF closes it.
A Ceiling but No Rules
To understand where this gap comes from, we need to dig into the specification 3GPP TS 23.203 “Policy and charging control architecture”.
QoS architecture in 3GPP is built around bearers: EPS bearers in LTE and QoS Flows in 5G. A bearer is a logical channel between the user device and the packet gateway with its own set of quality parameters.
Dedicated Bearer
If a data flow needs specific service parameters (guaranteed bit rate, acceptable latency, and packet loss rate) or a specific priority, a separate dedicated bearer is created for it with its own QoS profile (QCI/5QI, ARP).
The standard also lets you set priority through ARP (Allocation and Retention Priority), but this is the priority of the bearer, not of an individual service. SDF (service definition function) maps services to bearers with defined QCI and ARP values. When radio resources run short, a bearer with a low ARP won’t be created, and an existing one may be torn down entirely. So the bearer does have a priority, but it only affects creating or deleting the entire bearer along with all the services in it, and it doesn’t allow bandwidth to be flexibly allocated between services.
Default Bearer
All traffic from services that don’t have a dedicated bearer (web, messaging apps, YouTube, torrents, background updates) goes through the base channel, the default bearer. It’s always a non-GBR (Non-Guaranteed Bit Rate) bearer and is usually assigned the low-priority QCI 9 class. Traffic in this class is handled on a best-effort basis, and delivery isn’t guaranteed. For all non-GBR traffic, the standard provides a shared parameter, APN-AMBR.
According to the 3GPP specification, the job of the PCEF (Policy and Charging Enforcement Function) is to ensure that the total bit rate of all non-GBR service data flows (SDFs) within an access point name (APN) doesn’t exceed this ceiling. The standard doesn’t describe how to allocate bandwidth between competing flows when their combined demand exceeds the ceiling. As a result, the interfaces the policy server (PCRF) uses to pass rules to the PCEF (for example, Gx over the Diameter protocol) have no attributes (AVPs) that could carry such an allocation.
Imagine a subscriber’s plan is 50 Mbps, while a torrent or game update can take up to 100 Mbps, so the link is completely saturated. Messaging app packets hit the same policer as the torrent. With no balancing rules, the policer cuts traffic without distinguishing between services. As a result, nearly all the bandwidth goes to whoever generates the most traffic, which in our case is the torrent.
The 3GPP standard strictly defines the interfaces between nodes but deliberately leaves scheduling logic and traffic competition within a single APN up to equipment vendors. As a result, the standard has no mechanism for allocating bandwidth between services by priority.
Hierarchical QoS on PCEF from VAS Experts
VAS Experts solves this with hierarchical QoS (HQoS) on the PCEF using local profiles. The subscriber’s bandwidth isn’t increased; instead, it’s allocated between services by priority. Priority traffic types, such as voice and web, get bandwidth first, while P2P and background downloads use what’s left.
Two Policing Levels
The top level of the hierarchy is the root HTB class, which represents the subscriber’s total bandwidth. It’s set in the policing profile (rate plan). This is where the APN-AMBR value (or the home internet plan speed) goes, for example, 50 Mbps. The subscriber can’t exceed this ceiling in total.
The second level (leaf classes) contains eight classes, from class0 to class7. By default, class0 has the highest priority and class7 the lowest. The signature-based DPI engine recognizes the protocol or traffic destination (YouTube, BitTorrent, Telegram) and assigns the flow to the appropriate class. Class assignment is defined either by global marking by protocol and destination or by per-subscriber marking by protocol. The classes themselves are linked to rating groups through a mapping table.
Figure 1 — Policing levels
How Bandwidth Is Shared Between Classes
The administrator can choose between two policing mechanisms.
The main mechanism is HTB (Hierarchical Token Bucket), which implements hierarchical QoS. When a new APN-AMBR value arrives from the PCRF, the system dynamically applies it to the root class and allocates that bandwidth across the classes. For each of the eight classes, you set a guaranteed rate (rate) and a maximum rate (ceil).
What it delivers: a priority service gets its bandwidth as soon as its traffic appears, while a low-priority service uses whatever is left. When there’s no high-priority traffic, low-priority traffic can take all the available speed.
Example of bandwidth allocation by class for a 50 Mbps plan: # Inbound traffic (to the subscriber), 50 Mbps plan htb_inbound_root=rate 50mbit # class0 — calls: 5 Mbps guaranteed htb_inbound_class0=rate 5mbit ceil 50mbit # class1 — video: 20 Mbps guaranteed htb_inbound_class1=rate 20mbit ceil 50mbit htb_inbound_class2=rate 8bit ceil 50mbit htb_inbound_class3=rate 8bit ceil 50mbit htb_inbound_class4=rate 8bit ceil 50mbit htb_inbound_class5=rate 8bit ceil 50mbit htb_inbound_class6=rate 8bit ceil 50mbit # class7 — torrents: 1 Mbps guaranteed, but can take the whole link when it's free htb_inbound_class7=rate 1mbit ceil 50mbit
The second is TBF (Token Bucket Filter), a non-hierarchical policer. It limits each class independently: a class gets a fixed rate ceiling and won’t go above it, even if the rest of the bandwidth is idle. Classes without a set limit aren’t restricted. TBF has no overall ceiling.
What it delivers: a predictable hard limit on, or blocking of, a specific traffic class.
Example of a hard limit on torrents at 3 Mbps:
tbf_inbound_class7=rate 3mbit tbf_class7=rate 3mbit
What This Means for Subscribers and Operators
Now the subscriber can talk over a messaging app and download a large file at the same time, because the torrent goes into class7 with the lowest priority and takes all 50 Mbps until other services need the link. As soon as the subscriber starts a call or opens YouTube, that traffic goes into class0 or class1, and the HTB scheduler immediately takes bandwidth from the torrent and gives it to the priority service. The call no longer drops, the video plays without pauses, and the torrent keeps downloading, just more slowly.
The plan speed hasn’t changed. Only the way it’s shared between services has.
At the same time, the operator gets the most quality out of the resources it already has. Even if the core cuts APN-AMBR to 7–10 Mbps during congestion, priorities within that limit are maintained. The reduced bandwidth goes primarily to video and calls, so video plays without rebuffering, and calls in the MAX messenger stay in Full HD.
Less Manual Work for the Operator
Without priorities, rating groups have to be balanced manually: expanding one so another doesn’t get squeezed, while keeping overall traffic volume in mind so that everything works together.
With HQoS, the operator assigns a priority class to each service once. The operator defines the classes and their order based on its business model and on which services have the greatest impact on user experience. The policing profile is created once and assigned to subscribers. From then on, bandwidth is allocated automatically in every subscriber session, no matter how the network load or the subscriber’s allocated bandwidth changes. Unused classes can be put to work later: you just change the marking on the DPI, with no need to modify the profile itself.
If subscribers on your network complain about dropped calls and stuttering video while the radio link is working fine, and during congestion you have to throttle bandwidth for everyone indiscriminately, it’s worth seeing how HQoS on Stingray PCEF performs with your traffic. VAS Experts specialists will help you map services to priority classes based on your business model and rate plans. Contact us, and we’ll discuss where to start.
