HiCellTek Events : capture passive et scripted testing sur un seul smartphone

Il est 2 h 15 du matin. Un ingénieur RF est garé au sous-sol B2 d’un centre commercial, smartphone posé sur le tableau de bord, outil de drive test en enregistrement. Son script de mesure exécute un cycle d’appels VoLTE toutes les 90 secondes et un test de débit HTTP entre chaque appel. Les résultats tombent : appels établis, débit correct, MOS acceptable. Vert partout.

Pourtant, entre deux cycles, un appel VoLTE entrant échoue silencieusement. Le terminal tente un RRC Connection Request, reçoit un Reject, bascule en fallback CSFB, puis perd le service pendant 4,2 secondes. Le script ne capture rien. Pour l’outil, cet intervalle n’existe pas.

Quand j’ai vu des équipes terrain rater des Radio Link Failures systématiquement parce que leurs scripts ne les cherchaient pas, j’ai compris que le problème n’était pas la configuration. C’était l’architecture même du drive test.

Ce que le scripted testing ne voit pas

Le drive test scripté est un pilier de l’optimisation réseau depuis vingt ans. Un scénario prédéfini déclenche des appels, des sessions data, des SMS selon une séquence contrôlée. Les résultats sont reproductibles, comparables, exploitables pour le benchmarking.

Mais la reproductibilité a un prix : elle ne capture que ce qu’elle provoque. Les études d’Opensignal et de la GSMA confirment un écart persistant entre les KPI mesurés en drive test et la QoE réelle des abonnés. L’explication est structurelle : le script ignore tout ce qui se passe entre ses propres stimuli.

Ce qu’un script traditionnel rate systématiquement :

• Les Radio Link Failures (RLF) entre deux cycles de mesure
• Les changements d’état RRC provoqués par le réseau
• Les tentatives de handover échouées non corrélées à un test actif
• Les sessions data applicatives (push notifications, synchronisations)
• Les événements Call Manager (CM) déclenchés par le réseau
• Les procédures NAS (attach, detach, TAU) révélant le comportement de la couche coeur

Ce n’est pas un défaut de configuration. C’est une limitation architecturale du modèle stimulus-réponse sur lequel reposent les chaînes de mesure traditionnelles.

HiCellTek Events : écouter le chipset en temps réel

C’est exactement le problème que résout HiCellTek Events. Au lieu de commander des actions et de mesurer leurs résultats, notre moteur de capture passive écoute en permanence l’interface DIAG du chipset Qualcomm : le canal binaire natif qui transporte chaque message interne entre le modem cellulaire et le processeur applicatif.

Chaque événement est interprété dès sa réception, pas dans un logiciel de post-traitement. Un NR_RADIO_LINK_FAILURE est identifié à la milliseconde. Un LTE_RRC_STATE_CHANGE est horodaté avec la précision du bus DIAG.

Cette granularité permet de corréler des événements qui semblent indépendants en post-traitement mais qui sont liés par quelques dizaines de millisecondes. Exemple concret : un CM_DS_CALL_EVENT_ORIG (tentative d’appel) suivi 80 ms plus tard d’un LTE_ESM_OUTGOING_MSG (activation de bearer EPS), puis 200 ms plus tard d’un échec RRC. Cette séquence de 280 ms révèle un problème de dimensionnement de bearer VoLTE que ni un script d’appel (qui verra juste “appel échoué”) ni un analyseur de couverture (qui verra des niveaux RF corrects) ne pourront diagnostiquer seuls.

Six couches protocolaires sont décodées simultanément, chacune filtrée par code couleur dans l’interface :

Lors d’une session terrain de 30 minutes en zone urbaine, HiCellTek Events capture typiquement plus de 40 événements distincts — RLF silencieux, transitions RRC erratiques, échecs de bearer, restrictions d’accès SSAC — tous horodatés, filtrables, consultables via le moteur de recherche intégré.

La capture d’écran ci-dessous montre une session live sur le terrain : un appel VoLTE placé par l’utilisateur (pas par un script), avec les événements réseau capturés automatiquement et les KPI RF en temps réel.

Scripted + passif : pourquoi nous avons fusionné les deux

Chez HiCellTek, nous n’avons pas conçu la capture passive comme un remplacement du scripted testing. Nous avons construit les deux dans le même outil parce qu’ils répondent à des questions différentes — et que les réponses n’ont de valeur que corrélées.

L’ingénieur lance ses scripts de benchmark habituels — campagne d’appels VoLTE, test de débit HTTP, ping continu — tout en capturant automatiquement tout ce que le terminal fait en dehors de ces scripts. Quand un appel scripté échoue, HiCellTek Events montre la séquence exacte de messages RRC, NAS et CM qui a précédé l’échec. Quand le débit chute pendant un test HTTP, les événements passifs révèlent si un handover a eu lieu ou si le terminal a subi un RLF.

Ce niveau de corrélation était jusqu’ici réservé aux chaînes de mesure lourdes avec analyseur de protocole dédié et logiciel de post-traitement. L’exécuter en temps réel sur un smartphone Android commercial change l’économie du drive test.

Ce que HiCellTek fait différemment

Les outils existants — TEMS, Nemo, XCAL — font du décodage DIAG. Ce n’est pas nouveau. Ce qui est nouveau, c’est la combinaison de trois capacités qui n’existaient pas ensemble avant HiCellTek :

Pour la qualité vocale, le scoring MOS est calculé par l’algorithme ViSQOL, un modèle perceptuel développé par Andrew Hines à TU Dublin, qui évalue la qualité en mode no-reference. Contrairement aux approches POLQA traditionnelles nécessitant un fichier source connu, ViSQOL permet de scorer aussi bien les appels scriptés que les appels passifs capturés de manière opportuniste.

Voyez ce que vos outils actuels ne capturent pas

Nous ouvrons l’accès early adopter à HiCellTek Events pour les équipes terrain qui veulent voir ce qui se passe réellement entre leurs mesures scriptées.

Demander une démo live — nous vous montrons HiCellTek Events sur un vrai réseau, avec vos scénarios de test, en 20 minutes.

Accès early adopter — installez HiCellTek sur vos smartphones de test et voyez la différence sur votre prochain drive test.

Une question technique ? Écrivez-nous directement : sales@hicelltek.com