Zusammenfassung

  • RFC 9699 behandelt mobiles XR als gekoppelte Kette: Tracking, Weltmodell, Registrierung, Erzeugung, Transport und Anzeige müssen einem weiter bewegten Nutzer folgen.
  • Edge-Offload entlastet Wärme und Akku, doch Funkvariation, Queue, Ausführung und Rückweg verbrauchen dasselbe Motion-to-Photon-Budget; Nähe und Mittelwert sind kein End-to-End-Beleg.
  • Der RFC erwartet heavy-tailed Betriebsparameter und Bursts. Jedes angezeigte Bild muss mit Pose, Modellzustand, Berechnung und beobachteter QoE verknüpft werden.

Der Fehler in einem gesunden Mittelwert

Eine Besucherin mit XR-Headset dreht sich zu einem Torbogen. Das Dashboard zeigt 11 ms im Mittel zwischen Gerät und Edge. Fast alle Bilder laufen sauber. Eines wartet hinter einem kurzen Burst. Beim Absenden stimmte die Kopf-/Augenpose; bei der Rückkehr ist sie alt, und das Overlay liegt neben dem Bogen.

Der Mittelwert ist wahr. Er ist nur nicht der Beleg, den die Erfahrung braucht.

Der im Dezember 2024 als IETF Informational veröffentlichte RFC 9699 folgt Touristen im Tower of London. Die Anwendung legt historische Szenen über eine veränderliche reale Sicht. Sie trennt Tracking, Erwerb eines Weltmodells und Registrierung. Tracking umfasst die sechsdimensionale Pose von Kopf, Augen und Objekten. Das Modell kann clientseitiges Mapping mit serverseitiger Lokalisierung verbinden. Registrierung gleicht Geometrie, Helligkeit und Farbe ab, behandelt Occlusion, Verzerrung, Unschärfe und Rauschen. Die situated visualisation muss danach zeitliche Kohärenz trotz Bewegung wahren.

Lokale Videoanalyse und Bilderzeugung erzeugen Hitze und leeren den Akku. Eine entfernte Cloud passt schlecht in Millisekundenfristen, also wandert Rechenarbeit zum Edge. Sie verschwindet nicht, sondern verteilt sich auf Sensoren, Offload-Entscheidung, Funkpfad, Admission/Queue, CPU/GPU, Modell, Rücktransport und Display.

Eine Frist, mehrere Uhren

Für den Anwendungsfall nennt der RFC maximal 20 ms Motion-to-Photon, bevorzugt 7–15 ms. Display-Refresh und Pixelumschaltung können 12–13 ms beanspruchen; 7–8 ms bleiben für Sensorverarbeitung, Rendering und RTT. Das sind keine universellen Produktgarantien. Sie zeigen, dass Netzwerk, Compute und Pose-Alter dasselbe Budget teilen.

Die Offload-Antwortzeit addiert Berechnung und RTT. Funk kann sein Ziel erfüllen, während eine GPU-Queue die Erfahrung verfehlt. Der Edge kann schnell rechnen, während zusätzliche Bilddaten den Uplink bremsen. Der nächste Standort kann das nötige Weltmodell noch nicht halten. Ein Bild im Netzwerk-SLO kann auf alte Geometrie oder Pose registriert sein.

Mobilität verändert Bandbreite, Latenz und Komponentenbeziehungen; Links können ausfallen. Ein Edge ist kleiner als die Cloud und kann durch eine Besuchergruppe überlastet werden. „Nah“ bedeutet daher einen aktuell kurzen und ausreichend großen Pfad, nicht nur Kartenentfernung oder einen früher gemessenen Hop Count.

Der Tail gehört zum Produkt

RFC 9699 erwartet heavy tails bei Buffer-Belegung, Durchsatz, Client-Server-Latenz und Übertragungszeit. Er warnt, dass Sample Means langsam stabilisieren und Varianz bzw. Standardabweichung ungeeignet sein können. Große Bursts mit langen Lücken, Long-range dependence und millisekundige Burstiness kommen hinzu. 6DoF-Video/Point Cloud verlangt im Beispiel 200–1000 Mbps; Burst plus variable Queue erzeugt Jitter, der Motion Sickness begünstigen kann.

Das beweist nicht dieselbe Verteilung für jede XR-Last. Es widerlegt aber Freigaben allein nach Mittelwert. Wenige Bilder können ihre Pose gerade bei Handover, Besucheransturm, Model Fetch oder GPU-Contention verlieren.

Ein belastbarer Beleg beginnt mit der Frame-ID: Sensorprobe und Zeit, Offload-Entscheidung, Funk/Handover, Admission, Queue, Ausführung, Modell-/Szenenversion, Renderende, Downlink, Pose der finalen Registrierung, Displayzeit und QoE. Nicht beobachtet ist legitim; „Edge erfolgreich“ ersetzt keine Lücken.

Der RFC nennt dynamische Platzierung, Mobility und Energiemanagement sowie DetNet, zuverlässigen Funk, DiffServ oder QoS als mögliche Stützen und lässt Wirtschaftlichkeit offen. Er standardisiert keinen Frame-Beleg, zertifiziert kein Deployment und garantiert keinen Tail durch Nähe. Prüfbare Kontinuität entsteht erst, wenn der gesamte gekoppelte Pfad als Produkt betrieben wird.

Quellen

Primärquellen: RFC 9699, RFC Editor, IETF Datatracker, RFC 8939, RFC 9023, RFC 9450 und 3GPP XR Study. Öffentliche redaktionelle Linse: Realität statt Advocacy.