跳转至

PBE-CC: Congestion Control via Endpoint-Centric, Physical-Layer Bandwidth Measurements

(1) 研究背景与挑战

  • 瓶颈所在: 在当今的互联网中, 蜂窝网络 (如移动端所在的最后一跳) 往往是导致端到端网络流出现最大延迟, 抖动和吞吐量受损的环节

  • 传统算法的局限性:

    • 由于无线介质的共享特性, 用户移动性以及 5G/LTE 中使用的载波聚合 (Carrier Aggregation) 等先进技术, 蜂窝链路的可用容量会发生剧烈且突然的升降
    • 传统的 基于 ACK 的端到端 拥塞控制协议无法足够迅速和精确地感知这些变化

(2) 核心创新与解决方案 (PBE-CC)

  • 跨层设计: 论文提出了一种名为 PBE-CC 的跨层拥塞控制算法
  • 物理层测量: 其核心思想是让移动设备 (Endpoint) 直接解码蜂窝网络的物理控制信道 (Physical control channel), 从而获取极其详细的无线容量分配信息
  • 毫秒级精度: 这种方法使得移动端能够在毫秒级别精确测量和跟踪可用的蜂窝链路容量, 并将这些细粒度的测量结果反馈给发送端 (Server)
TLDR

传统的 CCAs 基于 ACK 的反馈机制, 无法及时感知蜂窝链路容量的剧烈变化!

PBE-CC 通过让 移动设备直接解码物理控制信道, 实现了对无线容量的毫秒级测量和反馈, 从而显著提升了 CC 响应速度!

(3) 关键机制

  • 瓶颈状态切换: PBE-CC 能够识别端到端连接的瓶颈位置
  • 无线瓶颈状态 (Wireless-bottleneck state): 大多数情况下, 蜂窝链路是瓶颈
    • PBE-CC 通过计算物理资源块 (PRB) 的分配和空闲情况, 得出当前连接的公平份额带宽 (Fair-share bandwidth)
    • 并指导发送端精确匹配该速率, 从而在最大化吞吐量的同时避免网络排队
  • 互联网瓶颈状态 (Internet-bottleneck state):
    • 如果互联网链路的容量小于无线链路, PBE-CC 会检测到数据包单向延迟的增加, 并切换到一种专为蜂窝网络定制的类似 BBR 的拥塞控制策略, 以探测互联网瓶颈带宽并参与公平竞争
  • 跨层速率转换:
    • 由于物理层的容量与传输层 (TCP/UDP) 的实际吞吐量存在差异, PBE-CC 还对 MAC 层重传和协议头开销进行了建模
    • 将物理层容量转换为传输层速率 (Goodput) 后再反馈给发送端

Introduction

(1) 现有网络拥塞控制面临的三大挑战

在当今的下行端到端数据流中, 蜂窝网络最后一跳 (移动端) 往往会带来最严重的延迟, 抖动, 丢包和带宽限制. 所有在无线网络中运行的拥塞控制算法都面临以下三个挑战:

  1. 无线介质的共享性:

    • 当某个用户的网络流开始或结束时, 同一基站下的其他用户会经历可用容量的骤降或骤升
    • 传统的基于 ACK 的协议 需要较长时间才能对这些变化做出反应
  2. 载波聚合 (Carrier Aggregation) 带来的容量剧变:

    • 为了提高吞吐量, LTE-A 和 5G NR 等现代蜂窝标准广泛使用了 载波聚合技术
    • 基站的动态添加或移除会导致用户可用容量发生突变, 现有的感知无线的拥塞控制系统 (如 ABC) 很难在开启载波聚合时跨基站共享状态
  3. 无线信道质量的高动态性:

    • 由于用户移动, 多径传播和干扰, 无线数据速率在毫秒级的相干时间内会发生剧烈变化
    • 尽管基站和移动端都能观察到这些波动, 但 只有移动端 掌握着与所有连接基站之间最实时的无线连接状态
载波聚合技术

可以把无线频段想象成高速公路: 在以前, 一个手机只能在一条特定的 "车道" (单个载波频段) 上接收数据.

而 "载波聚合技术" 就是把多个不同的 "车道" 捆绑在一起, 同时给同一个手机使用, 从而成倍地提升网速.

具体到蜂窝网络的实际操作机制如下:

  • 主小区 (Primary Cell) 常驻:

    • 默认情况下, 基站会通过一个主要的载波频段 (即主小区) 向移动用户传递数据.
  • 辅小区 (Secondary Cell) 按需激活:

    • 当突然有海量数据需要发送给用户时, 基站为了提供更大的容量, 会临时激活一个或多个 "辅小区".
    • 蜂窝网络会为 每个用户维护 一个可以聚合的小区列表 (CellList), 并在需要时按顺序依次激活它们
  • 动态去激活以节省资源:

    • 一旦用户不再需要这么大的额外容量 (比如数据传输需求下降), 网络就会将这些辅小区去激活, 把资源让给其他用户.

论文中的具体例子 (如 Figure 2 所示):

alt text

  1. 当服务器以 40 Mbit/s 的高负载向手机发送数据时, 这超过了 "主小区" 的最大承载能力, 数据包开始在主小区产生缓冲排队.
  2. 蜂窝网络察觉到这个高数据率用户后, 在 0.13 秒时迅速激活了 "辅小区" 来帮忙传输数据.
  3. 后来, 服务器把发送速率降到了 6 Mbit/s (这在主小区的承受范围内), 网络就随之将 "辅小区" 去激活了.

为什么这会让传统拥塞控制算法 "头疼"?

正是因为基站可以动态地添加或移除参与聚合的基站, 导致分配给用户的可用无线容量会发生 相应的突然跳变.

传统的感知无线的拥塞控制算法 (如 ABC) 通常以单个基站为中心, 当开启载波聚合时, 它们很难跨越多个蜂窝站点来共享和管理状态. 这就导致它们反应迟缓, 容易造成网络拥堵延迟或带宽浪费.

(2) 核心主张与解决方案: PBE-CC

基于上述挑战, 作者提出, 移动端是测量端到端连接拥塞状态的最佳位置. 论文提出了一种基于移动端物理层带宽测量的拥塞控制算法 - PBE-CC

  • 跨层架构: PBE-CC 包含两个模块: 一个松散地基于 TCP BBR 修改的端到端拥塞控制模块, 以及一个用于移动设备的无线物理层容量测量模块
  • 毫秒级精准控制:
    • 其核心创新在于: 能够以毫秒级的粒度精确跟踪蜂窝链路的容量变化
    • 当无线容量增加时, PBE-CC 能迅速检测到新出现的空闲容量并提高发送速率
    • 当容量下降时, 它能迅速降低发送速率以避免排队延迟

(3) PBE-CC 的运行机制

  • 无线瓶颈状态: 协议初步假设蜂窝链路是端到端路径的瓶颈

    • 它利用物理层的测量数据来控制发送端的发送节奏, 并结合共享无线链路的用户数量, 以实现容量在多用户间的公平分配
  • 互联网瓶颈状态:

    • 如果 PBE-CC 检测到数据包的单向延迟增加 (且超出了无线容量预测的范围), 它会触发类似 BBR 的机制, 依靠接收到的 ACK 速率来探测瓶颈带宽

(1) End-to-end congestion control

  • 传统算法:

    • 基于丢包 (Loss-based) 的算法虽然能实现高吞吐量, 但通常会引入过高的延迟.
    • 基于延迟 (Delay-based) 的算法容易受到 ACK 延迟, ACK 压缩或网络抖动的影响, 经常导致网络容量利用率不足.
      • 当它们与基于丢包的算法竞争时, 容量利用率表现很差.
  • 基于学习的算法:

    • 一些提案使用学习算法 (如 Copa, PCC, PCC-Vivace 等) 来优化特定目标, 但在线学习经常会收敛到导致网络严重未被充分利用的结果.
  • BBR 算法:

    • BBR 致力于同时最大化吞吐量和最小化延迟, 在作者测试的所有算法中表现最好.
    • 但由于其容量估计粒度较粗, 仍然存在网络利用率不足和引入过多延迟的问题.

(2) End-to-end congestion control for cellular networks

"黑盒" 推断:

这类方案通常将蜂窝链路视为 "黑盒", 利用吞吐量, 数据包延迟和丢包统计数据来推断链路容量.

典型代表:

例如, PROTEUS 收集当前吞吐量, 丢包和单向延迟等信息来预测网络性能.

Sprout 利用数据包到达时间来推断网络路径的不确定动态.

Verus 则尝试学习延迟配置文件以调整发送窗口.

局限性:

由于纯粹依赖端到端统计数据, 这些算法不可避免地会面临容量估计不准确的问题, 并且对网络动态变化非常敏感.

相比之下, PBE-CC 通过直接测量无线信道来实现更细粒度的容量估计, 从而提供了卓越的性能.

(3) Cellular-aware congestion control proposals

  • 基站修改方案:

    • 像 ABC 和 MTG 标准提议修改移动基站, 以向发送端明确通信最佳速率.
    • 但它们并没有阐明对高性能至关重要的容量监控器的具体设计.
  • 基于信号强度的预测:

    • piStream 和 CLAW 建立了一个从 信号强度 测量结果预测已利用资源块的模型.
    • 然而, 信号强度的预测能力非常有限.
    • 而 PBE-CC 是直接解码控制信道的元数据, 生成的是精确的带宽利用率数据, 而非粗略估算.

(4) Cellular PHY-layer monitoring tools

  • 信息获取受限:

    • QXDM 和 MobileInsight 等工具只能提取 单一移动用户 的控制消息.
    • 无法像 PBE-CC 那样提供基站整体容量占用的信息.
  • 技术兼容性不足:

    • LTEye 和 OWL 虽然能解码控制消息, 但它们不支持载波聚合以及后期高级的 MIMO 标准 (而 PBE-CC 支持).
  • 缺乏控制闭环:

    • 最关键的是, 所有这些工具都停留在监控层面, 并没有进一步进行拥塞控制算法的设计.

LTE/5G Radio Primer

(1) 基础时频资源与调度机制 (Subframes, PRB & TB)

alt text

  • LTE 主要采用频分双工 (FDD) 模式和正交频分多址 (OFDMA) 技术, 将可用的无线频率带宽划分为 180 KHz 的块, 将时间划分为 0.5 毫秒的 slots
  • Figure 1 所示, 最小的时间-频率资源块称为 物理资源块 (PRB), 它是分配给用户的最小单位
  • 每两个时隙 (0.5 ms + 0.5 ms) 组成一个 1 毫秒的 子帧 (subframe), 在这两个时隙内的 PRB 分配是相同的
  • 在一个子帧内传输的数据称为一个 传输块 (Transport Block, TB)
    • 其大小取决于分配给该用户的 PRB 数量 + 无线物理层的数据速率 (例如调制和编码方案 MCS, 空间流数量等)

控制信道解码:

基站会通过物理控制信道发送控制消息, 精确告知移动用户其带宽分配情况 (PRB 数量和位置) 及速率信息

移动用户必须先解码这个控制消息, 然后才能解码其中的传输块 (TB)

(2) 载波聚合技术 (Carrier Aggregation)

  • 默认情况下, 基站会通过一个主载波 (或称主小区, primary cell) 向移动用户传递数据
  • 当有海量数据需要传输时, 基站会按需激活一个或多个辅小区 (secondary cell) 以增加容量
    • 并在用户不利用这些额外容量时将它们停用

Figure 2 所示, 作者展示了一个具体的例子:

alt text

当服务器发送负载 (40 Mbit/s) 超过主小区最大容量并在基站造成排队时, 蜂窝网络会在 0.13 秒激活辅小区来帮助传输并迅速清空排队的数据包

当发送速率降至主小区容量以内 (6 Mbit/s) 时, 辅小区又会被关闭

(3) 蜂窝网络层的重传与重排序机制 (Retransmission and Reordering)

Figure 3 所示, 如果在传输过程中某个传输块发生错误, 蜂窝网络会在初始传输后的 8 个子帧 (即 8 毫秒) 后对该错误块进行重传

alt text

为了向传输层保证数据的按序交付, 移动端必须将 "这段时间内正确接收的乱序传输块" 全部暂存在 重排序缓冲区 (reordering buffer) 中, 直到错误的传输块被成功重传并纠正

这一底层机制会产生连锁反应: 不仅会给错误传输块内的数据包带来额外的 8 毫秒延迟, 还会给后续缓冲的传输块带来从 7 毫秒递减到 0 毫秒的延迟. 如果重传失败, 基站最多允许重复 3 次, 从而引发 8 毫秒倍数级别的网络延迟惩罚

Design

(1) 总体架构与双状态运行机制

  • PBE-CC 是一种基于速率的端到端拥塞控制算法, 主要用于穿越蜂窝网络并终止于移动设备的网络流.
  • Figure 4 所示:
    • 移动客户端通过解码蜂窝物理控制信道来估算可用的无线容量, 并将该瓶颈容量信息反馈给发送端 (Server)
    • 发送端依靠该信息或接收到的 ACK 来控制发送速率
    • alt text
  • 算法动态追踪网络所处的两种状态:
    • "无线瓶颈状态" (大多数情况, 无线蜂窝链路是瓶颈)
    • "互联网瓶颈状态" (互联网内部链路容量小于无线链路)

(2) 连接启动阶段

  • 在连接建立之初, PBE-CC 采用线性速率增加策略, 以平缓地接近瓶颈容量的公平份额
  • 移动客户端通过解码控制信道, 获知共享该小区带宽的活跃用户数量, 从而通过公式明确计算出预期的公平份额带宽
    • Figure 5 所示, 设备能够清晰追踪分配给自己, 其他用户以及处于空闲状态的 PRB
    • alt text
  • 发送端在 3 个 RTT 内将发送速率从零线性增加到该公平份额速率, 以防止突发流量, 并给基站和其他用户留出调整流量的时间

(3) 稳态: 拥塞避免

  • 无线瓶颈状态下的容量挖掘:

    • 当连接处于该状态时, 如果蜂窝小区出现空闲 PRB (例如其他用户结束传输或降速, 如 Figure 5 所示的子帧 7-12), 所有 PBE-CC 客户端能立即检测到, 并通知发送端提高速率以抢占属于自己的空闲份额
  • 跨层速率转换:

    • 物理层容量不能直接等同于传输层吞吐量 (Goodput)
    • PBE-CC 对协议头开销 (如 Figure 6(a) 所示) 和由于传输块错误 (如 Figure 6(b) 所示的理论与实际误块率) 引起的 MAC 层重传进行了数学建模, 将估算的物理层容量准确转换为传输层的实际可用速率
    • alt text
  • 过滤控制流量:

    • 算法观测到大量活跃用户实际上只存活了 1 个子帧或仅占用了 4 个 PRB (如 Figure 7(b) 所示), 这些通常是仅用于网络参数更新的流量
    • PBE-CC 会通过时长和 PRB 阈值过滤掉这些用户, 确保计算公平份额时的用户基数 (N) 准确无误 (如 Figure 7(a) 所示)
    • alt text
  • 状态切换与延迟阈值:

    • 当单向数据包延迟超过特定阈值时, 算法会判断发生了互联网拥塞并触发状态切换
    • alt text
    • 由于蜂窝网络的重传和重排序机制会在高负载下引入 8 毫秒倍数的延迟波动 (如 Figure 8 所示), PBE-CC 专门设计了一个包含传播延迟, 最大 3 次重传延迟以及 3 毫秒网络抖动在内的复合阈值公式, 以避免误判
  • 互联网瓶颈状态下的类 BBR 探测:

    • 当确认互联网为瓶颈时, PBE-CC 会切换到一种专为蜂窝网络定制的 BBR 算法
    • Figure 9 所示, 它继承了 BBR 的 8 阶段带宽探测循环, 但做出了关键修改: 将带宽探测速率的上限限制为之前算出的无线链路最大公平份额容量
    • alt text

(4) 公平性与 TCP 友好性

  • 传统算法通常依赖 "加法递增乘法递减" (AIMD) 来探测公平份额, 这会导致 RTT 较小的流占据优势
  • PBE-CC 由于显式计算公平份额, 且蜂窝基站为每个用户提供独立的缓冲区 (避免了大 RTT 连接注入过多数据包垄断缓冲区), 从而在具有不同传播延迟的连接之间实现了极佳的 RTT 公平性
Note

本文绘图特别值得学习