Why DPI: Application-Aware Traffic Policies and Visibility

Abstract. BQN Deep Packet Inspection (DPI) extends bandwidth management beyond subscriber and flow rate limits by identifying the applications that generate traffic. This application awareness allows operators to define policies for specific application categories, measure how applications are used, and evaluate their performance over time. DPI-based policies are not a replacement for BQN’s automatic control functions. Instead, they complement BQN Automatic Congestion Management (ACM), which detects and mitigates congestion from subscriber-level signals, and BQN Active Queue Management (AQM), which enforces limits with advanced per-flow queueing. Together, DPI, ACM, and AQM give operators both automatic Quality of Experience (QoE) protection and intentional application-aware control.

‍

Why application awareness matters

Subscriber-level bandwidth control answers the question “how much traffic should this user or group receive?” DPI adds a second dimension: “what kind of traffic is using that capacity?” This distinction matters because applications have different QoE sensitivities. A software update, a video stream, a cloud backup, a game session, and a video conference can all consume capacity, but they do not react to delay, loss, or temporary shaping in the same way.

BQN uses DPI profiles to identify flows whose DPI domain matches predefined or custom application signatures. These predefined signatures include popular applications such as teleconferences, major video-streaming services, and common software updates. Once traffic is classified, the policy system can apply different flow policies to different applications, while still operating within subscriber, group, or network-level controls.

‍

DPI as an application-policy selector

BQN policies are selected through rules that combine profiles with policies. Profiles classify the traffic; policies define the action. DPI therefore becomes a selector for application-aware decisions. A rule can match traffic from a subscriber group, time range, access network, or interface, and then further match the application signature through a DPI profile. This makes application-based traffic control precise enough to be useful without turning the network into a collection of static router access lists.

Three policy patterns cover most deployments:

• Application prioritization: give higher relative priority to latency-sensitive applications such as teleconferences when a subscriber or group reaches a limit. This prioritization is on top of the automatic prioritization provided by the AQM element, reinforcing it.
• Application moderation: slow down heavy or non-interactive categories during peak periods instead of applying a uniform penalty to all traffic.
• Rate plan measurement accuracy: identify speed tests so the result reflects the contracted rate rather than whatever capacity the rest of the home leaves over, as described below.

Speed tests are a good illustration of why identifying the application matters commercially and not only technically. When a subscriber runs a test, they interpret the number as the speed of their plan — but the test competes with everything else active in the home at that moment, so a household streaming video, backing up to the cloud, or downloading a console update will see a result well below the contracted rate even though the access network is delivering exactly what was sold. The subscriber concludes they are not getting their plan and opens a ticket, and the support team spends time proving a negative. Because DPI recognizes the major speed-test services by signature rather than by server address, BQN can treat those flows as a distinct application and give the test the subscriber’s full allowance for its short duration, letting concurrent background traffic yield while it runs. The measurement then reflects the plan limit rather than the plan minus whatever else the home happened to be doing, which removes a recurring and entirely avoidable class of support tickets.

‍

Application usage and performance data

DPI also turns BQN into an application-visibility platform. With BQN, operators can see which applications are running in the network and how they perform, down to individual subscriber groups and a single subscriber’s live traffic. This data has direct operational value. Support teams can determine whether a complaint is linked to a specific application, a subscriber access issue, or a congested network segment. Engineering teams can detect whether peak-hour capacity pressure is driven by a small number of heavy categories or by broad subscriber demand. Product teams can understand application mix and design policies that protect interactive QoE without unnecessarily suppressing useful traffic.

‍

How DPI complements ACM and AQM

ACM and AQM are automatic control mechanisms. ACM detects congestion by observing subscriber speed, latency, and loss behavior, then mitigates the condition when it appears. AQM enforces limits with per-flow queueing so that one heavy flow does not create excessive delay for other flows. DPI-based policies add operator intent. They answer questions ACM and AQM are not designed to answer, such as which application categories should receive priority during a busy hour and which high-volume categories should be moderated.

The relationship is therefore complementary. ACM finds the real congestion point and adjusts the operating rate. AQM keeps queues short and flows isolated at the enforced limit. DPI determines how applications should be treated inside that controlled environment. For example, when a subscriber group reaches a speed limit during peak time, AQM prevents large shared queues, ACM detects whether congestion remains harmful, and DPI policies can prioritize real-time applications over background updates or other elastic traffic.

‍

Design principles for DPI-based policies

• Use DPI to express intent, not to replace automatic control. Let ACM and AQM handle congestion mechanics; use DPI to decide which application classes deserve special treatment.
• Apply peak-hour scope. Combine DPI and time profiles so policies activate when capacity is scarce.
• Validate with application metrics. Check application speeds, latencies, retransmissions, and usage trends before and after policy changes.
• Work per subscriber group. Use subscriber groups to make policies specific to the affected segment.

‍

DPI vs. ASN for application identification

A simpler alternative to DPI is to classify traffic by the IP ranges or Autonomous System Number (ASN) it comes from. That approach is cheap, but it identifies the entity that operates the servers, not the service the subscriber is actually using. Large content providers serve many distinct services from the same ASN and often from the same address ranges, so an ASN-based rule cannot separate them. Netflix is the clearest example: video streaming and the fast.com speed test are both Netflix-operated and appear under the same autonomous system, yet they call for opposite treatment — a video stream is elastic, buffered, and a legitimate candidate for peak-hour moderation, while a speed test is a short measurement flow whose result the subscriber reads as the speed of their plan. Similarly, Google can host in the same IP address services as different as Youtube video streaming, Google Drive and Google Meet. An ASN rule sees one origin and treats all identically; a DPI profile matches the service signature and lets the operator moderate streaming while leaving the speed test untouched.

‍

Conclusion

BQN DPI adds application intelligence to the bandwidth-management loop. It lets operators identify applications, build application-based policies, and measure application usage and performance. ACM and AQM continue to provide the automatic QoE foundation: ACM detects and mitigates congestion, while AQM manages queues and flow isolation. DPI complements them by adding policy intent and visibility, allowing operators to protect latency-sensitive services, moderate elastic demand, and understand what applications are actually driving network load.