Layer 3 LTE/5G : décodage RRC et NAS en temps réel

Le décodage des messages Layer 3 (L3) est la compétence technique la plus différenciante pour un ingénieur réseau mobile. Là où les KPIs radio (RSRP, SINR, débit) décrivent l’état du lien, les messages L3 expliquent pourquoi le réseau s’est comporté d’une certaine façon. Ce guide présente les fondamentaux du Layer 3 en LTE et 5G NR, et comment l’analyser efficacement sur le terrain.

Architecture du Layer 3 en LTE et 5G NR

Les deux couches du Layer 3

Le Layer 3 dans les réseaux mobiles se divise en deux familles de protocoles, selon l’interface :

RRC (Radio Resource Control) — interface radio (Uu)

Gère la connexion entre le terminal (UE) et la base station (eNB/gNB)
Contrôle les mesures radio, les handovers, la configuration radio
Messages transportés sur le canal de contrôle radio (DCCH/BCCH/PCCH)

NAS (Non-Access Stratum) — interface core (S1/N1)

Gère l’enregistrement du terminal dans le réseau core (MME/AMF)
Contrôle les sessions data (bearers), l’authentification, la mobilité core
Messages transportés de façon transparente à travers le RAN

En LTE : le NAS est divisé en EMM (EPS Mobility Management) et ESM (EPS Session Management) En 5G NR SA : le NAS est divisé en 5G MM (5G Mobility Management) et 5G SM (5G Session Management)

Pourquoi le Layer 3 est indispensable pour le diagnostic

Un exemple concret : un abonné se plaint de coupures d’appels répétées dans un bâtiment.

Les KPIs radio disent : RSRP moyen -95 dBm, SINR 8 dB → correct. Pourquoi des coupures ?

Les messages L3 révèlent : des RRC Connection Release avec cause loadBalancingTAUrequired → le réseau déplace activement les terminaux pour équilibrer la charge. Ce n’est pas un problème de couverture, c’est un problème de capacité et de configuration d’équilibrage de charge.

Sans les messages L3, ce diagnostic est impossible à partir des seuls KPIs radio.

Messages RRC fondamentaux en LTE

Séquence d’établissement de connexion

UE                    eNB (base station)
 |                        |
 |--- RRCConnectionRequest -->|      (UE demande une connexion)
 |<-- RRCConnectionSetup  ---|      (eNB configure le canal)
 |--- RRCConnectionSetupComplete -->| (UE confirme)
 |<-- RRCConnectionReconfiguration -| (eNB configure les bearers)
 |--- RRCConnectionReconfigurationComplete -->|

RRCConnectionRequest : contient l’identifiant du UE et la cause de l’établissement (mobile originating, emergency, mobile terminating…). Analyser la cause révèle le type de service.

RRCConnectionSetup : contient la configuration radio initiale (canal, puissance, HARQ). Vérifier la cohérence avec la configuration opérateur.

RRCConnectionReconfiguration : le message le plus informatif. Contient :

Configuration des bearers (QCI, ARP, TEID)
Configuration de mesure (A3, A5, events, periodes)
Configuration de la cellule serving (EARFCN, PCI, bande)
Éventuellement la commande de handover (mobilityControlInfo)

Messages de handover

La commande de handover est contenue dans un RRCConnectionReconfiguration avec le champ mobilityControlInfo présent. Ce message inclut :

La cellule cible (PCI + EARFCN)
La configuration radio de la cible
Les paramètres de réorientation de la clé de sécurité (après handover)

Le succès du handover est confirmé par RRCConnectionReconfigurationComplete sur la cellule cible.

En cas d’échec : le UE envoie RRCConnectionReestablishmentRequest à la cellule la plus proche disponible, avec la cause (handoverFailure, otherFailure, reconfigurationFailure). La cause du failure guide directement l’action corrective.

Messages de mesure

MeasurementReport : envoyé par le UE vers l’eNB quand un événement de mesure est déclenché (A1, A2, A3, A4, A5, B1, B2). Contient :

Identifiant de l’événement déclenché
RSRP/RSRQ de la cellule serving
RSRP/RSRQ des cellules voisines candidates

Analyser les MeasurementReport en séquence permet de comprendre les décisions de handover du réseau et d’identifier les problèmes de voisinage.

Messages NAS fondamentaux en LTE (EPS)

Séquence d’attachement

UE                    MME (réseau core)
 |                        |
 |--- Attach Request  ---->|    (NAS)
 |<-- Authentication Request -|
 |--- Authentication Response ->|
 |<-- Security Mode Command -|
 |--- Security Mode Complete -->|
 |<-- Attach Accept    ----|    (bearers configurés)
 |--- Attach Complete  ---->|

Attach Request : contient l’IMSI ou le GUTI (identifiant temporaire), les capacités UE, les préférences de réseau (LTE/NR). Analyser ce message pour vérifier que le UE s’enregistre bien sur le bon PLMN.

Attach Accept : contient l’allocation des bearers par défaut (QCI, APN, adresse IP). Confirme le succès de l’enregistrement.

Attach Reject : indique un refus d’accès avec une cause explicite :

Cause 3 : IMSI unknown → SIM non provisionnée
Cause 7 : EPS services not allowed → abonné non autorisé
Cause 11 : PLMN not allowed → problème de roaming
Cause 22 : Congestion → surcharge du réseau core

Messages ESM (gestion des sessions data)

PDN Connectivity Request / Accept : établissement d’une session data (bearer par défaut). Vérifier l’APN alloué et les paramètres de qualité (QCI 6 pour data, QCI 1 pour voix VoLTE).

Bearer Modification : modification dynamique des bearers (changement de QCI, débit garanti). Apparaît notamment lors des transitions VoLTE (setup du bearer QCI 1 avant l’appel).

Deactivate EPS Bearer : désactivation d’un bearer (fin de session, expiration, congestion). Une désactivation inattendue du bearer voix pendant un appel VoLTE révèle une cause réseau à identifier.

Spécificités NAS en 5G NR SA

En 5G SA, le NAS évolue significativement :

Registration Request (remplace Attach Request) : contient les 5G-MM capabilities et les paramètres de sécurité 5G.

PDU Session Establishment Request (remplace PDN Connectivity) : la gestion des sessions est plus flexible, avec un modèle de QoS basé sur les QoS Flow (5QI) plutôt que les bearers fixes.

Différences clés à connaître :

Le concept de “bearer” disparaît au profit des “QoS Flows” (plus flexibles)
L’authentification 5G utilise EAP-AKA’ ou 5G-AKA (plus sécurisé)
Les messages Registration Reject remplacent Attach Reject — les codes cause restent similaires

Comment capturer et décoder les messages Layer 3 en pratique

Méthode 1 : Interface DIAG Qualcomm (recommandée)

L’interface DIAG des modems Qualcomm expose les messages L3 complets, encodés en ASN.1. La capture via cette interface requiert :

Root Android sur le device Qualcomm
Client DIAG (diagclient_cli) exécuté en root
Décodeur ASN.1 compilé pour LTE + NR (libasn1c_lte_rrc.so, libasn1c_nr_rrc.so)

Avantage : accès à tous les messages L3, avec timestamp précis au ms et corrélation automatique avec les KPIs radio du même instant.

Méthode 2 : Export QMDL + QCAT offline

Capturer la session en .qmdl (format Qualcomm DIAG brut) et analyser offline dans QCAT/QXDM. Cette approche est idéale pour les tickets vendor qui nécessitent la trace brute complète.

Méthode 3 : Tcpdump sur interface IP (NAS seulement)

Pour les messages NAS non chiffrés (initial attach avant établissement de la clé de sécurité), un tcpdump sur l’interface radio peut capturer une partie des messages. Limité en pratique aux premières étapes de l’attachement.

Diagnostic pratique : les 5 problèmes résolus grâce au Layer 3

Problème 1 : “Le téléphone se connecte mais pas d’internet”

Symptôme : attachement LTE réussi, mais pas de données.

Diagnostic L3 : chercher les messages ESM. Si PDN Connectivity Request est envoyé mais PDN Connectivity Reject est reçu avec cause Unknown APN (cause 27) → l’APN configuré dans le téléphone est incorrect.

Problème 2 : “Les appels VoLTE décrochent systématiquement”

Symptôme : appels qui se coupent après 20–30 secondes.

Diagnostic L3 : chercher les messages Deactivate EPS Bearer Context Request avec cause Insufficient bearer resources ou Reactivation required. Corréler avec la localisation GPS → identifier si la coupure survient toujours au même endroit (problème de couverture) ou de façon aléatoire (problème core).

Problème 3 : “La 5G disparaît à certains endroits”

Symptôme : terminal bascule de 5G NR à LTE sans raison apparente.

Diagnostic L3 : chercher les RRC Release with Redirect to LTE ou les RRC Reconfiguration qui suppriment la configuration NR (en NSA). Analyser le déclencheur : A2 threshold atteint (RSRP serving LTE trop bas pour maintenir le lien NR), ou cause de charge réseau.

Problème 4 : “Le téléphone ne se connecte pas après déplacement”

Symptôme : après un handover inter-TAC, le terminal prend 30–60 secondes à retrouver le service.

Diagnostic L3 : chercher un Tracking Area Update Request suivi d’un TAU Reject (cause 9 - UE identity cannot be derived → problème de contexte MME) ou d’un délai anormal sur le TAU Accept. Révèle souvent un problème de configuration inter-MME ou de synchronisation de contexte.

Problème 5 : “La qualité voix est dégradée même avec un bon signal”

Symptôme : MOS voix < 3.5 malgré RSRP -80 dBm et SINR 15 dB.

Diagnostic L3 : vérifier les messages SIP/IMS (VoLTE layer). Chercher des SIP BYE inattendus, des SIP Re-INVITE fréquents (renegociation codec pendant l’appel), ou une modification du bearer QCI 1 pendant la communication. Ces messages révèlent des problèmes au niveau IMS core, pas radio.

Conclusion

Le Layer 3 est la “boîte noire” du réseau mobile. Là où les KPIs radio décrivent des symptômes, les messages L3 révèlent les causes. Pour les équipes d’optimisation, le décodage L3 en temps réel est la compétence qui fait la différence entre un diagnostic de 2 semaines et un diagnostic de 2 heures.

L’accès aux messages L3 sur le terrain ne nécessite plus d’équipement dédié à 50 000 € — un smartphone Qualcomm rooté avec un décodeur ASN.1 embarqué délivre les mêmes données brutes que QCAT ou TEMS, directement sur le terrain.

Layer 3 LTE/5G : décodage RRC et NAS en temps réel — guide technique