摘要

  • RFC 9699 把移动 XR 描述为一条耦合管线：跟踪、世界模型获取、注册、图像生成、传输与显示，必须共同追上仍在移动的用户。
  • 边缘卸载可以减轻设备的热量与电池压力，但无线波动、边缘排队、执行和帧返回都在消耗同一份 motion-to-photon 预算；地理接近或平均值达标不是端到端收据。
  • RFC 预期多项运行参数呈重尾特征，流量具有突发性。管理层需要以尾部为中心，把每个显示帧同姿态、模型状态、计算过程和实际体验关联起来。

健康平均值里的那次失配

一名参观者戴着 XR 头显转向拱门。仪表盘显示，过去一分钟设备到边缘的平均服务时间是 11 毫秒。绝大多数画面平滑返回，只有一帧在短暂的边缘突发之后排队。请求发出时，它所使用的头眼姿态仍然正确；返回时，人已经转过头，覆盖层落在拱门旁边。

平均值没有撒谎。它只是不是这次体验所需要的证据。

RFC 9699 是 2024 年 12 月发布的 IETF Informational 文档。它以游客在伦敦塔内行走为例，应用持续生成历史场景并叠加到变化中的真实视野。场景处理不是一个不可分的“算力任务”。RFC 将它拆成连续三步：跟踪、获取现实世界模型、注册。跟踪要处理头部、眼睛和视野内物体的六维姿态；模型可以由客户端跟踪与建图和服务器端定位共同生成；注册则对齐虚实对象的坐标、亮度与颜色，还要处理遮挡、镜头畸变、模糊和噪声。最终的 situated visualization 还必须随着眼睛和头部继续移动而维持时间一致性。

这也是卸载的价值与风险同时出现的地方。实时视频处理和新画面生成会消耗电池、制造热量；远端云难以进入文档所引用的毫秒级时限，因此算力被放到更近的边缘。但工作负载并未消失，它只是被分给设备、无线链路、边缘准入与队列、CPU/GPU 执行、模型存储、返回传输和显示。

一个时限，多个时钟

RFC 9699 为该用例引用的 motion-to-photon 上限是 20 毫秒，最好为 7–15 毫秒。它还指出，显示刷新和像素切换可能消耗 20 毫秒预算中的 12–13 毫秒，只给传感器处理、图形渲染与设备—边缘往返留下 7–8 毫秒。这些数字是用例要求与被引用研究的结果，并非所有产品的保证；真正重要的是它揭示的算术：传输时延不能脱离计算耗时与姿态年龄单独管理。

RFC 把卸载后的响应时间定义为计算与 RTT 之和。无线团队可以完成自己的指标，而 GPU 队列破坏体验；边缘团队可以报告执行很快，而上行因为补传视觉特征而变慢；调度器可以挑选“最近”的节点，但需要的世界模型尚未加载。网络 SLO 内到达的帧，也可能注册在旧几何或旧姿态上。每一个事实都可能正确，却不能替代下一层证据。

移动还会改变这些边界。文档指出，用户行走时无线带宽与时延会波动，链路可能失败，软件组件之间的逻辑关系也会频繁变化。边缘资源比远端云有限，游客突然集中就可能压垮节点。因此，“接近”应当表示一条当下能够满足应用需求的短而高容量路径，而不是地图距离、跳数或部署时的一次测量。

尾部本来就是产品的一部分

RFC 预期 buffer occupancy、吞吐量、客户端—服务器时延和可变传输时间具有重尾特征，并警告样本均值可能稳定得太慢，方差与标准差可能不适合作为这些参数的指标。它还描述了大突发之间夹着长空隙、长程相关、自相似和毫秒级突发。其用例中的 6DoF 视频或点云需要 200–1000 Mbps；突发与可变排队结合，会形成可能加剧晕动不适的抖动。

这不意味着所有 XR 轨迹都有相同分布，却足以否定一种审批习惯：只看平均值。11 毫秒的平均数，完全可能与少量“错过所属姿态”的帧同时存在，而且这些帧往往聚集在切换、客流涌入、模型调取或 GPU 争用期间。

可辩护的收据应从帧身份开始，保留传感器样本及时间戳、卸载决策、无线与切换观测、边缘准入/排队/执行区间、模型与场景状态版本、渲染完成、下行交付、最终注册所用姿态、显示时刻和 QoE 结果。未观测 是合法状态；“边缘成功”不能填满空白。

RFC 没有替任何部署签字

文档提出动态 XR 服务器放置、移动性支持与能耗管理等 managed edge-cloud 能力，也列出确定性网络、可靠无线、差分服务和逐连接 QoS 等可能支持。它同时提醒，技术可行不等于经济可行。

RFC 没有定义通用逐帧收据，没有认证任何具名部署，也没有保证预测补偿一定避免不适，更没有证明地理上接近的服务器一定符合尾部时限。最稳妥的结论更窄：只有把整条耦合路径作为产品运行，边缘 XR 才谈得上可验证的连续性。

来源

一手记录：RFC 9699、RFC Editor 页面、IETF Datatracker、RFC 8939、RFC 9023、RFC 9450 与 3GPP XR 研究记录。公开编辑视角：现实，而非倡议。