Parser DIAG Qualcomm : anatomie d'un protocole de diagnostic mobile
Analyse technique du protocole DIAG Qualcomm : framing HDLC, CRC-16, codes de log, dispatch multi-radio. Comprendre le protocole pour mieux exploiter les données terrain.
Tous les outils de diagnostic réseau mobile qui fonctionnent sur chipset Qualcomm — TEMS, Nemo, Actix, et HiCellTek — reposent sur le même fondement technique : le protocole DIAG. C’est par ce canal que le modem Qualcomm expose ses données internes : messages Layer 3, mesures RF, événements radio, statistiques de performance. Comprendre l’anatomie de ce protocole permet de mieux appréhender les capacités et les limites des outils qui l’exploitent.
Qu’est-ce que le protocole DIAG ?
Le protocole DIAG (pour Diagnostic) est l’interface de communication entre le processeur applicatif (AP) d’un smartphone et le modem baseband Qualcomm. Il fonctionne sur un canal série virtuel accessible via le device /dev/diag sous Android (ou via un driver USB sous Windows).
Ce protocole remonte aux premiers chipsets Qualcomm des années 1990 (CDMA IS-95). Il a évolué avec chaque génération de technologie radio (CDMA2000, WCDMA, LTE, NR) tout en conservant sa structure fondamentale.
Position dans l’architecture
Application Layer (Android)
|
v
/dev/diag (character device, root access required)
|
v
DIAG Protocol Layer (HDLC framing)
|
v
Modem Baseband (Qualcomm Snapdragon DSP)
|
v
Radio Hardware (RF front-end, antennes)L’accès au device /dev/diag nécessite les privilèges root, ce qui explique pourquoi tous les outils de drive test sur smartphone Android Qualcomm exigent le root (Magisk).
Structure d’une trame DIAG
Framing HDLC
Le protocole DIAG utilise le framing HDLC (High-Level Data Link Control), un standard de couche liaison :
| Champ | Taille | Description |
|---|---|---|
| Flag de début | 1 octet | 0x7E — délimiteur de début de trame |
| Payload | Variable | Données DIAG (commande + payload) |
| CRC-16 | 2 octets | CRC-CCITT sur le payload |
| Flag de fin | 1 octet | 0x7E — délimiteur de fin de trame |
Le mécanisme de byte stuffing (escape 0x7D) est utilisé pour les occurrences de 0x7E et 0x7D dans le payload : chaque octet réservé est remplacé par 0x7D suivi de l’octet XOR 0x20.
Vérification CRC-16
Le CRC-16 CCITT (polynome 0x8408, seed 0xFFFF) est calculé sur le payload brut avant byte stuffing. Tout paquet dont le CRC ne correspond pas doit être rejeté — ce qui arrive régulièrement en conditions de charge modem ou de buffer overflow.
Types de commandes DIAG
Le premier octet du payload identifie le type de commande :
| Code commande | Type | Description |
|---|---|---|
0x10 | Log | Message de log (L3, RF, événement) |
0x60 | Event | Événement asynchrone du modem |
0x73 | Log config | Configuration des masques de log |
0x75 | Message | Message texte du modem (F3) |
0x98 | Extended log | Log étendu (multi-radio, NR) |
0x4B | Subsys | Commande de sous-système |
Structure d’un message de log (0x10)
Les messages de log constituent la majorité du trafic DIAG utile. Leur structure :
| Champ | Taille | Description |
|---|---|---|
| Cmd code | 1 octet | 0x10 |
| More flag | 1 octet | Fragmentation |
| Length | 2 octets | Taille totale du log |
| Log code | 2 octets | Identifiant du type de log |
| Timestamp | 8 octets | Horodatage modem (ticks) |
| Payload | Variable | Données du log |
Le log code est la clé de voûte du système. C’est lui qui identifie le contenu du payload :
| Log code | Contenu |
|---|---|
0xB0C0 | LTE RRC OTA (messages RRC over-the-air) |
0xB0EC | LTE NAS ESM plain |
0xB821 | NR RRC OTA |
0xB097 | LTE ML1 Serving Cell (RSRP, RSRQ, SINR) |
0xB825 | NR ML1 Serving Cell |
0xB16E | LTE PDCP DL Statistics |
Qualcomm maintient des milliers de log codes, dont beaucoup ne sont pas documentés publiquement. Chaque nouveau chipset peut ajouter, modifier ou déprécier des log codes.
Les défis du parsing DIAG
Protocole non documenté publiquement
Qualcomm ne publie pas de spécification officielle du protocole DIAG. Les développeurs d’outils tiers doivent :
- Utiliser les rares documents internes qui circulent dans l’industrie
- Faire du reverse engineering sur les trames capturées
- Maintenir une base de connaissance des log codes par chipset et par version firmware
Évolution par chipset
Chaque génération de chipset Qualcomm (Snapdragon 888, 8 Gen 1, 8 Gen 2, 8 Gen 3, 8 Elite) peut modifier :
- La structure interne des payloads de log (ajout de champs, changement de taille)
- Les log codes utilisés pour un même type d’information
- Le comportement du dispatcher multi-radio (sub-ID pour NR vs LTE)
- Les commandes de configuration des masques de log
Un parser qui fonctionne parfaitement sur Snapdragon 888 peut produire des données incorrectes sur Snapdragon 8 Gen 3 si les structures n’ont pas été mises à jour.
Multi-radio et multi-SIM
Les chipsets modernes gèrent simultanément :
- LTE + NR (mode NSA/SA) sur des stacks radio distinctes
- Dual-SIM (DSDS/DSDA) avec deux subscriptions actives
- Carrier Aggregation avec plusieurs composantes porteuses
Le dispatcher DIAG doit démultiplexer correctement ces flux : chaque log porte un subscription ID (pour dual-SIM) et un radio technology indicator (pour LTE vs NR). Un parser qui ignore ces indicateurs mélangera les données des deux SIM ou des deux technologies.
Performance et débit
En conditions de collecte active (masques de log complets pour LTE + NR + NAS), le modem peut générer 5 à 15 Mo/s de données DIAG brutes. Le parser doit :
- Traiter le framing HDLC en temps réel
- Vérifier les CRC sans introduire de latence
- Dispatcher chaque log au handler approprié
- Gérer les buffers overflow sans perte silencieuse de données
Sur ARM64, cela exige un code natif C/C++ optimisé. Un parser en Java ou Python ne tiendra pas le débit.
Le DiagClient SDK de HiCellTek
Le DiagClient SDK de HiCellTek encapsule toute la complexité du protocole DIAG dans une bibliothèque production-ready :
Composants inclus
- HDLC framer/deframer : gestion complète du byte stuffing, CRC-16 CCITT, fragmentation
- Dispatcher multi-radio : démultiplexage LTE/NR et dual-SIM par subscription ID
- Handlers de log : parseurs pour 200+ log codes couvrant L1, L2, L3, RF, NAS
- HLOG Writer : écriture des données parsées dans le format HLOG chiffré (chiffrement authentifié)
- Configuration manager : activation/désactivation dynamique des masques de log via commandes
0x73
Plateformes supportées
| Plateforme | Format | Architecture |
|---|---|---|
| Android | .so (shared library) | ARM64 (aarch64) |
| Linux | .so | ARM64 / x86_64 |
| Windows | .dll | x86_64 |
Tarif
Le DiagClient SDK est proposé à 5 990 EUR/an, incluant :
- Mises à jour trimestrielles avec support des nouveaux chipsets
- Ajout de nouveaux log codes par release
- Support technique dédié
- Documentation API complète
Conclusion
Le protocole DIAG Qualcomm est le fondement technique de tout outil de diagnostic réseau mobile sur chipset Snapdragon. Sa complexité — framing HDLC, CRC-16, milliers de log codes non documentés, évolution par chipset, multi-radio, multi-SIM — en fait un composant difficile et coûteux à développer et maintenir en interne. Le DiagClient SDK de HiCellTek fournit un parser production-ready qui abstrait cette complexité et permet aux équipes R&D de se concentrer sur la valeur ajoutée de leur produit.
Consultez les tarifs du DiagClient SDK ou découvrez l’architecture complète du produit pour évaluer l’intégration dans votre solution.
Fondatrice HiCellTek. +15 ans dans les télécoms, côté opérateur, côté éditeur, côté terrain. Construit l'outil terrain que les ingénieurs RF méritent.
Demandez une démo personnalisée de HiCellTek, diagnostic réseau 2G/3G/4G/5G sur Android.