3 messages NAS suffisent à dresser le portrait complet d'un réseau 5G SA
Registration Accept, PDU Session Accept, DL NAS Transport : comment décoder en temps réel les signaux NAS 5G depuis un simple Android via le DIAG Qualcomm.
Il est 10h06. Vous êtes sur un site 5G SA fraîchement déployé en zone dense. Le terminal affiche “5G”. Les barres de signal sont au maximum. Mais est-ce que le réseau a réellement alloué un slice eMBB ? Est-ce que la voix passera en VoNR ou retombera en VoLTE ?
Personne dans l’équipe ne peut répondre à ces questions sans accéder à la signalisation NAS.
Et c’est exactement ce que révèlent 3 messages NAS capturés en temps réel.
3 messages NAS 5G capturés en terrain réel. HiCellTek identifie automatiquement le slice alloué, la disponibilité VoNR et les sessions PDU actives — directement depuis le DIAG Qualcomm, sans sonde, sans Wireshark, sans licence opérateur.
Zéro hardware. Zéro infrastructure. Un seul téléphone Android.
Ce que le terminal ne vous dit pas
Quand un UE s’attache à un réseau 5G Standalone, une série de messages NAS (Non-Access Stratum) est échangée entre le terminal et le cœur de réseau via l’interface N1. Ces messages sont définis dans la spécification 3GPP TS 24.501 et contiennent des informations critiques que l’interface utilisateur du téléphone ne montre jamais.
Un ingénieur terrain qui se fie uniquement à l’icône “5G” et aux barres de signal travaille à l’aveugle. La couche NAS est le seul endroit où l’on peut confirmer ce que le réseau a réellement décidé pour ce terminal.
Registration Accept : le verdict du réseau
Le Registration Accept (message type 66, défini dans 3GPP TS 24.501 section 8.2.7) est la réponse du réseau à la demande d’enregistrement du terminal. C’est le message le plus riche en information sur la relation réseau-terminal.
Voici ce qu’une capture live révèle :
Allowed NSSAI : le champ liste les slices que le réseau autorise pour ce terminal. Dans notre capture, sst: 1 confirme l’allocation d’un slice eMBB (enhanced Mobile Broadband), le profil standard défini dans 3GPP TS 23.501 section 5.15.2.
imsVoPS3gpp : quand ce flag vaut 1, le réseau indique qu’il supporte les services voix IMS sur ce PLMN en 3GPP. Cela signifie que la voix peut passer en VoNR (Voice over New Radio) natif, sans nécessité de retomber en EPS Fallback vers le 4G.
TAC (Tracking Area Code) : confirme la zone de suivi dans laquelle le terminal est enregistré.
Sessions actives : la liste des PDU sessions déjà établies (ici sessions 1 et 2).
Pourquoi c’est critique : sans ce message, impossible de savoir si le réseau a réellement alloué le slice demandé ou s’il a substitué un slice par défaut. Sur un site multi-slice (eMBB + URLLC), cette vérification est indispensable.
PDU Session Establishment Accept : la connexion data confirmée
Le PDU Session Establishment Accept (message type 194, 3GPP TS 24.501 section 8.3.2) confirme les paramètres de la session data entre le terminal et le réseau.
Les champs clés capturés :
PDU Type = 2 (IPv6) : le réseau a alloué une adresse IPv6 pour cette session. En 5G SA, l’IPv6 est le type par défaut recommandé par le 3GPP, contrairement au dual-stack souvent vu en 4G.
SSC Mode = 1 : le Session and Service Continuity mode 1 (défini dans 3GPP TS 23.501 section 5.6.9) garantit que l’ancre UPF reste la même pendant toute la durée de la session. C’est le mode le plus courant, offrant une continuité d’adresse IP lors de la mobilité.
QoS Rules : une règle QoS est créée automatiquement avec ruleOpCode: 1 (Create new QoS rule) et un filtre de paquets bidirectionnel (dir: 3). Le flag dqr: yes confirme que cette règle est la Default QoS Rule, appliquée à tout le trafic qui ne correspond à aucun filtre spécifique.
DL NAS Transport : la deuxième session révélée
Le DL NAS Transport (message type 104, 3GPP TS 24.501 section 8.2.11) est un message conteneur utilisé par l’AMF pour transporter des messages SM (Session Management) vers le terminal via la couche MM (Mobility Management).
Dans notre capture, ce message encapsule un deuxième PDU Session Establishment Accept (pduSessionId: 2, pti: 5, msgType: 194), révélant qu’une seconde session data est établie simultanément.
Le champ ctnType: 1 indique que le contenu transporté est de type N1 SM information, c’est-à-dire un message de gestion de session destiné au UE. Cette deuxième session est également en IPv6 avec PDU type 2.
Pourquoi 2 sessions ? En 5G SA, un terminal peut maintenir plusieurs PDU sessions simultanées vers des DNN différents ou le même DNN avec des paramètres QoS distincts. C’est un changement fondamental par rapport au 4G où les bearers étaient liés à un seul APN.
Ce que l’analyse automatique révèle
En croisant ces 3 messages, une analyse cohérente du contexte réseau émerge :
Ce niveau de visibilité était historiquement réservé aux sondes cœur de réseau positionnées sur l’interface N11 (entre AMF et SMF) ou N4 (entre SMF et UPF). Pouvoir lire ces mêmes informations depuis le terminal, en temps réel, via l’interface DIAG du chipset Qualcomm, est un changement de paradigme pour le diagnostic terrain.
Implications pour le drive test 5G SA
L’accès à la signalisation NAS depuis le terminal ouvre des possibilités concrètes pour les équipes terrain :
Vérification de slice : confirmer que le slice demandé (eMBB, URLLC, MIoT) est bien celui alloué par le réseau, et non un fallback vers un slice par défaut.
Diagnostic VoNR : identifier si les appels voix utilisent VoNR natif ou retombent en EPS Fallback avant même de passer le premier appel.
Audit de sessions : voir combien de PDU sessions sont actives simultanément, leurs types IP et leurs paramètres QoS respectifs.
Validation SSC : vérifier que le mode de continuité de session correspond à l’architecture déployée (SSC 1 pour la mobilité classique, SSC 2/3 pour l’edge computing).
Tout cela sans déployer de sonde, sans accéder au cœur de réseau, et sans licence opérateur. Un seul terminal Android avec accès DIAG suffit.
Ce que cela change pour les ingénieurs terrain
La signalisation NAS 5G n’est plus un domaine réservé aux équipes cœur de réseau. Avec le bon outillage de lecture DIAG, chaque ingénieur terrain peut accéder au même niveau d’information qu’une sonde réseau, directement depuis le terminal qu’il utilise déjà pour ses mesures.
La question n’est plus “est-ce que le site affiche 5G ?” mais “est-ce que le réseau a réellement configuré ce site comme prévu ?”
3 messages NAS suffisent à répondre.
Références : 3GPP TS 24.501 (NAS protocol for 5GS), 3GPP TS 23.501 (System architecture for 5GS), 3GPP TS 23.502 (Procedures for 5GS)
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.