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 改包
- 仿真结果与真实结果做了对比，以验证保真度

Background¶

§2.1 5G mmWave

mmWave 的定位
- 5G 高吞吐主要靠引入 FR2 频段，也就是 mmWave（24.25–71 GHz），可提供多 Gbps 带宽，最高 20 Gbps
- LTE 和 5G FR1 都在 sub-6GHz 频段
- 为支撑 mmWave，5G 引入了 massive MIMO、先进信道编码、可伸缩调制等技术
部署现状
- 终端侧：Samsung、Apple 等已出货大量支持 mmWave 的手机
- 网络侧：Verizon、AT&T、T-Mobile、中国电信等在部署，美国已有 100 多个城市支持
与后文相关的关键点：覆盖小 → 基站密集 → 切换频繁
- mmWave 小区传播损耗大、易被遮挡，单个小区覆盖范围有限
- 运营商因此必须密集部署小区，主要集中在商场、机场、体育场等人口密集的城市区域
- 脚注 1：本文中"小区"（逻辑上提供无线接入的单元）和"基站"（物理设备，可管理多个小区）混用，不作区分

§2.2 5G 切换入门

(1) 切换的定义

如 Fig. 1a 所示，UE 即将移出源小区覆盖范围时，与源小区断开，转而关联到目标小区
对 mmWave 来说，这是常态，不是例外

(2) 切换的 9 个步骤

如 Fig. 1b 所示

alt text

步骤	内容	与后文的关联
① Configuration	源小区配置 UE：测哪些小区、满足什么条件时上报	规定了会触发哪些测量事件（Table 1）
② Measurement Report	UE 周期性测量，满足条件时上报事件（如服务小区信号低于门限）	M2HO 预测切换的依据（§4.2）
③ Coordination	源小区决定是否切换，并与目标小区协商	—
④ Handover Config	源小区向 UE 下发切换命令（HO command）	UE 在此释放链路层上下文 → 源小区侧乱序（Finding 2）
⑤ Handover ACK	UE 确认命令，准备切换	④到执行只有约 32.7 ms，太短，所以需要提前预测
⑥ Status transfer	源小区把 UE 状态和缓存数据转发给目标小区，目标小区缓存（Buffering）	数据在目标小区堆积 → buffer 溢出（Finding 3）
⑦ Handover Execution	UE 切到目标小区。这是硬切换，期间没有数据传输	中断时间约 27 ms，不是瓶颈（Finding 1）
⑧ Random Access Completed	UE 完成随机接入，与目标小区建立新的数据通路	M2HO 以此判断切换完成，进入 Smoothing 状态（§4.4）
⑨ Data Received	数据传输恢复	—

(3) 切换分类

异构切换：异构小区之间，即 mmWave ↔ sub-6GHz
同构切换：同构小区之间，即 mmWave → mmWave，或 sub-6 → sub-6

这一分类贯穿全文：Finding 4 和 M2HO 的 rwnd 控制主要针对垂直切换

(4) 载波聚合 (Carrier Aggregation, CA)

CA 允许 UE 同时连接多个小区，以提高吞吐
切换时 UE 可能同时释放和添加多个小区，但基本流程仍然符合 Fig. 1b

§2.3 TCP 与拥塞控制

发送窗口由两个量共同决定
- cwnd：发送端的拥塞窗口，防止网络拥塞
- rwnd：接收端通告的可用缓冲空间，防止接收端被淹没
- 实际可发送量：W_send = min(cwnd, rwnd)
- 这是 M2HO 的关键依据：终端只要改小 rwnd，就能在不改服务器的前提下限制发送速率（§4.3、§4.5）
  - 反过来，rwnd 只能压低速率，不能抬高
拥塞控制的三类方法
- 基于丢包：NewReno、BIC、CUBIC，以是否丢包作为拥塞信号
- 基于时延：Vegas、Verus、Copa，用包时延推算合适的窗口
- 基于模型：BBR、Westwood，直接估计瓶颈带宽
为什么聚焦 CUBIC
- CUBIC 是 Linux（自 2.6.19 起）和 Windows Server 2019 的默认拥塞控制算法，在 Alexa Top 20,000 网站中占比最高
- 基于 CUBIC 的结论可以推广到其他基于丢包的变体
- BBR 等暂不研究，留作未来工作
CUBIC 的机制（Eqn. 1），这是理解 Finding 4 的关键
- 收到 ACK 时增大 cwnd。遇到丢包（≥3 个 dupACK 或超时）时，把当前 cwnd 记为 W_max（对路径容量的估计），并把 cwnd 降为 β·W_max
- 之后 cwnd 按三次函数增长：W(t) = C·(t − K)³ + W_max，其中 K = ∛(W_max(1 − β)/C)
- 曲线形状是：先较快增长，在 W_max 附近进入平台期、增长缓慢，越过 W_max 之后再加速探测
- 与后文的关联：
  - 切到 mmWave 后带宽大增，但 W_max 仍是切换前 sub-6 时的旧值。CUBIC 在旧的 W_max 附近慢慢爬升，就形成了 Fig. 5 中约 12 s 的平台期（Finding 4）
- 源小区侧的伪 dupACK 和目标小区的 buffer 溢出，都会触发 cwnd 被砍到 β·W_max（Finding 2、3）

Handover Implications on TCP¶

§3 分四小节:

3.1 测量方法 → 3.2 现象（TCP 表现差，而且与切换相关）→ 3.3 根因（4 个 Finding）→ 3.4 设计启示

Warning

写作思路跟笔者的 Starpike 完全一致

§3.1 测量方法

忽略

§3.2 TCP 在切换下的表现

忽略

§3.3 CUBIC 在切换下的四个缺陷（根因分析）

Root Cause Analysis

(1) Finding 1：切换中断时间不是问题

3GPP Rel-16 虽然提出了软切换，但实测中只见到硬切换（执行期间不传数据，对应 Fig. 1b 的第 ⑦ 步）
最直观的猜测是"中断导致 TCP 超时（RTO）"，但数据不支持：
- 中断时间平均只有 27.0 ms，加上 RTT 69.7 ms，仍小于 Linux 的最小 RTO（200 ms）
- 722 次切换中只有 11 次（1.5%）发生超时，而且全部是随机接入失败导致的

(2) Finding 2：源小区侧丢包 → 伪 dupACK

这一点上一轮已经详细讲过，这里只列要点：
- 现象：切换后 UE 收到乱序包，TCP 发出 dupACK，服务器判定为拥塞
- 比例：18.4% 的切换出现，cwnd 平均下降 63.3%
- 机理：UE 收到 HO command 后释放与源小区的链路层上下文，把缓冲区里乱序的数据强制交给上层，TCP 于是看到序号空洞
证据：
- XCAL 中能看到被标记为"因上下文释放而递交给上层"的包；切换后链路层序号重新编号，说明建立了新的上下文
- 如 Fig. 3 所示
  - 服务器发送包长递增的 UDP 包，用包长把 XCAL 记录和 tcpdump 记录对齐
  - 254–272 字节的包因上下文释放被提前递交，而 250–253 字节的包缺失，两边的空洞位置一致

(3) Finding 3：目标小区 buffer 溢出

现象：切换刚执行完，就在目标小区侧出现丢包
- 占全部切换的 17.7%；源小区为 mmWave 时高达 68.7%
- 每次丢 1–995 个包，cwnd 平均下降 70.4%
如 Fig. 4 所示：
- 切换后链路层序号是连续的（链路层没有丢包），但传输层发现 UDP 120–161 号包丢失
- 说明这些包在目标小区开始服务 UE 之前就已经被丢弃了
推断的机理：
- 中断期间，源小区转发来的数据和发送端新发的数据都堆积在目标小区的 buffer 中。发送端不知道正在切换，会一直发满窗口，最终导致溢出
这是间接验证，有两条证据：
- 丢失的都是切换开始之后新发的数据，即队尾丢弃，符合溢出的特征
- 源小区为 mmWave 时，发送端的 cwnd 更大，堆积的数据更多，所以丢包更常见
需要注意：这一结论是推断出来的，设备侧日志无法直接观测到基站 buffer 的丢包

(4) Finding 4：切换后窗口增长太慢

所有类型的切换，cwnd 平均需要 6.7 s 才收敛（脚注 2：收敛定义为达到 UDP 吞吐的 75%）
sub6→mmW 的垂直切换最严重，平均需要 17.2 s；而 UE 在一个小区的驻留时间常常不足 20 s，所以吞吐几乎来不及收敛
如 Fig. 5 所示（30 s 内发生 3 次切换）
- 11.5 s：sub-6 水平切换，出现连续丢包，cwnd 下降
- 19 s：垂直切换到 mmWave，吞吐升到 384.4 Mbps
- 27 s：mmW→mmW 水平切换，之后 cwnd 缓慢增长，花了 24.5 s 才接近容量
- 图中还能看到在 W_max 附近约 12 s 的缓慢探测平台期
根因：
- 按照 Eqn. 1，CUBIC 在 W_max 附近增长很慢，其前提假设是"W_max 接近真实容量"
- 但 W_max 只在丢包时更新，切到 mmWave 后仍然停留在切换前的旧值，没有反映出新增的带宽

§3.4 设计启示

需要跨层方案
- 5G 链路层提供切换事件和实时容量信息，TCP 据此调整自身行为
需要按切换阶段分别处理
- 上面的问题分布在切换的不同阶段：
  - 切换前：目标小区 buffer 溢出，需要提前压低发送量
  - 切换后：伪 dupACK 和窗口增长慢
- 因此必须设计与状态相关的动作
  - 前提是能准确、及时地识别切换，才能在丢包发生之前采取措施
- 这直接引出了 §4 的状态机设计（如 Fig. 6 所示）

Mitigating Handover Effects with M2HO¶

§4.1 Overview¶

1. 定位

M2HO 是纯终端侧、符合标准的跨层方案，不修改 5G 协议栈、基站和服务器
工作方式：解析链路层信令来预测切换，再通过终端侧的包操作屏蔽切换带来的副作用
它利用链路层信息推断可用带宽，并通过 rwnd 间接调节服务器的发送速率

2. 适用范围

可用于任何基于丢包的 TCP 变体
对基于时延的变体影响较小，但减少重传对它们同样有帮助

3. 状态机与四个动作

状态	进入条件	对应动作	解决的问题
Stable	初始状态，或 Smoothing 结束	① 切换预测（§4.2）；④ rwnd 控速与带宽估计（§4.5）	① 为后续动作争取时间；④ 解决 Finding 4
Preparation	预测到即将切换	② 预防性窗口收缩（§4.3）	Finding 3：目标小区 buffer 溢出
Smoothing	切换完成（随机接入完成）	③ 乱序处理，抑制伪 dupACK（§4.4）	Finding 2：源小区侧乱序

alt text

Fig. 6 右侧：所有动作最终都通过 RWND Control（改写 rwnd）或丢弃 ACK 作用到服务器

§4.2 事件驱动的切换预测¶

1. 问题：为什么要预测，而不是等 HO command

从收到 HO command 到开始执行，平均只有 32.7 ms。这点时间不足以让服务器改变行为，因为改写后的 rwnd 至少要经过半个 RTT 才能到达服务器。

2. 思路：切换决策是事件驱动的，UE 可以推断基站的决定

UE 满足测量条件时会上报事件（对应 Fig. 1b 的第 ② 步），事件类型是 3GPP 标准化的，如 Table 1 所示
各小区的门限可以不同，但运营商的触发逻辑大体一致
因此 UE 只需检查自己上报的事件，就能在本地推断基站是否会发起切换

3. Table 1 中的测量事件

A 类事件是同一制式内部，B 类事件是跨制式（Inter-RAT，如 LTE ↔ NR）

事件	含义
A1	服务小区好于门限
A2	服务小区差于门限
A3	邻区比服务小区好出一个偏移量
A4	邻区好于门限
A5	服务小区差于门限 1，且邻区好于门限 2
B1	异制式邻区好于门限
B2	服务小区差于门限 1，且异制式邻区好于门限 2

4. Algorithm 1 的预测规则

条件	判定	背后的逻辑
A3，且服务小区与邻区类型相同	切换（水平）	同类邻区更好就切
服务小区为 sub-6，且出现 B1	切换（垂直，到 mmWave）	只要能上 mmWave 就切。文中提到 B1 对应从独立 LTE 切到 mmWave，说明这里的"sub-6"包含 LTE 锚点小区
服务小区为 sub-6，出现 A5 且邻区是 mmWave	切换（垂直，到 mmWave）	同上
服务小区为 mmWave，且出现 A2	切换（垂直，到 sub-6）	只有当 mmWave 信号变得不可接受时才回落
其他（包括 A4、B2）	不切换	实测中这些事件与切换的相关性弱

5. 误报回退机制（满足任一条件即取消已采取的动作）

预测之后又出现 A1 事件，说明服务小区信号变好，切换很可能被取消
预测之后 2·T₂ 时间内没有收到 HO command。T₂ 是 M2HO 记录的"测量事件到 HO command"的历史平均间隔

§4.3 预防性窗口收缩¶

1. 问题

需要防止切换后目标小区 buffer 溢出（Finding 3）
但 UE 看不到基站 buffer 的情况，也不能修改服务器

2. 思路：在 UE 侧改写 rwnd 来限制服务器发送

因为 W_send = min(cwnd, rwnd)（§2.3），把所有上行包的 rwnd 改写为一个较小的 rwnd_est，服务器收到后就会停止多发，在途数据量会收敛到 rwnd_est 以内
边界情况：如果改写后的 rwnd 到达服务器太晚，在途数据仍可能溢出，但结果不会比原生 CUBIC 更差：
- 改小 rwnd 不会增加在途数据，因此不会加重溢出
- 若真的发生丢包，切换后的速率由 cwnd 决定，M2HO 不再干预
- 由于预测提前量足够，§6 显示这种"太晚"的情况很少见

3. rwnd_est 应该取多大

取 0 不行（M-TCP 就是这么做的）：从测量上报到切换执行平均有 178.9 ms（最长 310.2 ms），完全停发会浪费这段带宽，还可能影响应用
理想值是 s_max，即目标小区的 buffer 上限
- 只要在途数据 ≤ s_max，就不会溢出，因为 buffer 中堆积的数据不可能超过在途数据
- 困难在于 UE 不知道 s_max

4. 实际做法：利用 burst 调度来估计 buffer 大小

如 Fig. 7 所示

alt text

调度背景：
- 5G 在时间上分成 slot，每个 slot 在频域上分成若干资源块（RB）。基站调度某个 UE 时，会在连续多个 slot 中把大部分 RB 分给它，直到清空它的队列，才去服务其他 UE
- 这段连续调度称为一个 burst
识别 burst（Fig. 7）：
- 开始：出现 RB 分配率 > 90% 的满分配 slot
- 结束：一个分配率 < 40% 的部分分配 slot，后面紧跟一个空 slot
估计方法：
- 一个 burst 清空了当时的队列，所以这个 burst 内收到的数据量 s_b 就约等于当时的队列长度，也就是 s_max 的一个下界
- 持续记录并取最大值作为 ŝ_max，满足: \(s_b ≤ rwnd_est = ŝ_max ≤ s_max\)
如何得到目标小区的 buffer 大小（burst 方法只能测当前服务小区）：
- 按 cell ID 把估计值存入本地数据库，切换时根据 HO command 中的目标 cell ID 查表
- 如果目标小区没来过，就用同类型小区中的最小值，作为保守估计
mmWave 的特殊处理：
- mmWave 使用定向波束，分给某个 UE 的资源不与其他 UE 共享，无法区分部分分配的 slot，因此 burst 方法失效。
- 观察到 mmW→mmW 切换没有溢出，而 mmW→sub6 常有溢出，据此假设 mmWave 的 buffer 不小于 sub-6。
- 实际做法：对 mmWave 统一使用 sub-6 buffer 的最小值作为安全估计

§4.4 乱序处理¶

Smoothing 状态

1. 问题

源小区侧的乱序会导致 UE 发出 dupACK，服务器随之降窗（Finding 2）
但缺失的包会由目标小区补发，所以这次降窗是不必要的

2. 做法：切换完成后，在一小段时间内丢弃所有上行 ACK

以观察到链路层的随机接入完成消息作为切换完成的标志，从此开始丢弃所有 ACK，服务器看不到 dupACK，cwnd 就不会变

3. 什么时候停止丢弃（满足任一即解除）

停得太早，dupACK 会漏出去；停得太晚，服务器长时间收不到 ACK，可能 RTO 超时
解除条件一：出现一个序号大于切换前最大 SN 的上行 ACK，说明转发到目标小区的旧数据已经全部递交
解除条件二：目标小区的第一个 burst 结束
- 依据与 §4.3 相同，目标小区会以 burst 方式迅速清空队列，其中包括源小区转发来的数据

4. 为什么不会误吞真实丢包

真实丢包主要来自 buffer 溢出，而溢出丢失的是切换后新发的数据，序号更高
一旦出现这种丢包，就会直接满足解除条件一，dupACK 正常放行，服务器照常重传

§4.5 rwnd 控速与带宽估计¶

回到 Stable 状态

1. 问题

切换到 mmWave 后，CUBIC 的 W_max 过时，窗口增长很慢（Finding 4）
但终端无法让服务器提速：rwnd 只能限制发送速率，不能提高它

2. 思路：不去提速，而是"不让窗口掉下来"

从 mmWave 切到 sub-6 后，让服务器的 cwnd 保持在 mmWave 时的量级，改用 rwnd 把实际速率压到 sub-6 的容量
- 因为没有溢出丢包，cwnd 就不会被砍
等切回 mmWave 时释放 rwnd 限制，服务器立即拥有大窗口，跳过了缓慢爬升的过程

3. 带宽估计：rwnd 必须贴合真实容量

rwnd 估小了，链路没用满；估大了，又会丢包、降窗
做法基于已有的终端侧算法 [38]：
- 用 TCP timestamp 选项测 RTT。
- 以每个 RTT 内收到的字节数 c_est 作为保守的带宽估计。
- 计算 rwnd：rwnd = λ · c_est · RTT_min / RTT（Eqn. 2）
直观理解：
- c_est 是当前的实际收包速率
- 当排队时延增大时，RTT 变大，RTT_min/RTT 这一项就变小，rwnd 随之收紧，从而避免队列堆积
- λ 控制探测的激进程度。取 λ = 2，是参考已有蜂窝网实验选的偏保守值，以免高估容量导致丢包

Improving throughput at 5G mmWave PHY. Considerable research has been conducted on fully exploiting the potential of 5G mmWave links. Many papers attempt to address the challenges arising due to the physical characteristics of mmWave, such as improving signal-to-interference-plusnoise ratio [25], mitigating mobile blockers [36], and enhancing reliability and throughput through multi-beamforming [37]. Our work studies deployed mmWave in 5G and its impact on TCP, which is complementary to these efforts.

Improving application performance in 5G. Some research efforts [49, 63] target application performance over highly dynamic 5G networks. They observe that TCP applications cannot make full use of bandwidth, and suggest specialized tuning for such applications. [33] measures handover characteristics (frequency, delay), and proposes a solution for video streaming application. On the other hand, M2HO reveals the root cause of such deficiencies by studying interactions between TCP and 5G handovers, and proposes device-centric, handover-aware solutions for CUBIC.

Reducing 5G handover disruption. To improve TCP performance during mobility, some prior efforts [30, 54] propose fine-tuning the handover control parameters to reduce handover disruption time, which may improve overall TCP performance. Our findings reveal that the packet losses caused by 5G handover have a significant and prolonged negative impact on performance beyond the disruption time.

TCP sending rate control efforts. Some works leverage PHY information to estimate the available bandwidth for TCP window control dynamically [43, 59]. These approaches however fail to resolve the adverse effects from 5G handovers, and/or pose impractical or high-overhead requirements such as knowledge of SINR to rate mapping. Other works rely on transport layer information only, to optimize TCP sending rates in dynamic cellular networks [17, 65]. However, they are handover agnostic and the link characteristic changes after handover leads to inaccurate estimation.

Window control and handover prediction. Some concepts similar to those used by M2HO have been partially explored, but are not applicable in our context. [31, 57] advertise receive window as zero during handovers to prevent packet loss and timeouts. However, unlike M2HO, they cannot predict mmWave handovers and setting the receive window to 0 wastes large mmWave bandwidth, while also disrupting applications. Several machine learning based handover prediction algorithms have been proposed [19, 33, 47, 49]; however, they either work on the network side or require modifying apps. Similar to M2HO, [55] uses a signaling-message for 4G handover prediction, but works poorly for 5G (§6.3).

类别	代表工作	核心思路 / 做法	局限 / 与 M2HO 的区别
5G mmWave 物理层吞吐提升	[25] Busari et al.（IEEE Commun. Mag. 2018） [36] Jain et al.（JSAC 2019） [37] Jain et al.，Two beams are better than one（SIGCOMM 2021）	针对 mmWave 的物理特性做优化： • [25] 提升 SINR（信干噪比） • [36] 缓解移动遮挡物的影响 • [37] 用多波束提升可靠性和吞吐	工作在物理层，不涉及 TCP。 M2HO 研究的是已部署 mmWave 对 TCP 的影响，与这类工作互补。
5G 应用层性能优化	[49] Narayanan et al.（SIGCOMM 2021） [63] Yuan et al.（SIGCOMM 2022）	观察到 TCP 应用无法用满 5G 带宽，建议针对具体应用做专门调优	只停留在现象层面，按应用分别调优。 M2HO 通过分析 TCP 与 5G 切换的交互找出根因，提出的是面向 CUBIC、与应用无关的方案。
	[33] Hassan et al.，Vivisecting mobility management in 5G（SIGCOMM 2022）	测量切换特性（频率、时延），并为视频流应用设计了解决方案	只针对特定应用（视频流）。 M2HO 是终端侧、感知切换的通用 TCP 优化。
减少 5G 切换中断时间	[30] Gannapathy et al.（IEEE Access 2023） [54] Spoorthi & Akkamahadevi（RTEICT 2019）	调整切换控制参数来缩短中断时间，从而间接改善 TCP 性能	本文 Finding 1 表明中断时间不是瓶颈。切换引起的丢包对性能的负面影响远长于中断本身，只缩短中断解决不了问题。
TCP 发送速率控制（利用物理层信息）	[43] CQIC（HotMobile 2015） [59] Xie et al.（MobiSys 2017）	利用物理层信息动态估计可用带宽，据此控制 TCP 窗口	• 无法解决 5G 切换带来的负面影响 • 需求不现实或开销大，例如需要事先知道 SINR 到速率的映射
TCP 发送速率控制（仅用传输层信息）	[17] C2TCP（JSAC 2019） [65] Verus（SIGCOMM 2015）	只依据传输层信息（如时延），在动态蜂窝网络中调整发送速率	不感知切换：切换后链路特性突变，导致带宽估计不准。（§6 中两者均作为基线；C2TCP 还需修改服务器，且依赖基站配置参数这类 oracle 信息）
切换期间的窗口控制	[31] Freeze-TCP（INFOCOM 2000） [57] Wang et al.（WCNC 2007）	切换期间向发送端通告 rwnd = 0，冻结发送，以避免丢包和超时	• 无法预测 mmWave 切换 • rwnd = 0 会浪费 mmWave 的大带宽，还会打断应用（M2HO 改为按 buffer 估计值 ŝ_max 收缩窗口，见 §4.3）
切换预测（机器学习）	[19] Alkhateeb et al.（GlobalSIP 2018） [33] Hassan et al.（SIGCOMM 2022） [47] Lumos5G（IMC 2020） [49] Narayanan et al.（SIGCOMM 2021）	用机器学习模型预测切换或遮挡	要么部署在网络侧，要么需要修改应用。 M2HO 的预测完全在终端侧完成，基于规则、轻量级（Algorithm 1）。
切换预测（基于信令）	[55] LTE-VR，Tan et al.（SIGMETRICS 2018）	与 M2HO 类似，利用信令消息预测 4G LTE 切换	用在 5G 上效果差：见 §6.3，M2HO 的 recall 比它高 23.9%。主要原因是它没有覆盖 B1 等与 mmWave 相关的事件。

Conclusion¶

本文主旨: 5G 网络 TCP CUBIC 带宽利用率不足, 根因是切换过程中链路层与 TCP 的三种不当交互, 解决方式是进行 "链路层&&传输层"的跨层优化

1. 背景

5G 引入 mmWave，可以提供 Gbps 级带宽。但 mmWave 覆盖小、容易被遮挡，只能密集部署，导致移动时切换极其频繁（驾车时平均每 9.2 s 一次）。而承载大部分互联网流量的 TCP CUBIC，是在"链路相对稳定"的假设下设计的。

2. 问题与动机

实测发现，TCP 在 mmWave 下只用满了 47.2% 的链路容量。

根因不是切换中断时间，而是切换过程中链路层与 TCP 的三种不当交互：

源小区侧乱序引发伪 dupACK
目标小区 buffer 溢出丢包
W_max 过时导致切换后窗口爬升极慢（平均 6.7 s，比小区驻留时间还长）

不解决这些问题，mmWave 的高带宽在移动场景下基本无法兑现

3. 方法论

核心洞察：
- 切换由测量事件驱动，UE 可以从自己上报的测量报告中提前推断基站的切换决策
- 同时: \(W_send = min(cwnd, rwnd)\) 意味着 UE 只要改写 rwnd 或丢弃 ACK，就能在不改服务器的前提下间接控制发送端
设计：M2HO 是一个纯终端侧的三状态机
- Stable 状态：根据测量事件预测切换；并在 sub-6 下用 rwnd 限速，使服务器的 cwnd 保持在 mmWave 量级
- Preparation 状态：利用 burst 调度估计目标小区的 buffer 大小，提前收缩 rwnd，防止溢出
- Smoothing 状态：切换完成后抑制伪 dupACK，直到转发数据递交完毕
效果：在回放 722 次切换的仿真中，吞吐比 CUBIC 提升 45.8%，收敛时间缩短 68%

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

Introduction¶

Background¶

Handover Implications on TCP¶

Mitigating Handover Effects with M2HO¶

§4.1 Overview¶

§4.2 事件驱动的切换预测¶

§4.3 预防性窗口收缩¶

§4.4 乱序处理¶

§4.5 rwnd 控速与带宽估计¶

Related Work¶

Conclusion¶