DREW: Double-Throughput Emulated WiFi¶

一种旨在使超低功耗蓝牙芯片能够直接与标准WiFi接入点(AP)进行双向通信的跨技术通信(CTC)解决方案

传统的 CTC 方案受限于 1Mbps 的吞吐量, 且不适用于缺乏传输混频器的 ULP BLE 芯片.

DREW 通过仅控制功率放大器(PA)来发送 WiFi 数据包, 并通过创新地利用BLE的IQ采样能力来接收 WiFi 数据包, 从根本上克服了这些限制

简单看了一下, 本文与笔者研究方向基本没关系, 且“写作框架”比较奇怪

这里笔者只整理本文的“写作框架”, 论文架构具体内容就不说了!

本文是一个 Real System Implementation 类文章

这篇文章的核心不是“搭建一个平台去模拟”, 而是“我们在真实的、受限的（通常是廉价的）硬件上，通过巧妙的技巧/算法实现了XXX功能”

个人认为这种行文方式并非“典型”, 看一下了解即可, 没必要效仿

具体来说:

Introduction (引言)
- Background: 跨技术通信 (CTC) 很重要，尤其是 WiFi 和 BLE (蓝牙低功耗) 之间的通信，它能让低功耗设备（如可穿戴设备）直接连接互联网
- Problem: 现有的 CTC 方案 (如 FLEW, Unify) 有两个致命缺陷：
  1. 硬件依赖: 它们依赖老式 FSK 芯片中的"混频器"(mixers) 来实现
  2. 硬件过时: 为了极致省电，新型的"超低功耗"(ULP) BLE 芯片已经移除了混频器，导致老方案完全不适用
  3. 性能瓶颈: 就算能用，老方案也只支持 BPSK，速率上限仅为 1Mbps
- Solution: 我们提出了 DREW。它专门为"无混频器"的 ULP BLE 芯片设计
  - 接收 (Rx) 方案: 创新性地利用 ULP 芯片上用于"定位"(AoA) 的 IQ 采样功能来接收 WiFi 信号
  - 发送 (Tx) 方案: 创新性地通过直接控制功率放大器 (PA) 来"模拟"出 WiFi 信号
- Key Contribution: DREW 不仅解决了硬件兼容问题，还独特地支持了 QPSK 解调，将下行速率翻倍至 2Mbps
- Key Result: 1Mbps 的老方案看不了高品质音频，而 DREW 的 2Mbps 速率，使其成为第一个能够支持"无损、高保真立体声音频流" (1.411Mbps) 的方案
System Design (系统设计)
- 2.1 WiFi to BLE (接收设计)
  - 可行性分析 (Observation): 先分析 WiFi DSSS 信号的频谱特性。然后提出"关键洞察"：既然 BLE 芯片能为 AoA 定位功能进行 IQ 采样，那我们就可以"劫持"这个功能来捕获 WiFi 信号的 PSK 频谱
  - 详细设计 (Detailed Design): 详细阐述如何用 BLE 芯片上性能很弱的 ARM M0 内核实时处理这些 IQ 样本。包括 BPSK 和 QPSK 的解调算法、包检测、以及利用 SIMD 指令加速
- 2.2 BLE to WiFi (发送设计)
  - 可行性分析 (Observation): 再次分析 WiFi BPSK 信号。并发现一个"关键事实"：WiFi 接收器在解调前，普遍会执行"DC 移除" (DC Removal) 操作
  - 详细设计 (Key Idea): 这意味着，BLE 芯片（发送端）不需要用混频器去完美生成"正负切换"的 BPSK 信号；它只需要通过快速"开关 PA"来生成一个"在 0 和 1 之间切换"的信号 (如图 8c)。这个信号在 WiFi 接收器看来，经过 DC 移除后，就等同于一个标准的 BPSK 信号
- 2.3 MAC Layer (协议层设计)
  - 设计: 为了让 DREW 芯片能被 WiFi AP 识别为"标准 WiFi 设备"，我们必须完整模拟 WiFi 的 MAC 层，包括 CSMA/CA (信道竞争)、ACK/CTS (确认)。这通过一个"有限状态机"(FSM) 来实现
- 2.4 Implementation (具体实现)
  - 这部分对应我们先前整理出来的框架中"Implementation", 但作者将其归为"设计"的最后一步
  - 硬件: 我们在 NXP Kinetis KW41Z 这款商用 ULP BLE 芯片上实现了 DREW
  - 软件: 核心的实时任务 (如收发) 使用 ARM 汇编编写，上层逻辑使用 C 语言
  - 踩坑: 详细描述了实现中遇到的具体工程挑战，例如如何配置 IQ 采样和如何解决 FLL 导致的"时钟抖动"(Clocking)
Evaluation (实验评估)
- 这部分不是"仿真"，而是"实测"
- 实验设置 (Setup): 将我们刷了 DREW 固件的 BLE 芯片，与市面上主流的 WiFi AP (Atheros, Broadcom, Realtek 等) 进行连接测试
- 微观基准 (Microbenchmark): 测试最底层的 PHY 性能，即包错误率 (PER)。结果表明我们的 QPSK 解调 (下行) 和 PA 发送 (上行) 都非常可靠
- 系统吞吐量 (Throughputs): 测试 TCP/UDP 吞吐量。结果证明下行吞吐量 (QPSK) 远超老方案，上行吞吐量 (零等待发送) 也优于老方案
- 应用展示 (End-to-End Applications):。我们成功地使用 DREW 实现了:
  1. 无损音频流 (1.44Mbps)
  2. 观看 720p Youtube 和 Netflix 视频
  3. 运行 ChatGPT 和谷歌语音搜索
- 其他: 测试了 RTT (延迟)、共存性和功耗 (证明了 DREW 确实保持了 ULP 的低功耗特性)
Discussion (讨论)
- (这是真实系统文章常有的部分，用于"答辩"，即预判并回答审稿人/读者可能提出的质疑)
- Q1: 为什么不直接用 WiFi 64-QAM？更快？
- A1: 我们的目标不是和专用 WiFi 芯片比快，而是在已有的、廉价的、超低功耗的 BLE 硬件上实现 WiFi 连接
- Q2: 你们用的 IQ 采样功能，别的 BLE 芯片上有吗？
- A2: 有。这是蓝牙 5.1 标准为了 AoA 定位引入的，是新芯片的标配
- Q3: 你们的包检测算法为什么不用"相关法"？
- A3: 相关法计算量太大，我们用的 ARM M0 跑不动。我们的 FIFO 算法更轻量，才能"实时"运行
Related Work (相关工作)
- 定位: 将 DREW 放在 CTC 领域中进行比较
- 核心对比: 再次强调与 FLEW 和 Unify 的区别：它们需要混频器且只有 1Mbps。DREW 是第一个在无混频器 ULP 芯片上实现 2Mbps (QPSK) 的工作
Conclusions (总结)
- 重申我们的贡献：提出了一种新颖的方法 (PA 发送, IQ 接收)，首次在 ULP BLE 芯片上实现了高吞吐量 (QPSK) 的 WiFi 连接