KPIs Drive Test 5G : La Référence Terrain Complète 2026
SS-RSRP, SS-SINR, CQI, MCS, RI, BLER, événements EN-DC : tous les KPIs 5G NR expliqués avec seuils 3GPP TS 38.215 et mapping cause racine.
Un ingénieur RF sur un site rural à minuit. Le cluster 5G SA vient d’être mis en service il y a 3 heures. Le SS-RSRP affiche -85 dBm, ce qui semble correct. Mais le débit est de 12 Mbps au lieu des 800 attendus. Pourquoi ? Parce que le RSRP seul ne dit rien sur la configuration des faisceaux, le rang MIMO, ou le MCS. La réponse se trouve dans la pile de KPIs de la couche 1, et savoir la lire est la différence entre un diagnostic de 3 heures et un ticket vendeur de 3 jours.
Cette référence couvre chaque KPI 5G NR qui compte sur le terrain : définitions, sources 3GPP, seuils de qualité, ce que l’API Android dissimule, et un mapping direct entre anomalie KPI et cause racine.
La pile de KPIs 5G NR
La 5G NR introduit une hiérarchie de KPIs fondamentalement différente de celle du LTE. Comprendre où chaque métrique se situe dans cette pile est le premier pas vers un diagnostic pertinent.
SS-RSRP : l’ancre de couverture
Le SS-RSRP (Synchronization Signal Reference Signal Received Power) est défini dans la norme 3GPP TS 38.215 §5.1.1. Il mesure la puissance linéaire moyenne des éléments de ressource portant les signaux de référence du bloc SS/PBCH (SSB). Plage : -44 à -156 dBm.
La distinction critique par rapport au RSRP LTE : le SS-RSRP est spécifique au faisceau. Chaque faisceau SSB possède sa propre valeur de RSRP. Un site émettant 8 faisceaux produit 8 mesures SS-RSRP distinctes. Le UE rapporte le faisceau avec le RSRP le plus élevé, mais les 7 autres sont déterminants pour les décisions de handover et la continuité de couverture. Seuils pratiques :
- Excellent : > -80 dBm (macro extérieur)
- Bon : -80 à -95 dBm
- Marginal : -95 à -110 dBm
- Faible : < -110 dBm (service en risque)
En environnement intérieur, un décalage de 10 à 15 dB s’applique, ramenant le seuil “bon” à > -95 dBm.
SS-RSRQ et SS-SINR : interférence et capacité
Le SS-RSRQ (Synchronization Signal Reference Signal Received Quality) exprime le rapport entre le SS-RSRP et la puissance totale reçue incluant les interférences. Plage : -43 à 20 dB. Il reflète simultanément le niveau d’interférence et la charge de la cellule, ce qui le rend moins précis pour l’isolation de cause racine, mais utile comme indicateur de premier niveau.
Le SS-SINR (Synchronization Signal Signal-to-Interference-plus-Noise Ratio) est le KPI le plus fiable pour la prédiction de capacité. Plage : -23 à 40 dB. Il mesure directement la qualité du signal reçu par rapport au bruit et aux interférences, sans dépendance à la charge de la cellule. Cible : > 20 dB pour exploiter le débit crête. En dessous de 0 dB, la cellule est dans un trou de couverture ou subit une pollution pilot sévère.
CSI-RSRP vs SS-RSRP : deux rôles distincts
Le CSI-RSRP utilise les CSI-RS (Channel State Information Reference Signals), transmis plus fréquemment et sur davantage d’éléments de ressource que le SSB. Les deux KPIs servent des objectifs diagnostiques différents :
- Utiliser le SS-RSRP pour l’évaluation de la couverture et la validation initiale du déploiement
- Utiliser le CSI-RSRP pour l’analyse des performances de beamforming, la qualité du beam tracking, et l’évaluation du précodage MIMO
Un écart entre SS-RSRP et CSI-RSRP au même emplacement pointe souvent vers un problème de gestion des faisceaux : le sweep SSB couvre le UE, mais le raffinement du faisceau CSI-RS échoue.
KPIs de couche 1 : ce que l’API Android dissimule
L’API téléphonie Android expose un sous-ensemble utile mais délibérément limité des données du modem. Pour le drive test, cette limitation n’est pas un désagrément mineur : elle masque l’intégralité du tableau diagnostique de la couche physique. L’interface Qualcomm DIAG donne accès à tout ce que le modem traite réellement.
| KPI | API Android | Qualcomm DIAG |
|---|---|---|
| SS-RSRP | Oui (approximatif) | Oui (précis, par SSB) |
| SS-SINR | Oui (depuis Android 11) | Oui |
| CQI | Non | Oui (wideband + subband) |
| RI (Rank Indicator) | Non | Oui |
| PMI | Non | Oui |
| MCS (DL/UL) | Non | Oui |
| BLER | Non | Oui |
| Resource Blocks alloués | Non | Oui |
| Statistiques HARQ | Non | Oui |
| Timing Advance | Non | Oui |
L’écart entre les données API et les données DIAG est l’écart entre “je vois la 5G” et “je comprends pourquoi le débit est de 12 Mbps.”
CQI (Channel Quality Indicator) : plage 0-15. Rapporté par le UE au scheduler pour indiquer le MCS maximal qu’il peut supporter. Un CQI < 7 signifie un ordre de modulation réduit, ce qui limite directement le débit. Le CQI wideband donne une valeur unique pour l’ensemble de la bande passante ; le CQI subband révèle des motifs d’évanouissement sélectif en fréquence que le moyennage wideband masque.
RI (Rank Indicator) et PMI (Precoding Matrix Indicator) : le RI indique le nombre de couches spatiales que le canal peut supporter. RI = 1 signifie une transmission mono-flux ; RI = 4 signifie quatre flux spatiaux simultanés. Le PMI indique au gNB quelle matrice de précodage appliquer. Ces deux valeurs définissent ensemble le point de fonctionnement MIMO et sont invisibles via l’API Android.
MCS (Modulation and Coding Scheme) : détermine directement les bits par élément de ressource. Le MCS 28 (256-QAM) délivre 8,64 bits par élément de ressource ; le MCS 0 (QPSK, faible rendement) en délivre 0,23. Ce ratio explique pourquoi 12 Mbps sur un site devant délivrer 800 Mbps est un problème de couche 1, pas un problème de réseau coeur.
BLER (Block Error Rate) : la fraction de blocs de transport reçus en erreur avant la retransmission HARQ. Cible : < 10 %. Au-delà, le scheduler opère dans une zone où les retransmissions HARQ consomment une part significative de la capacité.
Pour les travaux de drive test nécessitant une visibilité complète de la couche 1, un outil de drive test Android professionnel avec accès natif Qualcomm DIAG élimine intégralement ce déficit de l’API.
KPIs EN-DC : mesures spécifiques au mode NSA
En mode Non-Standalone (NSA), le UE maintient une double connectivité : une ancre LTE et un noeud secondaire NR fonctionnant simultanément. Cette architecture nécessite un ensemble de KPIs distincts des mesures RF NR standard.
Le MCG (Master Cell Group) gère le côté ancre LTE : il prend en charge le plan de contrôle, les décisions de mobilité et la signalisation NAS via le MME. Le SCG (Secondary Cell Group) est le porteur NR : tous les débits 5G y transitent.
KPIs NSA critiques sans équivalent dans les tests SA :
- SCG Add Success Rate : pourcentage d’ajouts réussis de la cellule secondaire NR. En dessous de 90 %, cela indique un problème NSA significatif. Chaque échec est mappé à une cause RRC spécifique et doit être corrélé avec la couverture NR au point d’échec.
- SCG Failure Rate : capture les échecs RACH, les défaillances de liaison radio et les erreurs de configuration. Selon la norme 3GPP TS 38.331, les échecs SCG sont rapportés via
SCGFailureInformationNRdans le message RRC. Chaque type d’échec pointe vers une cause racine différente. - Débit EN-DC (split MCG/SCG) : le ratio de contribution MCG (LTE) vs SCG (NR). Si le SCG ne contribue jamais de manière significative, le déploiement NSA est mal configuré ou la couverture NR est insuffisante au point de mesure.
- Délai de réordonnancement PDCP : latence inter-couches introduite par la répartition des PDU PDCP entre les chemins MCG et SCG. Un délai de réordonnancement élevé augmente la latence applicative même lorsque les conditions RF paraissent acceptables.
5G SA (Standalone)
- Plan de contrôle NR complet
- NAS sur coeur 5G (AMF)
- SS-RSRP + CSI-RSRP
- Événements Registration/Deregistration
- Gestion des PDU Sessions
- Network Slicing (S-NSSAI)
5G NSA (EN-DC)
- Ancre LTE + données NR
- NAS sur LTE (MME)
- KPIs MCG + SCG
- Événements SCG Add/Fail/Release
- Répartition débit dual connectivity
- Suivi réordonnancement PDCP
Mapping KPI vers cause racine
C’est la section qui convertit une campagne de mesure en diagnostic. Pour chaque anomalie KPI, il existe une interprétation spécifique et une action suivante précise.
| KPI observé | Cause racine probable | Action suivante |
|---|---|---|
| SS-SINR < 0 dB | Interférence sévère ou trou de couverture | Vérifier la liste des cellules voisines, pollution pilot |
| MCS < 5 (QPSK) | Couverture limitée, RSRP < -110 dBm | Optimisation puissance/tilt, qualification site |
| RI = 1 en continu | Corrélation spatiale élevée (chemin unique) | Vérification cross-polarisation antenne, réflexion |
| BLER > 10 % | Interférence ou instabilité de liaison | Vérifier canal adjacent, contrôler config ICIC |
| SCG Add Fail > 10 % | Trou de couverture NR ou erreur de configuration | Vérifier plan cellulaire NR, contrôler interface X2/Xn |
| TA > 500 µs | UE très éloigné de la cellule (> 75 km équivalent) | Bord de couverture, vérifier plan site |
| CQI < 7 | Canal dégradé, débit réduit attendu | Corréler avec RSRP, SINR, interférences |
Ce tableau est un point de départ, pas un arbre de décision complet. En pratique, les anomalies KPI apparaissent rarement de manière isolée. Un cluster terrain avec SINR < 0 dB, RI = 1 et BLER > 10 % simultanément pointe vers un scénario précis : le UE se trouve à la frontière de deux faisceaux forts de secteurs différents, en situation de pollution pilot, et la configuration antennaire nécessite une révision.
Machine d’état RRC et événements protocole
Les KPIs RF expliquent ce que fait la couche radio. Les événements protocole expliquent ce que le réseau décide. Les deux sont nécessaires pour fermer une boucle diagnostique.
Transitions d’état RRC
Les transitions RRC Connected vers RRC Idle trop fréquentes signalent un timer d’inactivité mal configuré. Chaque transition introduit un délai de ré-établissement de 50 à 200 ms, qui se cumule en conditions de mobilité. Si les logs de mesure montrent des dizaines de transitions Connected-to-Idle par minute, le timer d’inactivité est trop agressif pour le trafic de l’application.
Événements de rapport de mesure
Le réseau configure le UE avec des déclencheurs d’événements de mesure définis dans la norme 3GPP TS 38.331 :
- Événement A3 : une cellule voisine devient plus forte que la cellule servant d’un décalage défini. Déclenche le handover intra-fréquence.
- Événement B1 : une cellule inter-RAT dépasse un seuil configuré. Utilisé pour le fallback 5G vers LTE.
- Événement B2 : la cellule servant tombe sous un seuil tandis qu’un voisin dépasse un autre. Utilisé pour le handover inter-RAT quand la couverture se dégrade.
Tous ces événements sont transportés dans les messages RRC MeasurementReport. Les capturer et les décoder est le seul moyen de comprendre pourquoi un handover a été déclenché, s’il était approprié, et si la cellule cible choisie était la bonne.
Événements NAS en 5G SA
Dans les déploiements Standalone, la couche NAS fournit une seconde dimension diagnostique :
- Registration Request / Accept / Reject : un enregistrement rejeté avec le code de cause
#7 (5GS services not allowed)ou#22 (congestion)pointe vers un problème de configuration ou de capacité AMF qui est totalement invisible aux KPIs de la couche RF. - PDU Session Establishment : les échecs ici indiquent des problèmes SMF ou UPF, pas des problèmes radio. Distinguer ces cas des défaillances RF économise un temps diagnostique considérable.
- Procédure d’authentification : les échecs d’authentification pointent vers des problèmes de configuration AUSF ou UDM dans le coeur 5G.
Un décodeur de protocoles 3GPP qui affiche les messages NAS en regard de la timeline des KPIs RF rend cette corrélation possible sans analyse manuelle des logs.
Latence de handover
La latence cible de handover (du moment de l’envoi du MeasurementReport à la réception du RRCReconfigurationComplete) doit être inférieure à 50 ms pour les services sensibles à la mobilité. Une latence supérieure à 100 ms pendant le handover cause des perturbations visibles sur la vidéo et les applications temps réel. Capturer cette métrique nécessite un logging de messages L3 avec horodatage, pas seulement un échantillonnage de KPIs RF.
Conclusion
Un drive test sans KPIs de couche 1, c’est comme diagnostiquer un moteur avec seulement un compteur de vitesse. SS-RSRP, SS-SINR, RI, MCS, BLER et événements EN-DC forment ensemble le tableau diagnostique complet de la 5G NR. La couverture semble correcte, le débit est défaillant : la réponse est dans le MCS et le RI, pas dans le RSRP.
La conséquence pratique : tout outil de drive test incapable d’accéder à l’interface Qualcomm DIAG est structurellement dans l’incapacité de fermer un diagnostic de couche 1. Le déficit de l’API Android n’est pas une limitation mineure, c’est l’écart entre “nous avons mesuré la puissance du signal” et “nous avons diagnostiqué le réseau.”
Pour aller plus loin sur la méthodologie de test 5G et la structuration d’une campagne de mesure complète, consultez le guide de l’outil de test réseau 5G.
Quel KPI 5G vous a le plus surpris sur le terrain, et quelle cause racine a-t-il révélé ? Partagez votre expérience dans les commentaires.
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.