Export QMDL et post-traitement : guide pratique pour ingénieurs RF....

Le format QMDL (Qualcomm Mobile Diagnostic Log) est le standard de facto pour la capture de logs réseau mobile sur les chipsets Qualcomm. Tout ingénieur RF qui travaille sur le terrain finit par rencontrer ce format, que ce soit pour du drive test, du diagnostic indoor ou du débogage protocolaire. Ce guide couvre le workflow complet : de la capture DIAG brute au post-traitement exploitable.

Qu’est-ce que le QMDL ?

Origine et rôle

Le QMDL est un format binaire propriétaire développé par Qualcomm pour stocker les données issues de l’interface DIAG (diagnostic) des modems Qualcomm. Cette interface expose en temps réel :

Les messages Layer 3 (NAS, RRC, SIP) décodés depuis le modem
Les métriques RF (RSRP, RSRQ, SINR, puissance Tx, timing advance)
Les événements internes du modem (handover, cell reselection, RACH, bearer setup)
Les paquets DIAG bruts (packets 0xB0xx, 0xB1xx, 0xB8xx, 0xB9xx)
Les logs GPS associés

Un fichier QMDL est essentiellement un enregistrement séquentiel de tous ces flux, horodatés et sérialisés dans un format binaire compact.

Structure du fichier

Un fichier QMDL contient des enregistrements (records) de taille variable, chacun composé de :

Un header : type de log, timestamp, taille
Le payload : données DIAG brutes (format spécifique à chaque type de packet)
Un CRC : vérification d’intégrité

Les fichiers QMDL peuvent atteindre plusieurs gigaoctets pour une session de drive test longue (2 à 4 heures). La taille dépend du nombre de log codes activés et de la fréquence d’échantillonnage.

Ce que le QMDL capture vs ce qu’il ne capture pas

Capturé dans le QMDL	Non capturé
Messages RRC (LTE + NR)	Trafic applicatif (IP payload)
Messages NAS (EMM, ESM, 5GMM, 5GSM)	Contenu des paquets data
Métriques RF par antenne	Métriques côté réseau (compteurs eNB/gNB)
Événements RACH, handover	Configuration réseau (paramètres eNB)
SIB (System Information Blocks)	Données des cellules non détectées
Logs GPS/GNSS	Vidéo/photo du terrain

Pour comprendre en détail la structure des paquets DIAG Qualcomm, consultez notre article sur l’anatomie du protocole DIAG.

Workflow de capture QMDL

Étape 1 : Connexion à l’interface DIAG

L’interface DIAG est accessible de deux manières :

Via USB (méthode traditionnelle) : le terminal est connecté en USB à un PC exécutant QXDM ou QCAT. Le port DIAG apparaît comme un port série virtuel (COM port sous Windows, /dev/ttyUSB sous Linux). Cette méthode nécessite les drivers Qualcomm et un accès au mode DIAG du terminal (souvent verrouillé par l’OEM).

Via l’application embarquée (méthode moderne) : une application Android accède directement à l’interface DIAG via le nœud /dev/diag. Cette approche élimine le besoin d’un PC embarqué et simplifie considérablement le setup terrain. L’application capture les packets DIAG en temps réel et les stocke localement.

Étape 2 : Configuration des log codes

Avant de lancer la capture, il faut sélectionner les log codes à enregistrer. Activer tous les log codes produit des fichiers volumineux et peut saturer le buffer DIAG.

Configuration minimale pour un drive test LTE :

0xB193 : LTE RRC OTA (messages RRC)
0xB0C0 : LTE NAS EMM (messages NAS)
0xB17F : LTE ML1 Serving Cell Measurement
0xB197 : LTE ML1 Neighbor Cell Measurement
0xB887 : LTE MAC DL Transport Block

Configuration minimale pour un drive test 5G NR :

0xB821 : NR RRC OTA
0xB97F : NR ML1 Serving Cell Measurement
0xB826 : NR ML1 Neighbor Cell Measurement
0xB883 : NR MAC DL Transport Block

Configuration étendue (débogage protocolaire) :

Ajoutez les log codes pour les événements RACH (0xB889), les SIB (0xB818), les UE Capabilities (0xB826) et les logs de bearer setup (0xB0E2).

Étape 3 : Capture terrain

Pendant la capture, quelques bonnes pratiques :

Vérifiez le flux DIAG : avant de démarrer le trajet, confirmez que les packets arrivent en temps réel
Surveillez la taille du fichier : un fichier QMDL qui ne grossit pas indique un problème de capture
Segmentez les fichiers : pour les longs trajets, découpez la capture en segments de 30 à 60 minutes (plus facile à post-traiter)
Notez les événements terrain : marquez les points d’intérêt (zone de coupure, zone indoor, changement de route) avec des timestamps ou des marqueurs GPS

Post-traitement avec QCAT

Présentation de QCAT

QCAT (Qualcomm Comprehensive Analysis Tool) est l’outil officiel de Qualcomm pour le post-traitement des fichiers QMDL. Il décode les packets DIAG bruts en messages lisibles et permet l’export vers des formats exploitables.

Workflow QCAT standard

1. Import du fichier QMDL

Ouvrez QCAT et chargez le fichier QMDL. Pour les fichiers volumineux (> 2 Go), le chargement peut prendre plusieurs minutes.

2. Filtrage par type de log

QCAT permet de filtrer les logs par catégorie :

Messages RRC uniquement
Métriques RF uniquement
Événements de mobilité uniquement

Ce filtrage est essentiel pour une analyse ciblée sans être noyé par le volume de données.

3. Décodage des messages

QCAT décode automatiquement les messages L3 selon les spécifications 3GPP :

RRC : selon TS 36.331 (LTE) et TS 38.331 (NR)
NAS : selon TS 24.301 (EPS) et TS 24.501 (5GS)
SIB : selon les IE définies dans les ASN.1

4. Export

QCAT permet l’export en plusieurs formats :

Format export	Usage
Texte (.txt)	Lecture manuelle, grep/recherche
CSV	Import dans Excel, traitement statistique
ISOG	Import dans des outils de post-traitement tiers
HTML	Rapport visuel basique

Limites de QCAT

QCAT est un outil puissant mais avec des limitations notables :

Licence Qualcomm requise : QCAT n’est pas en accès libre. Il nécessite un compte Qualcomm actif (généralement réservé aux OEM et aux opérateurs)
Windows uniquement : pas de version Linux ou macOS
Pas de visualisation cartographique : QCAT ne corrèle pas les logs avec le GPS pour une vue cartographique
Traitement différé : le post-traitement se fait après la capture, pas en temps réel
Interface datée : l’ergonomie de QCAT reflète son ancienneté

Alternatives modernes au workflow QCAT

Décodage embarqué en temps réel

L’approche moderne consiste à décoder les packets DIAG directement sur le terminal Android, en temps réel, pendant la capture. Ce paradigme élimine le post-traitement QCAT :

Les messages L3 sont décodés et affichés instantanément
Les métriques RF sont visualisées en temps réel avec corrélation GPS
Les anomalies (échec de handover, perte de couverture, dégradation SINR) sont détectées pendant le test
Les données sont exportables directement en formats exploitables

Cette approche transforme le workflow : au lieu de capturer pendant 3 heures puis post-traiter pendant 2 heures au bureau, l’ingénieur obtient ses résultats en temps réel sur le terrain.

Formats d’export alternatifs

Au-delà du QMDL, les outils modernes proposent des exports plus directement exploitables :

Export Excel/CSV structuré : les métriques RF, les événements et les messages L3 sont exportés dans des feuilles Excel structurées, prêtes pour l’analyse statistique. Pas besoin de parser des logs bruts.

Export QMDL natif : pour les équipes qui ont déjà un pipeline basé sur QCAT, la compatibilité QMDL reste importante. Les fichiers capturés peuvent être relus dans QCAT pour un traitement complémentaire.

Export cartographique : les données géolocalisées sont exportables dans des formats compatibles avec les outils de cartographie (KML, GeoJSON) pour une visualisation immédiate.

Bonnes pratiques de gestion des fichiers

Nommage

Adoptez une convention de nommage systématique :

[DATE]_[HEURE]_[OPERATEUR]_[ZONE]_[TYPE].qmdl

Exemple : 20260317_1430_Orange_ParisNord_DriveTest.qmdl

Stockage

Les fichiers QMDL sont volumineux. Prévoyez :

Stockage local : 128 Go minimum sur le terminal pour une journée de test
Sauvegarde : copie sur NAS ou cloud le soir même (les fichiers QMDL sont irremplaçables)
Archivage : conservation pendant au moins 12 mois pour les comparaisons historiques

Intégrité

Vérifiez l’intégrité des fichiers après chaque transfert. Un fichier QMDL corrompu est irrécupérable. Utilisez des checksums (MD5 ou SHA-256) pour valider les copies.

Cas pratique : diagnostic d’un problème de handover

Un opérateur signale des coupures d’appel sur un axe routier. Voici le workflow de diagnostic complet :

1. Capture : drive test sur l’axe avec capture QMDL, log codes RRC + NAS + métriques RF activés.

2. Analyse des métriques RF : identification d’une zone avec RSRP correct (-88 dBm) mais SINR dégradé (2 dB). Trois cellules avec des RSRP comparables sont détectées simultanément.

3. Analyse L3 : dans cette zone, les logs montrent des MeasurementReport suivis de RRCConnectionReconfiguration (handover ordonné), puis RRCConnectionReestablishmentRequest (échec de handover). Le PCI cible dans le MeasurementReport correspond à deux cellules physiques différentes.

4. Diagnostic : collision PCI entre deux cellules voisines. Le réseau ordonne un handover vers le mauvais site.

5. Résolution : replanification PCI des cellules impliquées, suivi d’un drive test de validation.

Ce diagnostic aurait été impossible sans l’accès aux messages L3 contenus dans le QMDL.

Conclusion

Le format QMDL reste la référence pour la capture exhaustive de données réseau mobile sur chipsets Qualcomm. Maîtriser son workflow, de la configuration des log codes au post-traitement, est une compétence fondamentale pour tout ingénieur RF terrain. Les outils modernes qui décodent le DIAG en temps réel sur le terminal simplifient considérablement ce workflow, mais la compréhension du format sous-jacent reste indispensable pour exploiter pleinement les données de diagnostic.

Export QMDL et post-traitement : guide pratique pour ingénieurs RF