DBA (Dynamic Bandwidth Allocation) is how an OLT shares one upstream pipe among dozens or hundreds of ONUs: each ONU reports how much data it is holding, and the OLT grants timeslots accordingly — more to whoever is busy, less to whoever is idle. Fixed slices would waste capacity at night and starve everyone at peak.
A GPON trunk offers about 1.25 Gbps upstream in total. Split it evenly and you get the worst of both worlds: everyone short at 8pm, and most of that allocation sitting unused at 3am. DBA exists to close that gap, and it is one of the reasons a well-engineered FTTH build feels fast on the same fiber that a badly scheduled one does not.
Key takeaways
ONUs report queue depth with each upstream burst (DBRu in GPON), so the OLT schedules from real demand rather than guesswork.
Bandwidth comes in tiers: fixed, assured, non-assured and best-effort. Only the part above the assured tier is truly dynamic.
DBA decides who gets this slot; QoS decides which traffic is more important. You need both.
It does not guess. Inside its upstream burst, an ONU attaches a status report — the DBRu field in GPON — saying how many bytes are queued and which priority queue they belong to. The OLT collects these reports, applies the bandwidth profile configured for each ONU, works out the next frame's grants, and writes them into the BWmap that goes back downstream.
The whole loop runs on a 125 microsecond frame, so DBA reacts in milliseconds. Subscribers perceive a link that simply keeps up, rather than one that visibly stalls and recovers.
DBA is not "whoever shouts loudest goes first." Each ONU's allocation is split into tiers, from most to least protected:
| Tier | Behaviour | Typical use |
|---|---|---|
| Fixed | Reserved regardless of demand | Leased lines, critical control traffic |
| Assured | Guaranteed; idle share can be lent out, but the floor holds under load | Business subscribers |
| Non-assured | Granted when available, dropped first | Standard data |
| Best-effort | Whatever the pool has left | Bulk downloads, background sync |
The genuinely dynamic part sits above the assured tier. If an ONU is not using its assured share today, the OLT lends that capacity to another ONU that is congested right now, and hands it back when the first one gets busy again. Every subscriber keeps a floor, and idle capacity does not sleep.
Note: This is also where traffic prioritization meets capacity planning. Rate limiting at the ONU port is a separate lever — it caps what one subscriber can take, while DBA decides how the shared pool is divided at any instant. They solve different problems and are usually configured together.
| Allocation | Upstream efficiency | Peak-hour experience | Complexity | Best fit |
|---|---|---|---|---|
| Static even split | Low (idles at night) | Poor (no fallback when squeezed) | Low | Very simple, few users |
| Fixed plus assured, no dynamic | Medium | Average | Medium | Predictable traffic |
| DBA, dynamic | High (idle share is lent) | Good (scheduled on demand) | Higher | Many users, bursty traffic |
The two get conflated constantly. QoS decides which data matters more — voice above video above web browsing. DBA decides who gets the slot at this instant. The OLT fills grants for high-priority queue reports first, then lower ones, which is why voice and video keep their slots under congestion instead of freezing. That ordering is traffic prioritization doing its job inside the scheduler.
Run one without the other and you get half a solution: DBA alone does not know what is important, and QoS alone cannot free up bandwidth that a static schedule has already assigned.
The larger the split ratio, the thinner the average slice per ONU, and the more often bursts collide. That is exactly where DBA earns its keep — it reflects who is busy right now into the schedule, so limited upstream capacity flows to the ONUs that need it instead of sitting reserved for someone idle.
At high split ratios, DBA quality becomes a real differentiator between vendors. Two OLTs with identical line rates can feel very different to subscribers purely because of grant granularity and how short their scheduling cycle is.
Tip: When comparing OLTs for a large-split build, ask about grant granularity and scheduling interval, not just headline upstream rate. Those two numbers decide how well the box handles simultaneous bursts.
Which should I configure first, DBA or QoS? QoS first — it classifies traffic into priorities, and DBA then schedules according to them. In practice they are configured together. DBA alone has no notion of priority; QoS alone cannot conjure free slots out of a fixed schedule.
How do I prioritise voice and video? Mark voice and video into high-priority queues in the QoS configuration. The ONU's status report carries queue depth per queue, and the OLT satisfies those queues first when it builds the grant map.
Does DBA still help at 1:128? It helps more. The bigger the split, the tighter upstream becomes and the more valuable dynamic borrowing gets — provided the OLT's grant granularity is fine enough and its scheduling cycle short enough.
Can DBA fix upstream congestion completely? No. DBA optimises how existing bandwidth is divided. If total demand exceeds what the trunk can carry, you need more upstream capacity or fewer subscribers per PON port — DBA cannot create bandwidth that is not there.
Is DBA only for GPON? The concept appears across PON standards, since any shared upstream needs it. The reporting fields, tier names and grant mechanisms differ between standards, so the configuration details do not carry over directly.
DBA turns PON upstream from a fixed cake into a flowing allocation: an assured floor per subscriber, idle share lent out on demand, and high-priority queues served first — all rolling on a 125 microsecond beat. It explains why one operator's 1.25 Gbps upstream carries a hundred subscribers smoothly while another stutters — and why FTTH operators set rate limiting per subscriber rather than trusting a flat cap. Rayin's GPON OLT lineup covers the port counts used in these builds.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
