eRedCap : l'IoT 5G a cout reduit qui change la donne (Release 18). ...

Une usine automobile en Baviere deploie 10 000 capteurs de vibration sur ses lignes de production. Chaque capteur remonte 50 Ko de donnees toutes les 30 secondes. Le WiFi industriel a ete ecarte : trop de points d’acces, trop d’interference dans un hangar metallique de 40 000 m2. Le choix se porte sur le cellulaire. Le directeur technique veut de la 5G NR pour la latence. Le directeur financier regarde le prix unitaire des modules : 35 EUR par chipset 5G NR standard, multiplie par 10 000 terminaux. 350 000 EUR rien qu’en silicium. Pour des capteurs qui n’ont besoin que de 500 kbps.

C’est exactement le probleme que le 3GPP a voulu resoudre avec la hierarchie IoT cellulaire. Et c’est exactement la que eRedCap, introduit dans la Release 18, change la donne.

La hierarchie IoT cellulaire : du compteur d’eau au robot industriel

L’IoT cellulaire n’est pas monolithique. Le 3GPP a construit une echelle de technologies ou chaque barreau correspond a un compromis entre debit, latence, cout et consommation energetique. Comprendre cette hierarchie est le prerequis a toute decision d’architecture.

NB-IoT (Release 13, 2016)

NB-IoT occupe une bande de 200 kHz — soit un seul PRB LTE. Le debit maximal theorique est de 250 kbps en downlink, 20 kbps en uplink (single-tone). La conception cible des terminaux statiques ou quasi-statiques qui remontent de tres petits volumes de donnees : compteurs d’eau, capteurs de temperature, detecteurs de fuite. NB-IoT ne supporte ni le handover ni la voix. Le terminal s’attache a une cellule et y reste. En contrepartie, la complexite du chipset est minimale et la duree de vie sur batterie peut depasser 10 ans.

LTE-M / eMTC (Release 13, 2016)

LTE-M elargit la bande a 1,4 MHz et le debit a 1 Mbps. La difference fondamentale avec NB-IoT est le support de la mobilite (handover) et de la voix (VoLTE). LTE-M est le choix naturel pour les wearables medicaux, les trackers GPS, les alarmes connectees — tout terminal qui bouge et qui peut avoir besoin d’emettre un appel vocal. Le cout chipset est superieur a NB-IoT mais reste dans la gamme des 5-8 EUR.

RedCap (Release 17, 2022)

RedCap (Reduced Capability) marque l’entree de l’IoT dans le monde 5G NR. Le terminal RedCap utilise une bande de 20 MHz (FR1), avec un debit plafonne a 150 Mbps en downlink. C’est un terminal 5G NR complet mais simplifie : une seule antenne de reception (1Rx au lieu de 2Rx ou 4Rx), pas de support du carrier aggregation, pas de MIMO multi-couche. RedCap cible les cameras de surveillance IP, les robots de service, les wearables haut de gamme, les capteurs industriels a haut debit. Le cout chipset se situe autour de 15-20 EUR — significativement moins qu’un modem 5G NR complet, mais encore trop pour des capteurs a faible debit deployes en volume.

eRedCap (Release 18, 2024)

C’est la que l’innovation architecturale entre en jeu. eRedCap (enhanced RedCap) plafonne le debit a 10 Mbps en downlink et en uplink. Mais la reduction de debit n’est pas le point central. Ce qui change tout, c’est l’architecture dual bandwidth.

L’innovation dual bandwidth : comment eRedCap divise le cout par deux

Pour comprendre l’astuce d’eRedCap, il faut d’abord comprendre pourquoi un modem 5G NR coute cher. Le composant le plus couteux d’un chipset radio est la chaine de traitement en bande de base — specifiquement, le processeur FFT (Fast Fourier Transform) qui convertit le signal RF en symboles OFDM exploitables. Plus la bande passante a traiter est large, plus le processeur FFT doit etre rapide et complexe, et plus le silicium coute cher.

Un terminal RedCap (R17) recoit et traite 20 MHz de bande passante. Son processeur FFT doit gerer la totalite de ces 20 MHz. Un terminal 5G NR standard en FR1 peut traiter jusqu’a 100 MHz. Le cout du silicium est directement proportionnel a cette largeur de bande.

eRedCap introduit une separation entre la bande passante RF et la bande passante de donnees :

Bande passante RF : 20 MHz. Le frontend RF du terminal eRedCap recoit la totalite des 20 MHz de la cellule. C’est necessaire pour decoder les canaux de controle et de synchronisation qui occupent la bande passante complete de la cellule :

PSS/SSS (Primary/Secondary Synchronization Signals) : synchronisation temporelle et frequentielle initiale
PBCH (Physical Broadcast Channel) : informations systeme de base (MIB)
PDCCH (Physical Downlink Control Channel) : ordonnancement, attributions de ressources, DCI
SIB (System Information Blocks) : parametres de la cellule, configuration d’acces

Bande passante de donnees : ~5 MHz. Pour le trafic de donnees — PDSCH (Physical Downlink Shared Channel) en reception, PUSCH (Physical Uplink Shared Channel) en emission — le terminal ne traite qu’une sous-bande d’environ 5 MHz extraite de la bande de 20 MHz.

Architecture dual bandwidth eRedCap (R18)

Frontend RF20 MHz completPSS/SSS + PBCH + PDCCH + SIB

Traitement donnees~5 MHz (sous-bande)PDSCH / PUSCH uniquement

Chaine FFTTraite 20 MHz complet, extraction sous-bande 5 MHz pour les donnees

Concretement, la chaine FFT du terminal traite la totalite du signal 20 MHz recu par le frontend RF. Mais au lieu de decoder l’integralite de la bande pour les donnees, un mecanisme d’extraction de sous-bande isole les ~5 MHz assignes par le scheduler pour le canal de donnees. Le processeur de bande de base en aval — demodulation, decodage de canal, HARQ — ne traite que cette sous-bande etroite.

Le resultat : le frontend RF et le processeur FFT sont calibres pour 20 MHz (necessaire pour la signalisation), mais la chaine de traitement de donnees est dimensionnee pour 5 MHz seulement. C’est cette chaine de donnees qui domine le cout du silicium dans les debits intermediaires. En la reduisant de 20 MHz a 5 MHz, le cout total du chipset chute de plus de 50 % par rapport a RedCap, pour un prix cible de 7-10 EUR par module.

Comparaison des standards IoT cellulaires

Le tableau ci-dessous synthetise les caracteristiques des quatre standards IoT cellulaires du 3GPP. Chaque ligne represente un critere de selection que l’ingenieur doit evaluer pour un deploiement donne.

Critere	NB-IoT (R13)	LTE-M (R13)	eRedCap (R18)	RedCap (R17)
Bande passante	200 kHz	1,4 MHz	~5 MHz (donnees) / 20 MHz (RF)	20 MHz
Debit DL max	250 kbps	1 Mbps	10 Mbps	150 Mbps
Debit UL max	20 kbps (single-tone)	1 Mbps	10 Mbps	50 Mbps
Latence typique	1-10 s	100 ms - 1 s	10-50 ms	5-20 ms
Nombre d’antennes Rx	1	1	1	1
Mobilite (handover)	Non	Oui	Oui	Oui
Voix (VoNR/VoLTE)	Non	Oui (VoLTE)	Non	Optionnel
Duplex	HD-FDD	HD-FDD / FD-FDD	HD-FDD / FD-FDD	HD-FDD / FD-FDD
Cout chipset estime	3-5 EUR	5-8 EUR	7-10 EUR	15-20 EUR
Technologie radio	LTE (in-band / guard-band / standalone)	LTE	5G NR	5G NR
Use cases principaux	Compteurs, capteurs statiques, agriculture	Wearables, trackers, alarmes	Capteurs semi-haut debit, meters avances, IoT industriel	Cameras IP, robots, wearables avances
PSM / eDRX	Oui	Oui	Oui	Optionnel
Duree de vie batterie cible	10-15 ans	5-10 ans	3-7 ans	1-3 ans (souvent alimente)

PSM et eDRX : la cle de la duree de vie batterie

Pour les deploiements IoT sur batterie, deux mecanismes 3GPP sont determinants : PSM (Power Saving Mode) et eDRX (Extended Discontinuous Reception). Ces mecanismes sont disponibles sur NB-IoT, LTE-M et eRedCap.

PSM (Power Saving Mode)

PSM a ete introduit dans la Release 12. Le principe est simple : apres une transmission de donnees, le terminal entre dans un etat de sommeil profond ou il est effectivement eteint du point de vue radio, mais reste enregistre sur le reseau. Le terminal ne repond pas au paging du reseau pendant la duree du timer T3412 etendu.

La valeur maximale du timer T3412 etendu est de 413 jours (timer unit = 320 heures, timer value = 31, soit 31 x 320 = 9920 heures = 413,3 jours). Pendant ce sommeil, la consommation est de l’ordre de quelques microamperes — comparable a l’autodechargement de la batterie elle-meme.

L’inconvenient est clair : le terminal est injoignable pendant toute la duree du PSM. Le reseau ne peut pas le paginer pour lui pousser des donnees. Seul le terminal peut initier la communication a son reveil. Pour un compteur d’eau qui remonte un releve quotidien, c’est parfait. Pour un capteur qui doit etre interrogeable a la demande, c’est incompatible.

eDRX (Extended Discontinuous Reception)

eDRX (Release 13) offre un compromis. Le terminal alterne entre periodes de sommeil et breves fenetres d’ecoute du paging. Le cycle eDRX maximal est de 43,69 minutes en mode connecte (LTE-M) et 2,91 heures en mode idle (NB-IoT).

Pendant la fenetre d’ecoute (Paging Time Window), le terminal se reveille, ecoute le canal de paging, et se rendort si aucun message n’est adresse a lui. La duree de la fenetre d’ecoute est configurable (typiquement 1,28 a 2,56 secondes).

La combinaison PSM + eDRX est la configuration la plus courante pour les deployements IoT sur batterie longue duree : le terminal utilise eDRX pour rester joignable a intervalles reguliers, et bascule en PSM entre les cycles de transmission prevus.

Arbre de decision : quel standard pour quel use case

La selection du standard IoT cellulaire n’est pas un choix technologique pur. C’est un calcul d’optimisation multi-variable : debit requis, latence acceptable, mobilite, besoin de voix, volume de deploiement, duree de vie batterie, couverture de l’operateur.

Choisir NB-IoT si :

Le terminal est statique ou quasi-statique
Le volume de donnees par transmission est inferieur a 1 Ko
La latence de plusieurs secondes est acceptable
Le deploiement concerne des dizaines de milliers de terminaux a cout minimal
La duree de vie batterie cible depasse 10 ans
Aucun besoin de voix ou de handover

Exemples : compteurs d’eau et de gaz, capteurs de temperature/humidite en agriculture, detecteurs de fuite, capteurs de stationnement.

Choisir LTE-M si :

Le terminal est mobile (trackers, vehicules, wearables)
La voix est un besoin (alarmes avec rappel vocal, appareils medicaux)
Le debit requis est entre 100 kbps et 1 Mbps
Le handover entre cellules est necessaire
La latence sub-seconde est souhaitee

Exemples : montres connectees medicales, trackers d’actifs logistiques, alarmes personnelles, terminaux de paiement mobiles.

Choisir eRedCap si :

Le terminal a besoin de 1 a 10 Mbps de debit
L’integration dans l’ecosysteme 5G NR est souhaitee (memes frequences, memes sites)
Le volume de deploiement est suffisamment grand pour que le cout chipset soit un facteur determinant
La mobilite et des latences de l’ordre de 10-50 ms sont requises
L’alimentation par batterie est prevue (3-7 ans)

Exemples : capteurs de vibration industriels a reporting frequent, compteurs intelligents de nouvelle generation, terminaux de point de vente, capteurs environnementaux urbains semi-haut debit.

Choisir RedCap si :

Le debit requis depasse 10 Mbps (jusqu’a 150 Mbps)
La latence sub-20 ms est necessaire
Le terminal transmet des flux video ou des volumes de donnees importants
Le terminal est generalement alimente sur secteur ou dispose d’une batterie rechargeable

Exemples : cameras de surveillance IP, robots de service en interieur, wearables AR/VR, portails de tele-medecine.

Ce que cela signifie pour l’ingenieur terrain

Pour l’ingenieur RF ou l’ingenieur reseau qui deploie et valide des reseaux IoT, eRedCap introduit un nouveau point de verification dans les procedures de test.

Verification de la configuration dual bandwidth. Le terminal eRedCap doit recevoir la bande passante RF complete de 20 MHz pour la signalisation mais ne doit traiter qu’une sous-bande pour les donnees. Lors de l’analyse des traces L3, l’ingenieur doit verifier que le RRC Reconfiguration attribue correctement la bande passante initiale BWP (Bandwidth Part) pour la signalisation et une BWP reduite pour le trafic de donnees. Si le terminal tente de decoder l’integralite de la bande pour les donnees, le comportement est non conforme et la consommation energetique sera superieure aux specifications.

Validation des mecanismes PSM/eDRX. L’ingenieur doit confirmer que les timers negocies lors de l’Attach/Registration (T3324 pour la duree active apres transmission, T3412 etendu pour le cycle PSM, eDRX cycle length) correspondent aux valeurs demandees par le terminal. Un reseau qui refuse les valeurs eDRX demandees et impose des cycles plus courts degradera la duree de vie batterie bien en dessous des specifications du deploiement.

Compatibilite avec l’infrastructure existante. eRedCap fonctionne sur les memes cellules 5G NR que les terminaux standard. Pas de nouvelle infrastructure radio necessaire. Mais le scheduler du gNB doit supporter les BWP reduites pour eRedCap, ce qui implique une mise a jour logicielle du RAN. L’ingenieur terrain doit valider que la version logicielle du gNB supporte les profils eRedCap avant de declarer un site operationnel pour ce type de terminaux.

L’ecosysteme eRedCap en 2026

Les premiers chipsets eRedCap sont attendus en echantillonnage au second semestre 2026, avec une disponibilite commerciale prevue en 2027. Qualcomm, MediaTek et Unisoc ont tous annonce des feuilles de route incluant eRedCap. Les operateurs qui deploient la 5G SA aujourd’hui devront s’assurer que leur infrastructure RAN sera compatible eRedCap via mise a jour logicielle — un point a negocier dans les contrats avec les fournisseurs d’equipement des maintenant.

Pour l’usine bavaroise du debut de cet article, eRedCap change l’equation. Au lieu de 35 EUR par chipset 5G NR, le cout tombe a environ 8 EUR. Sur 10 000 capteurs : 80 000 EUR au lieu de 350 000 EUR. Et les capteurs sont nativement 5G, sur le meme reseau prive que les robots et les cameras qui utilisent RedCap et 5G NR standard.

Les termes techniques utilises dans cet article — eRedCap, RedCap, NB-IoT, LTE-M, PSM, eDRX, BWP, PDCCH, PDSCH, PUSCH, FFT, PRB — sont definis dans notre glossaire technique. Pour approfondir l’architecture 5G NR et les mecanismes de signalisation, consultez nos articles sur la 5G SA.