Resumen

  • El RFC 9699 presenta un caso de uso informativo: no es un estándar de rendimiento ni acredita una instalación comercial.
  • Una escena difícil puede elevar el tráfico de subida justo cuando otras condiciones empeoran; la media no revela todas las interrupciones.
  • La compra de capacidad próxima necesita pruebas de plazos, pérdidas y degradación para una carga concreta, además de métricas de transporte.

Una pared con pocos rasgos visuales puede ser menos sencilla para una aplicación de realidad aumentada que una fachada llena de detalles. No porque deba dibujar más, sino porque puede necesitar enviar más información para reconocer y relacionar la escena. El RFC 9699 recoge ese mecanismo al comentar investigaciones anteriores de AR multiusuario. Es una advertencia contra una costumbre comercial: explicar la XR como si todo dependiera de descargar imágenes con rapidez.

La subida, el procesamiento remoto y el estado de la escena también cuentan. Si una ráfaga queda esperando acceso a la radio, unos metros menos hasta el servidor no recuperan necesariamente ese tiempo. Si la información llega a un GPU ocupado, la cercanía vuelve a ser una ventaja incompleta. Son consecuencias analíticas de la cadena, no resultados que este artículo haya medido en un operador.

Lo que dice el documento y lo que no

Publicado en diciembre de 2024, el RFC tiene categoría Informational. Su recorrido ilustrativo por la Torre de Londres ayuda a exponer necesidades de seguimiento, modelo del entorno, registro de objetos virtuales y generación de imágenes. No describe una visita comercial verificada. Tampoco certifica una arquitectura ni impone una solución de despliegue.

El motivo de descargar trabajo del dispositivo es comprensible: batería y disipación limitan lo que cabe sostener junto al usuario. Pero mover una tarea cambia las dependencias. Ahora hacen falta comunicación, admisión y ejecución a tiempo. La movilidad puede alterar la relación con los recursos, y una multitud puede competir por la misma infraestructura.

El RFC destaca distribuciones de cola pesada y tráfico en ráfagas. Ese diagnóstico invita a estudiar extremos y acumulaciones, no a declarar que toda carga XR tiene una distribución idéntica o que sus medias carecen de valor. Un promedio de capacidad sirve para ciertas decisiones; no basta para saber cuántas actualizaciones llegan tarde ni cuánto dura una secuencia de fallos.

El plazo debe tener principio y final

Entre las cifras citadas figuran 20 milisegundos y una franja preferible de 7 a 15. Son objetivos de diseño procedentes de las referencias del documento, no un umbral médico universal ni la medición de un visor actual. Un ejemplo asigna unos 12–13 milisegundos a la pantalla, dejando poco margen para el resto. En otro lugar se trata la respuesta del servidor. Es necesario conservar esas diferencias.

Nuestra propuesta es anotar una trayectoria causal de trabajo: captura o seguimiento, subida, entrada en cola, ejecución, retorno y presentación. No todo equipo expone todos esos datos; el informe debe declarar los huecos y el error de sincronización. Sumar percentiles de etapas no calcula automáticamente el percentil de la experiencia completa. Contar solo lo que volvió, además, elimina del análisis parte de lo que peor funcionó.

Tampoco conviene reemplazar las pruebas térmicas por una deducción. El modelo de gafas inteligentes de 2020 estudia rutas de calor mediante modelado y comparación con elementos finitos; la comprobación física quedaba pendiente. Muestra por qué importan materiales y disposición, no cuánto mejorará un producto comercial al trasladar tareas. La radio y el trabajo local restante siguen consumiendo energía.

Probar la cadena sin prometer más que la muestra

Los mecanismos de red tienen un ámbito. RFC 8655 sitúa DetNet en un dominio administrativo o un conjunto cerrado de dominios que cooperan; no ofrece límites universales sobre cualquier recorrido de Internet. Aun dentro del ámbito previsto, una garantía de transporte no valida el seguimiento espacial, la espera del GPU o el comportamiento de la pantalla.

Por eso conviene comparar ubicaciones con las mismas escenas y movimientos, incluyendo una base local cuando sea viable. Puffer aporta una lección metodológica desde el vídeo convencional: las ventajas de una simulación deben contrastarse en el entorno real frente a alternativas sencillas. No es un experimento de XR y no autoriza a trasladar sus resultados a un visor.

La conclusión no es que el borde resulte inútil. Es que su utilidad debe formularse con condiciones: qué dispositivos, qué mezcla de tareas, qué nivel de concurrencia y qué fracción de sesiones siguió siendo utilizable. El RFC plantea el problema; esa prueba sigue correspondiendo a quien vende o adopta el servicio.