La 5G RedCap modifie profondément la manière dont un réseau RAN doit être dimensionné pour des usages IoT et industriels intermédiaires. Contrairement aux LPWAN,RedCap consomme de vraies ressources NR,et contrairement à l’eMBB,il impose une planification fine pour éviter une dilution silencieuse de la capacité cellule. Vu côté RAN,RedCap n’est pas un “petit UE”,mais un profil NR à contraintes spécifiques qui doit être intégré explicitement dans les modèles de charge,les politiques de scheduling et les hypothèses de couverture. Cet article se place volontairement du point de vue ingénieur radio,et décrit comment dimensionner une cellule 5G accueillant des UEs RedCap sans dégrader les SLA globaux.
1. RedCap vu par le gNB : un UE NR à capacités déclarées réduites
Du point de vue RAN,un UE RedCap est vu comme un UE NR standard qui annonce des capacités limitées lors de la procédure de capability exchange. Le gNB n’active pas de stack spécifique,mais adapte ses décisions de scheduling aux capacités déclarées :bande passante maximale réduite,une seule couche spatiale,et débits plafonnés.
Cela signifie que RedCap n’est pas isolé par défaut. Sans politique explicite,les UEs RedCap partagent les mêmes ressources physiques PRB que les UEs eMBB et URLLC.
2. Hypothèses de bande passante et impact sur la planification
RedCap est généralement limité à 20 MHz maximum en FR1. Dans une cellule NR typique de 40 à 100 MHz,les UEs RedCap n’exploitent donc qu’une fraction du spectre disponible.
Cependant,la consommation RAN ne se mesure pas en MHz supportés par l’UE,mais en PRB effectivement alloués. Un UE RedCap peut consommer un nombre significatif de PRB s’il transmet fréquemment ou si la modulation chute en raison de la couverture.
Erreur classique :supposer que RedCap “ne coûte presque rien” en RAN parce que le débit est modéré. En réalité,un RedCap mal couvert peut coûter plus cher en PRB qu’un UE eMBB bien radio.
3. Modulation,codage et coût en PRB
La performance RedCap dépend fortement du MCS réellement utilisé. En zone de bonne couverture,un UE RedCap peut fonctionner avec des modulations efficaces et transmettre rapidement ses données,libérant les PRB.
En zone de couverture limite,le même UE bascule vers des MCS robustes,augmente son temps de transmission et consomme davantage de ressources radio par bit utile. Pour le dimensionnement,il faut toujours raisonner sur le MCS plancher accepté en exploitation,et non sur les valeurs nominales.
4. Modèle simple de charge RedCap uplink
Prenons un exemple réaliste. Un UE RedCap transmet 100 octets utiles toutes les secondes. Avec overhead NR,le payload total peut atteindre environ 200 à 300 octets. Si le MCS effectif donne un débit utile de 500 kbps,le temps radio nécessaire est de l’ordre de quelques millisecondes par seconde,soit une occupation très faible.
Mais si le MCS chute à 100 kbps en bord de cellule,le temps radio est multiplié par cinq. À l’échelle de centaines ou milliers d’UEs RedCap,cette différence devient déterminante pour la charge cellule.
5. RedCap et uplink : point critique du dimensionnement
Dans les scénarios IoT industriels,le trafic RedCap est souvent majoritairement uplink. Or l’uplink est généralement la ressource limitante en RAN FR1,notamment en TDD.
Un dimensionnement sérieux doit vérifier que la configuration TDD offre suffisamment de symboles uplink pour absorber la charge RedCap sans dégrader l’uplink eMBB ou URLLC. Dans certains cas,il peut être nécessaire d’ajuster le ratio DL/UL ou de réserver des ressources spécifiques.
6. Scheduler et priorisation des UEs RedCap
Le scheduler NR est clé. Sans règles explicites,les UEs RedCap peuvent entrer en concurrence directe avec des UEs eMBB pour des PRB uplink,ou être pénalisés par des flux haut débit.
En environnement industriel,il est recommandé d’utiliser le slicing ou des politiques de QoS différenciées pour garantir un comportement prévisible. RedCap n’impose pas un slice dédié,mais il le rend souvent nécessaire pour maîtriser la charge.
7. Dimensionnement cellule multi-profil
Une cellule RedCap bien conçue distingue plusieurs profils. Capteurs périodiques à faible débit,terminaux quasi temps réel,et équipements semi-continus comme des caméras basse résolution.
Chaque profil a une signature RAN différente. Le dimensionnement doit considérer le pire cas combiné,par exemple des transmissions simultanées en uplink lors d’événements industriels ou de synchronisation périodique.
8. RedCap et latence : attention aux effets de congestion
La latence RedCap dépend moins de la PHY que de la congestion cellule. Un RedCap en zone propre peut avoir une latence très faible,mais dès que la cellule est chargée,les délais de scheduling dominent.
Cela signifie que les SLA de latence RedCap ne sont tenables que si la charge globale est maîtrisée. La latence n’est pas garantie par RedCap en soi,mais par la politique RAN associée.
9. RedCap et couverture : piège du “ça passe donc c’est bon”
RedCap étant NR FR1,la couverture est similaire à la 5G classique. Toutefois,un UE RedCap en limite de couverture reste connecté mais consomme énormément de ressources radio.
Pour éviter une dilution de capacité,il est recommandé de dimensionner la couverture avec une marge suffisante pour RedCap,ou de restreindre l’accès RedCap dans certaines zones limites si la charge devient excessive.
10. RedCap et handover
Les UEs RedCap sont souvent mobiles mais à vitesse modérée. Le handover NR fonctionne normalement,mais les pertes de qualité radio lors des transitions peuvent provoquer des pics de consommation PRB temporaires.
Dans les sites industriels ou campus,une densification modérée des cellules est souvent préférable à une couverture étendue avec des zones limites chroniques.
11. Interaction RedCap et URLLC
RedCap peut coexister avec des flux URLLC,mais il ne doit jamais perturber les ressources réservées à ces flux critiques. Cela impose une configuration stricte du scheduler et des priorités.
RedCap n’est pas URLLC par défaut. Il peut être utilisé dans des applications quasi temps réel,mais uniquement si le RAN est dimensionné pour absorber les pics sans contention.
12. Méthodologie de dimensionnement recommandée
Étape un,définir les profils RedCap avec volume,fréquence et latence cible. Étape deux,fixer un MCS plancher réaliste basé sur la couverture minimale acceptée. Étape trois,calculer la charge uplink en PRB au pire cas. Étape quatre,valider la configuration TDD et la priorisation scheduler. Étape cinq,simuler ou mesurer en charge pour détecter les effets de congestion.
Tout dimensionnement qui saute l’une de ces étapes conduit à des réseaux RedCap instables ou surdimensionnés.
13. RedCap dans une cellule mixte eMBB,URLLC,IoT
Le vrai défi n’est pas une cellule “RedCap only”,mais une cellule mixte. RedCap doit être vu comme un consommateur de ressources intermédiaire,qui peut devenir dominant en nombre d’UEs même si le trafic individuel est faible.
Le dimensionnement doit donc raisonner en nombre d’UEs actifs simultanément et non uniquement en débit agrégé.
Conclusion
Vu côté RAN,la 5G RedCap est une question de discipline de dimensionnement plus que de technologie. RedCap s’intègre parfaitement dans une cellule NR existante,mais uniquement si la couverture,le scheduler et la charge uplink sont maîtrisés. Sous-estimer l’impact RedCap conduit à une dilution silencieuse de la capacité et à des latences imprévisibles. Bien dimensionnée,RedCap permet d’étendre la 5G à des usages IoT et industriels intermédiaires sans sacrifier la performance globale du réseau. C’est un outil d’ingénierie puissant,mais exigeant.