M2HO: Mitigating the Adverse Effects of 5G Handovers on TCP¶

TLDR:

作者在商用 5G mmWave 网络中测量发现，TCP CUBIC 吞吐低的主因不是切换中断时间，而是==切换过程中链路层与 TCP 的不当交互==，具体是丢包、伪 dupACK 和 cwnd 恢复慢。

为此提出 M2HO：一个纯终端侧的用户态中间层，读取 RRC/MAC 信令来预测和识别切换阶段，再通过改写上行 ACK 的 rwnd 以及丢弃 ACK 来间接控制服务器的发送行为。

Introduction¶

1. 研究背景：5G mmWave 带来高带宽的前景

mmWave 工作在 24.25–71 GHz，理论速率可达 20 Gbps。据 2022 年的测量，商用网络的聚合吞吐已超过 3 Gbps
这为 VR/AR、无人机、自动驾驶等高吞吐应用提供了可能

2. 挑战：mmWave 的物理特性导致频繁切换

mmWave 只能依靠直射波传播，极易被墙体、人体甚至手部遮挡
运营商因此必须密集部署基站，而密集部署的直接后果是移动时切换非常频繁

3. 研究问题

核心问题是："频繁切换（尤其是 mmWave 引起的切换）会不会损害 TCP 性能？"
论文聚焦于部署最广的 TCP CUBIC
已有工作发现 TCP 在 5G 中存在带宽欠利用，但 5G 链路层与 TCP 之间的交互如何导致这种欠利用，尚未被研究清楚
- 这是本文要填补的空白

4. 测量研究与主要现象

规模：2 家运营商，3 个城市 6 个地点，共采集 190 GB 的 TCP 层和 5G 链路层跨层 trace
结论：频繁切换确实造成严重的带宽欠利用。TCP 平均吞吐只有 468.4 Mbps，而 UDP 饱和测试得到的链路容量为 993.1 Mbps
每次切换后，TCP 需要约 6.7 s 的缓慢爬升才能恢复到稳定吞吐

5. 根因：链路层与 TCP 的不当交互 (三点)

问题	机理	发生比例	cwnd 平均降幅
源小区丢包	切换前的链路层上下文重建导致丢包，引发 dupACK，发送端降速	18.4% 的切换	63.3%
buffer 溢出	切换期间堆积的数据超出 buffer 容量，发生溢出丢包	17.7% 的切换	70.4%
感知不到带宽变化	TCP 不知道带宽已变，cwnd 增长缓慢	—	平均 6.7 s、最长 22.1 s 才达到最大吞吐

源小区丢包: 什么意思? 危害是?

(1) 先弄清"源小区"

切换就是 UE 从一个小区换到另一个小区：

源小区（source cell）：切换之前 UE 连着的小区
- 也就是切换前的服务小区（serving cell）
目标小区（target cell）：切换之后 UE 要连上的新小区

所以"源小区丢包"的意思是：问题发生在切换前、UE 还在和源小区通信的那一段，而不是切换到目标小区之后

(2) 背景：链路层本身有"重传 + 保序"

对做网络的人，可以这样理解：5G 空口的链路层（RLC 层）就像一跳"小 TCP"

无线信道会出错，所以链路层有自己的重传机制
某个包出错、正在等重传时，它后面先到的包不会立刻交给上层，而是放在重排序缓冲区里等待，凑齐之后才按序往上交
这些状态合起来叫链路层上下文（context）: 包括链路层序号、缓冲区里的包、重传状态等

正常情况下，TCP 看到的永远是有序的数据，完全感知不到空口丢过包

(3) 切换时出了什么问题

以一个时间线为例：

Text Only
源小区下发 1~10 号包，其中 4、5 号在空口出错，等待重传

UE 链路层：1、2、3 → 已按序交给 TCP
           6~10    → 放在重排序缓冲区里，等 4、5

此时 UE 收到 HO command（Fig.1b 第④步）
  → UE 释放与源小区的链路层上下文
  → 缓冲区里的 6~10 被"强制清空"，直接交给 TCP（即使 4、5 还没到）

因此 TCP 看到：1、2、3、6、7、8、9、10  → 序号空洞 → 连续发 dupACK
服务器：收到 ≥3 个 dupACK → 判定为拥塞丢包 → cwnd 大幅下降

所以这里的"丢包"，实质是：Handover 迫使链路层放弃保序，TCP 因此看到序号空洞，误以为发生了丢包

(4) 为什么说这个"丢包"是冤枉的

4、5 号包通常并没有真正消失!

按照 Fig. 1b 第⑥步（Status transfer），源小区会把没送达的数据转发给目标小区，切换完成后由目标小区补发

结果是：

服务器因为 dupACK 把 cwnd 砍掉了 63.3%
但 4、5 号包其实很快就会到

这正是 M2HO 在 §4.4 的做法：切换完成后的一小段时间内，丢弃这些 dupACK，不让服务器看到

6. 解决方案：M2HO

M2HO 是纯终端侧的方案:
- 它监测基带处理器上报的轻量控制面消息，用事件驱动算法预测和识别 Handover and its Stages
针对上面三个问题，分别采用三个与状态相关的动作：
- 用 buffer 估计算法，在切换前预防 buffer 溢出
- 在切换后抑制 dupACK，同时不影响可靠传输
- 操纵 rwnd, 实现快速收敛
整个方案对固件、基站、服务器和应用都透明，无需修改

7. 实现方式

在商用 Android 手机上实现为中间层：
- 读取链路层事件来驱动状态转移，并改写上行 TCP 包
由于固件 API 导出链路层消息存在延迟，而作者无法修改固件，因此另外构建了仿真器：
- 由仿真器模拟信道动态并向手机投递链路层消息，再通过用户态 API 改包
- 仿真结果与真实结果做了对比，以验证保真度

M2HO: Mitigating the Adverse Effects of 5G Handovers on TCP¶

Introduction¶

Background¶