QMDL : le format de log diagnostic Qualcomm expliqué — capturer et analyser les données terrain

Vous venez de terminer un drive test de 6 heures sur trois sites. Le log RRC révèle un échec de handover sur le Site 2 à exactement 14h37. Votre équipe de post-traitement est à Paris, vous êtes à Lyon, et ils ont besoin des données protocolaires brutes — immédiatement. Vous exportez le fichier QMDL, vous l’envoyez, et en 10 minutes ils ont décodé la séquence de handover trame par trame. Le QMDL est le langage universel des données terrain Qualcomm.

Qu’est-ce que le QMDL ?

QMDL signifie Qualcomm Modem Diagnostic Log. C’est le format binaire natif produit par le protocole Qualcomm DIAG — une interface de diagnostic intégrée dans chaque modem Qualcomm Snapdragon. Capturer un fichier QMDL, c’est enregistrer un flux binaire brut provenant du port de diagnostic Qualcomm, contenant des paquets journalisés horodatés pour chaque couche protocolaire active : mesures de couche physique, signalisation RRC, procédures NAS, statistiques PDCP, et bien davantage.

Deux variantes existent sur le terrain. Le format standard .qmdl est de loin le plus courant — c’est ce que produit tout appareil Android rooté équipé d’un chipset Snapdragon lorsque le port DIAG est ouvert. Le format étendu .qmdl2 embarque des métadonnées supplémentaires, notamment des horodatages UTC absolus, et se rencontre sur les plateformes Snapdragon 8 Gen 2 et ultérieures. Pour le post-traitement et le partage avec les équipes opérateurs, le .qmdl reste le format dominant en raison de son écosystème de parsers étendu et de sa compatibilité avec QCAT (Qualcomm Code Activation Tool).

Au niveau binaire, chaque enregistrement d’un fichier QMDL est une trame DM (Diagnostic Monitor). Chaque trame DM possède un en-tête de structure fixe contenant le code du paquet log, la longueur de la trame et un horodatage QTimerTick, suivi d’un payload dont les deux premiers octets constituent l’ID du paquet log. Cet ID de paquet est la clé pour comprendre ce que contient la trame.

Le format n’est pas un standard ouvert. Il est issu de la chaîne d’outils de diagnostic interne de Qualcomm et nécessite soit le logiciel officiel QCAT, soit un parser tiers ayant procédé à la rétro-ingénierie du cadrage et de la structure des paquets.

IDs de paquets QMDL de référence

ID de paquet (hex)	Contenu	Protocole
0x1568	Message RRC OTA LTE	RRC 36.331
0x5226	Message RRC OTA NR	RRC 38.331
0x713A	Message NAS OTA LTE	NAS 24.301
0x7030	Message NAS OTA 5G	NAS 24.501
0x184B	Mesures cellule serveuse LTE ML1	PHY Couche 1
0x2584	Infos cellule serveuse NR ML1	PHY Couche 1
0x1472	Statistiques PDCP DL LTE	PDCP Couche 2

QMDL vs QMDL2 vs HLOG

Les formats de logs ne se valent pas tous. Comprendre les différences entre les trois formats les plus courants en travail terrain permet de choisir la bonne stratégie de capture.

Caractéristique	QMDL	QMDL2	HLOG
Format	Trames DM binaires	DM binaire étendu	Chiffré propriétaire
Horodatage	Relatif (QTimerTick)	UTC absolu	UTC absolu
Chiffrement	Aucun	Aucun	Chiffrement AEAD
GPS embarqué	Non	Optionnel	Oui
Chipsets supportés	Qualcomm (tous)	Snapdragon 8 Gen 2+	Appareils HiCellTek
Compatibilité écosystème	Large (QCAT, parsers)	Limitée	Outil HiCellTek
Taille de fichier	Grande (brut)	Grande	Compressée

Le format QMDL standard l’emporte pour l’interopérabilité. Ses horodatages QTimerTick relatifs nécessitent une étape de conversion (décrite ci-dessous dans la section parsing), mais son écosystème de parsers est suffisamment large pour que n’importe quelle équipe de post-traitement d’un vendeur télécom majeur puisse l’ouvrir et le décoder sans outillage propriétaire. Le QMDL2 étend cela avec un GPS optionnel et le temps UTC absolu, mais le support des parsers hors QCAT reste limité. Le HLOG est le format chiffré et compressé utilisé par les appareils HiCellTek — idéal pour les transferts terrain-bureau sécurisés, mais il nécessite l’outil HiCellTek pour le décodage.

Pour les soumissions de tickets de défauts opérateurs et le post-traitement multi-vendeur, le QMDL est le format qui voyage le mieux.

Comment capturer un QMDL sur le terrain

La capture QMDL nécessite un smartphone Android avec un chipset Qualcomm Snapdragon, un accès root via Magisk, et l’interface DIAG activée sur l’appareil. La plupart des appareils terrain de grade professionnel exposent le port DIAG à /dev/diag.

Le masque de log est le paramètre de configuration le plus important dans toute capture QMDL. Le masque est envoyé au modem via la commande DM 0x7C et indique au chipset exactement quels IDs de paquets inclure dans le flux de sortie. Un masque mal configuré est la raison la plus fréquente d’arriver en post-traitement avec un fichier QMDL ne contenant aucun message RRC — une erreur qui gâche une journée entière de données terrain. Avant tout long drive, vérifiez toujours que le masque active explicitement au minimum les IDs 0x1568 (RRC LTE), 0x5226 (RRC NR), 0x713A (NAS LTE) et 0x7030 (NAS 5G).

Un drive d’une heure typique à masque complet génère entre 200 Mo et 800 Mo de données QMDL brutes, selon l’activité réseau, la densité de cellules et le nombre d’IDs de paquets activés. Pour les campagnes d’optimisation, prévoyez 5 à 20 Go de QMDL par appareil et par jour.

Parser un QMDL — du binaire au protocole décodé

Le binaire QMDL brut ne peut pas être lu directement. Le parsing nécessite quatre étapes séquentielles qui convertissent le flux binaire en messages protocolaires lisibles.

Étape 1 — Extraction des trames DM : le flux binaire est encadré selon un encodage de type HDLC, où 0x7E est l’octet d’encadrement qui marque le début et la fin de chaque trame DM. Le parser doit parcourir le flux, identifier les frontières et extraire les trames individuelles. Les octets échappés (séquences 0x7D) doivent être désescapés avant tout traitement.

Étape 2 — Lookup de l’ID de paquet : une fois la trame extraite, les deux premiers octets du payload identifient le type de paquet log. Un lookup dans une table d’IDs de paquets connus détermine si la trame contient un message RRC OTA, une PDU NAS, un enregistrement de mesure PHY ou un autre type de log.

Étape 3 — Décodage ASN.1 : pour les trames RRC et NAS (0x1568, 0x5226, 0x713A, 0x7030), le payload après l’en-tête de paquet contient un message 3GPP encodé en ASN.1 PER. Le décodage de celui-ci nécessite un décodeur ASN.1 compilé sur la bonne version de la spécification 3GPP (36.331 pour RRC LTE, 38.331 pour RRC NR, 24.301 pour NAS LTE, 24.501 pour NAS 5G). Le résultat décodé est identique à ce qu’affichent les outils terrain professionnels — parce que les données protocolaires sous-jacentes sont les mêmes.

Étape 4 — Conversion des horodatages : les trames DM embarquent une valeur QTimerTick sur 32 bits. La conversion de cette valeur en heure réelle nécessite de connaître la fréquence du timer du chipset, qui est de 19,2 MHz sur la plupart des plateformes Snapdragon. La formule est : heure_UTC = référence_UTC + (QTimerTick / 19200000). L’ancre UTC de référence est généralement extraite d’un événement de synchronisation GPS ou d’un horodatage NTP embarqué dans la session de capture.

Pour les équipes qui ont besoin de décoder des messages RRC ou NAS individuels extraits d’un QMDL sans faire tourner une pile complète de parsers, le décodeur en ligne de protocoles L3 RRC et NAS supporte le collage direct de payloads encodés en hexadécimal et produit une sortie ASN.1 structurée.

Pour les ingénieurs qui préfèrent un décodage en temps réel natif sur le terrain sans QCAT, l’outil de drive test Android avec accès DIAG natif capture et décode les flux QMDL directement sur l’appareil pendant le drive, supprimant la boucle de post-traitement pour une identification rapide des défauts.

Bonnes pratiques QMDL sur le terrain

Connaître le format est une chose. L’utiliser efficacement dans une vraie campagne d’optimisation nécessite un ensemble de pratiques opérationnelles que les ingénieurs terrain expérimentés développent sur des années de travail en drive.

Nommage des fichiers : incluez toujours la date, l’ID du site et le segment de drive dans le nom de fichier — par exemple 2026-03-27_SITE-A_SEG1.qmdl. Cela rend la corrélation avec les traces GPS et les exports de KPI immédiate, et évite le problème de disambiguation de fichiers qui affecte les équipes de post-traitement recevant des lots de captures de plusieurs ingénieurs.

Rotation des logs : pour les drives de plus de 30 minutes, configurez votre outil de capture pour effectuer une rotation de fichiers toutes les 30 minutes. Les fichiers dépassant 2 Go provoquent des échecs de parsing dans plusieurs outils courants et ralentissent l’étape de scan initial. Des fichiers plus petits permettent également le traitement parallèle de différents segments de drive.

Corrélation GPS : les fichiers QMDL ne contiennent aucune donnée GPS par défaut. L’approche standard consiste à capturer une trace GPX en parallèle et à la corréler avec les horodatages QMDL après application de la conversion QTimerTick vers UTC. Certains outils de drive test Android gèrent automatiquement cette corrélation et embarquent le GPS dans un fichier sidecar. Le format QMDL2 supporte l’embarquement GPS optionnel, ce qui simplifie cette étape sur les chipsets compatibles.

Preuves pour tickets vendeurs : conformément au 3GPP TS 37.320 (mode test UE), les logs QMDL avec horodatages des messages RRC sont acceptés comme preuves primaires lors des escalades de tickets de défauts vendeurs. Pour préparer un ticket, extrayez les trames 0x1568 ou 0x5226 pertinentes autour de l’événement de défaillance, convertissez-les en ASN.1 lisible et joignez à la fois le segment QMDL brut et le résultat décodé. Cette combinaison élimine toute ambiguïté sur ce que l’UE a réellement envoyé et reçu.

Confidentialité et sécurité : les fichiers QMDL contiennent l’IMSI et l’IMEI de l’appareil dans les paquets NAS Attach et Registration Request. Avant de partager tout fichier QMDL hors de votre organisation — avec des vendeurs, opérateurs ou partenaires — supprimez ou anonymisez les payloads NAS contenant ces identifiants. Ne pas le faire constitue une fuite de données personnelles au sens de l’article 4(1) du RGPD, l’IMSI étant un identifiant d’abonné directement lié à une personne.

Planification du stockage : une campagne d’optimisation LTE/NR typique génère 5 à 20 Go de QMDL par appareil et par jour. Pour une équipe de quatre ingénieurs sur une campagne de deux semaines, cela représente 280 à 1 120 Go de données brutes. Planifiez l’infrastructure de stockage terrain, de transfert et d’archivage avant le début de la campagne — et non après.

Conclusion

Le QMDL n’est pas qu’un format de fichier — c’est l’enregistrement le plus complet de ce qui s’est passé entre un appareil et un réseau à chaque couche protocolaire. Savoir le capturer efficacement, le parser correctement et extraire les bons IDs de paquets fait la différence entre un ingénieur qui dit « j’ai vu un échec de handover » et celui qui peut le prouver avec une séquence RRC précise à la milliseconde.

Les quatre IDs de paquets qui couvrent 90 % des scénarios de troubleshooting terrain sont 0x1568, 0x5226, 0x713A et 0x7030. Maîtrisez le masque de log qui les active, comprenez l’encadrement de type HDLC qui structure le flux binaire, et appliquez la conversion QTimerTick pour une corrélation temporelle précise — et le QMDL devient un instrument de diagnostic aussi précis que la spécification du réseau elle-même.

Question pour les commentaires : quel est le problème le plus complexe que vous ayez résolu grâce à l’analyse QMDL — et quel ID de paquet a été la clé ?