Towards Wifi Mobility without Fast Handover

TL; DR

传统 WiFi 移动性的目标是 fast handover，作者认为这个目标本身就错了。他们的认为真正好的方案是: 客户端同时关联视野内所有 AP，每个 AP 拿一个 IP，每个 IP 上建一条 MPTCP 子流，由 MPTCP 在传输层做负载均衡

这样 L2 的切换问题被挪到 L4 解决，与具体接入技术无关，也不需要改 AP 或基础设施，只改客户端

(1) 为什么 fast handover 是错误目标:

1. 切换必须先失去连接才能触发，即 break-before-make
2. 没有标准方法判断该选哪个 AP
3. 一旦选定就锁死，无法随信号或负载变化动态调整

更根本的一点是，"最好的 AP"即使在客户端静止时也在变。原因有三:

1. 客户端移动
2. 其他用户抢占信道
3. 信道短时衰落。

单 AP 方案为了避免在 AP 之间来回翻转("乒乓切换")，只能保守地 stick to 当前选择

(2) 理想的流量分配:

由于只有一块无线网卡，同一时刻只能从一个 AP 收包。最优策略是: 大部分数据走最好的 AP，其余 AP 只承载少量"探测"流量，以便条件变化时快速迁移

(3) 实现方式:

客户端锁定一个信道并持续监听 beacon，发现新 AP 就创建一个 Linux 虚拟无线接口

每个虚拟接口有独立的 IP 和关联状态，但共享 PHY（信道、载波侦听），然后在该接口上新开一条 MPTCP 子流

问题分为两类

1. 同信道多 AP（第 4、5 节，论文重点）
2. 不同信道多 AP（第 7 节，靠信道切换）

Introduction

1. 背景：WiFi 正在成为移动设备的首选接入方式

移动流量增长给蜂窝网络带来很大压力，把流量卸载（offload）到 WiFi 一直被视为解决方案。

在密集城区，WiFi 由众多主体各自部署，几乎随处可用，而且带宽更高、能耗更低。在这种环境下，甚至不需要在 WiFi 和蜂窝之间来回切换。

2. 问题：现实中的 AP 部署是碎片化、无协调的

已有很多改善移动体验的方案依赖 AP 之间的协调 [1, 2]。但真实部署分属多个运营商，比如布加勒斯特市中心步行区同时有三家热点运营商。

作者把问题限定为：在混合、无协调的 AP 部署中漫游，且不改动现有基础设施

• 前提假设：客户端能接入多个运营商的 AP，或者能接入家庭用户共享的 AP
• 现实依据：调查显示，城市中最常用的信道上往往能看到几十个网络

3. 批判：fast handover 是错误的目标

传统 WiFi（以及所有 L2）移动性都建立在 fast handover 之上：离开一个 AP 的覆盖后，尽快找到并关联下一个

相关的优化研究很多（提前扫描、复用 IP 避免 DHCP、AP 间同步、加装额外网卡等）。作者认为这条路本身有三个根本问题：

• 必须先失去当前连接才能触发切换，即 break-before-make
• 没有标准方法决定在众多 AP 中选哪个性能最好
• 一旦选定，就无法随信号强度或负载变化动态调整

4. 核心假设：借助 MPTCP，客户端应持续同时连接附近的多个 AP

新兴的 MPTCP 标准让同时使用多个 AP 变得自然，无论这些 AP 在同一信道还是不同信道。

长期困扰 L2 的切换问题因此被移到 L4 处理，成为一个干净、与接入技术无关的端到端方案。

5. 正面发现：开箱即用的效果出人意料地好

在 802.11a/b/g 下的大多数场景中，连接所有可见 AP 的客户端能拿到接近最大可达吞吐!!!

原因在于 WiFi MAC 的行为及其与 MPTCP 的良性交互。

特别地，隐藏终端问题得到了"建设性"的解决：同一连接的各子流轮流使用信道，而不是互相破坏性地竞争。

6. 负面发现：某些情况下性能会变差

对于某些标准组合（如 802.11n 与 g）和某些速率控制算法，客户端会从远处的 AP 下载过多数据，拉低总吞吐

下面我们来看如何“修复”

7. 核心设计：三项客户端侧的改进

主要是在“修复”上述负面影响

1. 一种新的客户端估计技术，能准确估计每个 AP 下行链路的效率
2. 一种有原则的客户端算法，用 ECN 标记帮助 MPTCP 拥塞控制找到最高效的 AP
3. 一种自适应信道切换机制，用来获取不同信道上 AP 的容量

TLDR

在碎片化、无协调的城市 WiFi 中，与其优化"切得更快"，不如借助 MPTCP"同时连多个 AP"

这种做法在多数情况下天然就好，少数不好的情况则用客户端测量、ECN 标记和信道切换来修正

Background and Related Work

1. Fast Handover：L2 切换优化

重点: "缩短扫描时间"

• 802.11 最初就是为无协调部署设计的，本身不适合高速切换
  • 一次切换分三个阶段：扫描（scanning）→ 认证（authentication）→ 关联（association）
  • 实测表明扫描占切换时间的 95% [7]，因此大部分优化都针对扫描阶段
• 主要思路是在失去当前连接之前就提前探测周围的 AP：
  • SyncScan [8]：周期性 切到其他信道扫描，使客户端始终掌握所有信道上的 AP 信息
  • DeuceScan [9]：利用时空图预测下一个 AP
  • Mishra 等 [10]：用邻居图记录客户端周围的拓扑，并借助 IAPP 加速 AP 之间的上下文传递
  • [6]：加装第二块网卡，专门负责持续探测

2. 企业网中的切换优化

依赖 AP 之间的协调

• 无线控制器（wireless controller）：
  • 掌握全网 AP 和客户端的全局视图，可以控制关联、引导切换。各大厂商都支持这种架构
• 单信道架构 / 虚拟小区：
  • 多个协调的 AP 共享同一个 MAC，对客户端"伪装"成一个 AP，由控制器决定通过哪个 AP 收发流量
  • 这样客户端根本不进入切换流程（Meru、Extricom、Ubiquiti 在用）
• 802.11r [12]：优化切换的后两个阶段
  • 认证和密钥在漫游发生前就提前建好，进入一个 mobility domain 时只认证一次 (很像 SATITCH 啊)
  • 之后在域内漫游使用派生的密钥材料
  • 这样既缩短了漫游时间，也减轻了后端认证服务器的负担
• 802.11k [13]：由 AP 协助漫游
  • AP 察觉客户端正在远离时，会发送通知，并可能附带周边其他 AP 的站点报告（site report）
• [14] 是一篇切换方案综述，按开销、需改动哪一端、标准兼容性、复杂度等维度分类

3. 作者对上述 L2 方案的总体批判

• 这些方案的可用性依赖 AP 和客户端的普遍支持
• 切换本质上是一个决定，会把客户端锁定在某一个 AP 上一段时间；而客户端无法得到网络侧信息，以预测近期能从哪个 AP 得到多少吞吐
  • 所以真正移动时，通常性能比较差
• 采用传输层移动性方案（同类思路见 [15, 16]）有两个好处
  • 不需要升级所有 AP 和客户端硬件
  • 更重要的是，MPTCP 能同时利用多个 AP

4. 信道切换（Channel Switch）

• 做法：
  • 让客户端在不同频率的 AP 之间轮转 (round robin)
  • 保持与每个 AP 的关联，并在每个 AP 的子网里各有一个 IP
• 这些方案都依赖客户端的省电模式（power save mode）
  • 客户端离开某个信道时，对该 AP 声称自己在"睡眠"，让它代为缓存数据包
  • 而实际上客户端正在别的信道与其他 AP 通信
• Spider [21] 研究了在同信道和不同信道上的多重关联，结论是：高速移动时，固定在一个信道上效果更好

5. AP 选择（AP Selection）

问题是根据信号强度、可用无线带宽、端到端带宽、RTT [22]、当前负载等指标选择合适的 AP

代表性工作包括：

• [23]：利用 beacon 帧的时间信息估计客户端能获得的无线带宽
• [24]：从博弈论角度说明 WLAN 多归属（multi-homing）在定价、效率、公平性上都更优
• [25]：用博弈论方法，基于时延探测研究 AP 关联策略
• [26]：AP 之间协作共享部分带宽，实现集中式负载均衡
• Divert [1]：利用物理路径多样性，分别为上行和下行选择最佳 AP
• MRD [27]：同样利用路径多样性，但只针对上行

6. MPTCP 与本文定位

• MPTCP 是新近标准化的 TCP 扩展 [28]
  • Apple 已在 iOS 7 中实现，其他手机厂商预计会跟进
• "同时关联多个 AP 以提升鲁棒性和吞吐"这个想法并不新
  • [21, 29, 18]
  • 缺失的是：未修改的应用无法从多 AP 中获益，因为 TCP 默认只用一个接口。MPTCP 正好补上了这一环
• 本文贡献的定位是研究并优化 WiFi MAC 与 MPTCP 之间的交互：
  • 以往工作主要关注信道切换，本文重点研究客户端关联到同一信道上多个 AP 的情况
  • 本文抛弃"一次只用一个 AP"的思路，让多个 AP 在包级别竞争信道
  • 这种竞争带来几项好处：
    • 优雅地解决 "隐藏终端" 问题
    • 对信道条件变化反应快
    • 即使客户端静止也能提升吞吐

一句话总结

已有工作:

• 要么想办法让 L2 切换更快（扫描优化、802.11r/k、控制器）
• 要么在多个 AP 之间做时分轮转（信道切换）
• 要么研究怎样选出单个最佳 AP

本文的区别在于用 MPTCP 让多个同信道 AP 同时+包级别 为客户端服务，研究重点是 MAC 与 MPTCP 之间的交互

Towards an optimal solution for WiFi Mobility

1. 出发点：客户端应该选哪个 AP？

• 如 Fig.1 左侧所示，客户端周围有三个可关联的 AP（AP₁、AP₂、AP₃），该连哪一个？
• ==已有工作表明信号强度不能很好地预测未来性能
  • 因此客户端可以先对三个 AP 做短暂的主动探测或被动测量 [23]，再从中选一个

2. 为什么"选一个"注定不行：最佳 AP 一直在变

即使初始选择是最优的，也会很快变得次优，而且原因都不在客户端的控制之内：

• 客户端自己在移动
• 其他客户端在使用信道，影响本客户端的吞吐，进而影响它的选择
• 到所选 AP 的无线信道存在短时波动，容量随之变化
  • 作者指出第 6 节有一个例子，对应的应是 6.4 节静止客户端实验，见 Fig.9 的长尾

这些因素叠加起来在实践中无法预测。因此最佳 AP 不仅在移动时会变，客户端静止时也会变。所有单 AP 方案都只能保守行事：频繁在 AP 之间翻转（flopping）会损害性能，所以它们倾向于在选定的 AP 上停留一段时间。

3. 方案：任何时刻都连接所有 AP

• MPTCP 的出现使一种根本不同的思路成为可能: 不再一次只用一个 AP、靠切换换 AP，而是移动客户端在任何时刻都连接所有 AP
• 如 Fig.1 所示，客户端同时关联 AP₁/AP₂/AP₃，从每个 AP 获得一个 IP（IP₁/IP₂/IP₃）
  • 每个 AP 上建立一条 MPTCP 子流（Subflow 1/2/3）
  • 三条子流汇聚到支持 MPTCP 的服务器或代理，由 MPTCP 在各 AP 之间分配数据
• 客户端移动时，遇到新的 AP 就新增子流；与远处 AP 的关联断开后，旧子流自然失效。整个过程中没有显式的切换。

4. 流量应如何在各 AP 之间分配？

• 客户端只有一块无线网卡: 同一时刻只能从一个 AP 收包，即使它同时关联着多个 AP
• 平均分配接收时间的策略只有在各 AP 吞吐相同时才最优。实际中总有一个 AP 性能最好，因此理想策略是：
  • 大部分数据走最好的 AP
  • 其他可用 AP 只承载少量探测流量，以便条件变化时客户端能察觉并快速迁移
• 原理很简单，但关键在于理解 MPTCP 与 WiFi MAC 之间的交互

5. 需要覆盖的两种情形之一：AP 在同一无线信道

• 信道资源有限。2.4GHz 只有 3 个不重叠信道，5GHz 更多。但 802.11n/ac 会把 2–8 个 20MHz 信道绑定（bonding）起来提升容量，结果是可用的不重叠绑定信道更少（802.11ac 最多 3 个，视国家而定）。所以多个 AP 落在同一信道上是常态
• 如果忽略 AP 之间的 WiFi 干扰，理论最优方案就是连接所有可见 AP，让 MPTCP 在传输层做负载均衡。信号差的 AP 带宽更低而 RTT 相近，因此丢包率更高，MPTCP 拥塞控制会自动把大部分流量迁移到连接更好的 AP。这样切换时延被消除，客户端获得持续连接
• 但干扰可能是大问题，第 4 节深入分析

6. 需要覆盖的两种情形之二：AP 在不同无线信道

• 客户端必须在保持多个关联的同时动态切换信道，让每个 AP 以为客户端在"睡眠"，而实际上客户端去了别的信道
• 信道切换已被 FatVAP [18]、Juggler [20] 等工作用来聚合多个 AP 的回程容量。MPTCP 与信道切换的交互在第 7 节讨论

Note

最佳 AP 不可预测且持续变化，所以与其"选一个、再切换"，不如同时连接所有 AP，每个 AP 上开一条 MPTCP 子流，让拥塞控制把流量引向最好的 AP，其余 AP 作为探测路径

方案能否奏效，取决于同信道下 MAC 与 MPTCP 的交互（第 4、5 节）和异信道下的信道切换（第 7 节）

Single-channel mobility

1. 设置：客户端锁定在单一信道上，每发现一个 AP 就创建一个虚拟接口（独立 IP 和关联状态，共享信道和 CS），并开一条 MPTCP 子流

2. 隐藏终端（两 AP 互相听不到）：天然接近最优

• 靠近任一 AP: 物理层捕获效应起作用，远 AP 的子流自动降到接近 0
• 在中间区域: 两路 UDP 因碰撞吞吐暴跌，MPTCP 总吞吐却很好
• 原因是 MAC 重传与 MPTCP 交互后，一条子流独占信道，另一条丢包约 40%，被饿死在慢启动里。作者称之为"MPTCP 层面的捕获效应"。

3. 载波侦听（两 AP 互相听得到）：取决于 AP 的速率控制

载波侦听: Carrier Sense

• 客户端在中间时
  • 多 AP 比单 AP 多 10–20%
  • 原因是两条信道的短时衰落相互独立（Fig.3b）
  • 一个 AP 瞬时变差就会退避让出信道，另一个补上，所以包到达间隔的尾部更短（Fig.3c）
• 一个 AP 占优、速率控制为 minstrel（11a/g）时:
  • 远 AP 坚持高速率、频繁重传和退避，近 AP 赢得更多竞争，结果接近最优（Fig.3a 两端）
• 一个 AP 占优、速率控制为 minstrel_ht（11n）时
  • Block ACK 使丢包反馈稀少，远 AP 改用保守的低速率，两个 AP 的胜率相近（包级公平）
  • 但远 AP 的低速率帧占用大量空口时间，吞吐只剩约一半

4. 结论：

• 隐藏终端下无需干预
• CS 下，凡是在多个发送方之间实现包级公平的速率控制都会拖垮吞吐
  • 而速率控制运行在 AP 上，客户端改不了
  • 这引出第 5 节的 ECN 方案

第 5 节只有 Fig.4（两个场景的示意图），另外有式 (1)–(5)。

Making MPTCP and the WiFi MAC Play Nicely Together

1. 问题根源：MPTCP 在共享空口下会误判

• 各子流的丢包率不反映对应 AP 的空口效率
  • AP 之间包级公平时，所有子流丢包率相同，MPTCP 无法判断该把流量放在哪条子流上
• MPTCP 假设走某条子流不会影响其他子流的瓶颈
  • 但在同信道 WiFi 中，空口是共享瓶颈，经由远 AP 发送会直接降低总吞吐

2. 为什么不用 on-off（同一时刻只用一个 AP，周期性轮换）

• 最简单的办法是干脆不用"拖后腿"的 AP，但这样移动时性能变差
• on-off 看似合理：同信道切换 AP 只需几条控制消息，不浪费空口。但它有三个缺点：
  • 时延和抖动增大，例如 200ms 周期会让很多包的 RTT 多出 200ms
  • 丢掉 信道独立性 带来的增益
  • 多个客户端独立切换时可能同时挤到同一个 AP，仿真显示约 35% 的容量被浪费
• 设计思路：
  • 客户端(UE) 能准确看到本地 PHY/MAC 状况，但看不到端到端的丢包和 RTT
  • 发送端(AP) 则只有被 WiFi 行为干扰过的指标
  • 因此让多个 AP 继续同时发送, 由客户端(UE) 测量 AP 效率，再用 ECN 标记告诉 发送端(AP) 避开差的 AP
  • 之所以用 ECN 而不是客户端主动丢包，是因为主动丢包不是 work-conserving 的

5.1 和 5.2 是算法，懒得看，跳过

一句话总结：

MPTCP 在共享空口下分不清 AP 的好坏!

作者不采用 on-off，而是让客户端用 retry bit 估计各 AP 的单包投递时间 T_i，再对低效 AP 的子流打上精确计算过的 ECN 标记（式 5）

这个标记率足以在场景 1 中把流量推向高效 AP，又不至于在场景 2 中把 AP₁ 应有的吞吐估计压低（Fig.4）

Conclusion & Future work

1. 背景

城市中 WiFi 由多个运营商无协调地密集部署，几乎随处可用。传统 WiFi 移动性依赖 L2 fast handover，即一次只连一个 AP，信号变差时尽快切到下一个。

2. 问题与动机

单 AP 加切换的模式有三个根本缺陷：切换是 break-before-make 的；没有标准方法选出最佳 AP；选定后无法随环境调整。

而最佳 AP 在秒级时间尺度上不断变化（移动、其他用户竞争、信道衰落都会导致），连静止的客户端也一样。

因此单 AP 方案只能保守地停留在一个 AP 上，无法提供真正无缝、高吞吐的移动体验。

3. 方法论

• Key Insight：借助 MPTCP，把 L2 切换问题交给 L4 解决
  • 客户端同时连接所有可见 AP，每个 AP 上开一条子流，由拥塞控制自动把流量引向最好的 AP
  • 在多数同信道场景下，WiFi MAC 与 MPTCP 的交互本身就能完成这种负载均衡
• Design：
  • 在 MAC 交互失效的场景（CS 范围内、速率控制导致包级公平），客户端利用 MAC 头的 retry bit 被动估计各 AP 的单包投递时间 T_i，再以精确推导的安全比例对低效 AP 的子流打 ECN 标记，引导发送端避开这些 AP
  • 对于不同信道上的 AP，则用按带宽自适应分配时隙的信道切换来覆盖