Summary

  • RFC 9699 treats mobile XR as a coupled chain: tracking, world-model acquisition, registration, image generation, transport and display must follow a user who is still moving.
  • Edge offload can reduce device heat and battery pressure, yet wireless variation, edge queues, execution and frame return all consume the same motion-to-photon budget; a nearby site or a passing mean is not an end-to-end receipt.
  • The RFC expects heavy-tailed operational parameters and bursty traffic. Leadership therefore needs tail-aware evidence linking each displayed frame to its pose, model state, computation and observed experience.

The miss hidden inside a healthy average

A visitor wearing an XR headset turns towards an arch. The dashboard says the device-to-edge service averaged 11 milliseconds over the last minute. Most frames arrive smoothly. One frame, however, waits behind a short burst at the edge. It was rendered against a head-and-eye pose that was current when the request left; it returns after the visitor has moved. The overlay lands beside the arch rather than on it.

Nothing in the average is false. It is simply the wrong receipt.

RFC 9699, an Informational IETF document published in December 2024, gives this problem a concrete operating shape. Its example follows tourists through the Tower of London while an application generates historical scenes and overlays them on the changing real view. Scene processing is not one undifferentiated workload. The RFC separates tracking, acquisition of a real-world model and registration. Tracking covers the six-dimensional pose of the head, eyes and visible objects. Model construction can combine client-side mapping with server-side localisation. Registration aligns geometry, brightness and colour, resolves occlusion and handles visual artifacts. Situated visualisation must then preserve temporal coherence as the eyes and head keep moving.

That sequence explains both the attraction and the danger of offload. Real-time video analysis and new-frame generation consume battery and generate heat on a mobile device. A distant cloud cannot fit comfortably inside the cited millisecond-scale response requirement, so computation moves closer to the user. But the workload has not disappeared. Its ownership has been divided among the device, radio path, edge admission and queue, CPU or GPU execution, model store, return transport and display.

One deadline, several clocks

RFC 9699 cites a motion-to-photon target of no more than 20 ms and preferably 7–15 ms for its use case. It also notes that display refresh and pixel switching can consume 12–13 ms of a 20 ms budget, leaving only 7–8 ms for sensor processing, rendering and the round trip between device and edge. These figures are requirements and cited study results, not a promise about every product. Their strategic value lies in the arithmetic: transport latency cannot be managed independently from compute time and pose age.

The RFC defines an offloaded response time as the sum of computation and RTT. A radio team can meet its slice while a GPU queue misses the experience. An edge team can report fast execution while the uplink stalls on extra visual data. A placement controller can choose the nearest site while the required world model is cold there. A frame can arrive within a network SLO yet be registered to stale geometry or an old pose. Each fact is real; none substitutes for the next.

Mobility makes those boundaries move. RFC 9699 says wireless bandwidth and latency fluctuate as the user moves, the link may fail, and logical relationships among software components can change frequently. The edge itself is smaller than a remote cloud and can be overwhelmed by a crowd surge. Proximity is therefore conditional: it means a short, high-capacity path capable of meeting the application requirement, not merely a small distance on a map or a low hop count at commissioning time.

The tail is part of the product

The RFC expects buffer occupancy, throughput, client-server latency and variable transmission times to be heavy-tailed. It warns that sample means can stabilise too slowly and that variance or standard deviation may be unsuitable for these parameters. It also describes large XR bursts separated by gaps, long-range dependence, self-similarity and millisecond-scale burstiness. In its example, 6DoF video or point-cloud traffic requires 200–1000 Mbps; burst plus variable queueing can create jitter that contributes to motion sickness.

This does not prove that every XR trace has the same distribution. It does defeat a management habit: approving the system from an average alone. An 11 ms mean can coexist with a thin set of frames that miss the pose they belong to. Those frames may cluster during handover, crowd arrival, model fetch or GPU contention—the exact moments in which continuity matters most.

A useful receipt starts with a frame identity. It should preserve the device sensor sample and its timestamp; the offload decision; radio and handover observations; edge admission, queue and execution intervals; model and scene-state versions; rendering completion; downlink delivery; the pose used for final registration; display presentation time; and the resulting QoE signal. Not observed is a valid state. “Edge success” is not a valid substitute for the missing cells.

What RFC 9699 does not certify

The document recommends thinking about managed edge-cloud functions such as dynamic server placement, mobility support and energy management. It mentions deterministic networking, reliable wireless, differentiated services and per-connection QoS as possible support. It also says economic viability still matters.

It does not define a universal frame-receipt format, certify a named deployment, guarantee that predictive compensation prevents discomfort, or prove that a geographically close server meets tail deadlines. Its security section introduces no new issue beyond referenced distributed and cloud-computing concerns. The defensible conclusion is narrower: edge XR is technically feasible only when the whole coupled path is operated as the product.

Sources

Primary records: RFC 9699, its RFC Editor record, the IETF Datatracker record, RFC 8939, RFC 9023, RFC 9450 and the 3GPP XR study record. Editorial lens: reality, not advocacy.