定义
带宽管理（Bandwidth Management）对网络带宽进行分配、预留、限速等管理，确保关键业务获得足够带宽，防止单一用户或业务占满资源。3GPP在QoS框架中定义了GBR（Guaranteed Bit Rate，保证比特率）、非GBR、AMBR（Aggregate Maximum Bit Rate，聚合最大比特率）等机制，与差异化服务、流量调度协同，实现带宽的精细化管控。
核心机制
- GBR（保证比特率）：为语音、视频等实时业务预留固定带宽，确保时延与抖动可控
- 非GBR：尽力而为业务，无带宽保证，根据负载动态分配
- AMBR限速：对用户或APN的聚合流量设置上限，防止单用户占满资源；UE-AMBR、APN-AMBR分别限制终端与APN维度
- 带宽预留与优先级：结合优先级QoS，高优先级业务优先获得带宽
实现层级
带宽管理在基站（调度）、核心网（承载建立、QoS策略）、专网网关等多层级实现。物联网场景中，可为关键设备配置GBR或高优先级，为海量低优先级传感器配置AMBR限速，实现带宽的合理分配与成本控制。
典型应用场景
专线、物联网关键业务、视频监控、车联网、工业控制等需带宽保障；公网接入、低优先级传感器等需AMBR限速。达希物联可根据客户业务需求，配置差异化带宽策略。
达希物联为物联网客户提供灵活的带宽与流量管理方案。通过APN专网与QoS配置，可为关键业务预留带宽、对低优先级设备限速，避免单设备占满资源。达希物联云平台支持按设备、按业务维度的流量监控与带宽策略下发。
保证比特率建失败时业务会落到默认承载
保证比特率承载要在建立时就向调度器预留资源。小区负载已经很高、或签约里没有相应服务质量等级时，专用承载会被拒绝。很多模组这时不会拆掉整个连接，而是继续用默认的非保证承载发数据。应用层看到的是“在线但时延突然变大”，速率曲线不再平稳。判断条件是：信令里有承载建立失败，随后业务仍在默认承载上发送。这时加应用层重试解决不了预留失败。
预留是否生效，还要看无线侧能不能持续满足保证速率。只在核心网写下保证值、基站调度给不出资源，承载可以处于建立成功、实际速率不足的状态。应同时看承载状态和空口调度份额，而不是只看签约单上的数字。
聚合上限在终端侧和接入点侧各卡一层
终端聚合最大比特率把这张卡上所有非保证承载的总和封顶；接入点名称上的聚合上限再把同一接入点下的流量封顶。两层同时存在时，先触到的那一层生效。只放宽终端侧、接入点侧仍是小额度，视频回传还是上不去。反过来，接入点额度很大、终端侧仍按低档签约，单台设备也跑不满。排查时把两层限额和当前承载类型记在同一行：保证承载不受终端聚合上限约束，非保证承载受约束。
限速的实现常是令牌桶。桶深决定能吞下多大的瞬时突发，补充速率决定长期平均。桶深设得过浅，周期上报的一小簇报文也会被整形，表现为每分钟开头的几包时延高、后面恢复。桶深设得过深，短时突发能把小区上行打满，邻居设备的保证业务被挤占。参数要按上报周期和单包大小来定，而不是按实验室的峰值灌包来定。
小包节奏比平均速率更容易触发整形
物联网流量常常是几十字节跟着长沉默。按月流量看并不大，但若几百台设备在同一秒醒来，瞬时速率会顶到聚合上限，随后整段被延迟。判断是不是带宽管理在起作用，要看延迟是否卡在策略设备上：空口信号正常、服务器负载正常、报文在网关处排队变长。把上报起点按设备标识打散，比单纯提高套餐带宽更对症。
达希物联能配合的是接入点策略、签约速率和平台侧的用量观察。这些手段约束的是蜂窝承载上的额度，约束不了设备局域网内部的交换容量，也替代不了应用自己的发送队列。平台曲线已经顶在签约上限时，应先调整聚合比特率或错峰，而不是更换天线。
保证速率和套餐流量不是同一个计数器
保证比特率约束的是某一时刻调度器愿意留给这条承载的速度，套餐或接入点额度约束的是一段时间内累计能用的字节。速度没到顶、累计字节已经用完时，网络可以继续保持连接但把后续报文丢弃或降到极低速率。只看瞬时测速会以为带宽管理没有生效。反过来，累计字节还很多、瞬时却上不去，要查的是保证速率有没有真正建上，以及令牌桶是不是被突发打空。两个计数器应在同一张图上，一个看斜率，一个看面积。
月结清零或额度恢复的时刻，所有设备可能同时恢复全速，形成人为的整点拥塞。恢复后的第一轮上报应仍受聚合上限约束，不能因为额度刚恢复就取消整形。达希物联平台上的用量是累计字节，基站上的保证速率是即时调度，两者同时正常才说明带宽策略整段生效。用量很低但时延很大，不要先加套餐，先看承载是不是掉回了非保证；用量已尽而信号很好，加天线也多传不出字节。