Resumen

  • RFC 9699 trata XR móvil como una cadena acoplada: seguimiento, modelo real, registro, generación, transporte y pantalla deben seguir a un usuario que continúa moviéndose.
  • El offload al edge alivia calor y batería, pero variación radio, espera, ejecución y retorno gastan el mismo presupuesto motion-to-photon; cercanía y media no son un recibo extremo a extremo.
  • El RFC espera parámetros heavy-tailed y tráfico en ráfagas. La evidencia debe vincular cada fotograma con pose, estado del modelo, cómputo y experiencia observada.

El fallo dentro de una media saludable

Una visitante con visor XR gira hacia un arco. El panel muestra 11 ms de media del dispositivo al edge. Casi todos los fotogramas llegan bien. Uno queda detrás de una ráfaga breve. Fue renderizado con la pose correcta al salir, pero vuelve después del giro; la superposición cae al lado del arco.

La media es cierta. No es la prueba que necesita la experiencia.

El RFC 9699, documento IETF Informational de diciembre de 2024, sigue a turistas por la Torre de Londres. La aplicación genera escenas históricas sobre una vista real que cambia. Divide el procesamiento en seguimiento, adquisición del modelo del mundo y registro. El seguimiento usa la pose en seis dimensiones de cabeza, ojos y objetos. El modelo puede combinar mapeo del cliente y localización del servidor. El registro alinea geometría, brillo y color, resuelve oclusión y trata distorsión, desenfoque y ruido. La visualización situada aún debe mantener coherencia temporal mientras se mueven cabeza y ojos.

Procesar vídeo y generar imágenes en el dispositivo produce calor y agota batería. Una nube distante encaja mal en límites de milisegundos, por lo que el trabajo se desplaza al edge. No desaparece: se reparte entre sensores, decisión de descarga, ruta radio, admisión y cola, CPU/GPU, almacén de modelo, retorno y pantalla.

Un plazo, varios relojes

Para su caso, el RFC cita motion-to-photon de hasta 20 ms y preferentemente 7–15 ms. Refresco de pantalla y conmutación de píxel pueden usar 12–13 ms, dejando 7–8 ms para sensor, renderizado y RTT. No son garantías universales; sí demuestran que red, ejecución y edad de pose comparten la misma aritmética.

El tiempo de respuesta descargado suma cómputo y RTT. Radio puede cumplir mientras una cola GPU rompe la experiencia. Edge puede ejecutar rápido mientras el uplink envía más datos por falta de rasgos visuales. El nodo más cercano puede no tener el modelo correcto cargado. Un fotograma dentro del SLO de red puede estar registrado contra geometría o pose antigua.

Con movilidad, cambian ancho de banda, latencia y relación entre componentes; el enlace puede fallar. El edge tiene menos recursos que la nube y una llegada de público puede saturarlo. «Cerca» debe significar un camino corto y capaz que satisface ahora la aplicación, no distancia en un mapa ni hops medidos al desplegar.

La cola estadística pertenece al producto

RFC 9699 espera heavy tails en ocupación de buffer, throughput, latencia cliente-servidor y tiempos variables; advierte que la media muestral puede estabilizarse demasiado despacio y que varianza o desviación estándar pueden no servir. Describe ráfagas grandes separadas por huecos, dependencia de largo alcance y burstiness de milisegundos. Su ejemplo 6DoF o point cloud necesita 200–1000 Mbps; ráfaga y espera variable producen jitter que puede contribuir al mareo.

No demuestra que toda traza XR tenga idéntica distribución. Sí impide aprobar por promedio. Una media de 11 ms puede convivir con pocos fotogramas que pierden su pose, concentrados en handover, llegada de público, carga de modelo o contención GPU.

El recibo debe partir de la identidad del fotograma: muestra del sensor y tiempo, decisión de offload, radio/handover, admisión, cola y ejecución, versiones de modelo y escena, fin de render, entrega descendente, pose del registro final, presentación y QoE. No observado es válido; “éxito edge” no rellena datos ausentes.

El RFC propone placement dinámico, soporte de movilidad y energía, con DetNet, wireless fiable, DiffServ o QoS como apoyos posibles, y mantiene abierta la viabilidad económica. No normaliza recibos por fotograma, certifica despliegues ni garantiza tails por proximidad. La conclusión defendible: XR en edge sólo tiene continuidad verificable cuando toda la ruta acoplada se opera como producto.

Fuentes

Registros primarios: RFC 9699, RFC Editor, IETF Datatracker, RFC 8939, RFC 9023, RFC 9450 y estudio XR de 3GPP. Lente editorial pública: realidad, no activismo.