Captura pasiva y scripted testing: cuando una sola herramienta hace ambas cosas

Son las 9:17 de la mañana. Un ingeniero RF entra en el estacionamiento subterráneo de un centro comercial de tres plantas en las afueras de Madrid. Lleva su smartphone de medición con una campaña de scripted testing en ejecución: llamadas VoLTE automatizadas cada 90 segundos, ping continuo, speed test cada 5 minutos. El script funciona. Los resultados se registran. Todo parece normal.

En el nivel -2, un suscriptor real intenta hacer una llamada VoLTE. La llamada falla. El terminal envía un CM_DS_CALL_EVENT_ORIG, recibe un rechazo de la red, ejecuta un fallback a CSFB, y finalmente establece la llamada sobre 3G con un retraso de 4,3 segundos. El suscriptor percibe un corte. La calidad de su experiencia acaba de degradarse de forma medible.

El script de medición no capturó nada de esto. Estaba ocupado ejecutando su propia secuencia de llamada VoLTE, que en ese preciso instante se completó con éxito porque utilizó un canal diferente y un timing distinto.

Este escenario no es hipotético. Es el punto ciego estructural de todas las herramientas de drive test que dependen exclusivamente de scripted testing.

La brecha entre medición controlada y experiencia real

Las herramientas de drive test tradicionales operan bajo un principio simple: el ingeniero define un script, la herramienta lo ejecuta, y los resultados se registran. Llamadas VoLTE cada 60 segundos. Speed test DL/UL cada 3 minutos. Ping continuo a un servidor de referencia. Este modelo ha funcionado durante dos décadas.

Pero la red que ve un script no es la red que vive el suscriptor.

Según datos de la GSMA publicados en 2025, el 73 % de los problemas de calidad de experiencia reportados por suscriptores ocurren fuera de las ventanas de prueba configuradas en las campañas de drive test. Los informes de Opensignal confirman la tendencia: la discrepancia entre los KPI medidos por herramientas de campo y la percepción real del suscriptor puede alcanzar el 35 % en entornos urbanos densos y superar el 50 % en zonas indoor con cobertura marginal.

La razón es matemática. Un script que ejecuta una llamada VoLTE cada 90 segundos captura exactamente 40 muestras por hora. El dispositivo real del suscriptor genera entre 200 y 600 eventos de red por hora: transiciones RRC, negociaciones de portadora, cambios de banda, Radio Link Failures parciales, procedimientos NAS, actualizaciones de tracking area. Todo eso ocurre entre las muestras del script. Todo eso es invisible para la herramienta de medición.

Anatomía de la captura pasiva DIAG-native

La captura pasiva no es un filtro sobre logs existentes. Es una interceptación directa de los mensajes de diagnóstico que el chipset Qualcomm genera en cada transacción de red. Cada vez que el modem envía o recibe un mensaje RRC, cada vez que una sesión de datos se establece o libera, cada vez que el terminal negocia un cambio de banda o ejecuta un procedimiento NAS, el chipset emite un log DIAG con timestamp en milisegundos, identificador de protocolo y contenido completo del mensaje.

La diferencia con el enfoque tradicional es fundamental. Una herramienta de scripted testing inicia una acción (llamar, enviar datos, hacer ping) y mide el resultado de esa acción. La captura pasiva no inicia nada. Observa todo lo que el dispositivo hace por su cuenta, o todo lo que la red le ordena hacer, y lo registra con la misma granularidad que un analizador de protocolo.

En la práctica, esto significa que un ingeniero que enciende la captura pasiva en un smartphone Android comercial y lo deja en su bolsillo durante una hora obtiene un registro completo de cada evento de red que ese dispositivo experimentó: cada transición de RRC_Connected a RRC_Idle, cada reselección de celda, cada Radio Link Failure, cada establecimiento y liberación de sesión de datos, cada procedimiento de tracking area update.

No hay polling. No hay muestreo. No hay buffer de 500 ms que suavice la realidad. Cada evento es capturado en el instante en que el chipset lo procesa, con precisión de milisegundo.

La convergencia: scripted + pasivo en un solo dispositivo

Aquí es donde la diferencia se vuelve tangible. El scripted testing y la captura pasiva no son alternativas. Son complementarios, y su valor real emerge cuando operan simultáneamente en el mismo dispositivo.

Considere el escenario de un ingeniero que ejecuta una campaña de drive test urbano. Su script automatizado lanza una llamada VoLTE cada 60 segundos y un speed test cada 5 minutos. Esas mediciones controladas le dan un baseline de rendimiento: tasa de éxito de llamada, MOS, throughput DL/UL, latencia.

Pero mientras el script ejecuta su secuencia, la captura pasiva registra en paralelo todo lo que la red le hace al dispositivo entre las muestras del script. Una reselección de celda inesperada entre dos llamadas programadas. Un Radio Link Failure parcial que se recuperó antes de la siguiente muestra del script. Un cambio de banda de la Band 3 a la Band 20 que degradó el throughput durante 12 segundos, invisible para el speed test que se ejecutó 3 minutos después.

El resultado es un diagnóstico de doble resolución. Las mediciones controladas del script dan los KPI de referencia. La captura pasiva revela todo lo que ocurre entre esas mediciones. Juntos, eliminan el punto ciego que ningún enfoque puede cerrar por sí solo.

La puntuación MOS ilustra esta complementariedad. El scripted testing calcula el MOS sobre llamadas VoLTE que la herramienta misma inicia: condiciones controladas, duración predefinida, codec conocido. La captura pasiva permite calcular el MOS sobre llamadas VoLTE reales del suscriptor, utilizando el algoritmo ViSQOL de Google: un modelo de machine learning perceptual que evalúa la calidad vocal sin necesidad de señal de referencia. La diferencia entre el MOS de script (4.1) y el MOS de llamada real del suscriptor (3.2) es exactamente la brecha que las herramientas tradicionales no pueden medir.

Y todo esto se ejecuta en un smartphone Android comercial. Sin hardware dedicado. Sin controlador rack-mounted. Sin licencia por funcionalidad. Un solo dispositivo que hace lo que antes requería dos herramientas separadas, dos licencias, y a menudo dos terminales físicos.

Lo que revela la pantalla de eventos en condiciones reales

La pantalla de eventos es donde la captura pasiva se materializa. Cada línea es un evento real que el dispositivo experimentó, no una medición que un script ordenó.

La captura de pantalla a continuación muestra una sesión en vivo: una llamada VoLTE realizada por el usuario (no por un script), con eventos de red capturados automáticamente, KPIs RF en tiempo real en la parte superior, y filtros de capa de protocolo codificados por color.

En una sesión de campo de 25 minutos en un entorno urbano, la pantalla muestra 44 eventos capturados. Cada evento tiene un timestamp con precisión de milisegundo, un identificador de capa de protocolo, y el contexto RF en el instante del evento.

Los eventos aparecen clasificados por capa de protocolo, cada una con su código de color:

Un NR_RADIO_LINK_FAILURE aparece con borde rojo a las 09:17:23.847. En ese instante, los KPI RF muestran RSRP = -115 dBm, RSRQ = -13.6 dB, SNR = -1.2 dB, RSSI = -82.5 dBm. La correlación es inmediata: un Radio Link Failure en NR con un SNR negativo y un RSRP marginal apuntan a una zona de cobertura NR insuficiente donde el dispositivo debería haber ejecutado un fallback a LTE antes.

Tres segundos después, un LTE_RRC_STATE_CHANGE confirma que el dispositivo cayó a LTE y restableció la conexión. El PCI de la celda LTE de destino, el ECI, el TAC y el eNB ID son visibles, lo que permite identificar exactamente en qué celda aterrizó el terminal.

Un CM_DS_CALL_EVENT_ORIG a las 09:18:01.234 registra el origen de una llamada VoLTE por parte de un suscriptor. Esta llamada no fue iniciada por ningún script. Es una llamada real que el usuario del dispositivo realizó. Su resultado, duración, codec utilizado y calidad vocal son capturados automáticamente.

Más adelante en la sesión, un LTE_ESM_OUTGOING_MSG revela un procedimiento de establecimiento de sesión de datos. Un CM_BAND_PREF muestra un cambio de preferencia de banda. Un CM_SSAC_TIME indica una restricción temporal de acceso a servicios (Service Specific Access Control), que en condiciones de congestión puede bloquear las llamadas VoLTE del suscriptor sin que ningún script de drive test lo detecte.

La pantalla soporta búsqueda por texto y filtrado por capa de protocolo. Soporte dual SIM permite distinguir eventos de cada tarjeta. La identidad de celda completa (PCI, ECI, TAC, eNB) acompaña cada evento para geolocalización precisa.

Lo que esto cambia en la práctica del drive test

La combinación de scripted testing y captura pasiva en un solo dispositivo Android no es una mejora incremental. Es un cambio de paradigma en lo que un ingeniero RF puede diagnosticar en campo.

Con scripted testing solo, el ingeniero obtiene una fotografía periódica del rendimiento de la red: una llamada cada minuto, un throughput cada 5 minutos, un ping continuo. Los intervalos entre muestras son puntos ciegos. Si un problema dura 8 segundos y ocurre entre dos muestras del script, no existe en los datos de la campaña.

Con la captura pasiva añadida, esos intervalos dejan de ser puntos ciegos. Cada transición RRC, cada Radio Link Failure, cada reselección de celda, cada procedimiento NAS queda registrado con timestamp de milisegundo. El ingeniero puede reconstruir la secuencia completa de eventos que condujo a una degradación, no solo observar el resultado final.

La implicación operativa es directa. Un operador que ejecuta campañas de drive test con scripted testing solo necesita multiplicar sus campañas para aumentar la cobertura temporal de sus mediciones. Más scripts, más frecuencia, más terminales, más licencias. Un operador que combina scripted y pasivo obtiene una cobertura temporal del 100 % desde el primer instante: cada evento es capturado, cada segundo está documentado.

Y esta convergencia ocurre sobre un dispositivo que el ingeniero ya lleva en su bolsillo. Un smartphone Android comercial con chipset Qualcomm, sin modificaciones de hardware, sin dongles externos, sin controladores de rack, sin licencias por funcionalidad apiladas.

Tecnología DIAG-native. Concebida y desarrollada en Francia. Soberanía tecnológica aplicada al diagnóstico de red.

La pregunta que queda abierta

Si un Radio Link Failure de 3 segundos ocurre entre dos muestras de un script de 60 segundos, y ninguna herramienta de drive test lo captura, ¿realmente ocurrió?

Para la red del operador, sí. Para el suscriptor que perdió su llamada, sí. Para el KPI de la campaña de drive test, no.

La captura pasiva no reemplaza el scripted testing. Lo completa. Cierra la brecha entre lo que medimos y lo que el suscriptor experimenta. Y lo hace en el único dispositivo que importa: el smartphone que el ingeniero ya tiene en la mano.

¿Cuál es el evento de red más inesperado que has descubierto en campo, uno que ningún script habría capturado?