Escalade opérateur et vendor ticket : construire un dossier de preu...

Un vendor ticket n’a de valeur que si les preuves terrain qui l’accompagnent sont complètes, structurées et exploitables. La réalité du terrain est pourtant tout autre : les données sont dispersées entre plusieurs outils, les captures d’écran sont partielles, les traces sont incomplètes, et le format du dossier varie d’un ingénieur à l’autre. Résultat : le premier retour du vendor est systématiquement le même — “Can you reproduce and send traces?”.

Cet article présente une méthode structurée pour constituer un dossier de preuve terrain complet dès la première soumission, en exploitant les capacités d’export de HiCellTek pour produire un pack d’escalade prêt à l’envoi.

Pourquoi les vendor tickets échouent

Le cycle d’escalade typique

Voici le cycle d’un vendor ticket mal documenté :

L’ingénieur terrain détecte un problème (coupure d’appel, handover échoué, débit anormal)
Il ouvre un ticket avec une description textuelle : “Handover failure sur site X, RSRP OK, SINR OK, mais coupure”
Le NOC/SOC transmet au vendor avec les informations disponibles
Le vendor répond : “Merci. Pouvez-vous fournir les traces L3, les UE capabilities, la configuration CA, les MRDC combinations, et le contexte radio complet (PCI, EARFCN/NR-ARFCN, RSRP/RSRQ/SINR serving et neighbors) ?”
L’ingénieur doit retourner sur le terrain, reproduire le problème, capturer les traces manquantes
Délai : 3 à 10 jours perdus. Si le problème est intermittent, la reproduction échoue
Le ticket stagne ou est fermé “cannot reproduce”

Ce cycle est un gouffre de productivité. Un dossier complet dès la première soumission élimine les allers-retours et accélère la résolution.

Les 5 erreurs les plus fréquentes dans les vendor tickets

Erreur	Conséquence	Fréquence
Pas de traces Layer 3 (RRC/NAS)	Le vendor ne peut pas analyser la cause root	80% des tickets
UE Capabilities manquantes	Le vendor ne sait pas ce que le terminal supporte	70% des tickets
Pas de contexte radio (PCI, band, RSRP)	Le vendor ne peut pas situer le problème	60% des tickets
Screenshots au lieu de données brutes	Non exploitable dans les outils d’analyse du vendor	50% des tickets
Pas de timestamp précis	Impossible de corréler avec les logs réseau côté vendor	45% des tickets

Anatomie d’un dossier de preuve terrain complet

Un dossier de preuve terrain exploitable par un vendor doit contenir 6 blocs d’information. Chaque bloc répond à une question que le vendor va poser.

Bloc 1 : Contexte radio au moment du problème

Question du vendor : “Dans quelles conditions radio le problème s’est-il produit ?”

Données requises :

PCI (Physical Cell Identity) de la cellule servante
EARFCN (LTE) / NR-ARFCN (5G NR) : identifiant de fréquence
Bande : B1, B3, B7, n78, etc.
RSRP, RSRQ, SINR de la cellule servante
RSRP, RSRQ, SINR des cellules voisines (top 3 minimum)
Timestamp précis (format UTC ou avec fuseau horaire explicite)
Coordonnées GPS du point de mesure

Ce contexte permet au vendor de retrouver l’instant exact dans ses logs réseau et de corréler avec les compteurs eNB/gNB.

Bloc 2 : Messages Layer 3 — RRC

Question du vendor : “Que s’est-il passé au niveau de la signalisation radio ?”

Les messages RRC racontent l’histoire de la connexion radio entre le terminal et le réseau. Les messages critiques pour un vendor ticket :

En LTE :

RRCConnectionSetup / RRCConnectionSetupComplete : établissement de la connexion
RRCConnectionReconfiguration : handover, ajout/retrait de SCell, modification bearer
RRCConnectionRelease : libération de la connexion (examiner la cause)
RRCConnectionReestablishmentRequest : tentative de rétablissement après échec
MeasurementReport : les mesures radio que le terminal reporte au réseau

En 5G NR :

RRCSetup / RRCSetupComplete
RRCReconfiguration : handover, beam management, ajout SCG
RRCRelease : libération
RRCReestablishmentRequest : échec de connexion
MeasurementReport : mesures per-beam (SSB RSRP)
UECapabilityInformation : réponse aux capability enquiries du réseau

La capture des messages RRC complets (pas uniquement les noms de messages, mais le contenu décodé ASN.1) est indispensable. Un simple “RRC Reconfiguration reçu” ne suffit pas — le vendor a besoin du contenu pour voir quelle configuration a été appliquée.

Pour une compréhension approfondie des messages Layer 3, consultez notre guide technique Layer 3 LTE/5G.

Bloc 3 : Messages Layer 3 — NAS

Question du vendor : “Que s’est-il passé au niveau du core network ?”

Les messages NAS concernent l’enregistrement, l’authentification et la gestion des sessions data :

Messages NAS critiques :

Attach Request / Attach Accept / Attach Reject : enregistrement initial
TAU (Tracking Area Update) : mise à jour de localisation
Service Request : demande de service (data, voix)
PDN Connectivity Request / Activate Default Bearer : établissement de session data
ESM Information Request / Response : configuration de bearer
Detach : déconnexion du réseau

En 5G SA :

Registration Request / Accept / Reject
PDU Session Establishment Request / Accept
Service Request
Deregistration

Les messages NAS avec un code de rejet (cause code) sont particulièrement importants pour les vendors : ils indiquent pourquoi le core network a refusé une demande.

Bloc 4 : UE Capabilities et combinaisons supportées

Question du vendor : “Qu’est-ce que ce terminal supporte réellement ?”

C’est le bloc le plus souvent manquant dans les vendor tickets, et pourtant c’est celui qui permet de déterminer si un problème est une limitation terminal ou un défaut réseau.

Les UE Capabilities incluent :

Bandes supportées : LTE bands, NR bands, SUL bands
Carrier Aggregation (CA) combinations : combinaisons de bandes simultanées supportées (BandCombination-v1590, etc.)
MRDC (Multi-RAT Dual Connectivity) combinations : combinaisons LTE+NR supportées (EN-DC, NE-DC, NR-DC)
Catégorie UE : Cat 4, Cat 6, Cat 12, Cat 18, etc. (LTE) ou feature sets (NR)
Modulations supportées : 256QAM DL/UL, 1024QAM
MIMO layers : 2x2, 4x4 DL, 1T2R UL
Codecs vocaux : AMR-NB, AMR-WB, EVS (et débits supportés)

Exemple concret : un terminal signale ne pas bénéficier de l’agrégation de porteuses en 5G NR. Le vendor demande les CA/MRDC combinations du terminal. Si le terminal ne supporte pas la combinaison n78+n1 configurée sur le réseau, ce n’est pas un bug réseau — c’est une incompatibilité terminal. Sans les UE Capabilities dans le ticket, cette conclusion est impossible.

Bloc 5 : Configuration active au moment du problème

Question du vendor : “Quelle configuration était active sur le terminal ?”

Au-delà de ce que le terminal supporte (Bloc 4), le vendor a besoin de savoir ce qui était effectivement configuré au moment du problème :

SCell(s) active(s) : quelles bandes étaient agrégées au moment du problème
SCG configuration : en EN-DC, quelle était la configuration NR active
DRX configuration : cycle DRX actif (impact sur les mesures et le handover)
Bearer configuration : QCI/5QI des bearers actifs, TFT filters
Measurement configuration : quels événements de mesure étaient configurés (A1-A6, B1-B2)

Ces informations sont contenues dans les messages RRCConnectionReconfiguration (LTE) ou RRCReconfiguration (NR) les plus récents avant le problème.

Bloc 6 : Traces et exports exploitables

Question du vendor : “Pouvez-vous envoyer les traces brutes ?”

Le vendor dispose d’outils d’analyse propriétaires qui nécessitent des formats spécifiques. Les formats exploitables :

Format	Usage	Avantage
QMDL	Analyse dans les outils Qualcomm	Format natif, aucune perte d’information
PCAP	Analyse protocolaire (Wireshark)	Standard ouvert, filtrable
JSON structuré	Intégration dans des outils custom	Parseable, scriptable
CSV	Analyse dans Excel/Python	KPIs tabulaires, graphiques rapides
HLOG	Format HiCellTek chiffré	Archivage sécurisé, rejouable

Point critique : les captures d’écran ne sont PAS des traces exploitables. Un screenshot d’un graphique RSRP ne permet pas au vendor de filtrer les données, de zoomer sur l’instant du problème, ou de corréler avec ses propres logs. Les données brutes sont indispensables.

Construire le dossier avec HiCellTek : workflow en 5 étapes

Étape 1 : Capture terrain complète

Avant de sortir sur le terrain, configurer HiCellTek pour capturer tous les KPIs et messages nécessaires :

Activer la capture Layer 3 complète (RRC + NAS)
Activer l’enregistrement des UE Capabilities
Activer la capture des KPIs radio (serving + neighbors)
Activer le GPS logging
Activer le format d’export souhaité (QMDL + PCAP recommandé)

HiCellTek capture l’ensemble de ces données simultanément en temps réel, depuis l’interface DIAG Qualcomm. Pas besoin de lancer plusieurs outils ou de synchroniser des captures disparates.

Étape 2 : Reproduction et marquage

Sur le terrain, reproduire le problème et marquer le moment exact :

Utiliser la fonction de bookmark/marker dans HiCellTek pour marquer l’instant du problème
Le marker crée un timestamp précis dans les traces, facilitant la localisation par le vendor
Si le problème est intermittent, laisser la capture tourner en continu et marquer chaque occurrence

Étape 3 : Extraction des UE Capabilities

HiCellTek décode et exporte les UE Capabilities du terminal en format structuré :

Bandes supportées : liste complète avec bandwidth classes
CA combinations : tableau des combinaisons CA supportées avec MIMO layers
MRDC combinations : combinaisons EN-DC/NE-DC avec détail des composantes
Feature sets : NR feature sets per CC et per UE

L’export est formaté pour être directement intégrable dans un vendor ticket, sans retraitement.

Pour une référence détaillée sur les UE Capabilities et les MRDC combinations, consultez notre article dédié UE Capabilities et CA/MRDC combos.

Étape 4 : Génération du rapport structuré

HiCellTek génère un rapport d’escalade structuré contenant les 6 blocs décrits ci-dessus :

En-tête : date, heure, localisation GPS, terminal, opérateur, version firmware
Contexte radio : tableau des KPIs serving + neighbors au moment du marker
Traces Layer 3 : messages RRC/NAS décodés (ASN.1 lisible) autour du marker
UE Capabilities : export structuré des capabilities et combinaisons
Configuration active : SCell, SCG, bearers, measurement config
Fichiers joints : QMDL, PCAP, CSV pour analyse approfondie

Étape 5 : Export et transmission

L’export depuis HiCellTek produit un package complet :

Fichier QMDL (traces brutes compatibles avec les outils d’analyse Qualcomm)
Fichier JSON structuré (KPIs + messages L3 + UE Capabilities)
Fichier CSV (KPIs tabulaires pour analyse rapide)
Rapport PDF (synthèse visuelle avec cartes et graphiques)

Ce package est directement transmissible au vendor ou au NOC, sans post-processing.

Template de vendor ticket structuré

Voici la structure recommandée pour un vendor ticket efficace, avec les données produites par HiCellTek :

Section 1 : Description du problème

PROBLÈME : [Description concise — ex. "Handover failure LTE→NR sur bande n78"]
IMPACT : [Impact opérationnel — ex. "Coupure data pendant 3-5 secondes"]
FRÉQUENCE : [Intermittent / Systématique / Conditionnel]
PREMIER CONSTAT : [Date et heure]
REPRODUCTIBILITÉ : [Oui/Non — si oui, conditions]

Section 2 : Contexte environnemental

SITE(S) CONCERNÉ(S) : [Site ID, nom, coordonnées GPS]
TERMINAL : [Modèle, chipset, version firmware, version modem]
OPÉRATEUR : [Nom, PLMN]
BANDE(S) : [LTE: B1/B3/B7 — NR: n78]
CONFIGURATION RÉSEAU : [CA, EN-DC, SA, NSA]

Section 3 : Données terrain (produites par HiCellTek)

TIMESTAMP DU PROBLÈME : [UTC précis au format ISO 8601]
CONTEXTE RADIO :
  - Serving: PCI=XXX, EARFCN=XXXX, RSRP=-XX dBm, RSRQ=-XX dB, SINR=XX dB
  - Neighbor 1: PCI=YYY, EARFCN=YYYY, RSRP=-XX dBm
  - Neighbor 2: PCI=ZZZ, EARFCN=ZZZZ, RSRP=-XX dBm
GPS : [Lat, Lon]

Section 4 : Analyse Layer 3

DERNIER MESSAGE RRC AVANT LE PROBLÈME : [Type + résumé]
MESSAGE RRC DU PROBLÈME : [Type + résumé — ex. "RRC Re-establishment, cause: handoverFailure"]
MESSAGES NAS PERTINENTS : [Type + résumé si applicable]
UE CAPABILITIES SUMMARY :
  - CA support: [Oui/Non — combos pertinentes]
  - MRDC support: [EN-DC combos pertinentes]
  - Max layers DL: [2/4]
  - 256QAM DL/UL: [Oui/Non]

Section 5 : Pièces jointes

1. Traces QMDL : [nom du fichier, durée, taille]
2. Export PCAP : [nom du fichier]
3. Export CSV KPIs : [nom du fichier]
4. Rapport PDF : [nom du fichier]
5. UE Capabilities export : [nom du fichier]

Bonnes pratiques d’escalade

Timing

Soumettre le ticket dans les 24h suivant la capture terrain. Les logs côté vendor ont une rétention limitée (souvent 7 à 14 jours). Plus le ticket est ancien, moins les logs côté réseau seront disponibles pour la corrélation.

Communication

Un problème par ticket. Ne pas regrouper plusieurs problèmes dans un seul ticket — cela dilue l’attention et complique le suivi.
Être factuel. Décrire ce qui a été observé (messages L3, KPIs), pas ce que vous pensez être la cause. Le vendor a le contexte côté réseau que vous n’avez pas.
Fournir les données brutes ET le résumé. Le résumé permet au L1/L2 du vendor de qualifier le ticket rapidement. Les données brutes permettent au L3/L4 de faire l’analyse approfondie.

Suivi

Demander un accusé de réception avec un numéro de ticket côté vendor
Relancer à J+3 si pas de réponse substantielle
Fournir les données complémentaires proactivement si le problème est reproduit avec de nouvelles captures

Conclusion : un dossier complet dès le premier envoi

La qualité d’un vendor ticket se mesure au nombre d’allers-retours nécessaires avant résolution. Un dossier complet — contexte radio, traces Layer 3 décodées, UE Capabilities, configuration active, et données brutes exportables — élimine le cycle classique “reproduce and send traces” qui fait perdre des jours à des semaines.

HiCellTek capture, décode et exporte l’ensemble de ces données depuis un seul smartphone sur le terrain. Le résultat est un package d’escalade structuré, prêt à être transmis au vendor sans post-processing ni dispersion entre plusieurs outils.

Vous souhaitez réduire le temps de résolution de vos vendor tickets ? Contactez-nous à sales@hicelltek.com ou visitez hicelltek.com pour découvrir comment HiCellTek structure vos preuves terrain automatiquement.

Escalade opérateur et vendor ticket : construire un dossier de preuve terrain structuré