La réussite d’un déploiement 5G RedCap repose beaucoup moins sur la norme que sur le paramétrage effectif du RAN. Un réseau mal configuré peut transformer RedCap en consommateur silencieux de PRB uplink,dégradant la latence eMBB et les flux critiques. À l’inverse,un paramétrage rigoureux permet d’absorber des centaines voire des milliers d’UEs RedCap par cellule sans impact visible. Ce guide décrit les leviers concrets de configuration du scheduler NR et les règles d’ingénierie associées.
1. Principe fondamental : RedCap n’est pas auto-isolé
Par défaut,un UE RedCap est traité comme un UE NR standard avec des capacités réduites. Le scheduler ne “protège” pas la cellule contre RedCap sans règles explicites. Toute stratégie sérieuse commence par accepter que RedCap doit être volontairement contenu et priorisé correctement.
Objectif du paramétrage : empêcher RedCap de consommer excessivement l’uplink tout en garantissant une latence et une fiabilité suffisantes pour les cas d’usage visés.
2. Déclaration de capacités et admission control
Première étape critique : exploiter la déclaration de capacités UE lors de l’attach. Les UEs RedCap annoncent explicitement leur bande passante maximale,leur configuration MIMO et leurs limites de débit.
Bonne pratique : utiliser ces informations dans l’admission control pour plafonner le nombre d’UEs RedCap simultanément actifs dans une cellule. Il est préférable de refuser ou retarder l’accès plutôt que de dégrader l’ensemble de la cellule.
Règle terrain : définir un seuil maximal d’UEs RedCap actifs simultanément par cellule,en fonction du profil de trafic et du MCS plancher accepté.
3. Segmentation logique via QoS Flow et slicing
Même sans slice dédié,RedCap doit être associé à des QoS Flows spécifiques avec des 5QI adaptés. Éviter absolument de placer RedCap sur des 5QI best-effort identiques à eMBB.
Approche recommandée :
– un 5QI pour capteurs périodiques tolérant une latence plus élevée,
– un 5QI distinct pour RedCap quasi temps réel,
– jamais de partage avec URLLC critique.
Si le réseau supporte le slicing,un slice RedCap dédié est idéal pour isoler complètement les politiques de scheduling.
4. Paramétrage du scheduler uplink
L’uplink est le point le plus critique. Le scheduler doit limiter la part de PRB UL consommée par RedCap.
Bonnes pratiques génériques :
– définir un plafond de PRB UL allouables aux UEs RedCap par TTI,
– éviter les politiques purement throughput-oriented pour RedCap,
– privilégier des politiques fairness contrôlée plutôt que max-rate.
Objectif : garantir que même en cas de rafale RedCap,l’uplink conserve des ressources pour eMBB et URLLC.
5. Gestion du MCS plancher
Le MCS effectif a un impact direct sur la charge cellule. Autoriser RedCap à fonctionner à des MCS trop bas revient à accepter une explosion de la consommation PRB.
Paramétrage clé : définir un MCS minimal acceptable pour RedCap. En dessous de ce seuil,l’UE peut être temporairement ralenti,mis en backoff,ou même dépriorisé.
C’est contre-intuitif,mais refuser des transmissions en très mauvaise radio améliore la stabilité globale.
6. Configuration TDD et symboles uplink
Dans les déploiements TDD,le ratio DL/UL est souvent optimisé pour eMBB. L’introduction massive de RedCap uplink peut saturer l’UL.
Actions possibles :
– augmenter légèrement la proportion de symboles UL,
– réserver certaines fenêtres UL pour RedCap,
– éviter les profils TDD trop asymétriques en environnement RedCap dense.
Le dimensionnement doit être fait sur le pire cas d’activité RedCap simultanée.
7. DRX,eDRX et comportement UE
RedCap bénéficie de DRX,mais un mauvais paramétrage peut provoquer des réveils trop fréquents et une charge UL inutile.
Bonne pratique : aligner les cycles DRX RedCap sur la périodicité applicative réelle. Pour des capteurs périodiques,des DRX longs réduisent la contention et la consommation.
Pour les usages quasi temps réel,accepter une consommation plus élevée mais limiter le nombre d’UEs dans ce profil.
8. Gestion des pics synchronisés
Erreur classique : synchronisation involontaire des transmissions RedCap,par exemple des capteurs envoyant tous leurs données à la même seconde.
Contre-mesures RAN :
– randomisation des fenêtres de scheduling,
– limitation du nombre d’UEs RedCap servis par TTI,
– backoff contrôlé en cas de rafale.
Un réseau stable est un réseau qui désynchronise volontairement ses objets.
9. Handover et mobilité RedCap
Lors d’un handover,un UE RedCap peut brièvement consommer plus de ressources en raison de la dégradation radio transitoire.
Paramétrage recommandé :
– éviter des cellules trop larges avec zones limites chroniques,
– préférer une densification modérée,
– limiter les reconfigurations radio agressives pendant handover pour RedCap.
10. Supervision et KPIs spécifiques RedCap
Un réseau RedCap bien paramétré se surveille avec des KPIs dédiés :
– PRB UL consommés par classe UE,
– MCS moyen et MCS minimal RedCap,
– latence de scheduling RedCap,
– taux de retransmissions HARQ RedCap.
Sans visibilité spécifique,RedCap devient un bruit de fond invisible.
11. Politique de dégradation contrôlée
Il est essentiel de définir une politique claire en cas de surcharge. RedCap doit être le premier à être ralenti avant eMBB critique ou URLLC.
Dégradation acceptable : augmentation de latence RedCap,taux d’update plus faible. Dégradation inacceptable : impact sur flux critiques ou instabilité cellule.
12. Check-list de paramétrage synthétique
Limiter UE RedCap actifs simultanément. Associer RedCap à QoS dédiées. Plafonner PRB UL RedCap. Définir MCS plancher. Ajuster TDD UL si nécessaire. Aligner DRX avec l’application. Désynchroniser les transmissions. Surveiller KPIs dédiés. Prévoir une politique de dégradation explicite.
Conclusion
La 5G RedCap ne pose pas un problème technologique,mais un problème de gouvernance radio. Le scheduler NR est suffisamment puissant pour absorber RedCap,à condition d’être explicitement configuré pour cela. Sans règles claires,RedCap dilue silencieusement la capacité uplink et détruit les garanties de latence. Avec un paramétrage discipliné,RedCap devient une extension naturelle et maîtrisée de la 5G industrielle. C’est un sujet de paramétrage avant d’être un sujet de standard.