5G RedCap en avril 2026 : qui déploie, ce qui change pour les tests, et comment valider un module sur réseau commercial

Avril 2026, Lyon. Un PM module IoT chez un OEM industriel est devant son banc de test, un échantillon Quectel RG255C-EU dans la main, et regarde son intégrateur. Le rapport “GSA 5G RedCap April 2026 Industry Update” est sorti il y a deux semaines avec ce chiffre frappant : 42 opérateurs dans 27 pays investissent désormais dans la 5G RedCap. Pourtant, le module sur le banc, équipé d’une SIM d’un opérateur français, campe obstinément sur LTE bande 3. La couverture est correcte, le RSRP indique -78 dBm, le modem est sain. La question posée est courte et opérationnelle : “RedCap est-il vraiment actif sur ce réseau dans cette cellule, ou l’opérateur l’a-t-il activé ailleurs ?”. Cet article décompose la réponse en cinq parties, avec à chaque étape les preuves Layer 3 à chercher.

Photographie RedCap en avril 2026 : 42 opérateurs, 27 pays, des déploiements commerciaux réels

Le rapport “5G RedCap April 2026 Industry Update” du GSA est désormais la source publique de référence sur la traction RedCap. Selon ce rapport, 42 opérateurs investissent dans la 5G RedCap dans 27 pays, un saut significatif par rapport au baseline 2025. Les engagements commerciaux Tier-1 sont concentrés en Amérique du Nord : T-Mobile US a lancé le premier dispositif consumer RedCap commercial avec le TCL Linkport en octobre 2024, Verizon a annoncé une intention commerciale RedCap, et AT&T positionne RedCap comme la voie pour l’IoT industriel sur sa couche 5G mid-band.

Les essais actifs couvrent une géographie plus large : Bahreïn, Tchéquie, Finlande, Inde, Indonésie, Malaisie, Oman, Arabie saoudite, Corée du Sud, Thaïlande, Turquie, Royaume-Uni. Certains sont des pilotes 5G privés, d’autres sont intégrés dans des cellules de test public. La référence industrielle la plus citée reste l’essai Hyundai-Samsung à Ulsan, où la plus grande usine d’assemblage automobile au monde sur un seul site exploite RedCap pour son IoT de production (capteurs, caméras, AGV) afin de valider la technologie à l’échelle industrielle.

Côté silicium, l’écosystème module a mûri : Quectel, Fibocom, Telit Cinterion, Smawave et MeiG livrent des modules RedCap construits sur des chipsets Qualcomm, MediaTek, ASR ou Sequans. Le marché n’est plus une curiosité, c’est une réalité. Mais le terme “actif” varie cellule par cellule, et c’est là que le test terrain entre en scène.

Ce que la 3GPP Release 17 RedCap contraint réellement (et ce qu’elle ne contraint pas)

Le 3GPP TS 38.300 (NR Stage 2) définit RedCap (Reduced Capability) comme une classe d’UE aux fonctions radio délibérément limitées, calibrée pour combler l’écart entre LTE Cat-1 / Cat-4 et la 5G eMBB complète. Le contrat est précis. En FR1, un UE RedCap supporte une bande maximale de 20 MHz, contre 100 MHz pour eMBB. En FR2, le plafond est de 100 MHz contre 400 MHz. La configuration antennaire est réduite à 1 ou 2 RX, contre 4 RX pour eMBB, ce qui réduit directement le coût module et l’encombrement PCB.

Le débit s’inscrit dans une enveloppe utile : environ 150 Mbps DL et 50 Mbps UL, comparable au LTE Cat-4 (environ 150 DL / 50 UL), mais avec le jeu de fonctionnalités 5G, le slicing, et la trajectoire long terme du NR. Le half-duplex FDD (HD-FDD) est optionnel et réduit le coût et la consommation au prix d’une latence plus élevée. L’agrégation de porteuses, la double connectivité et le MIMO 4x4 ne font pas partie du profil RedCap. C’est intentionnel.

Pour la suite, eRedCap (Release 18) prend la relève après RedCap, avec une enveloppe encore plus serrée : 5 MHz de bande, ciblant les usages IoT bas de gamme (asset trackers, capteurs très bas débit). Le calendrier commercial attendu se situe autour de 2026-2027.

Pour les équipes de test, la conclusion pratique est qu’un module RedCap n’est pas un module eMBB défaillant : c’est une classe d’UE avec un contrat de fonctionnalités explicite, et le gNB doit l’honorer.

Comment un réseau commercial traite un UE RedCap différemment (et pourquoi le test doit s’adapter)

Un gNB commercial n’accepte pas n’importe quelle classe d’UE sur n’importe quelle cellule à n’importe quel moment. Le support RedCap est signalé et appliqué via plusieurs mécanismes Layer 3 définis dans le TS 38.331 (RRC).

Le point de départ est la signalisation UE capability. L’UE envoie un conteneur NR-UE-Capability qui inclut l’indicateur redcap-r17. L’ordonnanceur du gNB lit ce flag et contraint l’allocation de BWP, le comportement HARQ et l’assignation fréquentielle en conséquence. Si le flag est absent ou mal formé, le gNB peut rejeter l’UE ou le traiter comme un dispositif eMBB normal, ce qui casse alors les attentes en débit.

L’histoire du Bandwidth Part (BWP) compte aussi. Une cellule peut porter un RedCapInitialBWP dédié (TS 38.331), dimensionné pour les UE RedCap (typiquement 20 MHz de large). L’UE campe sur ce BWP après le RRC Setup, pas sur le BWP eMBB complet. Si la cellule est consciente de RedCap mais mal configurée, l’UE échoue à trouver un BWP initial ou bascule sur LTE.

Le cell barring est la barrière suivante. L’opérateur peut interdire RedCap sur des cellules spécifiques via le champ cellBarred-redcap-r17 dans le SIB1. Ce n’est pas théorique : sur les réseaux commerciaux, les opérateurs activent fréquemment RedCap uniquement sur un sous-ensemble de leur footprint (sites industriels, small cells urbaines denses, systèmes indoor dédiés). Le scénario lyonnais évoqué en ouverture est un cas d’école de cette logique.

Le RACH peut aussi être spécifique RedCap : une configuration PRACH séparée peut être annoncée pour permettre au gNB d’identifier et d’admettre les UE RedCap dès le premier préambule. La mobilité est largement supportée intra-RAT, mais le fallback inter-RAT vers LTE doit être validé sur le terrain au cas par cas, parce que toutes les cellules voisines ne portent pas la même configuration RedCap.

Pour le test, la séquence logique est sans pardon : capturer le SIB1, puis l’UECapabilityInformation, puis le RRCSetup / RRCReconfiguration, et confirmer que le réseau accepte effectivement la classe d’UE et la provisionne correctement. Comme évoqué précédemment, le primer sur la signalisation UE capability s’applique aussi à RedCap : le champ redcap-r17 est une capability parmi d’autres, mais elle conditionne tout le reste.

Les 5 choses qui partent en vrille avec un module RedCap sur réseau commercial (et comment les identifier en Layer 3)

Une fois qu’un module RedCap atteint une vraie cellule commerciale, cinq modes de défaillance concentrent l’essentiel des tickets d’intégration. Chacun a une signature spécifique dans la trace Layer 3, et les confondre coûte cher.

Le cas A est le rejet de cellule. Le module tente l’attach, le gNB renvoie un RRCReject avec un wait time, ou l’UE ne trouve jamais un BWP utilisable et boucle indéfiniment. La cause racine est presque toujours cellBarred-redcap-r17 positionné à true dans le SIB1 : l’opérateur a explicitement barré RedCap sur cette cellule. La correction est opérationnelle, pas technique, mais l’ingénieur terrain doit reconnaître le champ SIB1 pour escalader correctement.

Le cas B est l’incohérence de capability UE. Le module annonce un set de capabilities eMBB dans UECapabilityInformation, mais le comportement à l’exécution est contraint à RedCap (débit faible, BWP étroit). C’est un bug firmware côté module : le modem déclare plus que ce qu’il supporte réellement. Décoder l’UECapabilityInformation complet, chercher le champ redcap-r17, et croiser avec les combinaisons de bandes annoncées, expose l’incohérence.

Le cas C est la surprise du plafond de débit. Le downlink sature autour de 150 Mbps même avec un RSRP à -75 dBm et un SINR propre. Les équipes produit habituées aux pics eMBB de 600 Mbps et plus le remontent comme un défaut. Ce n’en est pas un. Le plafond DL à 150 Mbps est normal pour RedCap (20 MHz, 1 ou 2 RX, pas de CA). La correction est un alignement, pas de l’ingénierie.

Le cas D est la rupture de mobilité. Un handover réussit au niveau RRC, mais le gNB cible n’a pas de configuration RedCap, et l’UE se retrouve dans un état RedCap hors couverture. Décoder RRCReconfiguration côté source et vérifier la configuration de la targetCell est la seule voie pour confirmer.

Le cas E est une consommation supérieure aux specs. Le module tire plus de courant que ce que la datasheet promet. Deux causes fréquentes : le cycle DRX n’est pas optimal (le gNB ordonnance un cycle court alors qu’un cycle long suffirait), ou le HD-FDD n’a pas été négocié alors qu’il aurait dû l’être. Les deux laissent des traces dans RRCReconfiguration (drx-Config et physicalCellGroupConfig).

Un protocole de validation terrain d’un module RedCap en 60 minutes

Le protocole qui suit est ce qu’un ingénieur terrain peut exécuter en une heure sur un réseau commercial, avec le module sous test (exemple : Quectel RG255C-EU) et un smartphone Android Qualcomm en parallèle pour le contrôle croisé. Le téléphone est la référence Layer 3, le module est le device under test.

L’étape 1 est la connexion initiale. Mettre le module sous tension sur la SIM d’essai, observer la tentative RACH, le RRC Setup, et la registration NAS sur l’AMF. Capturer NAS Registration Accept. Vérifier le PLMN, le slice (S-NSSAI) si applicable, et les types de PDU session autorisés. Si la registration échoue, le module n’entre jamais dans le chemin RedCap, et le reste devient sans objet.

L’étape 2 est le contrôle de capability UE. Extraire le message UECapabilityInformation de la trace. Trouver le champ redcap-r17, confirmer qu’il est présent, et vérifier que la combinaison de bandes négociée correspond à la bande de la cellule. Le /decoder/ accélère cette inspection, et le UE capabilities guide liste les champs exacts à vérifier sur un module RedCap.

L’étape 3 est le débit. Lancer un transfert DL pic de 5 minutes (HTTP ou iperf), puis un UL pic de 5 minutes. Le DL attendu se situe entre 100 et 150 Mbps sur une cellule 20 MHz propre, l’UL attendu autour de 30 à 50 Mbps. Des déviations de plus de 30 pour cent pointent vers du RF, une mauvaise configuration de BWP, ou des soucis d’ordonnanceur.

L’étape 4 est la mobilité. Se déplacer (en voiture ou à pied) entre deux cellules de la zone d’essai, forcer un handover, et capturer RRCReconfiguration des deux côtés. Confirmer que la cellule cible admet RedCap et que la session de données ne casse pas.

L’étape 5 est la consommation et le DRX. Observer le cycle DRX en mode connecté et en mode idle. Un cycle DRX court (10 à 40 ms) est typique en mode connecté, un cycle long (320 ms ou plus) en idle. Un écart avec la datasheet impose une renégociation. Le /diagclient-sdk/ donne la vue interne au modem qui complète le décodage over-the-air.

L’étape 6 est le stress de reconnexion. Exécuter 100 cycles power-on / power-off avec un intervalle de 30 secondes, journaliser le taux de succès et le temps moyen d’attach. Tout taux inférieur à 98 pour cent mérite une investigation. Pour des parcs plus grands, /blog/imei-iot-m2m-gestion-parc/ couvre la façon de garder l’inventaire device propre pendant un déploiement.

Le reporting tient dans une petite table markdown :

Six étapes, une heure, chaque test adossé à un message Layer 3 que vous pouvez montrer.

En résumé

La 5G RedCap en avril 2026 n’est plus un slide. 42 opérateurs dans 27 pays (selon le GSA April 2026 update) construisent de vrais déploiements RedCap, T-Mobile US livre des dispositifs commerciaux depuis octobre 2024, et l’essai Hyundai-Samsung à Ulsan prouve que la technologie tient à l’échelle industrielle. L’écosystème module (Quectel, Fibocom, Telit Cinterion, Smawave, MeiG sur Qualcomm, MediaTek, ASR, Sequans) est suffisamment mûr pour démarrer les intégrations.

Ce qui change pour les équipes de test, c’est la discipline : un module RedCap est une classe d’UE avec un contrat de fonctionnalités explicite (TS 38.300, TS 38.331, TS 38.306), et le gNB applique ce contrat via redcap-r17, des BWP initiaux dédiés, cellBarred-redcap-r17 dans le SIB1, et un ordonnanceur conscient de RedCap. La validation exige des preuves Layer 3, pas seulement des dashboards de débit.

Pour le PM module IoT à Lyon, la réponse à “RedCap est-il vraiment actif sur ce réseau ?” se trouve dans trois messages : SIB1 (cellBarred-redcap-r17), UECapabilityInformation (champ redcap-r17), et RRCReconfiguration (taille de BWP, DRX). Extrayez ces trois-là, et la conversation d’architecture devient opérationnelle.

Combien de cellules spécifiques RedCap votre opérateur d’essai annonce-t-il vraiment dans le SIB1 aujourd’hui, et est-ce que ce sont les cellules sur lesquelles vos sites industriels sont effectivement campés ?