A Practical Traffic Management System for Integrated LTE-WiFi Networks¶
Introduction¶
1. 背景：运营商大规模部署 WiFi，但缺乏管理
移动数据需求的增长快于蜂窝网络扩容，所以中国移动、AT&T 等运营商大量部署 WLAN 来补充容量，因为 WiFi 便宜、易于大规模铺设。
但问题在于，仅部署"不受管理的 WLAN"无法保证 QoE。 作者认为，按流精细管理用户走 WiFi 还是 LTE，是下一代移动网络优化的关键一环。
2. 现有方案的缺陷一：策略朴素、静态、粗粒度
- 朴素：
- 终端的连接管理器默认"有 WiFi 就用 WiFi"。
- 而 AP 本就部署在热点区域，高峰期大量用户都能收到强 WiFi 信号，选接口时又不考虑 AP 负载，结果吞吐反而上不去。
- 静态：
- 运营商大多无法在不断连的情况下切换流接口，只能在建连时决定一次，无法适应无线环境的变化。
- 粗粒度：
- 同样的吞吐对不同应用意味着不同的 QoE。
- 把一个用户的所有流都压到同一接口，而该接口还要被其他用户的流共享，并不能让每条流都获益。
3. 现有方案的缺陷二：缺少可落地的系统
已有工作 [7–10] 只研究接口分配算法，默认"无缝切换框架已经存在"。但真正实现这样的框架有很多工程约束。少数系统工作 [11, 12] 虽然在 WiFi 和蜂窝之间调度数据，却只适用于时延容忍型流量，不支持视频这类实时应用。
4. 四个设计挑战
- 实用性: 系统要轻量、可扩展，作为现有 LTE 网络上的 overlay 部署，不依赖新标准
- 自适应: 随流的到达、离开和链路变化动态选择接口
- 无缝性: 接口(也就是 IP 地址) 变化时不中断已有连接
- 商业利益:
- 现有的无缝迁移方案要求把所有 WiFi 流量回传到 LTE 核心网做 IP 锚定，成本很高
- 而对 OTT 流量，运营商缺乏为其 QoE 大量投入的动力
5. 核心挑战的归纳（原文斜体强调）
目标不只是设计一个可扩展、动态、无缝的流量管理方案，还要构建一个能部署在任何运营商核心网中（operator-agnostic）、且不要求 WiFi 与 LTE 数据面紧耦合的端到端系统。
6. ATOM 的两个组件与关键洞察
- 组件一：细粒度流量管理
- 用实用的接口选择算法最大化全网效用
- 即后文的 NIA
- 组件二：切换服务
- 无需数据面集成就能无缝切换部分流的接口，从而降低回传成本
- 即后文的 ISS
- 关键洞察：
- 利用 HTTP 视频流和网页浏览特性，借助 HTTP 代理重定向这些流，避免把它们从 WiFi 回传到 LTE
- ATOM 也支持非 HTTP 流，只是这些流享受不到回传节省
- 由于移动网络中大部分流量是 HTTP 视频，这一节省很可观
Background and Motivation¶
2.1 LTE 网络架构¶
如 Fig.1 上半部分所示
- 整体组成:
- LTE 网络分为两部分，即: 演进分组核心网（EPC）和无线接入网（RAN）
- EPC 控制面:
- MME: 负责会话与用户管理，包括认证、移动性管理、空闲态终端位置管理
- MME: Mobility Management Entity
- HSS: 用户签约信息数据库
- HSS: Home Subscriber Server
- PCRF: 管理业务策略，为每条流配置 QoS 参数
- PCRF: Policy and Charging Rules Function
- MME: 负责会话与用户管理，包括认证、移动性管理、空闲态终端位置管理
- EPC 数据面:
- S-GW: 用户在基站之间移动时的本地移动性锚点
- 位于:
UE-gNB侧
- 位于:
- PDN-GW: 连接多个 S-GW，把流量路由到外部网络，同时负责策略执行、包过滤和计费
- 位于:
gNB-Core侧
- 位于:
- S-GW: 用户在基站之间移动时的本地移动性锚点
- RAN: 由 eNodeB 组成，负责无线资源管理和干扰抑制
这一节是铺垫。后文 ATOM 部署在 PDN-GW 旁的网关上，正是因为 DPI、策略引擎等功能都位于 EPC 中
2.2 运营商网络中的 WiFi 集成¶
如 Fig.1 下半部分所示：WiFi AP、ePDG、IPsec 隧道
3GPP 和 WiFi Alliance 定义的集成方案分两类:
- 接入控制集成：目标是在 LTE 和 WiFi 之间统一认证与计费
- 多数运营商采用基于 SIM 的认证，共用一个用户数据库
- 少数运营商采用网页门户输入账号密码的方式 (这一集成已被广泛采用)
- 数据面集成：3GPP 标准化了 I-WLAN 架构。其工作方式如下
- 每台终端与 ePDG 之间建立 IPsec 隧道
- 认证完成、隧道建立后，ePDG 通过 PMIPv6 在 PDN-GW 上更新 IP 地址绑定
- IP 地址始终锚定在 PDN-GW
- 因此：在 WiFi 和 LTE 之间迁移时 IP 不变，流可以无缝迁移
代价：所有 WiFi 流量都必须回传到 LTE 核心网，回传成本大幅上升，因此大多数运营商不愿采用
Tip
本文重点肯定是围绕 "数据面集成"有问题, 需要展开
接入控制集成, 什么意思
这里的"接入控制集成"，本质上只解决一个问题：这个连 WiFi 的人是谁，是不是我的用户，该怎么计费。 它不管用户的数据后续走哪条路。
(1) 例子一：网页门户认证（传统方式）
这种方式和校园网网页登录的体验几乎一样。以中国移动早年的 "CMCC" 热点为例：
- 手机连上名为 "CMCC" 的开放 WiFi，不需要密码。
- 打开浏览器访问任意网页，会被强制跳转到一个登录页面。
- 在页面上输入手机号，收到短信验证码，填入后登录。
- 网关把这台设备的 MAC 或 IP 加入放行名单，之后才能上网。
这里的"统一"只体现在一点：用的是移动的手机号账户，费用可以记到这个号码名下。但整个过程需要用户手动操作，换一个热点可能还要重新登录，体验很差。
这就是论文里说的 "web-based authentication which requires the users to enter their credentials in the browser"。
(2) 例子二：基于 SIM 卡的认证（主流方式）
后来运营商推出了类似 "CMCC-AUTO" 这样的 SSID。用户体验是：手机走进热点范围，自动连上，什么都不用输入，就像手机在 4G 基站之间切换一样无感。
背后的原理是：手机 SIM 卡里存着一个只有运营商知道的密钥 Ki，LTE 入网时就是用它做身份认证的。
SIM 认证（EAP-SIM 或 EAP-AKA）把这套机制搬到了 WiFi 上，流程如下：
- 手机关联 AP，发起 802.1X 认证
- 这里的 802.1X 和校园网里填学号密码的那种企业级 WiFi 是同一个框架
- 只是把 "学号+密码" 换成了 "SIM 卡身份"
- AP 本身不做判断，只负责把认证消息转发给运营商的 AAA 服务器
- AAA 可以理解为运营商的认证服务端
- AAA 服务器向 HSS 请求这个用户的认证材料
- HSS 就是 Fig.1 里那个存放用户签约信息的数据库，和 LTE 共用
- 挑战-应答
- 网络发来一个随机数，SIM 卡用 Ki 计算出结果发回，网络侧核对是否一致
- 整个过程中密钥本身从不在空口上传输
- 认证通过后，双方派生出 WiFi 的加密密钥，手机开始上网
- 计费记录也挂到这张 SIM 卡对应的账户上
所谓"共用一个用户数据库"，指的就是第 3 步：WiFi 和 LTE 查的是同一个 HSS。运营商不需要为 WiFi 另建一套账号体系，用户也不需要额外注册。
(3) 关键点: 认证统一了，但数据并没有进核心网 (数据面还没通)
这也是论文区分两类集成的原因。以 SIM 认证为例，认证完成后：
- 只做了接入控制集成时：
- 数据从 AP 出来后直接经 WiFi 自己的网关上互联网，不经过 LTE 的 S-GW 和 PDN-GW
- 手机在 WiFi 上拿到的是 WiFi 网络分配的 IP，和 LTE 上的 IP 不同
- 这就是 普通的 WiFi 上网
- 做了数据面集成（I-WLAN）时：
- 数据还要经过 IPsec 隧道送到 ePDG，再到 PDN-GW
- 这样 IP 才能与 LTE 保持一致
- 代价是: 所有流量都要回传 (至 CoreNet)
这正是 ATOM 要利用的空隙：
运营商已经有了接入控制集成，知道 WiFi 上的用户是谁。ATOM 在此基础上用 HTTP 代理实现切换，就能在不做数据面集成的情况下获得接近无缝的切换效果。
2.3 现有部署及其不足¶
如 Fig.2 所示
现状：运营商希望 WiFi 不只用于补覆盖或缓解拥塞，还能承载新业务、提升 QoE。 但现有部署并不是为联合优化 LTE 和 WiFi 而设计的。终端上的连接管理器主要只负责发现、选择和认证网络。
作者在单 eNodeB 加单 AP 的测试床上，用实验逐一验证了三个缺陷。
（i）朴素策略：不考虑 AP 负载
实验设置：8 个用户都在看约 2 Mbps 的 YouTube 视频，其中 6 个在 WiFi 覆盖内，2 个只能用 LTE
- 如 Fig.2(a) 所示，WiFi 用户的吞吐低于 2 Mbps 的视频码率，出现卡顿
- 如 Fig.2(b) 所示，LTE 用户的吞吐高于码率，播放流畅
- 如 Fig.2(c) 所示，WiFi AP 的资源被用满，而 LTE 基站利用率只有约 25%
（ii）静态决策：只在建连时选接口
实验设置：4 个 WiFi 用户，开始时吞吐都高于视频码率。约第 10 秒，其中两人以步行速度远离 AP
- 如 Fig.2(d) 所示，这两人的 PHY 速率下降，AP 无法再满足所有用户的码率，视频中途卡顿
- 要动态调整就必须能无缝切换接口，而这需要数据面紧耦合。运营商抵触这种耦合，有三个原因
- 回传 WiFi 流量会同时推高 OPEX（回传费用）和 CAPEX（扩容核心网网关）
- 大部分流量是 OTT 流量，不给运营商带来直接收入，运营商缺乏为其 QoE 投资的动力
- 运营商的 WiFi 业务部门和 LTE 业务部门往往是分开独立运营的
OTT流量
OTT 是 Over-The-Top 的缩写，字面意思是"架在（运营商网络）上面跑的"。它指的是由第三方提供、借用运营商网络传输、但与运营商没有直接商业关系的服务。运营商只负责把数据包送到，服务本身的内容和收入都与运营商无关。
对照两类服务就很清楚：
| 运营商自营业务 | OTT 业务 | |
|---|---|---|
| 例子 | 电话、短信、运营商自己的 IPTV / 彩铃 | YouTube、Netflix、抖音、微信、B 站 |
| 服务由谁提供 | 运营商 | 第三方公司 |
| 用户为服务付钱给谁 | 运营商（按次、按条、按套餐） | 内容商（会员费），或者免费（靠广告） |
| 运营商扮演的角色 | 服务提供者 | 只是"管道" |
为什么运营商缺乏为 OTT 的 QoE 投资的动力:
-
收入不会因为 QoE 变好而增加
- 用户买的是按字节计费或包月流量套餐（论文 §3 也提到这两种计费方式）
- YouTube 从卡顿变成流畅，用户付给运营商的钱基本不变
- 体验变好带来的价值，比如用户更愿意看、广告收入更多，归 YouTube 所有
-
提升 QoE 的成本却要运营商承担
- 以 §2.2 的 I-WLAN 为例，要实现无缝切换，就得把 WiFi 流量回传到 LTE 核心网
- 这会同时推高回传带宽的费用（OPEX）和扩容 PDN-GW 等网关的投入（CAPEX）
-
WiFi 流量本身往往不赚钱
- 论文 §3 提到，运营商的 WiFi 通常对自家用户免费
- 于是出现一个很尴尬的局面：花大价钱把免费的 WiFi 流量回传进核心网，只为了让不付钱给运营商的 OTT 服务更流畅
-
视频正是 OTT 的大头
- 论文 §5 引用的数据是 HTTP 视频占移动网络字节量的 60% 以上
- 也就是说，最需要保障 QoE、最占回传带宽的流量，恰恰是运营商赚不到额外收入的那部分
合起来就是：成本随流量增长，收入却与 QoE 无关，理性的运营商自然不愿投资。
（iii）粗粒度策略：按用户而非按应用分配
运营商希望能按应用分配接口。这样既能根据应用需求提供相应的 QoE，将来也可能向愿意为 QoE 付费的内容商收费。
- 实验设置：8 个 WiFi 覆盖内的用户都从 AP 下载大文件，其中 User#5 同时还在看 2 Mbps 的视频；另有 4 个 LTE 用户在看同一视频。
- 如 Fig.2(e) 所示，对比了两种场景：
- Scenario 1：User#5 的所有流都在 WiFi 上。它的视频因 AP 拥塞而严重卡顿。
- Scenario 2：按用户粒度把 User#5 的视频和下载都搬到 LTE。结果 LTE 被挤爆，5 个视频用户全部卡顿。
- 作者由此指出:
- 理想做法是只把 User#5 的视频流移到 LTE，下载流留在 WiFi
- 这样 5 个视频都能流畅播放。这个效果在 §7 的 Fig.8(d) 中得到验证
本节逻辑
(1) 2.1 和 2.2 说明"无缝迁移"在标准上可行，但代价是回传
(2) 2.3 用实验说明不做动态、细粒度管理，QoE 和资源利用都会很差
两者合起来，引出 ATOM 的目标: 在不回传的前提下，实现动态、按流粒度的接口管理
§3 篇幅不长，主体是四条设计考虑，结尾给出系统的整体形态和两个组件。只涉及一张图：Fig.3（ATOM 架构图）。
ATOM Design¶
- 左上角的 ATOM 服务器 (网关式设计):
- 内部分为两块，Network Interface Assignment（NIA）和 Interface Switching Service（ISS）
- 左下方的 LTE Core Network:
- 包括 Serving-gateway 和 PDN-gateway
- ATOM 挂在 PDN-gateway 旁边，位于核心网内部，而不是基站上
- 右侧的 LTE Cell:
- 一个 LTE 小区的覆盖范围内分布着多个 WiFi AP
- 用户终端上运行着 YouTube、Netflix、Hulu 等应用
- WiFi Gateway:
- WiFi 流量经它直接连到 Internet，不经过 LTE 核心网
设计考虑 (i): 以网络为中心 - 集中式、网关级
- 集中式而非客户端分布式
- ATOM 掌握全网视图，包括小区负载、用户 QoE 等，由它统一决定接口
- 客户端方案（如 MOTA [8]）需要网络向终端下发负载信息，这会增加空口信令，还需要修改标准。而这些信息对 ATOM 来说在网络侧就能直接拿到
- 部署在网关而非每个 eNodeB
- 如 Fig.3 中 ATOM 挂在 PDN-gateway 旁所示
- 这样做有两个好处:
- DPI (Deep packet inspection)、策略引擎等模块，本来就在 EPC 里。ATOM 与它们放在一起，取数据方便
- 如果把 ATOM 部署到每个基站，会加重基站的计算负担，不利于部署
设计考虑 (ii): 可扩展性 - 按小区隔离
- 以一个 LTE 小区为单位独立决策
- 一个小区及其覆盖内的所有 WiFi AP 由一个 ATOM Instance 管理。如 Fig.3 中的 LTE Cell 所示
- 多个实例并行运行，彼此互不影响
- 为什么可以这样隔离
- 从某个小区卸载出去的流量，只会落到这个小区覆盖范围内的 AP 上，不同小区之间基本没有耦合
- 带来的好处
- 运营商新增基站或 AP 时，只需要增加实例，系统随之平滑扩展
- 可以只给拥塞的小区启动实例，节省资源
设计考虑 (iii): 无缝切换
- 切换机制需要满足两个要求：一是成本低，也就是不回传；二是能随无线环境的变化动态调整
- 一个关键的设计选择：
- TCP 连接刚建立时，很难判断这个应用需要什么，比如用户接下来会选哪个视频分辨率
- 所以 ATOM 在终端上只设一条简单的静态策略：所有连接一律先从 WiFi 发起
- 等会话进行中、信息更充分时，再借助无缝切换把流调整到合适的接口
- 这样运营商就可以制定更精细的策略，例如按用户选择的视频分辨率来决定接口
这一条的思路是
把"选对接口"从建连时刻推迟到会话进行中，而能推迟的前提就是切换必须无缝
设计考虑(iv): 计费
- 现有的两种计费模式
- 按字节计费：每 KB 收固定费用
- 阶梯流量包：例如每月 3GB，付固定月费
- 现状：
- 运营商的 WiFi 通常对自家用户免费，但将来如果 WiFi 也提供运营商级服务，就可能开始收费
- 设计目标：
- ATOM 的框架要能兼容通用的计费机制，在上面两种模式下都适用
- 具体做法（在效用函数中减去代价项）放在 §4 中介绍
最终形态: 网关级部署 - 一个网关托管多个实例
- ATOM 部署在运营商管理范围内，但基站之外的网关上
- 一个网关通常负责多个基站，因此它上面运行多个 ATOM 实例，每个实例对应一个 LTE 基站
- 每个实例由两个组件构成，也就是 Fig.3 中 ATOM 框内的两块：
- NIA（网络接口分配）：决定每条流该走哪个接口，在 §4 展开
- ISS（接口切换服务）：负责执行切换，在 §5 展开
NIA: Network Interface Assignment¶
§4 是全文的算法核心，回答的是"每条流该分到哪个接口"
很无聊, 笔者不喜欢看算法. 先略过
ISS: Interface Switching Service¶
§5 回答的是"NIA 做出决定之后，怎样在不断连、不回传的前提下把流真正切过去":
- 上方虚线框 "Interface Switching Service"：
- 这是网络侧，包含 Control Logic 和 HTTP Proxy
- 左侧的 "Interface to NIA" 表示 NIA 通过这里下发切换指令
- 中间两条接入路径：LTE 基站和两个 WiFi AP，分别通往 Internet
- 两类数据路径：
- "HTTP Download Traffic"（黑色椭圆）经过网络侧的 HTTP Proxy 再到 Internet
- "HTTP based Video streaming / Browsing"（灰色椭圆）从 LTE 或 WiFi 直接到 Internet，不经过网络侧代理
- 左侧 "Control Traffic"：
- 网络侧 Control Logic 经 LTE 连到终端上的 Control Logic，专门用来传切换指令
- 下方虚线框 "Mobile Device"：
- Application / Browser 把 HTTP 请求交给本地 HTTP Proxy
- 本地 Control Logic 收到指令后，通知本地代理切换接口 ("Switch Interface")
(1) 要解决的根本问题¶
- ISS 的定位：
- 它是 NIA 的执行层。每个周期 \(T\)，按照 NIA 的决策切换相应流的接口
- 根本难点：
- 从 WiFi 切到 LTE 时，终端的 IP 地址会变，而 TCP 连接是用四元组（源/目的 IP 和端口）标识的。IP 一变，原来的 TCP 连接就断了
- 3GPP 的做法 (现有工作为什么不好)：
- 把所有流量锚定在同一个网关上（§2.2 中的 I-WLAN，IP 锚定在 PDN-GW）
- IP 不变，连接也就不断
- 代价是 WiFi 流量全部要回传
- ISS 的做法：不去保住旧连接，而是让应用层不在乎连接断没断
(2) 两个关键观察: 为什么要这样设计¶
- 运营商抵触数据面紧耦合，因为回传成本太高（§2 已经论证过）。所以切换方案不能依赖回传
- HTTP 是移动网络的主导协议
- 超过 90% 的流量走 HTTP，HTTP 视频占总字节数的 60% 以上，预计会升到 75% 以上
- 视频虽然更适合用 UDP 传输，但实际大多采用 HTTP/TCP
- 可以直接利用 HTTP 生态已有的优势：CDN 与缓存、容易穿越 NAT、基于 URL 的内容命名等
结论：只要把 HTTP 流量处理好，就能覆盖绝大部分字节
与 3GPP 方案的关系：互补，而不是替代。 ISS 可以作为 overlay 叠加在现有的 I-WLAN 之上：HTTP 流量由 ISS 处理，避免回传；其余流量仍走 I-WLAN 回传，保证能切换。
(3) HTTP 流量的特点¶
原文的 "Quick Primer on HTTP"
早年的 HTTP 视频就是一次性下载整个文件，现在主流的有两种方式，再加上网页浏览：
| 类型 | 怎么请求 | 为什么这样设计 |
|---|---|---|
| HTTP 渐进下载（PD），如当时的 YouTube | 按字节范围（byte-range）分段请求，不一次下载整个文件 | 控制下载速度与播放速度匹配，用户中途退出时不浪费带宽；也便于拖动进度条 |
| DASH 自适应流，如 Hulu、Netflix | 视频预先编码成多种码率，每种切成 4–10 秒的分片。播放器先下载一个清单文件（列出每个分片、每种码率的 URL），再根据实测 TCP 吞吐，逐片用 HTTP-GET 请求合适码率的分片 | 让码率随网络状况自适应 |
| 网页浏览 | 一个页面由 html、图片等许多小对象组成，每个对象单独发一个 HTTP-GET | — |
共同点
一个"会话"其实是一串相互独立的 HTTP-GET 请求，在时间上陆续发出
(4) 核心思路: 切换本质就是"下一个请求换条路发"¶
- 需要切换时，后续的 HTTP-GET 从新接口发出，已经发出的请求留在旧接口上收完即可
- HTTP 本身支持同时使用多条 TCP 连接，所以在新接口上建立新的 TCP 连接来发后续请求，是完全合法的用法
- 旧连接断了也无所谓：它上面没有未完成的请求，应用看到的只是"下一个分片从另一条连接回来了"
收益：视频和浏览流量不需要回传到 LTE 核心网。由于视频占字节数的大头，这为运营商省下了大部分回传成本
适用范围：只适用于 HTTP 视频和浏览类流量
(5) ISS 的组成¶
[1] 终端侧
Fig.4 下方的 Mobile Device 框
- 本地 HTTP 代理：一个轻量的用户态程序
- 应用和浏览器都配置为使用它，所以终端发出的所有 HTTP 请求都先经过它
- 这样: "从哪个接口发"就由代理说了算，应用本身不需要任何修改
- 代理可以把请求转发到网络侧代理，也可以直接发给内容服务器
- 本地 Control Logic：接收网络侧的切换指令，并告诉本地代理改用哪个接口
[2] 网络侧
Fig.4 上方的 Interface Switching Service 框
- Control Logic：
- 对上为 NIA 提供接口，接收切换决策
- 对下与每台终端的 Control Logic 经 LTE 保持一条长连接，用来把指令下发到对应的终端（"Control Traffic"）
- HTTP Proxy：
- 只给除视频和浏览之外的 HTTP 流量使用
- 运营商通常本来就部署了 HTTP 代理，用于优化和缓存，所以这一部分不增加新的设备
(6) 按流量类型分别处理¶
类型 1：HTTP 文件下载
中到大文件，如 Dropbox、软件更新，对应 Fig.4 中的黑色路径
- 问题：一个大文件往往只有一个 GET，没有"下一个请求"可以换路发送
- 做法：
- 这类流量始终经过"网络侧 HTTP"代理，由这个代理充当锚点
- 无论终端走 WiFi 还是 LTE，连的都是同一个代理。所以对内容服务器来说，终端换接口是完全透明的
- 切换过程：
- ISS 下发切换指令
- 终端代理用新接口与网络侧代理建立一条新的 TCP 连接
- 网络侧代理拆掉旧接口上的 TCP 连接，然后在新连接上继续发送剩余数据
- HTTP 会话因此得以保持
类型 2：HTTP 视频与浏览
对应 Fig.4 中的灰色路径
- 做法：
- 不经过网络侧代理，直接从接入网经过本地侧 HTTP 代理 到 Internet
- 切换过程：
- 终端 Control Logic 收到针对某个 web 会话的切换指令
- 终端代理把后续对象或视频分片的请求改从新接口发出
- 已经在旧接口上发出的请求继续在旧接口上收完
- 这正是第 4 点"下一个请求换条路发"的直接应用，也是 ATOM 省下回传成本的主要来源
类型 3：非 HTTP 流量
- ISS 无能为力，退回到 I-WLAN 等标准方案，这部分流量仍需回传到核心网
三类对比
| 流量类型 | 锚点 | 切换方式 | 是否回传 |
|---|---|---|---|
| HTTP 下载 | 网络侧 HTTP 代理 | 换一条 TCP 连到同一个代理 | 否（但要经过代理） |
| HTTP 视频 / 浏览 | 不需要锚点 | 后续请求从新接口发出 | 否 |
| 非 HTTP | PDN-GW（I-WLAN） | 标准的 IP 保持方案 | 是 |
Note
ISS 的思路是把"保持连接"问题从网络层挪到应用层来解决。它不去维持 IP 不变，而是利用 HTTP 会话由多个独立请求组成的特点，让切换发生在请求与请求之间
控制通道始终走 LTE，保证指令可达；数据通道按流量类型分别处理，使占大头的视频流量既能无缝切换，又不需要回传
Prototype¶
"半实物仿真图"画的很好. 值得学习
Related Work¶
| 类别 | 代表工作 | 核心思路 | 局限性 | 与 ATOM 的关系 |
|---|---|---|---|---|
| 商业方案 | Qualcomm CnE [29]；InterDigital SAM [30] | 决策逻辑主要放在终端上，根据吞吐与时延的测量结果，在 WiFi 与 3G/LTE 之间管理用户流 | 无缝连接依赖 I-WLAN 架构（即需要回传）；尚未广泛部署 | 互补：它们利用了终端上下文信息，并能管理非运营商管理的第三方 WLAN，可与 ATOM 配合使用。它们的存在也说明"受管理的 WiFi 卸载"很重要 |
| 客户端优化：接口选择算法 | Aryafar [7]（RAT 选择博弈，Infocom'12）；Deb [8]（MOTA，MobiCom'11）；Coucheney [9]（Infocom'09）；Zhu [10]（WCNC'10）；Pedrasa [31]（WCNC'10） | 各终端运行分布式算法，自行选择接口 | 需要网络额外下发负载信息，或借助 P2P 传播网络状态，信令开销大；即使拿到负载信息，效率仍不如集中式方案 | ATOM 采用集中式网络视图，不增加空口信令；§7.2 仿真表明 ATOM 的吞吐与聚合效用均优于 MOTA，且切换次数更少 |
| 客户端优化：公共 WiFi 卸载 | Lee [11]（ToN'13）；Balasubramanian [12]（MobiSys'10） | 论证利用公共 WiFi 卸载 3G 流量的可行性 | 只适用于时延容忍型流量；可能需要修改应用 | ATOM 支持视频等实时流量，且应用无需修改 |
| 客户端优化：无缝切换 | Rahmati [32]（TMC'14，无需网络支持的智能手机 TCP 迁移） | 在终端上实现用户流量的无缝切换 | 只有切换机制，不包含"该切到哪个接口"的决策 | ATOM 同时提供决策（NIA）和执行（ISS） |
| 网络侧方案 | Ye [6]（异构网络负载均衡的用户关联）；Wang [33]（网络选择建模综述）；Shen [34]（基于代价函数的网络选择）；Chan [35]（基于效用的多业务网络选择） | 由网络驱动接口选择或用户关联，多数用基于效用的优化来均衡负载、最大化吞吐 | ① 假设理想化场景，很少考虑实际约束；② 与基站调度器紧耦合，难以部署； ③ 缺少端到端方案，无法随网络变化动态调整接口 | ATOM 同样采用效用优化，但只按秒级周期做关联决策，包调度仍交给基站和 AP，与调度器解耦；它是端到端系统，自适应、轻量、可扩展，能部署在现有网络中 |
ATOM 相对于各类工作的定位
| 维度 | 商业方案 | 客户端优化 | 网络侧方案 | ATOM |
|---|---|---|---|---|
| 决策位置 | 终端 | 终端（分布式） | 网络 | 网络（集中式、网关级） |
| 是否需要额外信令或标准支持 | 依赖 I-WLAN | 需要网络下发负载信息或 P2P | 与基站调度器耦合 | 不需要（overlay 部署） |
| 是否有接口选择的决策 | 有 | 有（[32] 除外） | 有 | 有（NIA） |
| 是否有无缝切换机制 | 有（依赖 I-WLAN 回传） | 仅 [32] 有 | 缺少 | 有（ISS，HTTP 流量无需回传） |
| 是否支持实时或视频流量 | — | [11][12] 不支持 | — | 支持 |
| 是否为端到端可部署系统 | 部署有限 | 否 | 否 | 是（真实 LTE-WiFi 原型验证） |
Discussion¶
§9 讨论了 ATOM 在实际部署中可能遇到的五个问题：移动性、可扩展性、信令开销、频繁切换和能耗
(1) 移动性：高速用户需要特殊处理
- 现状：ATOM 对静止用户和中低速用户（如步行）效果良好，对应 §7.1 中 Fig.9 的步行移动实验
- 问题：车载等高速用户穿过一个 WiFi 热点只需几秒，而 ATOM 按秒级周期决策、切换也要几秒（Fig.10 中切换时间的中位数在几秒以内）。刚切到 WiFi 就可能已经离开覆盖范围，造成无谓的来回切换
- 建议：利用速度等上下文信息，把这类用户直接当作纯 LTE 用户处理，不参与 WiFi 分配
(2) 可扩展性：两个层面
[2.1] 小区之间是否真的可以隔离
- 当前的依据：
- 现有 LTE 部署中，宏站、微站和小站的覆盖范围都比 WiFi AP 大得多，一个 AP 基本只落在一个小区内
- 所以每个小区独立运行一个实例（§3 设计考虑 ii），性能几乎没有损失
- 未来的问题：如果蜂窝网络变得更密集、小区更小，一个 AP 可能同时落在多个小区的覆盖内，小区之间就不再独立
- 作者的态度：如何为这种密集场景设计一个可扩展的、跨多个小区联合管理的系统，留作未来工作
[2.2] 资源开销
- 问题：一个运营商有大量小区和流，为每个小区都分配 CPU 和状态存储来运行实例，成本很高
- 三种缓解办法：
- 只给负载超过阈值的小区启动实例；
- 把决策周期 \(T\) 拉长，例如到 1 分钟，以降低计算量；
- 改为事件驱动，只在有流到达或离开时才运行。
这与 §7.2 中 eff-ATOM"只对状态有变化的 AP 重新计算"的思路一致（Fig.12）
(3) 信令开销：粗略估算后认为可忽略
ATOM 依赖基站和 AP 上报反馈信息，作者做了一个粗略估算：
| 项目 | 假设 | 结果 |
|---|---|---|
| 每条流的反馈内容 | 当前 IP 地址和端口、在 LTE 与 WiFi 上的平均传输速率（按平均每个用户有 2 个候选 AP 计算） | 约 10 字节 |
| 每个基站 | 平均 50 条活跃流 | 每个反馈包约 500 字节 |
| 整个数据中心 | 管理约 1000 个基站，周期 \(T=10\) 秒 | 反馈速率约 400 Kbps |
| 用户数据 | 每个基站平均 10 Mbps（峰值约 60 Mbps） | 总计约 10 Gbps |
结论：信令开销不到用户数据的 0.05%。
需要注意，这里只算了"基站或 AP 向 ATOM 上报"这一个方向，没有计入 ISS 向终端下发切换指令的开销，也没有计入 WiFi 网关汇总信息的开销。
(4) 频繁切换：用历史切换次数来抑制
- 问题：
- 为了保证系统稳定，实际部署中 ATOM 的执行周期会在s-level。但在网络高度动态下，仍可能出现某些流在两个接口之间来回切换的情况
- 为什么要避免：
- 每次切换都会在移动网络中产生额外信令。§7.2 的 Fig.11(c) 显示，ATOM 平均每个用户每个会话切换不到 0.5 次，而 MOTA 约为 2 次
- 办法：
- 根据一条流最近的切换历史，给它加一个惩罚项。切换得越频繁，再次切换的代价就越高
- 这与 §4 中计费项 \(E_{ij}\) 的作用方式相同，都是在效用函数中减去一个代价
启发 NTN
"为了保证系统稳定，实际部署中 ATOM 的执行周期会在s-level。但在网络高度动态下，仍可能出现某些流在两个接口之间来回切换的情况"
这里"网络高度动态", 可是 NTN 的天然特征啊! 那这种 Ping-Pong Switching, 是不是很有"可做空间"?
Inspiration!
(5) 能耗：可以纳入框架，但没有实现
- 可以怎样纳入：
- 同样作为效用函数中的代价项。例如，电量很低的终端可以被分配到更省电的接口，即使那个接口的吞吐不是最高的
- 为什么没有实现：
- 终端的能耗模型很复杂，还取决于屏幕、CPU 等其他部件的耗电
- 为了保持设计简单，作者没有把能耗纳入 ATOM
Conclusion¶
1. 背景
移动数据需求的增长超过了蜂窝网络扩容的速度，运营商因此大规模部署 WiFi 来分流。但现有做法只是"有 WiFi 就用 WiFi"，LTE 和 WiFi 两张网基本各自为政，没有被联合管理
2. 问题与动机
要解决的问题是：如何按流粒度动态决定每条流走 LTE 还是哪个 WiFi AP，并在会话进行中无缝切换
现有策略不看负载、只在建连时决策、按用户整体分配，导致 WiFi 拥塞而 LTE 闲置、视频卡顿
而 3GPP 中唯一能做到无缝切换的 I-WLAN，要求把所有 WiFi 流量回传到核心网: 对不给运营商带来收入的 OTT 来说，这个成本运营商不愿承担
所以需要一个不改标准、不需要回传就能落地的方案!
3. 方法论
- 核心洞察：
- HTTP 视频和网页浏览的一个会话，由许多独立的 GET 请求组成。因此切换不必保住旧的 TCP 连接，只要让后续请求从新接口发出即可，也就无需回传
- 系统设计：ATOM 部署在核心网网关旁，每个 LTE 小区运行一个实例，由两部分组成：
- NIA 负责决策：
- 以加权 log 效用为目标，结合 LTE 的比例公平和 WiFi 的吞吐公平两种吞吐模型建模
- 问题是 NP-hard 的，因此用两层贪心算法按秒级周期求解
- ISS 负责执行：
- 通过 终端和网络两侧的 HTTP 代理 切换接口
- 视频和浏览流量直接换路发送后续请求:
- 下载流量以网络侧代理为锚点
- 非 HTTP 流量退回 I-WLAN
- NIA 负责决策：