先看一个现网最常见的投诉场景：用户在室外开阔地，手机显示信号满格，RSRP,-70 dBm，SINR 二十多，无线环境无可挑剔。可测速永远卡在 100 Mbps，换手机、换卡、重插SIM，结果一模一样。
这时如果继续在无线侧查覆盖、查干扰、查调度参数，方向就全错了。因为这个天花板根本不在空口物理层，而在一张签约数据里——它的名字叫 AMBR（Aggregate Maximum Bit Rate，聚合最大比特率）。
理解 AMBR，是每一个无线优化工程师和核心网工程师的必修课。它解释了三个高频问题：为什么信号好却跑不快、为什么换套餐测速没变化、为什么同一个用户开两个切片会互相“分蛋糕”。这篇文章就把这道天花板从设计动机、参数层级、执行机制到排查思路完整讲透。
要理解 AMBR，先回顾一个基本矛盾：无线频谱是所有用户共享的稀缺资源，而绝大多数业务（网页、视频、下载）都是“尽力而为”型流量——用户要多少，网络就尽力给多少。
如果不加限制，会发生什么？一个开着 20 线程下载器的用户，可以近乎无限制地吃掉小区的调度份额，把同小区其他用户的视频拖成幻灯片。调度器虽然有一整套公平性算法，但那是在“竞争者”之间分蛋糕——如果某个人报的需求本身就没有上限，公平算法也只能在他划定的巨大份额里腾挪。
所以资源管理需要两个方向的工具：
地板和天花板是一对互补的设计。GBR 回答“最少给你多少”，AMBR 回答“最多让你拿多少”。上一轮我们讲过的准入与抢占，管的是地板资源不够时谁让路；而 AMBR 管的是无底洞型流量必须被罩住。
AMBR 并非 5G 发明。4G 时代就有对应机制，一个用户级上限、一个连接级上限；5G 只是把连接级的名字随架构演进而调整——4G 里一条 PDN 连接的天花板，到了 5G 换成一条 PDU 会话的天花板，思路一脉相承。理解了这个血统，很多 5G QoS 的设计就不神秘了：5G 的 QoS 框架，很大程度上是 4G 骨架的细化重命名。
5G 里有两种 AMBR，管辖范围不同，这是本文最核心的一组概念：
Session-AMBR（会话级天花板）：封住一条 PDU 会话内所有 Non-GBR QoS 流的总速率。注意关键词是“总和”——不是每条流各限一个值，而是所有尽力而为的流加在一起，不能超过这个数。
UE-AMBR（用户级天花板）：封住一个用户所有 PDU 会话的 Non-GBR 流量总和。用户同时开了三个切片、三条会话，每条会话各有自己的 Session-AMBR，但三条加起来还得听 UE-AMBR 的。
为什么非要两层？因为单层封顶防不住两种失控：
只有 Session-AMBR、没有 UE-AMBR：一个用户可以开 N 条会话（切片场景下很常见：一条上公网、一条进企业内网、一条打视频），总速率就是 N 倍叠加，网络依然会被单用户击穿。
只有 UE-AMBR、没有 Session-AMBR：用户内部没有边界。企业专网切片里的会话可以无限挤占用户总配额，导致同一部手机上“办公业务”和“娱乐业务”互相踩踏，切片之间的隔离承诺落空。
两层天花板的关系是嵌套的，最终生效的 UE-AMBR 通常由核心网统一计算：把该用户所有已建立会话的 Session-AMBR 加总，再与签约的用户级上限取小值——相当于“各房间额度之和，不得超过整户电表容量”。这个最终值随着会话的建立与释放动态变化：用户建一条会话，基站看到的用户总天花板就上调一档；释放一条，就下调一档。
flowchart TD
U["UE-AMBR 用户总天花板<br/>由基站执行"] --> S1["会话1的Session-AMBR<br/>由UPF执行"]
U --> S2["会话2的Session-AMBR<br/>由UPF执行"]
S1 --> F1["QoS流a<br/>Non-GBR"]
S1 --> F2["QoS流b<br/>Non-GBR"]
S2 --> F3["QoS流c<br/>Non-GBR"]
把 AMBR 放进完整的速率参数体系里看，四个参数各司其职：
| 参数 | 管住谁 | 性质 | 适用流量 | 执行点 | 手机知道吗 |
|---|---|---|---|---|---|
| GFBR | 单条GBR流的速率地板 | 资源预留 | 仅GBR | 基站调度器 | 不需要 |
| MBR | 单条GBR流的速率天花板 | 单流上限 | 仅GBR | 基站/UPF | 不需要 |
| Session-AMBR | 一条会话内所有Non-GBR流总和 | 会话总闸 | 仅Non-GBR | UPF，UE上行自我限制 | 知道，NAS下发 |
| UE-AMBR | 一个用户所有会话Non-GBR总和 | 用户总闸 | 仅Non-GBR | 基站 | 不知道 |
这里有一个关键设计决策值得停下来想一想：为什么 AMBR 只管 Non-GBR 流量，GBR 流完全不受它约束？
因为 GBR 流在资源预留时已经拿到了专属承诺——它的地板是 GFBR，天花板是 MBR，账已经算清了。如果再让它叠加进 AMBR 的总闸，就会出现两套互相矛盾的约束：一条被保证 100 kbps 的语音流，可能因为所在的会话总闸已满而被限制，那“保证”就成了空话。所以设计上干脆切开：GBR 流的资源已单独预留，AMBR 这把总闸只罩住没有预留的“公共池”流量。这也是为什么用户开着 VoNR 通话时，即使数据会话被限速到很低，通话质量也不受影响——语音根本不走这个总闸。
天花板有了，接下来是怎么“执法”。直觉做法是硬限速：每秒数着字节数，超了就丢。但现网限速几乎都采用令牌桶（Token Bucket）算法，这背后是一系列工程权衡。
先看令牌桶怎么工作：系统以固定速率 $r$ 往桶里放令牌（每允许发送一个字节就消耗对应数量的令牌），桶的容量是 $b$。数据包到达时，桶里有足够令牌就放行并取走令牌；没有就排队等待或直接丢弃。用公式描述令牌的补充过程：
$$T_{\text{new}} = \min\left(b,\ T_{\text{old}} + r \cdot \Delta t\right)$$
其中 $T$ 是桶内当前令牌数，$b$ 是桶深，$r$ 是令牌生成速率（即 AMBR 限速值），$\Delta t$ 是流逝的时间。
这个设计有两个精妙之处。其一，长期平均速率被压在 $r$ 以内——令牌生成速度固定，发得再猛，平均也快不过发牌速度：
$$\lim_{T \to \infty} \frac{1}{T} \int_0^T x(t)\,dt \le r$$
其二，允许短期突发。空闲 $t$ 秒后，桶里积攒了 $\min(b,\ r \cdot t)$ 个令牌，此刻到达的数据可以一口气全放行。这太重要了：真实的网页浏览不是匀速流水，而是“一顿猛发、然后沉默”的脉冲式流量——TLS 握手、页面主文档、首屏图片会在几百毫秒内密集发出。如果限速器不容忍突发，每个网页的首屏都会被削平，用户感觉“网很卡”；令牌桶放过突发、只压平均值，体验和效率兼得。
flowchart TD
G["发牌机<br/>每秒发r个令牌"] --> B["令牌桶<br/>容量b"]
P["数据包到达<br/>消耗对应令牌"] --> C{"桶内令牌<br/>够吗"}
B --> C
C -->|"够"| E["放行"]
C -->|"不够"| D["缓存等待<br/>或直接丢弃"]
和另外两种常见限速方案对比，令牌桶的定位就清晰了：
| 方案 | 突发容忍 | 输出特征 | 对TCP的影响 | 典型用途 |
|---|---|---|---|---|
| 硬窗口计数 | 无 | 周期性卡顿 | 周期性丢包，抖动大 | 简单网关限速 |
| 漏桶 | 无，恒速输出 | 完全平滑 | 增加时延 | 流量整形 |
| 令牌桶 | 桶深内允许突发 | 平均受限、瞬时可超 | 平均丢包少 | AMBR执法、策略执行 |
还有一个容易混淆的概念要辨析：执法（policing）与整形（shaping）。执法是超标就丢（或打标记），数据不缓存；整形是超标先排队缓存，慢慢放出去。AMBR 在网络里的执行通常是执法式的——这直接决定了下一节要讲的测速曲线形状。
顺带一提执行点的选择逻辑，同样体现了“在哪管最省事”的工程直觉。Session-AMBR 的执行点在 UPF：因为一条会话的所有下行数据都从这个锚点经过，在源头装总闸，天然覆盖全部流量；上行方向则把限额通过 NAS 消息告诉手机，让 UE 自己约束发送节奏。UE-AMBR 的执行点在基站：因为空口是唯一真正物理共享的瓶颈，用户所有会话最终都挤进同一段频谱，只有调度器的所在地——基站——有能力把一个用户的所有会话加总控制。
一道天花板要生效，参数得先“上路”。以用户开通了 300 Mbps 套餐为例，看看 Session-AMBR 和 UE-AMBR 分别怎么到位：
sequenceDiagram
participant UE
participant AMF
participant SMF
participant UPF
participant gNB
UE->>AMF: 请求建立PDU会话
AMF->>SMF: 创建会话上下文
SMF->>UPF: 安装Session-AMBR限速规则
SMF->>AMF: N2会话信息含UE-AMBR
AMF->>gNB: QoS配置含UE-AMBR
SMF-->>AMF: 会话接受含Session-AMBR
AMF-->>UE: 接受消息含Session-AMBR
Note over SMF,UPF: 下行总闸在锚点落地
Note over UE,AMF: UE据此自我限制上行
参数源头在签约数据：用户开户时，UDM 里就记录了签约的会话级和用户级上限。但签约值不一定是最终执行值——PCF 可以根据套餐策略、动态加速请求对它做调整（比如用户临时购买了提速包）。SMF 拿到最终决策后分三路下发：
一个有意思的细节：为什么 Session-AMBR 要告诉手机，而 UE-AMBR 不告诉？因为 Session-AMBR 是 UE 自己上行限速的依据——手机知道了配额，就可以在协议栈里主动约束，省得基站在空口上丢包纠偏，浪费本就稀缺的无线资源。而 UE-AMBR 是服务网络根据在线会话动态算出来的值，会随着会话的建立和释放实时变化，手机知道了也没有执行义务，它的执法域在基站。
有了上面的原理，回看开头那张工单，排查路径就非常清晰了。
第一步，看测速曲线形状，一图定性。这是最快的一招：如果速率曲线呈锯齿状——爬升、跌落、再爬升——大概率是 AMBR 执法在起作用。机理是：令牌耗尽后超额包被丢弃，TCP 拥塞窗口乘性减小，发送速率骤降；随后窗口重新爬升，再次撞上令牌墙，周而复始，形成锯齿。如果曲线低而平滑，则更可能是无线环境问题——信号差时调度器持续给低码率，但不会周期性崩溃。一个锯齿，一个平线，两种病因肉眼可辨。
flowchart TD
A["投诉：网速被封顶"] --> B{"测速曲线<br/>什么形状"}
B -->|"低而平滑"| C["怀疑无线环境<br/>查RSRP与SINR"]
B -->|"锯齿状"| D["怀疑AMBR限速"]
D --> E{"限速值<br/>与套餐一致吗"}
E -->|"不一致"| F["查签约数据<br/>与PCF策略"]
E -->|"一致"| G["查多会话分摊<br/>UE-AMBR的情况"]
第二步，核对限速值与套餐是否吻合。如果测速稳定卡在某个值，而这个值恰好等于套餐带宽（或接近其 90% 以上），基本可以锁定签约天花板。进一步核对 UDM 中的签约数据和 PCF 实际下发的策略是否一致——现网不止一次出现过“套餐升级了、签约数据没同步”的乌龙。
第三步，警惕“多会话分蛋糕”。5G 用户很容易同时存在多条 PDU 会话（多切片场景）。此时每条会话受自己的 Session-AMBR 约束，总量还受 UE-AMBR 约束。如果用户在测试切片速率时，另一条会话恰好在后台跑流量，测试会话拿到的份额就会明显缩水——这不是故障，是设计如此。
第四步，注意生效时机。Session-AMBR 随会话建立/修改下发。用户换了套餐，但旧会话还在用旧天花板跑着；这时开关一次飞行模式，让 PDU 会话重建，新限额立刻到位。这也是一线支持最常用的“万能重启”背后的真实原理——不是玄学，是会话级参数的刷新机制。
最后是几个高频误解，都值得写进团队 Wiki：
Q: AMBR 和 GBR 流的 MBR 有什么区别？ A: 层级完全不同。MBR 是单条 GBR 流自己的天花板，管的是“这条被保证的流最多能跑多快”；AMBR 是一把总闸，管的是一条会话或一个用户所有 Non-GBR 流的加总速率，GBR 流不在它的管辖范围内。
Q: 超过 AMBR 的数据包一定会被丢弃吗？ A: 常见实现是执法式——超标即丢或打降级标记，TCP 因此呈现锯齿；也有实现采用整形，先缓存再匀速放行。具体行为取决于网络配置与实现选择，但“长期平均不超过限速值”这一点是确定的。
Q: 改了套餐，为什么测速还是老速度？ A: 天花板参数绑定在会话上。旧 PDU 会话建立时拿到的是旧 Session-AMBR，套餐变更后需要会话修改或重建才能拿到新值。最快验证方法：开关飞行模式强制会话重建。
Q: 一个用户同时用两个切片，限速怎么算？ A: 每条 PDU 会话各自受自己的 Session-AMBR 约束，所有会话加总再受 UE-AMBR 约束。所以两条切片会话同时跑满时，各自分到的份额是用户总天花板的二分之一左右，而不是各跑各的满速。
Q: UE-AMBR 为什么不像 Session-AMBR 那样下发给手机？ A: 因为两者的执法域不同。Session-AMBR 需要 UE 在上行方向自我限制，所以必须告知；UE-AMBR 由基站执行，且是随会话增减动态计算的值，手机知道了也无法参与执行，也就没有必要下发。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。