# 满格信号，为何网速被焊死：AMBR限速原理 ## 一张工单引出的问题 先看一个现网最常见的投诉场景：用户在室外开阔地，手机显示信号满格，RSRP,-70 dBm，SINR 二十多，无线环境无可挑剔。可测速永远卡在 100 Mbps，换手机、换卡、重插SIM，结果一模一样。 这时如果继续在无线侧查覆盖、查干扰、查调度参数，方向就全错了。因为这个天花板根本不在空口物理层，而在一张签约数据里——它的名字叫 **AMBR**（Aggregate Maximum Bit Rate，聚合最大比特率）。 理解 AMBR，是每一个无线优化工程师和核心网工程师的必修课。它解释了三个高频问题：为什么信号好却跑不快、为什么换套餐测速没变化、为什么同一个用户开两个切片会互相“分蛋糕”。这篇文章就把这道天花板从设计动机、参数层级、执行机制到排查思路完整讲透。 ## 一、为什么网络需要“天花板” 要理解 AMBR，先回顾一个基本矛盾：无线频谱是所有用户共享的稀缺资源，而绝大多数业务（网页、视频、下载）都是“尽力而为”型流量——用户要多少，网络就尽力给多少。 如果不加限制，会发生什么？一个开着 20 线程下载器的用户，可以近乎无限制地吃掉小区的调度份额，把同小区其他用户的视频拖成幻灯片。调度器虽然有一整套公平性算法，但那是在“竞争者”之间分蛋糕——如果某个人报的需求本身就没有上限，公平算法也只能在他划定的巨大份额里腾挪。 所以资源管理需要两个方向的工具： - **地板（GBR，保证比特率）**：对语音、视频通话这类实时业务，网络预留一条专用车道，保证流量下限。这属于资源预留。 - **天花板（AMBR）**：对尽力而为业务，网络封一个总闸，限制流量上限。这属于资源约束。 地板和天花板是一对互补的设计。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 加总，再与签约的用户级上限取小值——相当于“各房间额度之和，不得超过整户电表容量”。这个最终值随着会话的建立与释放动态变化：用户建一条会话，基站看到的用户总天花板就上调一档；释放一条，就下调一档。 ```mermaid flowchart TD U["UE-AMBR 用户总天花板
由基站执行"] --> S1["会话1的Session-AMBR
由UPF执行"] U --> S2["会话2的Session-AMBR
由UPF执行"] S1 --> F1["QoS流a
Non-GBR"] S1 --> F2["QoS流b
Non-GBR"] S2 --> F3["QoS流c
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 握手、页面主文档、首屏图片会在几百毫秒内密集发出。如果限速器不容忍突发，每个网页的首屏都会被削平，用户感觉“网很卡”；令牌桶放过突发、只压平均值，体验和效率兼得。 ```mermaid flowchart TD G["发牌机
每秒发r个令牌"] --> B["令牌桶
容量b"] P["数据包到达
消耗对应令牌"] --> C{"桶内令牌
够吗"} B --> C C -->|"够"| E["放行"] C -->|"不够"| D["缓存等待
或直接丢弃"] ``` 和另外两种常见限速方案对比，令牌桶的定位就清晰了： | 方案 | 突发容忍 | 输出特征 | 对TCP的影响 | 典型用途 | |---|---|---|---|---| | 硬窗口计数 | 无 | 周期性卡顿 | 周期性丢包，抖动大 | 简单网关限速 | | 漏桶 | 无，恒速输出 | 完全平滑 | 增加时延 | 流量整形 | | 令牌桶 | 桶深内允许突发 | 平均受限、瞬时可超 | 平均丢包少 | AMBR执法、策略执行 | 还有一个容易混淆的概念要辨析：**执法（policing）与整形（shaping）**。执法是超标就丢（或打标记），数据不缓存；整形是超标先排队缓存，慢慢放出去。AMBR 在网络里的执行通常是执法式的——这直接决定了下一节要讲的测速曲线形状。 顺带一提执行点的选择逻辑，同样体现了“在哪管最省事”的工程直觉。Session-AMBR 的执行点在 **UPF**：因为一条会话的所有下行数据都从这个锚点经过，在源头装总闸，天然覆盖全部流量；上行方向则把限额通过 NAS 消息告诉手机，让 UE 自己约束发送节奏。UE-AMBR 的执行点在**基站**：因为空口是唯一真正物理共享的瓶颈，用户所有会话最终都挤进同一段频谱，只有调度器的所在地——基站——有能力把一个用户的所有会话加总控制。 ## 四、参数的旅途：从签约数据到你的手机 一道天花板要生效，参数得先“上路”。以用户开通了 300 Mbps 套餐为例，看看 Session-AMBR 和 UE-AMBR 分别怎么到位： ```mermaid 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 拿到最终决策后分三路下发： 1. 通过 N4 接口把 Session-AMBR 安装到 UPF，下行总闸生效； 2. 通过 N2 把 UE-AMBR（以及各 QoS 流的配置）经 AMF 转交给基站，用户总闸在空口生效； 3. 通过 NAS 消息把 Session-AMBR 带给手机，UE 获知自己在这一条会话上的配额，用于上行发送的自我约束。 一个有意思的细节：**为什么 Session-AMBR 要告诉手机，而 UE-AMBR 不告诉？**因为 Session-AMBR 是 UE 自己上行限速的依据——手机知道了配额，就可以在协议栈里主动约束，省得基站在空口上丢包纠偏，浪费本就稀缺的无线资源。而 UE-AMBR 是服务网络根据在线会话动态算出来的值，会随着会话的建立和释放实时变化，手机知道了也没有执行义务，它的执法域在基站。 ## 五、现网实战：限速工单排查法 有了上面的原理，回看开头那张工单，排查路径就非常清晰了。 **第一步，看测速曲线形状，一图定性。**这是最快的一招：如果速率曲线呈**锯齿状**——爬升、跌落、再爬升——大概率是 AMBR 执法在起作用。机理是：令牌耗尽后超额包被丢弃，TCP 拥塞窗口乘性减小，发送速率骤降；随后窗口重新爬升，再次撞上令牌墙，周而复始，形成锯齿。如果曲线**低而平滑**，则更可能是无线环境问题——信号差时调度器持续给低码率，但不会周期性崩溃。一个锯齿，一个平线，两种病因肉眼可辨。 ```mermaid flowchart TD A["投诉：网速被封顶"] --> B{"测速曲线
什么形状"} B -->|"低而平滑"| C["怀疑无线环境
查RSRP与SINR"] B -->|"锯齿状"| D["怀疑AMBR限速"] D --> E{"限速值
与套餐一致吗"} E -->|"不一致"| F["查签约数据
与PCF策略"] E -->|"一致"| G["查多会话分摊
UE-AMBR的情况"] ``` **第二步，核对限速值与套餐是否吻合。**如果测速稳定卡在某个值，而这个值恰好等于套餐带宽（或接近其 90% 以上），基本可以锁定签约天花板。进一步核对 UDM 中的签约数据和 PCF 实际下发的策略是否一致——现网不止一次出现过“套餐升级了、签约数据没同步”的乌龙。 **第三步，警惕“多会话分蛋糕”。**5G 用户很容易同时存在多条 PDU 会话（多切片场景）。此时每条会话受自己的 Session-AMBR 约束，总量还受 UE-AMBR 约束。如果用户在测试切片速率时，另一条会话恰好在后台跑流量，测试会话拿到的份额就会明显缩水——这不是故障，是设计如此。 **第四步，注意生效时机。**Session-AMBR 随会话建立/修改下发。用户换了套餐，但旧会话还在用旧天花板跑着；这时开关一次飞行模式，让 PDU 会话重建，新限额立刻到位。这也是一线支持最常用的“万能重启”背后的真实原理——不是玄学，是会话级参数的刷新机制。 最后是几个高频误解，都值得写进团队 Wiki： 1. **“AMBR 是每条流的限速”**——错。AMBR 是总闸不是分闸：会话内开 4 条并发流，是 4 条流共享一份 AMBR 配额，每条大约四分之一，而不是每条各得一份全额。 2. **“限速是调度器干的事”**——错。调度器无法突破 AMBR，它只是被上方“告知”了预算；真正的执法点在 UPF（会话级）和基站的限速执行模块（用户级）。纯调参数解决不了签约限速。 3. **“GBR 流也会被 AMBR 卡住”**——错。GBR 流有独立的 MBR 天花板，不进入 AMBR 的账本。把语音问题往数据会话限速上引，是排查走弯路的常见原因。 4. **“限速值必须严格等于套餐值”**——不一定。UE-AMBR 是各会话之和与签约上限取小后的动态结果，多会话在线时单会话实测值低于套餐上限属正常现象。另外，标准层面允许多种实现选择，具体执行细节以各厂家官方文档为准。 ## 常见问题 **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 由基站执行，且是随会话增减动态计算的值，手机知道了也无法参与执行，也就没有必要下发。 ## 参考来源 1. [Token bucket - Wikipedia](https://en.wikipedia.org/wiki/Token_bucket) — 令牌桶算法的标准定义、突发与平均速率约束的数学描述 2. [Leaky bucket - Wikipedia](https://en.wikipedia.org/wiki/Leaky_bucket) — 漏桶与令牌桶两种变体的区别，整形与执法概念 3. [5G QoS - ShareTechnote](https://www.sharetechnote.com/html/5G/5G_QoS.html) — 5G QoS 框架、QoS 流与 AMBR 参数的工程视角讲解 4. [5G QoS - EventHelix](https://www.eventhelix.com/5g/qos/) — QoS 流映射与限速执行点的消息流程图解 --- > 本文由「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 等场景全覆盖。