一根 GPON 主干上行理论也就 1.25G，却要塞进几十到上百个 ONU 的流量。如果给每个 ONU 平均分一块固定带宽，结果是：白天大家同时刷视频时谁都不够用，深夜大多数用户睡了，那块固定带宽又白白空着。这种"闲时浪费、忙时挤爆"的矛盾，靠 DBA（Dynamic Bandwidth Allocation，动态带宽分配） 来解决。
DBA 的核心思路很简单：上行带宽是共享池，OLT 不做死板的平均切分，而是看着每个 ONU 实时的缓存情况，谁这会儿有数据要发就多给谁时隙，谁空闲就把份额收回来借给别人。
OLT 不会瞎猜。ONU 在上行时隙里会夹带一份状态报告（GPON 里叫 DBRu，附在用户数据后面），告诉 OLT："我这边目前排着多少字节没发出去、分别属于哪个优先级队列"。OLT 收集到所有 ONU 的报告，再结合给每个 ONU 定好的带宽档次，算出下一帧该给谁多少时隙，写进带宽授权（BWmap）下发给各 ONU。
整个调度以 125 微秒的帧为节拍循环，所以 DBA 的响应是毫秒级的，用户基本感觉不到拥塞。
DBA 不是"谁嗓门大谁先上"，它把每个 ONU 的带宽分成几个档次，从高到低大致是：
- 固定带宽（Fixed）：雷打不动保留给某业务，比如专线或关键控制信号；
- 保证带宽（Assured）：承诺给到，闲时不用可以腾出来，但忙时一定保底；
- 非保证带宽（Non-Assured）：有就给、没就弃，优先级低于保证带宽；
- 尽力带宽（Best-Effort）：池子里剩下的全归它，最容易被挤掉。
DBA 真正"动态"的部分，发生在保证带宽之上：一个 ONU 今天没用满它的保证份额，OLT 就把这部分临时借给另一个正挤着的 ONU；等前者又有流量了，份额再还回去。既保住了每个用户的底线，又不让空闲资源睡觉。
| 分配方式 | 上行利用率 | 忙时体验 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 静态平均分配 | 低（闲时空转） | 差（挤爆无兜底） | 低 | 极简单、用户数极少 |
| 固定+保证（无动态） | 中 | 一般 | 中 | 业务可预测 |
| DBA 动态分配 | 高（闲时借用） | 好（按需调度） | 较高 | 多用户、流量突发 |
有人把 DBA 和 QoS 混为一谈。简单说，QoS 决定"哪份数据更金贵"（语音 > 视频 > 上网），DBA 决定"这一刻把时隙分给谁"。OLT 在排班时会先满足高优先级队列的报告，再填低优先级的，这样语音和视频在拥塞时也能拿到时隙，不会卡成幻灯片。两者一起工作，才既"公平"又"保重点"。
分光比越大，单 ONU 摊到的平均带宽越薄，突发流量越容易撞车。正是这种场景让 DBA 的价值最突出：它能把"此刻谁在忙"实时反映到调度里，让有限的共享上行始终喂给最需要的 ONU，而不是被某个空闲用户长期占着坑。这也是为什么大分光比 PON 部署里，DBA 算法好坏直接拉开设备体验差距。
先有 QoS 把业务分好优先级，DBA 才能据此调度。两者一般一起配，单独开 DBA 不认优先级，单独开 QoS 没有动态时隙也腾不出带宽。
在 QoS 里把语音/视频标记为高优先级队列，ONU 的状态报告会带上队列长度，OLT 排班时优先满足这些队列的带宽请求。
更管用。分光比越大上行越紧张，动态借用的收益越明显；前提是 OLT 的 DBA 粒度够细、调度周期够短。
不能。DBA 优化的是"已有带宽怎么分"，如果总上行带宽本身不够（比如所有用户同时在线的总需求超过主干），那需要扩容上行链路或收敛用户数，DBA 无法凭空造带宽。
DBA 让 PON 的上行从"切蛋糕"变成"活水调配"：保证带宽托底、闲时份额借用、高优先级先得，所有动作以 125 微秒为节拍滚动。看懂 DBA，就明白为什么同样的 1.25G 上行，有的设备带得动上百户、有的却动不动卡顿。关于 OLT 怎么远程把这套配置下发到每个 ONU，我们在锐应科技的 OMCI 管理解析一文里继续展开；想直接看设备能力，锐应科技官网有 GPON OLT 的规格说明；PON 上行为什么不冲突的底层原理，可以参考锐应科技的 PON 测距与 TDMA 文章。
