📡 技术幻灯片 · 33 页 + 附录 · 数据全部标注一手来源

用光速当尺子：
WiFi FTM 精细时间测量完全指南

从 802.11mc 到 802.11az/bk —— 室内定位如何从「猜」走向「量」

RTT = (t₄ − t₁) − (t₃ − t₂)　　d = RTT × c / 2

核校截止 2026-08-056 个部分 · 33 页正文 + 2 页附录一手来源 30+

PART 1

定位技术全景
为什么你的手机在商场里找不到自己

室外定位在 2005 年就解决了，室内定位到 2026 年仍然没有统一答案。这一部分回答：GPS 进门后到底发生了什么，为什么 RSSI 和指纹这两条主流路线都撞在同一堵墙上。

GPS 一进门就瞎了
四条技术路线
RSSI 天生不准
指纹不 scale
换一把尺子

1.1 Slide 1.1

一个尴尬的事实：GPS 一进门就瞎了

不是"变得不准"，是根本收不到 —— 这是一道功率预算题

−128.5 dBm

GPS L1 C/A 到达地表的规范最小功率（IS-GPS-200）

−25 dB

常规室内额外衰减（深室内 >35 dB）

−140 dBm

手机 GNSS 捕获灵敏度门限

1/22

室内信号功率相对捕获门限，差 13.5 dB

图 1.1｜GPS 功率预算瀑布：常规室内衰减 25 dB 之后，信号掉进"捕不到星"的灰色区域。
数据来源：IS-GPS-200（−158.5 dBW）、MDPI Sensors 24(5):1416（室内衰减三档）、GPS World（手机灵敏度）

为什么室内需求是 <1 米（不是营销话术，是监管硬线）

FCC 无线 E911 要求垂直方向 ±3 米、覆盖 80% 的室内呼叫（前 25 大市场 2021-04 截止）。而楼层间距通常只有 3–4 米 —— ±3 米意味着必须能分清楼层。
水平方向要求 80% 的呼叫给出可调度地址或 ≤50 米精度。
零售场景的目标口径更狠：802.11bk 直接叫 "product on shelf"（在货架上找到那一件商品）。

指标	数值	统计口径	来源
GPS 空间信号 URE	≤ 2.0 m	日均全球，95% 概率	GPS.gov
手机 GPS 开阔天空	4.9 m 半径	典型值	GPS.gov
FCC E911 垂直（z 轴）	±3 m	80% 室内呼叫	FCC 2020
楼层间距（需求推导）	3–4 m	—	建筑常识
零售"货架级"目标	< 0.1 m	802.11bk 目标	arXiv:2509.03901

GPS 不是在室内"变得不准"，而是根本收不到——常规室内衰减 25 dB 之后，信号比手机的捕获门限还低 13.5 dB，功率只剩 1/22；而 FCC 那条 ±3 米的垂直硬线又要求你能分清楼层。供给和需求之间隔着的不是一个百分比，是一个数量级。

1.2 Slide 1.2

室内定位的四条技术路线

本质是：你拿信号的哪个属性当尺子

物理测量（有解析几何模型）

测强度 RSSI —— 路径损耗反推距离
测时间 ToF / RTT —— FTM 在这里
测角度 AoA / AoD —— 天线阵列测入射角

模式匹配（靠数据库）

测特征 指纹 / CSI / 地磁 / 视觉
离线建库 + 在线匹配
没有物理模型，只有相似度

这个划分决定了它们的失效方式完全不同：物理测量在多径下有偏（可建模、可治理），模式匹配在环境变化下失效（只能重建库）。

图 1.2｜精度 × 部署成本四象限。左上角的绿色高亮区只有三个点：WiFi RTT / 802.11az / 802.11bk —— 全篇的论点就是这个框。
数据来源：arXiv:2509.03901 Table 2、SpotFi (SIGCOMM'15)、MDPI Sensors 21(11):3589、Bluetooth SIG

综述给出的标准级横向对比（arXiv:2509.03901 Table 2）

	UWB	蓝牙信道探测	Wi-Fi 802.11
带宽	500 MHz / 1 GHz	40 × 2 MHz	20–320 MHz
功率谱密度	−41.3 / −31.3 dBm/MHz	17 dBm/MHz	17 dBm/MHz
LOS 精度	<0.1 m	1–2 m	0.4 m(az)｜<0.1 m(bk)
LOS 作用距离	<15 m	10 m	50+ m
需独立射频？	否（需专用芯片）	是	是（已装在墙上）

关键读法：UWB 精度赢，但作用距离只有 <15 米、功率谱密度低 58 dB —— 覆盖同样面积需要的锚点数量是 Wi-Fi 的数倍。这是 UWB 十年没铺开的根本原因，不是技术不行，是账不划算。

比精度表更有洞察的一张表：四条路线的"失效方式"

路线	在多径下	在 NLOS 下	环境变化时	换台设备时
测强度	抖动（随机）	有偏（偏远）	直接失效	系统性偏差
测时间	有偏（可分首径则可解）	有偏（可建模/可学习）	基本不受影响	固定偏置，一次校准可消
测角度	多径假峰（超分辨可解）	有偏	基本不受影响	取决于阵列一致性
测特征	被吸收进特征	被吸收进特征	直接失效	需跨设备校准

四条路线不是四种精度，是四种失效方式：测强度的东西怕环境变、测特征的东西怕数据库过期，而测时间的东西只怕多径 —— 而多径可以靠带宽和算法治，环境变化和数据库过期治不了。这就是为什么连蓝牙都在从 RSSI 改宗 Channel Sounding。

1.3 Slide 1.3

RSSI 为什么天生不准

模型本身没错，错在参数不可知 —— 路径损耗模型的四重崩塌

RSSI(d) = A − 10·n·log₁₀(d)　　　ITU-R P.1238 写作 N·log₁₀ d，N = 10n

别把 ITU 的 N 当成教科书的 n。ITU 办公室 N=30 就是 n=3.0，差 10 倍。PPT 上直接放 ITU 表务必加一列换算。

崩塌一：路径损耗指数 n 在同一栋楼里就漂 2.2 倍

ITU-R P.1238-7 官方结论段（900–2000 MHz）给出的漂移范围：

场景	N（ITU）	n（教科书）	说明
走廊、超市长货架通道	18	1.8	波导效应，比自由空间还小
有直射径 / 大开间（商场、体育馆）	20	2.0	自由空间损耗主导
常规办公室 2.4 GHz	30	3.0	ITU Table 2
绕障碍、穿墙、隔间式办公楼	40	4.0	同一栋楼里，n 变化 2.2 倍

而你的定位算法只能假设一个 n。真实 n=3 却按 n=2 算，10 米会被估成 31.6 米（3.2 倍），30 米估成 164 米（5.5 倍）。

图 1.3｜RSSI-距离曲线族（A = −40 dBm）。蓝色带为 n=3.0 时 ±10 dB 的阴影衰落 1σ。
数据来源：ITU-R P.1238-7 Table 2 / Table 4 / 结论段

崩塌二～四：随机、人体、设备，三层误差叠在模型误差之上

层	误差源	量级	能否消除	来源
① 模型层	n 随场景漂移 1.8 → 4.0	距离估计偏 2–5 倍	需现场标定，换场景失效	ITU-R P.1238-7
② 随机层	阴影衰落 σ（对数正态）	8–17 dB（5.8 GHz 办公室达 17）	空间相关，时间平均无效	ITU Table 4
③ 人体层	朝向 / 遮挡	≤5 dBm（同一点换个朝向）	不可预测	RADAR, INFOCOM 2000
④ 设备层	芯片/天线/固件差异	刻度不一，可见 AP 集合都不同	只能靠差分/排序绕开	Kjærgaard 2011

为什么平均救不了：把 σ=10 dB 压到 1 dB 需要 100 个独立样本，但阴影衰落是空间相关的 —— 同一位置反复采样拿到的是同一个衰落值。时间平均只能压掉快衰落，压不掉阴影衰落。这是物理天花板，不是工程问题。

把 σ 翻译成距离：全页最有杀伤力的一步计算

n=3.0、σ=10 dB → 距离估计的 1σ 乘性误差 = 10^(10/30) = 2.15×

真实距离	−2σ	−1σ	中心	+1σ	+2σ	95% 区间宽度
2 m	0.43	0.93	2.0	4.3	9.3	8.9 m
5 m	1.08	2.32	5.0	10.8	23.2	22.1 m
10 m	2.15	4.64	10.0	21.5	46.4	44.2 m
20 m	4.31	9.28	20.0	43.1	92.9	88.6 m

RSSI 的问题不是"不够准"，是它测的根本不是距离。ITU 自己的表就写着：同一栋楼从走廊走进隔间，路径损耗指数从 1.8 跳到 4.0；办公室的阴影衰落标准差是 10 dB。把这两个数代进公式，一次 RSSI 读数对应的 95% 距离区间是 2 米到 46 米 —— 你拿到的不是一把尺子，是一个概率云。

1.4 Slide 1.4

指纹定位为什么不 scale

不是不准，是不划算 —— 26 年过去了，实地部署的数字没有本质变好

开山之作就定下了精度天花板：RADAR（微软研究院, INFOCOM 2000）

980 m²

测试场地（3 层楼的 2 层，50+ 房间）

280

采样点 = 70 物理点 × 4 朝向，每点 ≥20 样本

2.94 m

中位误差（25/75 分位：1.92 / 4.69 m）

基站数量

这就是"3–5 米天花板"的原始出处。26 年后行业实地部署仍是 5–10 米（Mappedin 2026 指南），而同一份指南给 Wi-Fi RTT 的口径是优化部署下 1–2 米。

采集成本是原罪，而且是超线性的

RADAR 的采集密度是每 3.5 m² 一个采样点。按这个密度线性推算：

场地	面积	采样点数	纯采集工时（60 s/点）
RADAR 原始测试楼层	980 m²	280	~4.7 h（论文实测参数）
一层中型商场	10,000 m²	~2,857	~48 h
五层商场	50,000 m²	~14,286	~238 h（约 30 人日）
机场航站楼	200,000 m²	~57,143	~952 h（约 119 人日）

※ 按 RADAR 公开采集密度线性推算，不含建图、对齐、清洗与后续重测。

公开基准数据集的规模，说明这件事有多重

UJIIndoorLoc（2014，西班牙 Jaume I 大学，第一个公开 RSS 数据集）：3 栋楼、4–5 层、约 108,703 m²、933 个参考点、21,049 条样本、520 个 WAP、25 台不同设备、20 位采集者。

为一栋楼建一份能用的指纹库，需要 20 个人、25 台设备、两万多次采样。这就是"不 scale"的具体形状。

指纹会过期 —— 而且是断崖式，不是渐进式

UJI 团队跨越 2 年多（2019-02 → 2021-03）的连续长期数据集：7,446,538 条 Wi-Fi 样本，探测到 2,711 个不同的 AP。核心结论是：定位性能在指纹库与测试数据同一天采集时明显最好，虽然退化随时间累积，但只有当 Wi-Fi 基础设施发生显著变化时才导致大的定位误差。

关键洞察

退化不是均匀老化，是被"AP 换了 / 改了功率 / 装修了"这类离散事件打断的。所以你无法排一个"每季度重测一次"的运维计划 —— 你根本不知道什么时候需要重测。

顺带一个数字

2 年里在一栋楼探测到 2,711 个不同 AP，而 UJIIndoorLoc 建库时只有 520 个。射频环境的换手率本身就是指纹法的敌人。

别说"指纹库每 X 个月就要重测"。UJI 的长期数据集明确说退化是事件驱动的断崖，不是时间驱动的渐变；定量退化曲线在他们的另一篇论文里，不要编具体米数。

指纹定位不是不准，是不划算：RADAR 用 980 平米配 280 个采样点换来中位 2.94 米，26 年后行业实地部署仍然是 5–10 米；而 UJI 那份跨 2 年的数据集告诉你，同一栋楼里冒出过 2,711 个不同的 AP —— 你辛苦画的那张射频地图，从画完那天起就在被 IT 运维、装修队和人流悄悄改写，而且是断崖式改写。

1.5 Slide 1.5

换个思路：如果 WiFi 能直接告诉你「多远」

换尺子的真正理由不是"时间比强度准"，而是 —— 误差的形状变了

c = 299,792,458 m/s ≈ 30 cm / ns　　（英文口径更好记：光速 ≈ 1 foot / nanosecond）

RSSI 的误差随距离放大

∂d/∂RSSI = d·ln10/(10n) —— 与 d 成正比。
10 米处 1 dB 值 0.80 米；30 米处 1 dB 值 2.51 米。

ToF 的误差与距离无关

∂d/∂t = c/2 —— 是个常数。
3.3 ns 的时间戳精度 = 全程 ±1 米，2 米处和 30 米处一样。

图 1.5｜误差-距离对照。这是全 Part 1 想说的那件事，浓缩成一张图。

误差预算：1 米精度到底需要多准的时间戳

时间量	光走的距离（单程）	折算测距精度（÷2）	现实中谁有这个精度
1 μs	300 m	150 m	标准 802.11 TSF 计时器
100 ns	30 m	15 m	—
10 ns	3 m	1.5 m	旧标准时间戳分辨率
6.67 ns	2 m	1 m	← 1 米精度的 RTT 预算
3.3 ns	1 m	0.5 m	← 单个时间戳的精度要求
1 ns	30 cm	15 cm	—
0.1 ns (100 ps)	3 cm	1.5 cm	FTM 时间戳字段的分辨率

1 μs → 0.1 ns，这是 10,000 倍的提升。FTM 就是这一万倍的名字。

说"1 米精度 ≈ 3 ns 时间戳精度"时，要说清是单个时间戳。因为要除以 2，1 米测距误差对应的是 6.67 ns 的 RTT 误差；四个时间戳各有独立误差 σ_t 时，RTT 误差合成为 2σ_t，所以单时间戳预算约 3.3 ns。

但时钟不是唯一瓶颈 —— 带宽才是硬约束

MobiCom'18 原话："20 MHz 信道的 Wi-Fi 信号每 50 纳秒才采样一次，这段时间里信号已经跑了 15 米。"

信道带宽	采样间隔	原始距离分辨率（单程）	对应标准
20 MHz	50 ns	15 m	802.11mc 最低配置
40 MHz	25 ns	7.5 m
80 MHz	12.5 ns	3.75 m	802.11mc 常用
160 MHz	6.25 ns	1.88 m	802.11az
320 MHz	3.125 ns	0.94 m	802.11bk

这解释了三代标准的精度阶梯：1–2 m → 0.4 m → <0.1 m，本质上是 20→160→320 MHz 带宽 + 超分辨算法一起推出来的。

实测证明理论可达，也划出了边界（MobiCom'18，Intel 8260/8265 + 开源驱动）

室外开阔空间、校准后：估计距离落在真实距离 ±1 米以内
室内 LOS、5 GHz、80 MHz：接近米级精度
室内 NLOS、距离 >20 m：不可靠
2.4 GHz、20–40 MHz：不但不准，还会给出"负距离" —— 光速信号不可能提前到达，出现负值说明是硬件偏置而非物理

换尺子的关键不在于"时间比强度准"，而在于误差的形状变了：RSSI 的误差是一个随距离张开的喇叭（10 米处 1σ 区间就有 4.6–21.5 米），而飞行时间的误差是一条水平线（3.3 ns 的时间戳精度 = 全程 1 米）。代价是你得把 Wi-Fi 的时间戳从 1 微秒（150 米！）做到 100 皮秒（1.5 厘米）—— 一万倍。

Part 1 主要来源：ITU-R P.1238-7 · IS-GPS-200 · FCC E911 (2020) · GPS.gov · arXiv:2509.03901（AGH + Intel 综述，180+ 篇）· RADAR, INFOCOM 2000（微软）· MobiCom'18 Rutgers WINLAB · UJIIndoorLoc (2014) · PMC9698900（UJI 两年长期数据集）· SpotFi, SIGCOMM 2015 · Mappedin 2026 指南 · MDPI Sensors 24(5):1416

PART 2

FTM 的物理与数学
四个时间戳的游戏

一条减法算式让收发双方不需要同步时钟，这是 FTM 能在消费级设备上落地的全部秘密。但从"公式成立"到"米级精度"，中间隔着采样率、多径、硬件延迟和统计学四道关。

核心方程
纳秒从哪来
多径这个敌人
硬件延迟常数
Burst 与统计
从距离到坐标

2.1 Slide 2.1

核心方程：为什么不需要时钟同步

一条减法，消掉了整个产业级的难题

图 2.1｜FTM 一次帧交换的四个时间戳。t₁/t₃ 是"计划发射时刻"，硬件可精确给出；t₂/t₄ 需要 ToA 估计 —— 在多径叠加里找出最早到达的那一路径，这才是精度的真正瓶颈。

RTT = (t₄ − t₁) − (t₃ − t₂)　　d = RTT × c / 2

精妙之处在那个减法

(t₄−t₁) 全部由 RSTA 的钟测量；(t₃−t₂) 全部由 ISTA 的钟测量。两个差值各自在同一个时间基准内完成，所以两只钟的绝对偏差被完全消掉。
减去 (t₃−t₂) 的物理含义是扣掉响应方的处理时延 —— 剩下的才是纯粹的双程飞行时间。
结论：收发双方完全不需要同步时钟。这是 FTM 相对 TDoA 的决定性优势 —— TDoA 要求所有基站纳秒级同步，那是要铺光纤、装 GPS 授时的工程；FTM 只要两台设备各有一只稳定的钟。
残余项：两端晶振各 20 ppm 独立误差，本身贡献约 30 cm 的底噪（FTM 协议会估钟差，但残余频偏仍在）。

一个容易忽略的工程细节

n 次帧交换只能算出 n−1 个 RTT。因为第 i 次的 t₁、t₄ 要靠第 i+1 帧带回来 —— 所以一个 burst 最少 2 帧，burst size = 2 实际等于"只测一次、无平均"。

FTM（双程 RTT）

✅ 无需时钟同步
✅ 只需两台设备
✅ 结果与天线增益、发射功率无关
❌ 需要对方配合应答

TDoA / TOA（基站侧）

❌ 要求所有基站纳秒级同步
❌ 铺光纤 / GPS 授时
✅ 终端可以只发不收
→ 在 Wi-Fi 上部署不现实

FTM 的全部聪明之处就在那个减号：它不追求"两只钟走得一样准"，而是让每只钟只测量自己身上发生的那段间隔。把同步问题变成了减法问题 —— 这是它能跑在几十块钱的芯片上，而 TDoA 只能跑在基站机房里的原因。

2.2 Slide 2.2

纳秒从哪里来

时间戳打在物理层，分辨率靠信道估计，上限由带宽决定

第一步：时间戳打在 PHY 层，不是 MAC 层

普通 802.11 的 TSF 计时器分辨率是 1 μs —— 折算成距离是 150 米的量化误差，比整栋楼都大。
FTM 把时间戳定义在 PPDU 前导码（preamble）第一个符号的边界上，由 PHY 直接打点，绕开了 MAC 层的排队和中断抖动。
FTM 时间戳字段的分辨率是 0.1 ns（100 ps），折算 1.5 cm。1 μs → 0.1 ns，一万倍。

第二步：采样率不够，靠信道估计补

这里有个反直觉的矛盾：20 MHz 带宽的接收机每 50 ns 才采样一次，而我们要的是纳秒级。怎么办？

不是直接读采样点，而是用频域信道估计（CSI）反演时域冲激响应：对各子载波的复信道系数做 IFFT，得到多径的时延谱。
再对时延谱的首个峰做插值 / 超分辨（抛物线插值、MUSIC、ESPRIT 等子空间方法），把峰值位置估到亚采样精度。
这就是为什么"采样间隔 50 ns"不等于"精度 15 米"——插值能把单峰的位置估得很准。但它无法凭空分开两条间隔小于原始分辨率的路径，这才是带宽的硬约束所在。

图 2.2｜带宽决定原始距离分辨率。理论支撑是 Cramér-Rao 下界：带宽越大，ToA 估计的方差下界越低。

别把"分辨率"和"精度"混为一谈。20 MHz 的分辨率是 15 米（能分开两条路径的最小间隔），但配合插值，单条干净 LOS 路径的测距精度可以做到 1–2 米。分辨率限制的是"多径能不能分开"，不是"单峰能测多准"。

FTM 的纳秒来自三层叠加：PHY 层打点绕开 MAC 抖动（1 μs → 100 ps 的字段分辨率），信道估计 + 插值把峰位估到亚采样精度，而带宽决定了这套办法在多径面前的上限。三代标准的演进，本质上只做了最后一件事 —— 把带宽从 80 拉到 320 MHz。

2.3 Slide 2.3

多径：FTM 最大的敌人

要找的是"最早到的"，不是"最强的" —— 而这两者经常不是同一条

图 2.3｜多径环境下的信道冲激响应。正确做法是取首达峰，即使它更弱。

三个后果

误差是右偏的，不是高斯的。反射径永远比直射径走得更远，所以多径造成的误差几乎总是正的。NIST 实测走廊场景平均误差 +1.91 m，是系统性高估而非随机噪声。
均值滤波会失效。右偏分布下均值被长尾拽走，正确的统计量是中位数或截尾均值。反过来，"残差恒为正"本身就是多径正偏的诊断指纹（随机噪声的残差应当零均值）。
反直觉：走廊里的 LOS 比穿墙的 NLOS 还差。NIST 实测 —— 室内长走廊 LOS：MAE 2.35 m；隔 1–5 道墙 NLOS：MAE 1.26 m；户外停车场 LOS：MAE 0.45 m。原因是走廊里有"数百条来自墙、地板、天花板、两端墙面的反射路径"，而穿一两道干墙只是衰减 + 一点延迟。

所以判断难度的关键指标不是"有没有直视"，而是"周围有多少强反射面"。金属货架、玻璃幕墙、长走廊比一堵石膏板墙更难对付。

材料导电性决定 NLoS 偏置大小（爱丁堡大学实测，三部手机 RMSE）

遮挡材料	RMSE 范围	RSSI 变化（Pixel 2）	机理
无遮挡 LOS	0.32–0.82 m	−74.3 dBm	基准
木质	0.54–1.25 m	—	低损耗介质
玻璃	0.50–0.90 m	—	低损耗介质
金属	2.26–2.94 m	−84.3 dBm	趋肤效应，直射径几乎完全被反射

多径不是噪声，是偏差。噪声可以靠多测几次平均掉，偏差不行 —— 你测一万次，每一次的反射径都比直射径长同样那一截。这就是为什么 FTM 的工程重点不在"测得更多"，而在"能不能把首径从一堆反射里挑出来"，而这件事的能力上限由带宽决定。

2.4 Slide 2.4

那个恼人的常数：硬件延迟偏置

量级最大、最容易治，也最容易被跳过的一类误差

误差长什么样：斜率 ≈ 1，截距 ≠ 0

射频链路（天线 → LNA → 混频 → ADC → 基带）本身有固定的传播延时，几十纳秒量级。这段延时会原封不动地加进 RTT。
特征是：报出的距离对真值做线性回归，斜率非常接近 1，但截距显著非 0。所以一个常数补偿就能把 RMSE 拉到接近 0。
Android 官方对"理想标定"的定义就是：回归线斜率 1.0、y 轴截距 0.0 m。

但它不是"每 AP 一个 offset"这么简单 —— 是三维的

偏置是（机型 × AP 型号 × 频段）的函数。UPC 实测标定表（单位：米，✗ = 该组合根本测不出来）：

设备	Google AP 5 GHz	Google AP 2.4 GHz	Linksys 5 GHz	Linksys DFS	Linksys 2.4 GHz
Pixel 3a	−0.50	+11.72	−1.52	−1.39	+14.54
Pixel 4a	+1.94	−0.74	+1.28	+1.30	+2.35
Pixel 6 Pro	+1.64	✗	✗	+0.19	✗
Xiaomi Mi 10T	+3.24	+64.91	+2.58	✗	+67.73

67.73 m

小米 2.4 GHz 上的固定偏置 —— 不标定的 2.4 GHz FTM 等于没有

4 倍

同为 5 GHz，Pixel 2 (0.45 m) 与 Redmi K20 (1.85 m) 的偏置差距

≈ 0

常数补偿后各距离上的 RMSE

单边 vs 双边测距

双边（标准 FTM）

responder 把 t₂/t₃ 回传给 initiator，处理时延被精确扣除。精度 1–2 m（标定后）。代价：对方必须支持 FTM 并愿意应答。

单边（非合作测距）

只测"发出 NDP → 收到 ACK"的时间差，对方的内部处理时延 t_proc 未知，只能统计估计。精度 3–4 m。好处：不需要对方支持 FTM。详见 Slide 4.4。

互操作性：第二类"根本测不出来"

Pixel 6 Pro + Linksys Velop 5 GHz 室内信道：采样成功率 0.0000（10 个 burst size 配置全是 0）。
Mi 10T + Linksys 5 GHz DFS：成功率在 0.47–0.91 之间剧烈波动。
Mi 10T 无论请求多少帧，2.4 GHz 最多只返回 11 个 FTM。
研究结论：只有 Google AP 工作在 5 GHz 室内频段时，才能对四款手机都稳定交付样本。而且不是越新越贵越好 —— Pixel 6 Pro 是当时最新款，反而最不稳定。

四类误差里，只有一类不需要任何算法就能治好 —— 系统偏差，而它恰恰是量级最大的那一类（2.4 GHz 上能到 65 米）。工程队伍最常犯的错，是跳过一张标定表，直接去调卡尔曼的参数。

2.5 Slide 2.5

Burst 与统计：为什么一次测量不够

精度不是免费的 —— 它是用信道时间买来的

Burst 是什么

一次 FTM 会话内连续做多帧测量，称为一个 burst；典型配置 8 或 16 帧，标准允许的 burst duration 是 250 μs – 128 ms。
API 返回的是这一批测量的统计量：距离均值 + 标准差 + 成功帧数。
注意 burst size = 2 实际等于"只测一次、无平均"（n 帧只产生 n−1 个 RTT）。

标准差是免费的质量指标 —— 别扔掉它

distanceStdDevMm 大 = 多径严重或信道拥塞，可直接用作定位解算的置信度权重（1/σ²）。这是 FTM 相对 RSSI 的一个隐性优势：它会告诉你自己这次测得准不准。

图 2.5｜burst 平均只有第一步值钱：BS 从 2 到 5 标准差降 30–70%，之后基本平坦。BS>8 的小改善"并不总能 justify 注入网络的额外定位流量"。

精度是用时间买的：厂商侧的同一条曲线

135 cm

1 个 burst 的 P90 测距误差

39 cm

32 个 burst 平均后的 P90 —— 代价是测量时间 ×32

20–30 ms

单个 burst 耗时（含最多 5 次测距）

< 1 s

32 个 burst 的总耗时

时间成本的另一面（实测单次测距耗时）：Pixel 3a 从 BS=2 的 212 ms 涨到 BS=29 的 333 ms；Pixel 6 Pro 380 → 587 ms；Mi 10T 均值 0.86–1.70 s，且标准差高达 1.5 s。

Android `RangingResult` 的关键字段怎么用

字段	含义	怎么用
`getDistanceMm()`	本次会话的距离估计（毫米）	主值，但必须先减去标定偏置
`getDistanceStdDevMm()`	距离标准差	解算权重 1/σ²；也是多径严重程度的诊断信号
`getRssi()`	本次测距的 RSSI	与路损模型距离比对 → LoS/NLoS 判别、离群剔除
`getNumAttemptedMeasurements()` `getNumSuccessfulMeasurements()`	尝试 / 成功帧数	成功率 <90% 应报警（互操作性失效的信号）
`getStatus()`	成功 / 失败原因	区分"AP 不支持"与"信道太忙"

一次 FTM 会话不是"一次测量"，而是几十次测量的统计平均 —— 把 90% 误差从 1.35 米压到 0.39 米，靠的不是更好的算法，而是把 32 个 burst 的时间从信道里买下来。精度、刷新率、吞吐量三者共用同一份预算，你只能挑两个。

2.6 Slide 2.6

从一个距离到一个坐标

三边测量、加权最小二乘、GDOP —— 以及为什么 AP 不能站成一条线

三边测量与加权最小二乘

最少需要 3 个 AP 才能在二维平面上定位（三个圆的交点），实践中建议 4 个以上做冗余与自检。
各次测距质量不同，所以用加权最小二乘，权重取 1/σ²（σ 就是 distanceStdDevMm）—— 这是把 Slide 2.5 那个"免费的质量指标"真正兑现的地方。
工程门限：可见 AP < 3 个的点直接丢弃，而不是给一个假精确的坐标。

GDOP：几何精度因子 —— 布点的第一原则

定位误差 ≈ GDOP × 测距误差　　　精度大致与响应 AP 数量的 平方根 成反比

图 2.6｜三种 AP 布局的几何精度。好布局的特征：密度大致均匀、无死区、不聚簇；凸包角落处效果变差（那里拿不到各方向的约束）。

好消息

室内"为覆盖优化的 AP 布局"通常也适合定位 —— 覆盖要求本身就倾向于均匀铺开、不聚簇。

坏消息

室外或跨楼层就不成立：AP 全聚在楼内、全在用户一侧，几何条件急剧恶化。跨楼层定位的实测 MAE 是 2.34 m，比同层隔墙的 1.26 m 差近一倍。

时间维度：卡尔曼 / 粒子滤波 + PDR

单次解算的点会在房间之间乱跳，必须做时间平滑。但要小心：手机运动时噪声不是高斯的，标准卡尔曼的假设可能不成立。
实测排名（与单历元最小二乘基线比的平均改善）：粒子滤波 32% → 粒子 + RSSI 离群检测 40% → 遗传滤波 + 离群检测 48%（最佳）。
融合 PDR（手机计步 + 陀螺仪）提供连续相对位移，FTM 负责消除 PDR 的累积漂移。这才是产品级方案的形态 —— 详见 Slide 4.3。

从距离到坐标这一步，决定成败的往往不是解算算法，而是那几台 AP 站在哪里。GDOP 是从 GNSS 直接搬过来的概念：测距误差乘上一个由几何决定的放大系数才是最终的定位误差 —— AP 排成一条线时，这个系数会趋于无穷。

Part 2 主要来源：IEEE 802.11-2016 / 802.11az-2022 · arXiv:2509.03901 · MobiCom'18 (Rutgers WINLAB) · Zola & Martin-Escalona, Computer Communications 229 (2025) · MDPI Algorithms 15(12):464（爱丁堡）· NIST RF Ranging (2024) · Qualcomm Wi-Fi Ranging 白皮书 · Horn, Appl. Sci. 14(17):7805 (MIT) · developer.android.com WifiRttManager

PART 3

三代标准演进
802.11mc → az → bk

mc 把测距做成了却忘了上锁，az 把锁装上了却装不进手机，bk 把精度推到 UWB 门口却卡在一道频谱审批题上。三代标准，三种不同性质的困境。

mc (2016)
mc 的三个坑
az (2022)
bk (2025)
三代对照 + 三个时间点
完整会话时序

3.1 Slide 3.1

802.11mc (2016)：把测距塞进一次维护性修订

它以"顺带"的方式进入 Wi-Fi，也就以"顺带"的方式被产业忽略了两年

FTM 是搭"维护性修订"的车进标准的

802.11mc 不是一个功能修订案，而是 REVmc —— 把此前若干修订合并重发的 roll-up 版本，正式名 IEEE 802.11-2016。FTM 作为新增能力被塞在里面一起发布。
这解释了为什么 FTM 早期"没人当回事"：它没有独立的市场名号，没有 Wi-Fi 联盟同步的认证品牌，发布时被淹没在一次例行合并修订里。
直到 2018 年 Android 9 给了它 WifiRttManager API，FTM 才算真的存在。标准发布到能写代码，隔了整整 2 年。

能力边界（权威口径：arXiv:2509.03901 Table 13，作者含 802.11az 任务组主席）

项目	802.11mc
正式标准编号	IEEE 802.11-2016（REVmc roll-up）
发布	2016 年 12 月
带宽	20–80 MHz
频段	2.4 / 5 GHz
典型精度	1–2 m
测距模式	仅点对点（STA ↔ AP）
MU-MIMO / 单 TxOP 内完成	✗ / ✗
MAC 帧保护 / PHY LTF 保护	✗ / ✗ —— 安全机制为零
被动测距	✗
终端 API	Android 9 (2018) Wi-Fi RTT

别给 mc 写"部分支持 160 MHz"。权威对照表口径是 mc 上限 80 MHz，160 MHz 是 az 才引入的 —— 写错了会和 az 的卖点冲突。

这是个可以调的协议：FTM 会话参数的标准取值范围

时间参数

burst duration：250 μs – 128 ms
min delta FTM（连续两帧最小间隔）：以 100 μs 为单位
burst period：以 100 ms 为单位
ASAP=1 时建议首帧 ≤10 ms 内发出

一个工程细节

FTM 帧走 voice access category (AC_VO)，以降低信道接入延迟。

测距会话的信道和带宽不必等于 BSS 的工作信道 —— 这也是"开 FTM 会额外吃信道时间"的原因之一（可能要切信道）。

FTM 的第一次亮相不是发布会，是一次例行的标准合并 —— 它以"顺带"的方式进入 Wi-Fi，也就以"顺带"的方式被产业忽略了整整两年，直到 Android 9 给了它一个 API 才算真的存在。

3.2 Slide 3.2

mc 的三个坑

测不到 · 测得慢 · 测得不可信

坑 1 · 测不到

FTM 是请求-响应模型，完全依赖响应方的配置。手机端有 API 不等于测得到 —— 必须有一台愿意应答的 AP。

实地普查：5 GHz Responder 开启率 0.17%–1.56%（主动探测约 3%）

坑 2 · 测得慢

CSMA/CA 规则照常适用，FTM 帧要和数据帧一样竞争信道。

单次测量 ~30 ms → 一个 AP 每秒最多服务约 30 个终端（还没算普通流量）

坑 3 · 不可信

时间戳明文传输，管理帧不加密，LTF 训练序列采用公开、确定性的结构。

攻击成本：只发帧开头的 LTF 就够了

坑 1 的实证：能力"存在但不可达"

时间	地点	5 GHz Responder 开启率
2020-10	阿布扎比	0.17%
2020-10	波士顿 Back Bay	1.56%（最高）
2020-10	比利时 Hasselt	0.17%
2020-10	苏黎世	0.25%
2021-10	波士顿 Back Bay	1.36%
2021-12	Hasselt	0.26%

2.4 GHz 几乎全为 0.00–0.01%。厂商集中度极高：所有 responder 里 99.78% 是 Google 的设备，initiator 里 61.11% 是三星。爱丁堡 2022 年的调查也印证：面向消费者、官方声明支持 RTT 的 AP 只有 Google Wi-Fi / Nest Wi-Fi Router / Nest Wi-Fi Point 三款。

与其说"AP 默认关闭"，不如说 "FTM 的可用性不取决于终端，而取决于对面那台 AP 有没有被人打开这个开关" —— 这个说法有双重实证支撑，也更准确。

坑 3 的四类攻击（无认证的直接后果）

攻击	机制	后果
窃听 / 被动追踪	估计多次 FTM 交换的差分 ToA，解多点定位方程组	用户被隐蔽跟踪，受害者毫无察觉
伪造 (spoofing)	冒充 AP 返回假时间戳；或在会话中抢先发 ACK	距离结果任意操纵
LTF 前缀攻击	甚至不必发完整 ACK —— 只发帧开头的 LTF 就够了	攻击成本极低
重放 (replay)	拦截并重放合法的 FTM 响应	绕过基于距离的门禁

mc 把"用光速当尺子"这件事做成了，却忘了给尺子上锁 —— 在 mc 里，把距离改短的成本，仅仅是比合法设备早一点发出一段谁都能算出来的固定波形。

3.3 Slide 3.3

802.11az：把尺子锁起来

正式编号 IEEE Std 802.11az-2022 —— 网上普遍写的"az-2023"是发布日期，不是编号

az-2022

正式编号（2022-12-03 批准 / 2023-03-03 发布）

Amendment 4

Enhancements for Positioning

160 MHz

带宽上限（mc 是 80）

< 1 m

典型精度目标（LOS 口径 0.4 m）

别说 az 已"作废"。它的状态显示 Superseded，是因为已合并进 IEEE 802.11-2024 roll-up —— 这是转正，不是废止。

技术核心一：PASN —— 让"未关联也能安全测距"成立

用 authentication 帧派生一份新鲜的共享密钥，使包括 FTM 帧在内的管理流量在尚未关联时就受到保护。目标是建立 PTKSA，供后续 secure LTF 测量使用。
但有两种模式，安全性差别极大（这是最值得讲的"坑中之坑"）：
- 跑在已有的已认证连接之上：复用既有安全上下文，继承底层协议的双向认证 ✅
- 独立运行（无先行认证）：仍能派生密钥、保护管理帧，但标准明确声明不保证双向认证 → 攻击者可以分别与两端各建一份密钥，构成中间人 ⚠️

技术核心二：secure HE-LTF —— 把训练序列本身变成密文

图 3.3｜secure HE-LTF 的密钥派生链。这是 az 唯一真正的新东西。

保护间隔从循环前缀改成 1.6 μs 的零功率 GI：循环前缀本质是把 OFDM 符号尾部复制到头部，天然是一段确定性重复，攻击者可以利用这个结构相关性；改成零功率就抹掉了这个把柄。
PHY 层另一个安全特性：用 64-QAM 取代 BPSK —— 星座点更密，猜中更难。

别写 secure LTF 的具体密钥位长。两篇论文口径不一（128-bit vs AES-256），用"基于 AES 的单次性伪随机序列"最稳。

技术核心三：MU 测距 —— 三种新模式

TB / NTB

触发式与非触发式测距。AP 用 802.11ax MU-MIMO 同时为多个终端测距，最高 8×8。

被动测距

AP 广播帧，终端只接收不发射，基于 TDoA 做双曲定位。并发终端数理论上无上限，且终端无法被追踪。

单 TxOP 内完成

用短的 PHY 层 NDP 替代 mc 的较长 MAC 帧，整个协议压进一个 TxOP → 可扩展性 + 省电 + 大幅减少占用信道时间。

实测：az 相对 mc 到底强在哪（Arista 等，企业级 AP，105 次 FTM 交换/会话）

LOS + 干净 RF：az 结果更一致、方差更低，带宽越大改进越明显
NLOS + 干净 RF：绝对精度改进不显著，但 az 的测量一致性仍优于 mc
NLOS + 重度拥塞多径：40 MHz 及以上带宽时 az 明显优于 mc（归因于 MIMO 有效对抗多径）
作者结论原话："sub 1 meter accuracy seems difficult to achieve in challenging RF environments" —— <1 m 是能力上限，不是现场常态

但决定成败的还是标定，不是协议版本（真值 6 m）

配置	20 MHz	40 MHz	80 MHz
未校准 responder	71.89 m	47.89 m	66.07 m
已校准 responder	10.96 m	7.45 m	6.36 m（误差 0.36 m）

az 的关键不是把精度从 1–2 米推到 1 米以内 —— 而是把那把尺子的刻度本身变成了只有通信双方才知道的密码：攻击者可以听到波形，却无法预先算出下一段该长什么样。

3.4 Slide 3.4

802.11bk (2025)：320 MHz，以及一个中国式死结

正式名 Amendment 3: 320 MHz Positioning（2025-05-28 批准 / 2025-09-05 发布）

bk 干的事情非常单一

把带宽从 160 拉到 320 MHz，其余全部继承 az（包括全套安全机制）。官方 scope 原文写得很直白："enhances the Fine Timing Measurement protocol to make use of 320 MHz wide channels available with the IEEE 802.11be PHY and MAC"。

bk 没有发明新机制，它是一次"把 az 接到 Wi-Fi 7 的 PHY 上"的适配。理论支撑是 Cramér-Rao 下界：带宽越大，ToA 估计的方差下界越低。

为什么这一步是冲着 UWB 去的

	UWB	蓝牙信道探测	Wi-Fi FTM (bk)
带宽	500 MHz / 1 GHz	40 × 2 MHz	320 MHz
功率谱密度	−41.3 / −31.3 dBm/MHz	17 dBm/MHz	17 dBm/MHz（高出近 60 dB）
硬件	需专用芯片	需 BT 5.4+	你家里已经有的那台路由器

UWB 带宽更大，但发射功率谱密度被压得极低（比 Wi-Fi 低约 58 dB），所以作用距离有限（LOS <15 m）、且需要专门硬件。Wi-Fi 到 320 MHz 时带宽已接近 UWB 的量级，而功率高出近 60 dB，硬件还是现成的。

死结：320 MHz 信道只存在于 6 GHz 频段

5 GHz 频段物理上排不下连续 320 MHz。所以 bk 的全部价值，完全押在 6 GHz 对 Wi-Fi 开放这一件事上。

图 3.4｜全球 6 GHz 频谱划分对照（截至 2026-08）。中国是主要经济体中唯一没有把任何 6 GHz 频谱开放给 Wi-Fi 的国家。

中国 6 GHz 政策时间线（本 Part 信息量最大的一页）

2023-07-01：新版《无线电频率划分规定》施行，全球第一个将 6425–7125 MHz 划分给 IMT（含 5G/6G）。
2026-05-08：工信部批复 IMT-2030（6G）推进组 6G 试验频率使用许可，频段正是 6425–7125 MHz、带宽 700 MHz。行业解读：这基本等于把该频段在事实上锁定为国内 6G 商用频段。
5925–6425 MHz（下段）：至今未做明确划分，处于技术试验状态。
产业界正在推动：信通院、华为、中兴、紫光展锐联合提交《关于尽快明确 5925–6425 MHz 用于 RLAN 的建议书》，观点是若 2026 年仍不开放，中国将在 Wi-Fi 8 时代失去话语权。业界普遍把 2026–2027 视为最后窗口。

802.11bk 把 Wi-Fi 测距推进到 UWB 的门口，代价是它把全部筹码押在了 6 GHz 上 —— 于是一个纯粹的物理层精度问题，在中国变成了一道频谱行政审批题。

3.5 Slide 3.5

三代对照 · 以及那三个不同的时间点

标准发布 ≠ 芯片出货 ≠ 你能买到

特性	802.11mc	802.11az	802.11bk
正式编号	IEEE 802.11-2016 (REVmc)	IEEE 802.11az-2022	IEEE 802.11bk-2025
修订案标题	—（维护性 roll-up）	Amendment 4: Enhancements for Positioning	Amendment 3: 320 MHz Positioning
批准 / 发布	2016 年	2022-12-03 / 2023-03-03	2025-05-28 / 2025-09-05
信道带宽	20–80 MHz	20–160 MHz	20–320 MHz
工作频段	2.4, 5 GHz	2.4, 5, 6 GHz	2.4, 5, 6 GHz
典型精度	1–2 m	<1 m	<0.1 m（目标）
一站对多站测距	✗	✓	✓
MU-MIMO	✗	最高 8×8	最高 8×8
单 TxOP 内完成 / LTF 重复	✗ / ✗	✓ / ✓	✓ / ✓
MAC 帧保护	✗	✓	✓
PHY 层 LTF 保护	✗	✓	✓
被动测距	✗	✓	✓
终端 API	Android 9 (2018)	Android 15 (2024, NTB) Android 16 (2025, secure ranging)	截至 2026-08 无公开终端支持

仍未闭合 2025-09 发布，后两格空白标准发布 OS 有 API 真的买得到

图 3.5｜虚线未闭合的那一格，就是整页的论点。

③ 的实测证据（2026 年 3 月的一手硬件测试）

设备	声称	实测结果
Google Pixel 9a	Android 支持 az	未发现任何 secure FTM 功能
Google Nest Wifi Pro	新一代 AP	实际未对外暴露 802.11az 能力
Aruba AP-734	企业级 AP	是极少数公开宣称支持 secure FTM 的产品之一
某开发板（NDA，未点名）	声称完全符合 802.11az	只实现了 PMF，没有 secure HE-LTF，没有任何物理层保护。厂商确认：受架构限制，不支持也不计划支持

这里有一个特别值得点破的层次 —— 三种不同程度的"不可用"：

Pixel 9a / Nest Wifi Pro 是没做；
那块开发板是声称做了但只做了一半（做了 MAC 层的 PMF，跳过了 PHY 层的 secure HE-LTF）；
而 PHY 层恰恰是 az 唯一真正防住距离缩短攻击的地方。

"支持 802.11az"这个说法在市场上是没有约束力的 —— 它可以只意味着"管理帧加密了"，而距离本身依然可以被改。

802.11az 发布已经三年半，安全测距在纸面上完备、在 Android API 里可调用、在你手上的旗舰机里测不出来 —— 标准的时间和产品的时间从来不是同一条时间轴，而 az 卡住的恰恰是它唯一真正新增的那一层：物理层。

3.6 Slide 3.6

一次完整的 FTM 会话

从扫描到上报，以及 PASN 到底插在哪一步

图 3.6｜完整会话时序。PASN 位于阶段 ① 与 ③ 之间，是一次独立的 authentication 帧交换，不属于 FTM 帧序列本身。

这个位置正是攻击面所在

若 ② 被跳过（部署配置允许非认证测距），或用的是独立 PASN（无先行认证），则双向认证不成立，中间人可与两端各建一份密钥。
若攻击者阻断 ③ 中受保护的 FTM Request 并伪造一份未受保护的请求，就能降级到 legacy 测距或抹掉 "Secure HE-LTF Required" 标志 → ④ 里跑的仍是确定性 legacy HE-LTF，MAC 层看起来是保护的，PHY 层已经裸奔。
若阻断 ② 或 ③ 的初始帧，整个安全会话根本建立不起来 → 最简单的 DoS。而且配置越严格（拒绝不安全回落）反而越容易被简单干扰打瘫。

时间开销与刷新率

~30 ms

单次测量典型耗时

~30 个

一个 AP 每秒最多服务的终端数（还没算数据流量）

20–30 ms

单 burst 实测（含最多 5 次测距）

< 1 s

32 个 burst 的总耗时

这正是 az 引入 MU 测距和被动测距的动机：mc 的点对点模型在密集部署下会先撞上信道时间的墙，而不是精度的墙。

精度 ↔ 开销的权衡（Qualcomm 实测，2×2、5 GHz、80 MHz）

平均的 burst 数	90% 分位测距误差	叠加 Kalman 跟踪后
1	135 cm	不到 0.5 秒即可压到 5 cm (P90) / 7 cm (P99)
32	39 cm	不到 0.5 秒即可压到 5 cm (P90) / 7 cm (P99)

功耗

az 官方 scope 明确写入 "reduces wireless medium utilization and power consumption"。
机制：用短的 PHY 层 NDP 替代 mc 的较长 MAC 帧；整个协议压进单个 TxOP；被动测距进一步把功耗降到近乎为零（终端全程只收不发）。

别编 FTM 的绝对功耗数字（mJ / mW）。目前没有可引用的一手实测，用"短 NDP / 单 TxOP / 可完全被动"这类机制性表述最稳。

一次 FTM 会话不是"一次测量"，而是几十次测量的统计平均 —— 把 90% 误差从 1.35 米压到 0.39 米，靠的不是更好的算法，而是把 32 个 burst 的时间从信道里买下来。精度、刷新率、吞吐量三者共用同一份预算，你只能挑两个。

Part 3 主要来源：IEEE SA 官方页面（802.11az/7226、802.11bk/11117）· arXiv:2603.18687（KU Leuven COSIC + JKU Linz，2026-03，含商用设备实测）· arXiv:2511.17935（Arista，mc vs az 实测）· arXiv:2509.03901（AGH + Intel，含 az 任务组主席 Jonathan Segev）· arXiv:2303.03766（TII）· Qualcomm Wi-Fi Ranging 白皮书 · 工信部 2026-05-08 批复 ·《无线电频率划分规定》2023-07-01 施行 · source.android.com/docs/core/connect/wifi-rtt

PART 4

从实验室到现场
工程现实与误差治理

厂商说 21 厘米，学术说亚米，第三方实测说 3 米 —— 三个数字都没撒谎，因为它们回答的根本不是同一个问题。这一部分讲清楚：误差从哪来、怎么治、以及测距这件事的伦理边界在哪。

真实精度三档
误差解剖与治理
混合定位
非合作定位
隐私与安全

4.1 Slide 4.1

真实精度到底是多少

三档精度差了一个数量级，而且每一档的口径都不一样

厂商宣称

受控条件、自家参考设计、P90 口径。
21 cm（室内 LoS，5 GHz/80 MHz，32 burst）
11 cm（点对点）
<10 cm（加 Kalman）

回答的是："芯片能做多好"

学术实测

标定后、算法处理后、静态为主。
67% 亚米级，90.5% RMSE<2 m
前提："只要 AP 偏置做过标定"

回答的是："标定之后能做多好"

消费级实测

未标定、含运动、含遮挡。
MAE 3.04 m，RMS 4.96 m
同期 UWB-A 整体 MAE 0.27 m —— 差 11 倍

回答的是："用户口袋里真实发生了什么"

把学术那档拆开看，才是真相

条件	亚米级比例	样本
全 LoS 环境	95.2%	21 组试验
整体（静态，已标定）	67%	42 组试验
含 NLoS 的环境	38%	21 组里 7 组
一旦人走动起来	22.2%	全部动态试验

NIST 分场景实测：本 Part 最硬的一张表

图 4.1｜整体口径：Wi-Fi RTT MAE 3.04 m / RMS 4.96 m；UWB-A MAE 0.27 m。但下面那个覆盖率反转更重要。

覆盖率反转 —— FTM 真正的工程位置

住宅极限对角 16 组测点：Wi-Fi RTT 全部 16 组出结果，UWB-A 和 UWB-B 只有 6 组能测出来。车库 9 个点，也只有 Wi-Fi RTT 全部给出估计。

精度输、覆盖赢。

最反直觉的一条

真正排第二的影响变量不是"LoS/NLoS"，是多径环境类型。NIST 的解释：走廊里"有数百条来自墙、地板、天花板、两端墙面的反射路径"，而穿一两道干墙只是衰减 + 一点延迟。

"有没有直视"不如"周围有多少强反射面"重要。

为什么 90 分位比均值更有意义

误差分布不是高斯的。爱丁堡实测明确指出：手机运动时的噪声"可能不是高斯的，因此某些假设高斯误差的补偿算法（如卡尔曼滤波）可能不适用"。
在"距离变、位置变"场景，主导误差从波动变成离群点 —— 少量野值虽是少数，"对平均误差的影响是巨大的"。
佐证：金属遮挡下 Pixel 2 的 RMSE 从 0.822 涨到 2.487 m，但标准差只从 2.724 微增到 3.303。均值被尾巴拽走了，方差没怎么动 —— 这是长尾不是整体展宽。
厂商也只报 P90（Qualcomm、Android 平台 KPI 都是 90 分位），这本身就是行业承认均值不可用的证据。

六变量影响排序（按量级与可控性重排）

#	变量	量级证据	是否可工程控制
1	带宽	带宽每翻倍误差约减半；平台 KPI 20→80 MHz 从 8 m 收到 2 m	可（选 5 GHz / 80 MHz）
2	多径环境（走廊/金属/开阔）	同为 LoS，走廊 2.35 vs 户外 0.45；金属遮挡 RMSE 涨 3 倍	部分（布点避金属长廊）
3	AP / 机型标定	未标定偏置最高 67.73 m	完全可控，收益最大
4	机型 × AP × 频段组合	Pixel 6 Pro 配 Linksys 5 GHz 采样成功率 0.00%	可（选型验证）
5	用户运动	静态 σ 0.038–0.205 m → 行走 σ 0.367–1.135 m	不可控，只能靠融合
6	burst 数	BS 2→5 标准差降 30–70%，BS>8 几乎无收益	可，但收益早饱和

FTM 的三档精度不是同一个东西的三种测法，而是三个不同的问题：厂商测的是"芯片能做多好"，学术测的是"标定之后能做多好"，消费级测的是"用户口袋里真实发生了什么"。工程上你只能拿到第三档，除非你自己动手把它拉到第二档。

4.2 Slide 4.2

误差解剖：四类误差、四种药、四个诊断信号

先学会判断自己遇到的是哪一类，再谈治理

图 4.2｜误差四象限。横轴"是否随距离增长"，纵轴"是否零均值" —— 两个问题就能定位到象限，象限决定用哪种药。

为什么标定表是第一优先级

偏置是（机型 × AP × 频段）三维的，不是"每 AP 一个 offset"。Xiaomi Mi 10T 在 2.4 GHz 上的固定偏置是 64.91 / 67.73 米 —— 不标定的 2.4 GHz FTM 等于没有。（完整标定表见 Slide 2.4）

而这一项完全可控、成本最低、收益最大：一次线性回归、一张查找表，就能把 RMSE 拉到接近 0。

burst 平均的收益天花板

Burst Size	2	5	8	14	20	29
Pixel 4a @Google 5G	1.15	0.67	0.68	0.67	0.66	0.66
Pixel 3a @Google 2.4G	3.32	1.09	1.04	1.08	1.25	1.05
Pixel 3a @Linksys 5G	0.92	0.62	0.60	0.59	0.57	0.59
单位：测距标准差 (m)。配套时间成本：Pixel 3a 212→333 ms，Pixel 6 Pro 380→587 ms

BS=5 时收益的 90% 已经到手，BS>8 的小改善"并不总能 justify 注入网络的额外定位流量"。

第六类"误差"：根本测不出来

互操作性失效在论文里罕见但工程上致命 —— Pixel 6 Pro + Linksys Velop 5 GHz 的采样成功率是 0.0000（10 个 burst size 配置全是 0）。而且不是越新越贵越好：Pixel 6 Pro 是当时最新款，反而最不稳定。选型必须做交叉验证矩阵，成功率 <90% 就该报警。

四类误差里，只有一类不需要任何算法就能治好 —— 系统偏差，而它恰恰是量级最大的那一类（2.4 GHz 上能到 65 米）。工程队伍最常犯的错，是跳过一张标定表，直接去调卡尔曼的参数。

4.3 Slide 4.3

混合定位：工程价值 80% 在融合层

测距是原料，融合才是产品

源	提供什么	致命短板
FTM / RTT	绝对距离约束，与天线增益、发射功率无关	单点噪声大、NLoS 正偏、需 ≥3 AP、耗电与信令开销
RSSI	免费、无需 AP 配合、密集可用	分辨率粗；但特别适合当 LoS/NLoS 判别器
PDR	连续相对位移，高频率、零基础设施	误差随时间累积漂移（超过约 70 m 行进距离即不可靠）
地图	硬约束（墙不能穿）	需要底图 —— 但这是零硬件成本的一刀

图 4.3｜融合阶梯。总提升 6.3 倍，其中滤波贡献 2.1 倍，PDR + 地图再贡献 3.0 倍 —— 四倍的提升出自不产生任何一次测距的那一层。

RSSI 融进来的两条独立价值

① 当离群检测器（不参与解算，只判真伪）

把 RSSI 路损模型推的距离和 RTT 距离对比，差太多就丢掉这次测量。
NLoS 环境静态改善 41.3%、动态 14%。

② 当互补特征（真正参与解算）

不确定性区间宽度对比（90% 置信）：混合最紧；纯 RTT 比混合宽 4–50%；纯 RSS 比混合宽 100–200%。
融合不只提精度，更提"置信度可信"。

滤波器选择的实测排名（与单历元最小二乘基线比）

算法	静态平均改善	动态平均改善
粒子滤波	32%	—
粒子滤波 + RSSI 离群检测	40%	—
网格滤波 + RSSI 离群检测	40%	—
遗传滤波 + RSSI 离群检测	49.2%（最佳）	47%

动态场景的关键证据：单历元最小二乘平均 RMSE 2.79 m，且"位置估计不能正确跟随行人路径，多数情况下把行人放进了错误的房间"。作者由此直接得出"PDR 模型在定位算法中的重要性"。这句话就是"80% 价值在融合层"的最佳注脚。

工程分工建议

角色	技术	更新率	职责
绝对锚	FTM / RTT	低（0.2–1 Hz，受 burst 耗时 212 ms–1.7 s 限制）	消除 PDR 漂移，给全局坐标
相对连续	PDR / IMU	高（50–100 Hz）	提供轨迹连续性与航向
真伪判别	RSSI	与 RTT 同步	LoS/NLoS 判定、离群剔除
硬约束	室内地图	静态	禁止穿墙、吸附到通道

把 FTM 当主定位源，会得到一串在房间之间乱跳的点；把 FTM 当 PDR 的锚，才会得到一条能用的轨迹 —— 从 2.58 m 到 0.41 m 的六倍提升里，有四倍出自不产生任何一次测距的那一层。

4.4 Slide 4.4

非合作定位：AP 不开 FTM 的时候怎么办

一个不需要任何 AP 配合的系统，打败了楼里已经装了企业级 FTM AP 的官方服务

不用 FTM，用"数据帧 + ACK"

设备 A 向 B 发一个 Null Data Packet，B 按 802.11 规定必须在 SIFS 后回 ACK —— 这是协议强制的，不需要 B 支持 FTM，也不需要 B 同意。
A 测 NDP 发出到 ACK 收到的时间差 = 2d/c + t_proc。
难点：t_proc（接收方内部处理延时）不上报。FTM 之所以精确，就是因为 responder 会把 t₂/t₃ 告诉你；非合作模式下这一项是未知数 —— 只能用众包学一个 per-AP 的测距模型。
硬件门槛低到离谱：嗅探器就是一块 ESP32，240 MHz 时钟 → 时间分辨率约 4.16 ns（0.625 m 的距离量化步长），对每个可见 AP 每秒约 30 次单向测距。

众包轨迹反推 AP 位置：两阶段设计

阶段一 · AP 发现与定位

行人在户外用 GPS 定位；进楼后 GPS 丢失，改用惯性航迹推算（PDR）继续维持位置，沿途持续对所有可见 AP 做单向测距。多条轨迹的测距集合 → 反解 AP 坐标 → 存为锚点。

每楼层收 10 条行人轨迹，行进估计里程超过 70 m 就截断（超过这个距离 PDR 已不可靠）。

AP 定位误差中位数 1.43 m

阶段二 · 客户端定位

新用户进楼，从数据库取锚点，只靠单向测距做多边定位。检测到 AP <3 个的点直接丢弃（欠定）。

跨 4 栋校园楼实测：均值 3.41 m、中位数 3.06 m、标准差 1.63 m

MIT 的平行路线给出同一条线：单边 RTT 对非合作 AP，"典型 3–4 m"。两个独立来源重合。

图 4.4｜同一批测试点上的四系统对比。PeepLoc 归因于官方方案的两个缺陷：客户端与 AP 之间未校正的设备异质性（= Slide 4.2 的标定问题），以及 AP 坐标本身有误差。

精度上限从哪来（可诚实讲的天花板）

ESP32 时钟量化 0.625 m/tick；t_proc 只能统计估计
PDR 在 70 m 后失效 → AP 锚点标注精度受限（中位数 1.43 m 已经进了客户端误差预算）
依赖两个外生条件：足够的 AP 密度 + 足够的人流
只做了单层；AP 被搬动会失效（可用"PDR 与定位结果发散"检测并触发重建）

隐私争议 —— 这一页必须点破的一层

同一个原语，两种伦理后果

同样的"NDP → ACK"测距，可以让手机定位自己，也可以让第三方定位屋里任何一台开着 Wi-Fi 的设备。Wi-Peep 的原始设定就是用一架带 GPS 的无人机绕楼飞，定位楼里的设备。

四条争议

AP 主人从未同意成为定位锚点，也没有退出机制
众包出的 AP 坐标数据库本身是建筑内部结构的敏感测绘
同一原语可用于被动定位屋内设备（无人机 / 隔墙）
802.11az 的到来并不解决它 —— az AP 部署后其位置反而可以被众包模型推断或精化

非合作定位最刺眼的地方不是它只有 3.41 米，而是它在一栋已经部署了企业级 FTM AP 的楼里，比官方定位服务还准一倍多 —— 这说明合作式定位真正的瓶颈从来不是协议，而是没人去做标定和 AP 测绘；而它最刺眼的伦理后果是，让 AP"配合"这件事，从此变成了可选项。

4.5 Slide 4.5

隐私与安全：能被测量的距离，就能被伪造

今天任何把 FTM 距离当作信任凭证的设计，都是错的

攻击面一：伪造距离 —— 三个层次，加密都拦不住

层	手法	时间粒度	实测效果	加密能防住吗
逻辑层	注入伪造 response 帧	1 ps	目标 15 m，实得 14.20–15.26 m（1000 次会话）	❌ 否
逻辑层	重放整个会话	1 ps	4 m → 1.72 m；20 m → 19.40 m	❌ 否
混合层	重放 + 改 PHY 参数（不改任何时间戳）	100 ns	20 MHz：−3877 m；16-QAM：+916 m；组合可把 20.24 m 压到 2.40 m	❌ 否
物理层	ACK 欺骗	—	把受害者"搬"到攻击者位置，误差 ≤1.47 m；副作用 σ 飙至 11.58 m	❌ 否
物理层	Overshadow 重放 / 提前径注入	1 ps	需功率高于合法信号	❌ 否
信令层	Cicada（预测前导码 / 载荷）	—	预测准确率 99%	❌ 否

这些攻击在帧被加密保护时依然成功 —— WPA3-Personal 也无济于事，因为共享口令可推出密钥；且重放 / 物理层攻击不依赖解密。伪造 2–20 m 的距离，平均偏差不超过 75 cm：攻击者不仅能骗，还骗得很精准。

混合层最精彩的一击：不改时间戳，只改物理层参数

厂商固件的"防线"参差不齐

网卡	接受的距离范围	会话终止	PHY 校验	Min-Delta 校验
Qualcomm Snapdragon 855	[−22.5, +∞]	否	否	否
Intel AC-8260 v31	[−∞, +∞]	否	否	否
Intel AX-200 v55	[−∞, +∞]	否	否	否
Intel AX-200 v57/58	[0, +100]	否	否	是

没有一款做物理层校验，全部允许重传；只有最新的 Intel 固件做 Min Delta FTM 窗口校验。作者的定性判断：这暴露的是协议设计的根本缺陷 —— 能代答 ACK 的对手就能随意改距离，根本解法必须保护 ACK 帧本身。

攻击面二：位置追踪 —— MAC 随机化是漏的

序列号侧信道：802.11 头里的序列号计数器在做地址随机化时没有被正确管理 —— "测量请求帧使用连续的序列号"，把匿名会话关联回同一个客户端因此变得很容易。
能力位指纹：不同发起端支持的 FTM 参数集（ASAP、Min Delta FTM 等）不同，可用来指纹识别设备型号与固件版本。
旁观者拿到的精度和参与者一样好：因为 mc 不对 FTM 帧提供任何机密性，t₁/t₄ 是明文广播的。被动测距实测：Pixel 4 XL + Google AP 组合平均高估仅 0.06 m；Intel AX-200 + WILD AP 组合平均高估 0.49 m。
现实限制：商用网卡拿不到纳秒级到达时间戳 —— 不是硬件不行，是驱动不暴露。一次固件更新就能把这个能力普及。

产业侧：从"探针盒子"到"被动 FTM 观察者"

上一代：Wi-Fi 探针

手机 Wi-Fi 开着就会发 probe request，探针盒子据此拿到 MAC。央视 3·15 曾曝光：商场、超市、写字楼在用户毫不知情下抓取 MAC，有厂商将其转为 IMEI 进而关联手机号。

MAC 随机化普及后这条路基本被打断，行业大规模转向计算机视觉。

FTM 把这件事升级了一个维度

探针盒子只能知道"有一台设备在附近"，而被动 FTM 观察者能知道"这台设备在哪个坐标"，精度到米级。

而且 MAC 随机化在 FTM 场景下本来就是漏的（序列号可关联）。

802.11az 的防护现状：设计得对，落地得糟

机制	解决什么	弱点	2026 年落地
PMF 受保护管理帧	MAC 层时间戳伪造	完全依赖前置密钥；Personal 模式下同口令设备可推出 PTK	开发板有实现
PASN 预关联协商	免关联建密钥	独立模式不保证双向认证 → 中间人	部分
Secure HE-LTF	物理层距离缩短	计数器复用即失效；零功率 GI 射频难做；仿真显示波形贴近甚至超出发射频谱模板	几乎无（连"全兼容"开发板都缺）

落地障碍是硬的，不是懒：零功率 GI 要求发射链在单个 OFDM 符号内快速受控开关，与围绕循环前缀设计的传统射频不兼容；加 secure HE-LTF 要新的基带硅片，是数年设计周期，而高保障用例太少，厂商没有商业动机。

降级攻击：模式级 —— 阻断 secure FTM 请求，逼对方回落到传统 EDCA 测距；波形级 —— 转发未受保护的变体，使 responder 改用确定性训练序列。而配置越严格（拒绝不安全回落），反而越容易被简单干扰打瘫（DoS）。

结论建议（可直接引用）

secure FTM "更适合中低风险应用，而非高保障的访问控制" —— 适合室内导航与分析，不适合作为无钥匙进入或基于距离的授权的主要安全锚。高风险场景必须用 802.1X 企业网做双向认证，并强制要求 PTK 与 secure HE-LTF。

合规速查

中国：《个人信息保护法》把行踪轨迹列入敏感个人信息；GB/T 45574-2025 明确把"连续精准定位轨迹信息"列入。米级 FTM 轨迹 → 单独同意 + PIA + 最小必要 + 加密存储。
欧盟：位置数据属 GDPR 个人数据，需合法性基础（通常是同意），高风险需 DPIA。

802.11az 把安全做对了 —— 但对 2026 年货架上的手机来说它约等于不存在：Pixel 9a 上测不到任何 secure FTM，唯一公开宣称支持的是企业级 AP。所以今天任何把 FTM 距离当作信任凭证的设计（开锁、支付、门禁）都是错的；而反过来，任何以为"关掉定位就不会被定位"的用户也是错的 —— 明文时间戳让旁观者拿到的精度和参与者一模一样。

Part 4 主要来源：arXiv:2509.03901（综述）· MDPI Algorithms 15(12):464（爱丁堡，消费级实测）· NIST RF Ranging (2024-03) · Raja & Groves, J. Navigation (UCL, 2025-12) · Zola & Martin-Escalona, Computer Communications 229 (2025) · HPIPS, Sensors 2020, 20, 6795 · arXiv:2506.18317（UIUC PeepLoc）· Schepers et al., ACM WiSec'21（攻击实证）· Schepers & Ranganathan, PoPETs 2022(2)（隐私）· arXiv:2603.18687（az 安全与落地）· Sensors 2026, 26, 284 · Horn, Appl. Sci. 14(17):7805 (MIT) · GB/T 45574-2025 ·《个人信息保护法》第 28/29 条

PART 5

产业格局
WiFi FTM 在定位战争中的位置

基础设施侧已经就绪，瓶颈全部在终端侧。而占据高价值场景的那一半终端，压根不在牌桌上 —— 这决定了 FTM 会先在哪里跑通。

芯片与 AP 侧
终端侧的结构性问题
四方对比
bk 会终结战争吗
落地场景盘点

5.1 Slide 5.1

芯片与 AP 侧：基础设施已经就绪

墙上那台路由器早就能测距了，问题从来不在这一侧

芯片侧

高通是最积极的推动者，有公开的 Wi-Fi Ranging 白皮书，给出完整的精度-开销曲线（32 burst 平均后室内 LoS 21 cm @P90、点对点 11 cm @P90、叠加 Kalman <10 cm）。这也是全篇引用最多的厂商数据来源。
Intel 的网卡（AC-8260/8265、AX-200 系列）有开源 Linux 驱动支持，是学术界做 FTM 实验的主力平台 —— MobiCom'18 那篇奠基性评测就是在 Intel 8260/8265 上做的。
博通、联发科的芯片进入了 Android 生态的 RTT 支持列表，但公开的技术材料远少于高通。

企业级 AP 侧

HPE Aruba 是唯一公开宣称支持 802.11az secure FTM 的主流 AP 厂商 —— 2026 年 3 月的第三方安全研究里，Aruba AP-734 是"极少数公开宣称支持 secure FTM 的产品之一"。Aruba 也把 FTM 打包成 OpenLocate 定位方案来卖。
Juniper Mist 是重要的对照组：它没有押 FTM，走的是 BLE AoA 路线（AP 内置蓝牙天线阵列）。这条路线成熟、精度 1–3 米、且不依赖终端支持 —— 是 FTM 最现实的对手。
消费级方面，实地普查显示所有开启 FTM Responder 的设备里 99.78% 是 Google 的（Google Wi-Fi / Nest Wi-Fi Router / Nest Wi-Fi Point）。但 Nest Wifi Pro 实测并未对外暴露 802.11az 能力。

已经就绪的部分

芯片能力有了，企业级 AP 有了，标准有了，Android API 有了。边际部署成本接近零 —— 复用已经装在天花板上的 Wi-Fi。

没就绪的部分

存量 AP 绝大多数没打开 responder（实地普查 5 GHz 开启率 0.17%–1.56%）；而更根本的问题在下一页 —— 终端。

FTM 的产业困境很少见：它不缺技术，不缺标准，甚至不缺硬件 —— 它缺的是有人去把那个开关打开。而愿意打开开关的前提，是终端侧有足够多的设备真的会用它。

5.2 Slide 5.2

终端侧：Android 有，iOS 没有

这是 FTM 生态最大的结构性问题

🤖 Android —— 有 API，但支持面窄

Android 9 (2018)：WifiRttManager，支持 802.11mc
Android 15 (2024)：支持 802.11az NTB 测距（API 35）；CHARACTERISTICS_KEY_BOOLEAN_NTB_INITIATOR 查询能力
Android 16 (2025)：加入 secure ranging，并推出统一的 Ranging 模块 —— 把 UWB、蓝牙信道探测、蓝牙 RSSI 测距、Wi-Fi RTT 收进同一套 API
现实骨感：支持 RTT 的机型比例仍然不高，Pixel 系列最可靠

🍎 Apple —— 不在牌桌上

Apple 至今未开放 FTM API，走的是自家 UWB 路线（U1/U2 芯片 + Nearby Interaction 框架）。

这不是疏忽，是战略选择：UWB 精度更高、Apple 能完全控制生态（AirTag、数字车钥匙、精确查找）。

占据高价值场景的一半终端，压根不参与 FTM。

而"支持"这个词在 Android 上也是打折的

2026 年 3 月的一手硬件测试（详见 Slide 3.5）：Pixel 9a 实测未发现任何 secure FTM 功能；某开发板声称"完全符合 802.11az"，实测只做了 MAC 层 PMF，跳过了 PHY 层 secure HE-LTF，厂商确认因架构限制不做也不计划做。

由此推出一个重要判断

FTM 更可能在 B 端先跑通，而不是 C 端手机导航。

因为 B 端场景（资产追踪、AGV、工牌、巡检终端）有三个 C 端没有的条件：终端型号可控（可以只采购支持 RTT 的设备）、AP 可控（自己的场地，想开就开）、可以做标定和测绘（有专人、有预算）。而这三件事恰恰是 Part 4 证明的、决定精度的全部要素。

FTM 的技术曲线和它的商业曲线是脱节的：技术上它已经能做到亚米级，但商业上它卡在"iOS 不玩、Android 支持面窄、AP 开关默认关"这三件互为因果的事情上。谁都不愿意先动 —— 这是典型的双边市场冷启动问题，而 B 端是唯一可以绕开它的地方。

5.3 Slide 5.3

竞争格局：FTM vs UWB vs BLE vs 5G

四条路线，各有一块别人抢不走的地盘

	Wi-Fi FTM	UWB	BLE AoA	5G 定位
典型精度	1–2 m (mc) <1 m (az) <0.1 m (bk 目标)	<0.1 m（LOS）	0.3–1 m（办公室） 1–3 m（一般商用）	1–3 m（室内需密集部署）
现有基础设施	✅ 已装在天花板上	❌ 需专用锚点	⚠️ 需带阵列的 AP/信标	⚠️ 室内需 small cell
终端渗透率	Android 部分机型 iOS 完全没有	高端机（iPhone 11+、部分安卓旗舰）	几乎所有手机（只需能收 BLE）	所有手机（但需网络侧支持）
作用距离（LOS）	50+ m	<15 m	10–30 m	蜂窝级
功率谱密度	17 dBm/MHz	−41.3 dBm/MHz（低 58 dB）	17 dBm/MHz	高
单锚点成本	≈ 0（复用）	高（专用硬件）	中	很高
功耗（终端侧）	中（Wi-Fi 收发）	低（脉冲）	极低	高
典型场景	室内导航、资产盘点、楼宇	数字车钥匙、精确查找、工业高精	客流分析、人员/资产追踪	广域室内外连续定位

三个必须点破的取舍

UWB 的护城河不是精度，是功耗和安全。CCC（Car Connectivity Consortium）数字钥匙标准已经锁定 UWB —— 因为 UWB 的测距在物理层就有抗中继攻击的设计，而 FTM 的 secure HE-LTF 在 2026 年"几乎无落地"（Slide 4.5）。在需要用距离做授权的场景，UWB 是唯一选项。
BLE AoA 是 FTM 最现实的对手，不是 UWB。它便宜、生态成熟、精度 1–3 米，而且最关键的一点是不依赖终端支持 —— 终端只要发 BLE 广播就行，AP 侧负责测角。Mist / Quuppa 已经在楼宇市场跑通了这条路。
FTM 的独特卖点只有一个，但足够强：复用已经装好的 Wi-Fi，边际部署成本接近零。还有一条被低估的优势 —— NIST 实测的覆盖率反转：住宅极限对角 16 组测点，Wi-Fi RTT 全部出结果，UWB 只有 6 组能测出来。精度输、覆盖赢。

这不是一场"谁精度更高"的竞赛。UWB 赢在能当信任凭证，BLE 赢在不需要终端配合，FTM 赢在不需要新硬件。三条护城河互不重叠 —— 所以最终格局大概率是分层共存，而不是谁替代谁。

5.4 Slide 5.4

802.11bk 会终结这场战争吗

短答案：不会。但它会重画分界线

如果 bk 的 0.1 m 兑现

UWB 的精度护城河消失 —— 两者都进入分米级，而 FTM 的作用距离长 3 倍以上、功率谱密度高 58 dB、硬件是现成的。

在纯"我想知道东西在哪"的场景里，UWB 就没有理由了。

但 UWB 短期无法被替代的地方

数字钥匙：CCC 标准已锁定 UWB，汽车厂商的设计周期以年计。
安全测距：UWB 的抗中继攻击是物理层设计，而 FTM 的 secure HE-LTF 连"全兼容"开发板都没实现。
功耗：UWB 脉冲式收发比 Wi-Fi 省电得多，无源标签场景无解。

更有用的预测框架：按"是否需要专用标签"分层

自带 Wi-Fi 手机 · 平板 · AGV · 巡检终端 · 工牌 → 用 Wi-Fi FTM 边际成本 ≈ 0，只要 AP 开了 responder bk 落地后精度进分米级被定位物无源 / 无 Wi-Fi 托盘 · 工具 · 商品 · 车钥匙 · 行李 → 用 UWB / BLE 标签必须贴一个东西上去，那就选最优的那个数字钥匙场景 UWB 已被标准锁定分界线不是精度，是「有没有必要额外贴一个标签」

真正该盯的三个变量（而不是精度数字）

① 6 GHz 频谱政策

320 MHz 信道只存在于 6 GHz。中国 6425–7125 已划给 IMT，5925–6425 未定 —— bk 的 0.1 m 在中国目前没有落脚点。业界视 2026–2027 为最后窗口。

② iOS 是否开放 FTM

这是最大的单一变量。一旦开放，FTM 的终端渗透率一夜之间翻倍，AP 厂商打开开关的动机随之出现。Apple 目前没有任何迹象要这么做。

③ az 芯片真实出货量

不是"宣称支持"，而是PHY 层 secure HE-LTF 真的做进硅片的出货量。这需要新的基带设计，数年周期。

一个反向风险：如果 UWB 因数字钥匙普及而边际成本趋近于零（每台手机、每辆车都标配），FTM"不用新硬件"的成本优势会被侵蚀 —— 那时 UWB 也变成了"已经装好的东西"。

bk 不会终结战争，因为战争的分界线从来不在精度那条轴上。真正的分界线是"被定位的那个东西，自己会不会说话" —— 会说话的（有 Wi-Fi 的）用 FTM，不会说话的贴标签，而贴什么标签取决于你要不要用这个距离去开锁。

5.5 Slide 5.5

谁在真的用它：落地场景盘点

按"需要什么精度、能接受什么成本、当前用什么方案"三问，找 FTM 的真实切入点

场景	精度需求	成本容忍度	当前主流方案	FTM 的机会
仓储物流 AGV / 叉车定位、库位核验	0.1–0.5 m （库位级）	高	UWB、二维码地标、SLAM	⚠️ 精度暂不够，bk 落地后是最佳场景（AGV 都带 Wi-Fi）
办公楼宇工位/会议室占用、访客引导、应急疏散	1–3 m （房间级）	中	BLE 信标、Mist BLE AoA、人工	✅ 最现实的切入点 —— 精度够、AP 自己的、终端可控
零售商品级导航、客流热力	货架级 <0.5 m （导航 1–2 m）	低（要算 ROI）	Wi-Fi 探针（已被 MAC 随机化打断）、计算机视觉	⚠️ 客流分析有隐私红线；商品级导航要等 bk
制造业工具与在制品追踪	0.3–1 m	高	UWB、RFID	⚠️ 多为无源资产，属于"要贴标签"那一侧
医院设备/病床/人员定位	1–3 m （房间级）	中高	BLE 信标、RTLS 专用系统	✅ 房间级够用，且医院 Wi-Fi 覆盖本来就密
C 端室内导航商场 / 机场找路	1–3 m	极低	地图 App 的 Wi-Fi 指纹 + PDR	❌ iOS 缺席使其无法成为主方案

三条选择场景的经验规则

1️⃣ 先看终端型号能不能控。能控（企业采购、自有设备）→ FTM 可行；不能控（面向公众的 C 端）→ FTM 只能当辅助源，不能当主方案。
2️⃣ 再看精度需求落在哪一档。房间级（1–3 m）→ 今天的 mc 就够；亚米级 → 需要标定 + 融合 + LoS 环境；分米级 → 等 bk 和 6 GHz。
3️⃣ 最后看被定位的东西有没有 Wi-Fi。没有 → 这个场景根本不属于 FTM，别硬上。

FTM 最真实的切入点不是那些精度要求最高的场景（那些是 UWB 的），也不是用户最多的场景（那些卡在 iOS 上），而是"终端可控 + 精度要求房间级 + AP 是自己的"这个交集 —— 办公楼宇和医院。听起来不性感，但那是唯一三个条件同时成立的地方。

Part 5 主要来源：Qualcomm Wi-Fi Ranging 白皮书 · arXiv:2603.18687（Aruba AP-734 / Pixel 9a 实测）· NIST RF Ranging (2024)（UWB 对比与覆盖率反转）· arXiv:2509.03901 Table 2（四方带宽/PSD/精度对比）· source.android.com/docs/core/connect/wifi-rtt · Android 15/16 发布说明 · Car Connectivity Consortium 数字钥匙标准 · Schepers FTM 无线普查数据集（AP 开启率）

PART 6

动手玩起来
从一台手机到一套系统

几十块钱、两块开发板，一个下午就能把 FTM 的噪声量级摸清楚。而从这个 Demo 到能用的系统，中间隔着的 80% 工作量既不是算法也不是协议。

最低成本实验
ESP-IDF 跑通
Android Demo
Demo 到系统
未来三主线
三句话总结

6.1 Slide 6.1

最低成本的第一次实验

先建立对噪声量级的直觉，再决定要不要押注

方案 A · 手机 + AP（最快）

一台支持 RTT 的 Android 手机 —— Pixel 系列最可靠（Pixel 3a/4a 在文献里表现最稳）
一台开启 FTM Responder 的 AP —— Google Wi-Fi / Nest Wi-Fi Router / Nest Wi-Fi Point 是官方声明支持 RTT 的消费级选择
App：WifiRttScan（Google 官方示例）
⚠️ 优先用 5 GHz。2.4 GHz 的偏置可能有几十米（见 Slide 2.4）

方案 B · 两块 ESP32（最省钱）

两块支持 FTM 的 ESP32 系列开发板，成本几十元
一块配成 AP（FTM responder），一块配成 station（FTM initiator）
跑 ESP-IDF 自带的 examples/wifi/ftm
好处：ESP 之间互测比 ESP ↔ 手机稳定得多 —— 跨厂商互操作性是主要的坑

ESP32 系列里不是每一款都支持 FTM（初代 ESP32 不支持），且 initiator / responder 角色的支持情况因型号而异。下单前务必核对 ESP-IDF 当前版本的芯片能力表。

第一步要看的三个数字

distance

距离本身 —— 先在已知真距下看它偏了多少（这就是你的标定常数）

stdDev

标准差 —— 静止时应在 0.04–0.21 m，行走时会涨到 0.37–1.14 m

成功率

成功/尝试帧数比 —— 低于 90% 说明这个机型×AP 组合有问题

先别急着写定位算法。把手机放在距 AP 1 米、3 米、5 米、10 米的地方各采一组，画一张"报出距离 vs 真实距离"的散点图 —— 你会立刻看到那条斜率≈1、截距≠0 的直线，那就是 Part 2 讲的系统偏差。

这个实验的价值不在于得到什么数字，而在于亲眼看到误差的结构：一条平移的直线（可标定）、一片抖动（可平均）、几个野值（要剔除）。看过一次之后，Part 4 讲的所有治理手段都会变得显而易见。

6.2 Slide 6.2

用 ESP-IDF 跑通 FTM

官方示例就在 examples/wifi/ftm

核心 API 骨架

// 1. 注册 FTM 报告事件
esp_event_handler_register(WIFI_EVENT, WIFI_EVENT_FTM_REPORT, &ftm_report_handler, NULL);

// 2. 配置并发起一次 FTM 会话
wifi_ftm_initiator_cfg_t ftmi_cfg = {
  .resp_mac = { /* responder 的 MAC */ },
  .channel = 6,
  .frm_count = 32,  // burst 内的帧数：0/8/16/24/32/64
  .burst_period = 2, // 单位 100 ms
};
esp_wifi_ftm_initiate_session(&ftmi_cfg);

// 3. 在事件回调里读结果
wifi_event_ftm_report_t *e = (wifi_event_ftm_report_t *) event_data;
e->rtt_raw / e->rtt_est  // 往返时延（ns）
e->dist_est          // 估计距离（cm）
e->ftm_report_data     // 每帧的详细数据

※ API 签名以你安装的 ESP-IDF 版本为准（近几个大版本有过字段调整），务必对照本地 esp_wifi.h 与示例 README。

参数怎么调

参数	作用	建议
`frm_count`	一个 burst 里的 FTM 帧数	先试 8 或 16。Part 2 已证明收益在 5 帧左右就饱和，32 帧只是把时间成本翻倍
`burst_period`	burst 之间的周期（100 ms 为单位）	按你的刷新率需求定；连续测距对功耗和信道都是负担
`channel`	测距使用的信道	优先 5 GHz，带宽越大分辨率越好

标定流程（这一步不能省）

1️⃣ 在空旷处、LOS 条件下，把两块板固定在 1 / 3 / 5 / 10 米四个已知距离上
2️⃣ 每个点采一组（至少几十次会话），记录 dist_est 的中位数（不是均值 —— 分布右偏）
3️⃣ 对"报出距离 vs 真实距离"做线性回归，斜率应接近 1，截距就是你的标定常数
4️⃣ 把这个常数存进查找表，按（设备型号 × 对端型号 × 频段）三维索引

跨厂商互操作性是最大的坑。ESP ↔ ESP 通常很稳，ESP ↔ 手机、手机 ↔ 第三方 AP 就可能出现"成功率 0%"这种情况（Part 4 有实测：Pixel 6 Pro + Linksys Velop 5 GHz 完全测不出来）。换组合之前先测成功率，别先写算法。

把两块 ESP32 放在桌上互测一小时，你会得到比读十篇论文更扎实的直觉：原来那个"距离"是会跳的，原来它天生偏了 1.5 米，原来换个信道数字就全变了。这些都是文档不会告诉你的东西。

6.3 Slide 6.3

写一个最小的 Android 定位 Demo

从 N 个距离解算一个坐标，代码不到 100 行

前置检查与权限

// AndroidManifest.xml
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-feature android:name="android.hardware.wifi.rtt" />

// 运行时检查设备是否真的支持
val ok = packageManager.hasSystemFeature(PackageManager.FEATURE_WIFI_RTT)
val rtt = getSystemService(Context.WIFI_RTT_RANGING_SERVICE) as WifiRttManager
if (!rtt.isAvailable) { /* 用户可能关了定位开关 */ }

发起测距

// scanResults 来自 WifiManager.scanResults，先筛出支持 RTT 的 AP
val aps = scanResults.filter { it.is80211mcResponder }

val req = RangingRequest.Builder()
    .addAccessPoints(aps)  // 一次最多 RangingRequest.getMaxPeers() 个
    .build()

rtt.startRanging(req, mainExecutor, object : RangingResultCallback() {
  override fun onRangingResults(results: List<RangingResult>) {
    val good = results.filter { it.status == RangingResult.STATUS_SUCCESS }
        .map { r ->
            // ① 减掉标定偏置　② 用 stdDev 当权重
            Measure(
              d = r.distanceMm / 1000.0 - biasOf(r.macAddress),
              w = 1.0 / (r.distanceStdDevMm / 1000.0).pow(2),
              ap = apCoordOf(r.macAddress))
        }
    if (good.size >= 3) solve(good)  // 少于 3 个直接丢弃，别硬解
  }
  override fun onRangingFailure(code: Int) { /* 区分 AP 不支持 vs 信道太忙 */ }
})

※ Android 15+ 若要用 802.11az NTB，需查询 CHARACTERISTICS_KEY_BOOLEAN_NTB_INITIATOR；Android 16 起有统一的 Ranging 模块。API 细节以官方文档当前版本为准。

加权最小二乘解算的思路（30 行）

已知 N 个 AP 坐标 (xᵢ, yᵢ) 和测距 dᵢ，求 (x, y) 使 Σ wᵢ·(√((x−xᵢ)²+(y−yᵢ)²) − dᵢ)² 最小。
做法：把第一个 AP 作为参考做线性化（两两相减消掉二次项），得到超定线性方程组 A·p = b，用加权最小二乘 p = (AᵀWA)⁻¹AᵀWb 求解。
权重 W = diag(1/σᵢ²) —— 这就是把 distanceStdDevMm 兑现成精度的地方。
拿到初值后可以再做几步 Gauss-Newton 迭代收敛。

可视化：把误差看出来

把 AP 位置和解算点画在楼层平面图上，再画出误差椭圆（协方差矩阵的特征向量）。你会立刻看到 Slide 2.6 讲的 GDOP 效应 —— 走到 AP 凸包的角落，椭圆就会被拉成长条。

这个 Demo 会给你一个残酷但有用的第一印象：点在房间之间乱跳。这不是你写错了，这是 Part 4 说的"单历元最小二乘平均 RMSE 2.79 m，多数情况下把行人放进了错误的房间"。看到这个跳动，你才会真正理解为什么融合层占 80% 的工程价值。

6.4 Slide 6.4

从 Demo 到可用系统还差什么

算法只占工作量的 20%，测绘与运维占 80%

最贵的一步：AP 位置的高精度测绘

测绘误差直接进入定位误差，而且是不可消除的系统性误差 —— 你的定位精度不可能优于 AP 坐标的精度。
这往往是全项目最贵的一步：需要人工逐台测量、对齐到统一坐标系、录入数据库。一栋楼几百台 AP，就是几百次测量。
反例证据：Part 4 里 PeepLoc 打败 Aruba 官方方案的两个归因之一，就是"OpenLocate 给出的 AP 坐标本身有误差"。连企业级方案都栽在这一步。
替代路线：众包反推 AP 坐标（中位误差 1.43 m）—— 省了人力，但精度天花板也就到这儿了。

运维层：三件必须做的事

标定表管理

（机型 × AP × 频段）三维查找表。新机型上市要补，新 AP 型号要补。这张表就是你的核心资产。

AP 变更检测

AP 被搬动 / 更换 / 改功率 → 定位结果会与 PDR 预测发散。用这个发散量当监控信号，自动触发重测。

坐标系统一

楼层平面图、AP 坐标、地图约束、PDR 轨迹必须在同一个坐标系里。多楼层还要处理层高与楼层判定。

产品级权衡：刷新率 / 功耗 / 精度

用途	需要的刷新率	可接受的精度	工程含义
实时步行导航	~1 Hz	1–3 m	必须融合 PDR，FTM 只做低频锚点（单次测距 212 ms–1.7 s，硬顶在这里）
房间级占用检测	0.1 Hz	3–5 m	mc + 简单三边即可，功耗很低
资产盘点	0.01 Hz	1–3 m	可以慢慢测、多 burst 平均，精度换时间在这里最划算
安全授权（开锁）	按需	—	❌ 别做 —— 见 Slide 4.5，FTM 距离可被任意伪造

一句话结论：算法只占工作量的 20%，测绘与运维占 80%。这不是贬低算法，而是说 —— 如果你的团队把时间全花在调滤波器上，而没有一张标定表和一份准确的 AP 坐标，那么再好的算法也救不了这个系统。而这恰恰是 PeepLoc 那个"非合作系统打败官方方案"的案例想说的全部。

6.5 Slide 6.5

未来五年的三条主线

以及一个反向风险

主线一 · bk + 6 GHz

802.11bk 已于 2025 年发布，320 MHz 带宽把精度目标推到 <0.1 m。

但完全取决于 6 GHz 频谱政策。中国已把 6425–7125 划给 IMT、5925–6425 未定 —— 这一条在国内目前没有落脚点，业界视 2026–2027 为最后窗口。

该盯的不是芯片，是工信部的文件。

主线二 · 感知与定位合流

802.11bf（WLAN Sensing）让同一套 Wi-Fi 硬件既能定位、又能感知 —— 呼吸检测、跌倒告警、房间内人数统计、手势识别。

技术底座是同一个：都靠 CSI（信道状态信息）。FTM 测的是"你在哪"，bf 测的是"你在干什么"。

这可能比精度提升更能打开市场。

主线三 · 终端生态破局

iOS 是否开放 FTM，是最大的单一变量。

一旦开放，终端渗透率一夜翻倍，AP 厂商才有动机打开那个开关，整个双边市场才能启动。

Apple 目前没有任何迹象要这么做 —— 它在 UWB 上的投入（U 系列芯片、Nearby Interaction、数字车钥匙）都指向相反方向。

反向风险：如果 UWB 因数字钥匙普及而边际成本归零 —— 每台手机、每辆车、每个门锁都标配 UWB —— 那么 FTM"不用新硬件"的核心优势就被侵蚀了，因为那时 UWB 也变成了"已经装好的东西"。CCC 数字钥匙标准锁定 UWB 这件事，长期看比任何精度指标都重要。

如果只跟踪三个指标

① 工信部对 5925–6425 MHz 的划分决定 —— 决定 bk 在中国有没有戏
② Apple 是否在某个 iOS 版本里出现 FTM 相关 API —— 决定 C 端有没有戏
③ 真正把 PHY 层 secure HE-LTF 做进硅片的芯片出货量（不是"宣称支持 az"）—— 决定 FTM 能不能进安全场景

这三条主线里，只有第二条（802.11bf 感知）是纯技术演进，另外两条都是政策和商业决策。这很说明问题：FTM 的天花板已经不是物理问题了。光速这把尺子早就够用，卡住它的是频谱审批表和一家公司的产品路线图。

6.6 Slide 6.6

三句话记住 WiFi FTM

① 它的本质是

把每一颗 Wi-Fi 芯片变成一把纳秒级的尺子，用光速做刻度。
四个时间戳、一条减法，让收发双方不需要同步时钟 —— 这是它能跑在几十块钱芯片上的全部秘密。

② 它赢在 / 输在

赢在不用新硬件；输在终端支持不全、多径难缠、AP 要配合。
而这三个"输"里，只有多径是技术问题 —— 另外两个是商业问题，且互为因果。

③ 现在该做的

如果你在做室内空间相关的产品 —— 买一台 Pixel 和两块 ESP32，先把噪声量级摸清楚，再决定要不要押注。
一个下午的实验，胜过读十篇论文。你需要亲眼看到那条平移的直线、那片抖动和那几个野值。

如果只带走一个判断

FTM 已经不是一个技术问题了。光速这把尺子早就够用 —— 1 纳秒 30 厘米，802.11bk 的标准写得明明白白。真正卡住它的是三件跟物理无关的事：一家公司不开放 API，一份频谱划分文件，以及成千上万台从没被人打开过那个开关的路由器。

所以判断 FTM 前景的正确方式，不是看下一代标准能到多少厘米，而是看这三件事有没有松动。

Part 6 主要来源：ESP-IDF examples/wifi/ftm 与 esp_wifi.h · developer.android.com WifiRttManager / RangingRequest / RangingResult · source.android.com/docs/core/connect/wifi-rtt · Google WifiRttScan 示例 App · IEEE 802.11bf (WLAN Sensing) · Car Connectivity Consortium · arXiv:2506.18317（AP 测绘成本的反例证据）

附 A 附录 A

术语速查表

缩写	全称	一句话解释
FTM	Fine Timing Measurement	802.11mc 引入的精细时间测量协议，本篇主角
RTT	Round-Trip Time	往返时延；Android 把 FTM 能力叫做 Wi-Fi RTT
ToF	Time of Flight	飞行时间（单程）；RTT 是双程，两者差一个 ÷2
ToA / ToD	Time of Arrival / Departure	到达 / 发出时刻。t₂、t₄ 需要 ToA 估计
TDoA	Time Difference of Arrival	到达时间差定位，需基站间同步 —— FTM 正是为了绕开它
AoA / AoD	Angle of Arrival / Departure	测角度定位，需天线阵列（BLE 5.1、SpotFi 走这条路）
CSI	Channel State Information	信道状态信息，各子载波的复系数；ToA 超分辨和 WLAN Sensing 的共同底座
LTF	Long Training Field	前导码里的长训练字段，ToA 估计所依赖的已知波形
HE-LTF	High Efficiency LTF	802.11ax 的 LTF；az 的 secure HE-LTF 把它变成伪随机的
NDP	Null Data Packet	空数据包；az 用它替代较长的 MAC 帧以省时省电
PASN	Pre-Association Security Negotiation	预关联安全协商，让"未关联也能安全测距"成立
PMF	Protected Management Frames	受保护管理帧（802.11w），az 安全的第一层
PTK / KDK	Pairwise Transient Key / Key Derivation Key	成对临时密钥 / 密钥派生密钥，secure LTF 密钥链的起点
LMR	Location Measurement Report	测量结果上报帧
GDOP	Geometric Dilution of Precision	几何精度因子；定位误差 ≈ GDOP × 测距误差
LoS / NLoS	Line of Sight / Non-Line of Sight	视距 / 非视距
PDR	Pedestrian Dead Reckoning	行人航迹推算（计步 + 陀螺仪），FTM 的黄金搭档
TSF	Timing Synchronization Function	802.11 的标准计时器，分辨率 1 μs = 150 米
TxOP	Transmission Opportunity	传输机会；az 把整个测距协议压进单个 TxOP
UWB	Ultra-Wideband	超宽带，FTM 在精度上的主要对手

附 B 附录 B

关键文献与标准清单

标准

IEEE 802.11-2016（REVmc）—— FTM 首次引入
IEEE Std 802.11az-2022, Amendment 4: Enhancements for Positioning —— 2022-12-03 批准 / 2023-03-03 发布（现已并入 802.11-2024）
IEEE Std 802.11bk-2025, Amendment 3: 320 MHz Positioning —— 2025-05-28 批准 / 2025-09-05 发布
ITU-R P.1238-7 —— 室内传播模型（路径损耗系数 N、阴影衰落 σ 的权威出处）
IS-GPS-200 —— GPS L1 C/A 最小接收功率规范

核心论文（按重要性）

文献	贡献
arXiv:2509.03901 Kosek-Szott 等（AGH）+ Jonathan Segev（Intel，802.11az 任务组主席）	最权威的综述，30 页覆盖 180+ 篇；三代能力对照表、UWB/BTCS/Wi-Fi 横向对比的原始出处
arXiv:2603.18687 Antonijević 等（KU Leuven COSIC + JKU Linz），2026-03	最新、最有信息量的一手实测：az/bk 安全机制细节 + 商用设备实测（Pixel 9a 无 secure FTM、开发板只做 PMF）
arXiv:2511.17935 Rajendran 等（Arista Networks），2025-11	mc vs az 定量对比；校准前后的 71.89 m → 6.36 m
Schepers et al., ACM WiSec'21	FTM 安全奠基性工作：距离可任意伪造，加密拦不住
Schepers & Ranganathan, PoPETs 2022(2)	隐私分析：MAC 随机化被序列号侧信道击穿；被动观察者精度等同参与者
arXiv:2506.18317（UIUC PeepLoc）	非合作测距 + 众包 AP 定位，3.41 m 打败楼里的企业级 FTM 方案
NIST, 2024-03 A Performance Comparison of Wi-Fi RTT and UWB for RF Ranging	权威中立的分场景对比；覆盖率反转的证据
MDPI Algorithms 15(12):464（爱丁堡大学）	消费级设备四类误差分解、机型差异、材料遮挡实测
Computer Communications 229 (2025) 107980（UPC）	burst size 收益曲线、（机型×AP×频段）标定表、互操作性失效
MobiCom'18（Rutgers WINLAB + GM）	开源平台上的 FTM 精度评测，"1 ns = 1 foot"的经典表述
RADAR, INFOCOM 2000（微软研究院）	指纹定位开山之作，中位 2.94 m 的原始出处

工具链与文档

Android：source.android.com/docs/core/connect/wifi-rtt（平台 KPI）· developer.android.com 的 WifiRttManager / RangingRequest / RangingResult
ESP-IDF：examples/wifi/ftm · esp_wifi_ftm_initiate_session() · WIFI_EVENT_FTM_REPORT
Linux：wpa_supplicant 的 FTM 支持 · Intel 网卡开源驱动（学术实验主力平台）
厂商：Qualcomm Wi-Fi Ranging 白皮书（精度-开销曲线的原始出处）

写这份 PPT 时最重要的一条纪律：所有精度数字都必须带来源、测试条件（带宽、LoS/NLoS、设备型号）和统计口径（均值 / 中位数 / 90 分位）。不接受无条件的"精度 1 米"这类说法 —— 因为正如 Part 4 证明的，同一个"精度"词在厂商、学术和消费级三种语境下指的根本不是同一件事。

目录

用光速当尺子：WiFi FTM 精细时间测量完全指南

定位技术全景为什么你的手机在商场里找不到自己