Mobile Data Offloading: How Much Can WiFi Deliver?¶

背景:

2009–2010 年移动网络的处境

(1) 智能手机刚刚爆发:

iPhone 3G（2008）和 3GS（2009）带来了"随时上网 + 多媒体拍摄与播放"的使用方式，App Store 让应用流量迅速上升。智能机用户占比很小，消耗的流量却不成比例。论文引用了 AT&T 2009 年底的数据：智能机用户约占 3%，流量却占约 40%。这批用户也是运营商最有增长潜力的收入来源。

(2) 3G 网络扛不住:

时主流是 UMTS/HSPA 一类的 3G，小区容量由用户共享，上行尤其弱。论文按 200 kbps 估算 3G 上行，就是当时的典型体验。AT&T 在美国独家销售 iPhone 期间，纽约、旧金山等大城市频繁出现掉线和网速极慢的问题，成为当年标志性的"运营商网络危机"。

(3) 运营商当时可选的三条路:

论文第 1 节把选项归为三类，背后的权衡如下:

扩容：建更多基站、上小基站（picocell/femtocell）、升级 LTE/WiMAX
- 问题是成本高、周期长
- 作者还指出两点：在不限量定价下扩容不产生额外收入；4G 首先部署在曼哈顿、旧金山这类本已拥塞的地区，可能反而刺激更多使用。
改定价：用按量计费压制重度使用
- 问题是: 它恰好打击智能机用户这一最有价值的群体，容易引起反弹
- 作者的判断是"定价调整难以避免，但纯按量计费会适得其反"
WiFi 卸载：WiFi AP 便宜，而且大量已经存在，包括用户家里和公司的 AP、运营商热点、Boingo 这类第三方热点
- 它解决的是 time-to-capacity 问题：不必等新网络建成，现在就能把流量分流出去

作者认为第三条在当时最可行。但它的价值取决于一个当时没人能回答的问题：WiFi 到底能分走多少？

这一点跟 DTN 的核心思想很像!!!

DTN 是什么，以及它和延迟卸载的关系

Text Only
(1) 先看传统互联网的隐含假设

TCP/IP 默认一个前提：**通信的那一刻，源和目的之间存在一条完整、持续的端到端路径**

- IP 路由查表转发，查不到路由就丢包
- TCP 靠端到端的 ACK 和重传保证可靠性，RTT 一般在毫秒到秒级。RTT 太长或路径反复中断，握手和超时重传都会失效
- ==中间路由器只做"即收即转"，缓存只是为了吸收突发，不会把包存几分钟甚至几小时==

很多真实环境不满足这个前提，路径是**间歇存在**的：

- 深空通信：地球与火星探测器之间单程延迟几分钟到二十几分钟，而且只有特定窗口可见
- ==卫星：没有星间链路的低轨卫星，只有飞过地面站上空的几分钟才能下传数据==
- 偏远地区：例如村庄之间靠一辆每天往返的车捎带 U 盘或硬盘
- 野生动物追踪：如 ZebraNet，传感器项圈只在动物彼此靠近或靠近基站时才能交换数据

(2) ==DTN 的核心思想：存储 – 携带 – 转发==

**DTN（Delay/Disruption-Tolerant Network，时延/中断容忍网络）** 就是为这类环境设计的网络体系，2000 年代由深空互联网研究衍生而来，IETF 有对应的 Bundle Protocol（RFC 5050）。核心机制是 **store–carry–forward**：

1. **Store**: ==节点收到数据后，没有下一跳可达就先存在本地，可能存很久，不丢弃==
2. **Carry**: 节点物理移动，比如人走、车开、卫星绕地，把数据"带"到别处
3. **Forward**: 一旦遇到合适的下一跳，就把数据交出去

这里的关键概念是 **contact（接触）**：两个节点能互相通信的那段时间窗口。围绕它有两个基本统计量：

| 概念 | 含义 |
|---|---|
| contact duration（接触时长） | ==一次接触持续多久==. 决定这次能传多少数据 |
| inter-contact time（接触间隔） | ==一次接触结束后，到下一次接触开始要等多久==. 决定数据要排队等多久 |

DTN 的性能（投递时延、投递率）几乎完全由这两个分布决定。所以 2005–2010 年有大量研究去测量真实人群的 inter-contact time 分布（上次提到的 Chaintreau 2006、Karagiannis 2007）。主要发现是它呈**重尾**：大部分间隔较短，但存在不可忽视的极长间隔。

DTN 还有一个概念叫 **bundle lifetime（TTL）**：数据带有"有效期"，过期没送到就放弃

(3) 对应到本文的延迟卸载

把手机看作 DTN 节点、WiFi 覆盖区看作"可以接触的对象"，两者几乎一一对应：

![alt text](./image/3g-wifi-deliver-fig-8.png)

| DTN 概念 | 本文中的对应 |
|---|---|
| 节点在本地存储数据 | 文件在手机上的 FIFO 队列里排队（Fig. 8） |
| 节点移动、携带数据 | 用户带着手机走动 |
| contact | 手机进入 WiFi 覆盖区并连上 AP |
| contact duration | **connection time**（平均 122 min） |
| inter-contact time | **inter-connection time**（平均 41 min） |
| bundle lifetime / TTL | **deadline** |

所以"数据可以等，等到下一次接触再发"，说的就是**把一次传输从"必须立刻有路径"变成"可以存在本地，等到下一次 WiFi 接触再发"**，这正是 DTN 存储 – 携带 – 转发的思路

不过它和纯 DTN 有两点不同：

1. **有兜底**：纯 DTN 中数据过期就丢了，延迟卸载中 deadline 到了就改走永远在线的 3G
    * 所以它是"间歇的便宜网络 + 常在的昂贵网络"的混合体，等待只是为了省钱和省资源，而不是因为别无选择
2. **只有一跳，不经他人转发**：DTN 中的数据常在多个节点之间接力（A 交给 B，B 带着走再交给 C）
    * 延迟卸载中手机只是自己带着数据走，碰到 AP 就直接上传到互联网。"携带"的只有用户自己

TLDR¶

基于约 100 名韩国 iPhone 用户的真实日常 WiFi 连接轨迹，作者得出三点结论。

第一，不加任何延迟的 on-the-spot 卸载已能卸掉约 65% 流量

第二，把 deadline 设为 100 秒的延迟卸载几乎没有额外收益（+2~5%）

第三，延迟卸载要获得显著收益，deadline 至少要到几十分钟到小时级。这与此前 [6]（Balasubramanian et al., MobiSys'10）的结论截然相反，原因在于两者使用的轨迹来源不同

(1) 问题与动机¶

背景：2010 年移动数据爆炸。Cisco 预测 2014 年人均 7 GB/月，其中 66% 是视频
- 扩容（建站、上 LTE）成本高，在不限量定价下也不赚钱
- 按量计费又会伤害增长最快的智能机用户
- WiFi 卸载因此成为最现实的方案
两种卸载方式：
- On-the-spot：有 WiFi 就用，离开覆盖区后剩余数据走 3G。当时的智能机默认就是这样做的
- Delayed（延迟卸载）：每个传输带一个 deadline，期间可以跨多次 WiFi 接入断点续传，超时后才走 3G。思想接近 DTN
核心问题：
- 两种方式分别能卸掉多少流量、省多少电？
- 延迟卸载的 deadline 要多长才有意义？
对已有工作的批评：[6] 用公交车和 war-driving 轨迹，[16] 用几小时的步行轨迹。这些轨迹都不能反映普通用户"大部分时间待在家和办公室"的日常模式。

(2) 解法¶

搭建环境进行实测:

alt text

Warning

本文最大收获: 反复提醒笔者注意 "DTN" (延迟容忍网络)

本文高度借鉴 DTN 核心设计理念, 此外忽然想起, MobiCom23-CoSMAC 也是直接借鉴这一思想. 可惜当年笔者太年轻, 还没想到这一层

-> Inspiration: LEO / NTN 天然适合 DTN 啊 🤔🚀