Experimento de latencia WiFi

El único experimento con datos del proyecto: cuánto tarda un mensaje en ir del visor a la NUC y volver, bajo siete condiciones de carga de red. Primero el protocolo, luego cómo repetirlo y al final los resultados.

Protocolo

Hipótesis (EXP-LAT-001). La latencia de protocolo (RTT) entre la interfaz XR y la NUC se mantiene utilizable (P95 < 100 ms) incluso bajo carga combinada de video y LiDAR de alta resolución.

El protocolo del experimento de latencia: qué se mide exactamente, con qué instrumentos, bajo qué condiciones de carga y con qué criterio de aceptación. Se escribe antes de los resultados a propósito — es lo que permite que otro lo repita y compare.

Objetivo

Medir la latencia de ida y vuelta (RTT) a nivel de aplicación entre la interfaz de realidad mixta y un nodo edge simulado en PC.

El enlace bajo prueba es ZeroMQ sobre red WiFi local. La medición se repite bajo distintas condiciones de carga, para observar cómo afecta el tráfico concurrente a la latencia de los comandos.

Alcance y limitaciones

Esta prueba mide:

• Latencia de protocolo MR-edge: tiempo desde que Unity envía latency_probe hasta que recibe latency_ack.
• Impacto de cargas concurrentes (video JPEG 640×480, LiDAR 2D grid JSON) sobre la latencia de comandos.

Esta prueba NO mide:

• Latencia física del robot (serial, ESP32, drivers, motores, respuesta mecánica).
• Latencia de actuación total del sistema teleoperado.
• Latencia de ida vs. vuelta por separado — requeriría sincronización de relojes NTP/PTP entre dispositivos.

Definición de RTT:

RTT = client_receive_ts − client_send_ts   (Time.unscaledTime de Unity)

La medición no asume ninguna sincronización de reloj entre la Quest y la PC. Los campos server_recv_unix y server_send_unix que viajan en el ACK son informativos; el cálculo del RTT no los usa.

Condiciones experimentales

Siete condiciones, cada una variando la carga de video y LiDAR presente durante la medición de latencia de comandos:

ID	Nombre	Video	LiDAR	Modo cámara	Modo LiDAR	LiDAR Hz
C1	C1_control_only	No	No	off	off	—
C2	C2_video_normal	Sí	No	normal	off	—
C3	C3_lidar_detail	No	Sí	off	detail	12
C4	C4_lidar_medium	No	Sí	off	medium	8
C5	C5_lidar_panorama	No	Sí	off	panorama	4
C6	C6_full_detail	Sí	Sí	normal	detail	12
C7	C7_full_panorama	Sí	Sí	normal	panorama	4

Parámetros de la prueba

Parámetro	Valor
Duración por condición	60 s
Tasa de sondeo (probe rate)	10 Hz (≈ 600 muestras por condición)
Repeticiones	3 por condición, cuando el tiempo lo permite
Warm-up descartado	Primeras 10 muestras
Red WiFi	5 GHz, distancia < 5 m sin obstáculos
Escenario	Mismo cuarto, sin otros dispositivos en la red si es posible

Texto de limitaciones para el paper

El párrafo siguiente está redactado para citarse tal cual en una publicación. Conserva a propósito la densidad de la prosa académica, así que no sigue las mismas reglas de redacción que el resto de este sitio.

La prueba mide latencia de protocolo de la capa de aplicación MR-edge (RTT entre Unity/Quest y el nodo edge simulado), usando ZeroMQ sobre IEEE 802.11ac (WiFi 5 GHz). El RTT incluye serialización JSON, latencia de red WiFi (ida y vuelta) y deserialización, pero no incluye latencia serial, control de motores ni respuesta mecánica del robot. El RTT no puede separarse en latencia de ida y vuelta sin sincronización de relojes (NTP/PTP) entre los dispositivos; se reporta como RTT observado desde la perspectiva del operador en el visor MR. La carga de video y LiDAR es sintética pero usa los mismos canales ZMQ, frecuencias y tamaños de payload aproximados del sistema real.

Método

Reproducir el experimento requiere dos máquinas: una PC que ejecuta el simulador del nodo edge, y una Meta Quest con la aplicación de prueba instalada. Esta sección cubre el montaje, la ejecución y la extracción de los datos. El diseño experimental está en el protocolo.

Requisitos

Componente	Requisito
PC (simulador)	Windows / Linux / macOS, Python 3.10+
Python	pyzmq ≥ 25, opencv-python ≥ 4.8, numpy ≥ 1.24
Red	PC y Quest en la misma red WiFi (preferible 5 GHz)
Quest	Meta Quest 3, APK con WFIoTLatencyTestScene
Unity	Scripts copiados desde validation/Assets/Scripts/WFIoTLatency/

Simulador Python

cd <repo>/validation/tools
python wfiot_nuc_latency_simulator.py --host 0.0.0.0 --video-fps 30 --stat-hz 2 --lidar-hz 12 --jpeg-quality 85

Para las condiciones de LiDAR panorama (C5 y C7), con payload reducido:

python wfiot_nuc_latency_simulator.py --lidar-hz 4 --compact-lidar

Al arrancar, el simulador imprime su propia IP y los puertos que deja activos. Para averiguar la IP abre un socket UDP hacia 8.8.8.8, sin llegar a enviar datos. El significado de cada puerto está en Comunicaciones del sistema.

Ejecución en la Quest

Por cada condición del experimento:

1. Selecciona el preset de condición (C1 a C7) en el dropdown de la aplicación.
2. Confirma que los toggles de video y LiDAR coinciden con lo que el preset declara.
3. Pulsa Start. La corrida dura 60 s a 10 Hz.

Al terminar, la aplicación exporta dos CSV automáticamente:

/sdcard/Android/data/<bundle_id>/files/
  wfiot_latency_results_YYYYMMDD_HHMMSS.csv   ← detalle por muestra
  wfiot_latency_summary_YYYYMMDD_HHMMSS.csv   ← resumen estadístico

Para extraerlos por ADB:

adb pull /sdcard/Android/data/<bundle_id>/files/ ./csv_export/

Columnas relevantes

CSV	Columna	Descripción
detalle	rtt_ms	RTT observado en milisegundos
detalle	warmup	true = descartar del análisis estadístico
resumen	rtt_p95_ms	Percentil 95 — 95 % de las muestras tuvieron RTT ≤ este valor
resumen	jitter_std_ms	Desviación estándar de la latencia
resumen	loss_percent	Porcentaje de sondeos sin ACK recibido

Análisis estadístico

El script validation/tools/wfiot_stats_analysis.py procesa los CSV crudos y produce seis análisis:

• Kruskal-Wallis, como prueba ómnibus entre condiciones.
• Comparaciones pareadas de Mann-Whitney, con corrección de Holm.
• Intervalos de confianza por bootstrap.
• Probabilidad de cola.
• Clústeres de ráfagas.
• Modelo de carga ofrecida.

Los números que arroja sobre los datos reales están en Resultados.

Resultados

El experimento reunió 7 350 sondeos medidos sobre siete condiciones de carga, con las muestras de warm-up ya excluidas.

RTT por condición de carga. La caja muestra el rango intercuartílico; los bigotes, la dispersión que importa para el P95.

Todas las cifras de esta sección proceden de IEEE_IOT/analysis/stats_report.md del proyecto original, que wfiot_stats_analysis.py generó a partir de los CSV crudos exportados desde la Meta Quest.

Archivos

Archivo

stats_summary.csv

861 BQué contiene stats_summary.csv

Resumen estadístico por condición: media, mediana, P95, P99, jitter

Archivo

stats_report.md

5,9 KBQué contiene stats_report.md

Reporte completo del análisis estadístico

Estadística descriptiva por condición

Condición	n	Media (ms)	Mediana (ms)	Mín (ms)	Máx (ms)	P95 (ms)	P99 (ms)	Jitter σ (ms)
C1 · control solo	1050	22,54	16,62	3,44	303,57	58,10	117,43	23,38
C2 · video normal	1050	20,20	15,87	3,63	111,47	55,26	76,84	15,24
C3 · LiDAR detail	1050	19,63	15,65	3,62	121,90	55,45	86,74	15,91
C4 · LiDAR medium	1050	22,68	17,30	3,31	156,37	63,60	93,49	19,00
C5 · LiDAR panorama	1050	24,51	17,86	3,89	117,50	65,53	82,84	18,98
C6 · full detail	1050	20,34	16,13	3,93	130,75	55,32	71,45	15,01
C7 · full panorama	1050	25,08	17,60	3,56	118,67	71,87	83,86	19,79

Percentiles de RTT por condición. El P95 se mantiene por debajo del criterio de 100 ms en las siete condiciones.

VER-LAT-001PASS

RequisitoREQ-COM-002

MétodoMedición

ResultadoP95 máximo 71,87 ms (C7), P99 máximo 117,43 ms (C1)

• stats_summary.csv
• stats_report.md

El P95 se mantiene por debajo de 100 ms en las siete condiciones probadas. Eso incluye la carga combinada más pesada, C7, que suma video y LiDAR panorama con unos 37 Mbps de carga ofrecida.

El resultado contraintuitivo está en la cola de la distribución. La condición con la cola más larga no es ninguna de las cargadas, sino C1, la de solo comandos: acumula un P99 de 117,43 ms y el RTT máximo de todo el experimento, 303,57 ms. Esa asimetría apunta a que la cola no la produce el tráfico de video ni el de LiDAR, sino variabilidad de la red independiente de la carga aplicada. Los clústeres de ráfagas, más abajo, refuerzan esa lectura.

Significancia estadística

La prueba ómnibus de Kruskal-Wallis sobre RTT por condición da H = 70,26 con p < 0,001, para k = 7 y n = 7350. Las siete condiciones no son, por tanto, estadísticamente idénticas.

Cada condición se compara después contra C1 con la prueba U de Mann-Whitney, con corrección de Holm por comparaciones múltiples. La delta de Cliff acompaña a cada p para dar el tamaño del efecto:

Condición	p (Holm)	Delta de Cliff	Lectura
C2 · video normal	0,077	−0,056	Sin diferencia significativa
C3 · LiDAR detail	0,003	−0,087	Significativamente menor que C1
C4 · LiDAR medium	0,614	0,013	Sin diferencia significativa
C5 · LiDAR panorama	0,015	0,074	Significativamente mayor que C1
C6 · full detail	0,151	−0,045	Sin diferencia significativa
C7 · full panorama	0,015	0,075	Significativamente mayor que C1

Las deltas de Cliff son pequeñas en todos los casos: |δ| < 0,1. Con 1 050 muestras por condición, el tamaño de muestra basta para detectar diferencias estadísticamente, pero su magnitud práctica es modesta.

Probabilidad de cola — P(RTT > 100 ms)

Condición	n	n sobre 100 ms	% sobre 100 ms
C1 · control solo	1050	14	1,333 %
C2 · video normal	1050	2	0,190 %
C3 · LiDAR detail	1050	4	0,381 %
C4 · LiDAR medium	1050	9	0,857 %
C5 · LiDAR panorama	1050	5	0,476 %
C6 · full detail	1050	1	0,095 %
C7 · full panorama	1050	1	0,095 %

Probabilidad de cola frente a carga ofrecida. La relación no es monótona: la condición más liviana no es la de menor cola.

Clústeres de ráfagas

Un sondeo por encima de 100 ms no dice mucho por sí solo. Lo relevante es si esos sondeos aparecen dispersos o agrupados. Aquí se agrupan en un mismo clúster los eventos separados por menos de 5 s.

Los eventos de C1 en el tiempo. Se ve por qué 13 de los 14 caen en un solo clúster de 2,82 s en vez de repartirse por la corrida.

Condición	Eventos > 100 ms	Clústeres	Mayor clúster	Duración	RTT máx. (ms)
C1 · control solo	14	2	13	2,82 s	303,57
C2 · video normal	2	1	2	3,11 s	111,47
C3 · LiDAR detail	4	1	4	1,01 s	121,90
C4 · LiDAR medium	9	2	8	2,82 s	156,37
C5 · LiDAR panorama	5	2	3	5,53 s	117,50
C6 · full detail	1	1	1	0,00 s	130,75
C7 · full panorama	1	1	1	0,00 s	118,67

C1 concentra 13 de sus 14 eventos en un solo clúster de 2,82 s. La cola de esa condición no es degradación sostenida: es un episodio puntual de red dentro de una corrida por lo demás limpia. Eso explica por qué la condición más liviana registra el peor máximo de todo el experimento.

Modelo de carga ofrecida

El tráfico sintético que compite con los sondeos tiene estos tamaños:

Fuente	Payload
Video JPEG (640×480, calidad 85)	9 756 bytes por frame, de media
LiDAR detail	120 122 bytes
LiDAR medium	480 122 bytes
LiDAR panorama	1 080 124 bytes

Condición	Carga ofrecida (Mbps)	Mediana (ms)	P95 (ms)
C1	0,000	16,62	58,10
C2	2,342	15,87	55,26
C3	11,532	15,65	55,45
C4	30,728	17,30	63,60
C5	34,564	17,86	65,53
C6	13,873	16,13	55,32
C7	36,905	17,60	71,87

La correlación de Spearman entre carga ofrecida y P95 es ρ = 0,750 con p = 0,052, sobre las siete condiciones. Es una tendencia positiva que roza el umbral convencional de significancia, sin cruzarlo. La lectura razonable es que la cola de latencia sí crece con la carga, pero siete condiciones no bastan para afirmarlo con significancia estadística formal.

Conclusión

La hipótesis del experimento se sostiene con los datos medidos. El P95 se mantiene por debajo de 100 ms incluso bajo carga combinada: el valor más alto observado es 71,87 ms, en C7, un 28 % por debajo del umbral.

Los peores casos individuales no aparecen donde cabría esperarlos. Tanto el P99 más alto como el RTT máximo se registran en C1, la condición más liviana, y se concentran en un único episodio de 2,82 s. Lo que domina la cola es la variabilidad de la red, no la carga de datos del robot.

Esa segunda lectura es una interpretación de los datos hecha al migrar la documentación. Falta que el autor la revise antes de darla por buena para publicación.