QMDL: el formato de log diagnóstico de Qualcomm explicado — cómo capturar y analizar datos de campo

Acabas de terminar un drive test de 6 horas en tres sitios. El log RRC muestra un fallo de handover en el Sitio 2 exactamente a las 14:37. Tu equipo de post-procesamiento está en Madrid, tú estás en Sevilla, y necesitan los datos de protocolo brutos — ahora. Exportas el archivo QMDL, lo envías, y en 10 minutos han decodificado la secuencia de handover trama a trama. QMDL es el lenguaje universal de los datos de campo Qualcomm.

¿Qué es QMDL?

QMDL son las siglas de Qualcomm Modem Diagnostic Log. Es el formato binario nativo producido por el protocolo Qualcomm DIAG — una interfaz de diagnóstico integrada en cada módem Qualcomm Snapdragon. Capturar un archivo QMDL equivale a registrar un flujo binario crudo proveniente del puerto diagnóstico Qualcomm, que contiene paquetes de registro con marca de tiempo para cada capa de protocolo activa: mediciones de capa física, señalización RRC, procedimientos NAS, estadísticas PDCP y mucho más.

Existen dos variantes en el campo. El formato estándar .qmdl es, con diferencia, el más común — es lo que produce cualquier dispositivo Android con root equipado con un chipset Snapdragon cuando se abre el puerto DIAG. El formato extendido .qmdl2 incorpora metadatos adicionales, incluidas marcas de tiempo UTC absolutas, y se encuentra en plataformas Snapdragon 8 Gen 2 y posteriores. Para el post-procesamiento y el intercambio con equipos de operadoras, el .qmdl sigue siendo el formato dominante gracias a su amplio ecosistema de parsers y su compatibilidad con QCAT (Qualcomm Code Activation Tool).

A nivel binario, cada registro de un archivo QMDL es una trama DM (Diagnostic Monitor). Cada trama DM tiene una cabecera de estructura fija que contiene el código del paquete de log, la longitud de la trama y una marca de tiempo QTimerTick, seguida de un payload cuyos dos primeros bytes constituyen el ID del paquete de log. Ese ID de paquete es la clave para entender qué contiene la trama.

El formato no es un estándar abierto. Proviene de la cadena de herramientas de diagnóstico interna de Qualcomm y requiere el software oficial QCAT o bien un parser de terceros que haya realizado ingeniería inversa del encuadre y la estructura de paquetes.

IDs de paquetes QMDL de referencia

ID de paquete (hex)	Contenido	Protocolo
0x1568	Mensaje RRC OTA LTE	RRC 36.331
0x5226	Mensaje RRC OTA NR	RRC 38.331
0x713A	Mensaje NAS OTA LTE	NAS 24.301
0x7030	Mensaje NAS OTA 5G	NAS 24.501
0x184B	Mediciones celda servidora LTE ML1	PHY Capa 1
0x2584	Info celda servidora NR ML1	PHY Capa 1
0x1472	Estadísticas PDCP DL LTE	PDCP Capa 2

QMDL vs QMDL2 vs HLOG

No todos los formatos de log son equivalentes. Comprender las diferencias entre los tres formatos más comunes en el trabajo de campo permite elegir la estrategia de captura correcta.

Característica	QMDL	QMDL2	HLOG
Formato	Tramas DM binarias	DM binario extendido	Cifrado propietario
Marca de tiempo	Relativa (QTimerTick)	UTC absoluto	UTC absoluto
Cifrado	Ninguno	Ninguno	Cifrado AEAD
GPS embebido	No	Opcional	Sí
Chipsets soportados	Qualcomm (todos)	Snapdragon 8 Gen 2+	Dispositivos HiCellTek
Compatibilidad ecosistema	Amplia (QCAT, parsers)	Limitada	Herramienta HiCellTek
Tamaño de archivo	Grande (crudo)	Grande	Comprimido

El formato QMDL estándar gana en interoperabilidad. Sus marcas de tiempo QTimerTick relativas requieren un paso de conversión (descrito más adelante en la sección de parsing), pero su ecosistema de parsers es suficientemente amplio para que cualquier equipo de post-procesamiento de un proveedor de telecomunicaciones mayor pueda abrirlo y decodificarlo sin herramientas propietarias. El QMDL2 extiende esto con GPS opcional y tiempo UTC absoluto, pero el soporte de parsers fuera de QCAT sigue siendo limitado. El HLOG es el formato cifrado y comprimido utilizado por los dispositivos HiCellTek — ideal para transferencias seguras campo-oficina, pero requiere la herramienta HiCellTek para la decodificación.

Para envíos de tickets de incidencias a operadoras y post-procesamiento multi-proveedor, QMDL es el formato que mejor viaja.

Cómo capturar QMDL en el campo

La captura QMDL requiere un smartphone Android con chipset Qualcomm Snapdragon, acceso root mediante Magisk y la interfaz DIAG habilitada en el dispositivo. La mayoría de los dispositivos de campo de grado profesional exponen el puerto DIAG en /dev/diag.

La máscara de log es el parámetro de configuración más importante en cualquier captura QMDL. La máscara se envía al módem mediante el comando DM 0x7C e indica al chipset exactamente qué IDs de paquetes incluir en el flujo de salida. Una máscara mal configurada es la razón más frecuente de llegar al post-procesamiento con un archivo QMDL sin mensajes RRC — un error que desperdicia un día entero de datos de campo. Antes de cualquier drive largo, verifique siempre que la máscara active explícitamente como mínimo los IDs 0x1568 (RRC LTE), 0x5226 (RRC NR), 0x713A (NAS LTE) y 0x7030 (NAS 5G).

Un drive típico de una hora con máscara completa genera entre 200 MB y 800 MB de datos QMDL brutos, dependiendo de la actividad de red, la densidad de celdas y el número de IDs de paquetes habilitados. Para campañas de optimización, planifique entre 5 y 20 GB de QMDL por dispositivo y por día.

Parsear QMDL — del binario al protocolo decodificado

El binario QMDL crudo no puede leerse directamente. El parsing requiere cuatro pasos secuenciales que convierten el flujo binario en mensajes de protocolo legibles.

Paso 1 — Extracción de tramas DM: el flujo binario está enmarcado mediante una codificación similar a HDLC, donde 0x7E es el byte de encuadre que marca el inicio y el final de cada trama DM. El parser debe recorrer el flujo, identificar los límites y extraer tramas individuales. Los bytes escapados (secuencias 0x7D) deben des-escaparse antes del procesamiento.

Paso 2 — Lookup del ID de paquete: una vez extraída la trama, los dos primeros bytes del payload identifican el tipo de paquete de log. Una consulta en una tabla de IDs de paquetes conocidos determina si la trama contiene un mensaje RRC OTA, una PDU NAS, un registro de medición PHY u otro tipo de log.

Paso 3 — Decodificación ASN.1: para las tramas RRC y NAS (0x1568, 0x5226, 0x713A, 0x7030), el payload tras la cabecera del paquete contiene un mensaje 3GPP codificado en ASN.1 PER. Su decodificación requiere un decodificador ASN.1 compilado contra la versión correcta de la especificación 3GPP (36.331 para RRC LTE, 38.331 para RRC NR, 24.301 para NAS LTE, 24.501 para NAS 5G). El resultado decodificado es idéntico a lo que muestran las herramientas de campo profesionales — porque los datos de protocolo subyacentes son los mismos.

Paso 4 — Conversión de marcas de tiempo: las tramas DM llevan un valor QTimerTick de 32 bits. Convertir este valor a hora real requiere conocer la frecuencia del temporizador del chipset, que es 19,2 MHz en la mayoría de plataformas Snapdragon. La fórmula es: hora_UTC = referencia_UTC + (QTimerTick / 19200000). El ancla UTC de referencia se extrae habitualmente de un evento de sincronización GPS o de una marca de tiempo NTP embebida en la sesión de captura.

Para equipos que necesitan decodificar mensajes RRC o NAS individuales extraídos de un QMDL sin ejecutar una pila completa de parsers, el decodificador en línea de protocolos L3 RRC y NAS soporta el pegado directo de payloads codificados en hexadecimal y produce una salida ASN.1 estructurada.

Para ingenieros que prefieren una decodificación en tiempo real nativa en el campo sin QCAT, la herramienta de drive test Android con acceso DIAG nativo captura y decodifica flujos QMDL directamente en el dispositivo durante el drive, eliminando el ciclo de post-procesamiento para identificación rápida de fallos.

Buenas prácticas QMDL en el campo

Conocer el formato es una cosa. Usarlo eficientemente en una campaña de optimización real requiere un conjunto de prácticas operativas que los ingenieros de campo experimentados desarrollan a lo largo de años de trabajo en drive.

Nomenclatura de archivos: incluya siempre la fecha, el ID del sitio y el segmento de drive en el nombre del archivo — por ejemplo 2026-03-27_SITIO-A_SEG1.qmdl. Esto hace trivial la correlación con pistas GPS y exportaciones de KPI, y evita el problema de desambiguación de archivos que afecta a los equipos de post-procesamiento que reciben lotes de capturas de varios ingenieros.

Rotación de logs: para drives de más de 30 minutos, configure su herramienta de captura para rotar archivos cada 30 minutos. Los archivos que superan 2 GB provocan fallos de parsing en varias herramientas comunes y ralentizan el paso de escaneo inicial. Los archivos más pequeños también permiten el procesamiento paralelo de diferentes segmentos de drive.

Correlación GPS: los archivos QMDL no contienen datos GPS por defecto. El enfoque estándar consiste en capturar una pista GPX en paralelo y correlacionarla con las marcas de tiempo QMDL después de aplicar la conversión QTimerTick a UTC. Algunas herramientas de drive test Android gestionan esta correlación automáticamente y embeben el GPS en un archivo sidecar. El formato QMDL2 soporta el embebido de GPS opcional, lo que simplifica este paso en chipsets compatibles.

Evidencia para tickets de proveedor: según 3GPP TS 37.320 (modo test UE), los logs QMDL con marcas de tiempo de mensajes RRC son aceptados como evidencia primaria en las escaladas de tickets de incidencias a proveedores. Al preparar un ticket, extraiga las tramas 0x1568 o 0x5226 relevantes alrededor del evento de fallo, conviértalas a ASN.1 legible y adjunte tanto el segmento QMDL bruto como el resultado decodificado. Esta combinación elimina cualquier ambigüedad sobre lo que el UE realmente envió y recibió.

Privacidad y seguridad: los archivos QMDL contienen el IMSI e IMEI del dispositivo en los paquetes NAS Attach y Registration Request. Antes de compartir cualquier archivo QMDL fuera de su organización — con proveedores, operadoras o socios — elimine o anonimice los payloads NAS que contienen estos identificadores. No hacerlo constituye una filtración de datos personales bajo el RGPD, ya que el IMSI es un identificador de suscriptor directamente vinculable a una persona.

Planificación del almacenamiento: una campaña típica de optimización LTE/NR genera entre 5 y 20 GB de QMDL por dispositivo y por día. Para un equipo de cuatro ingenieros en una campaña de dos semanas, esto se traduce en entre 280 y 1.120 GB de datos brutos. Planifique la infraestructura de almacenamiento en campo, transferencia y archivo antes del inicio de la campaña — no después.

Conclusión

QMDL no es solo un formato de archivo — es el registro más completo de lo que ocurrió entre un dispositivo y una red en cada capa de protocolo. Saber capturarlo de manera eficiente, parsearlo correctamente y extraer los IDs de paquetes correctos separa a un ingeniero que dice “vi un fallo de handover” de uno que puede probarlo con una secuencia RRC con precisión de milisegundos.

Los cuatro IDs de paquetes que cubren el 90% de los escenarios de troubleshooting en campo son 0x1568, 0x5226, 0x713A y 0x7030. Domine la máscara de log que los habilita, comprenda el encuadre similar a HDLC que estructura el flujo binario y aplique la conversión QTimerTick para una correlación temporal precisa — y el QMDL se convierte en un instrumento de diagnóstico tan preciso como la especificación de la red en sí.

Pregunta para los comentarios: ¿cuál ha sido el problema más complejo que ha resuelto con el análisis QMDL — y qué ID de paquete fue la clave?