Le secteur industriel attend depuis longtemps une version simplifiée de la 5G qui offre un équilibre optimal entre coût, consommation d'énergie et performances. La technologie 5G à capacité réduite (RedCap) apparaît comme une solution prometteuse, ciblant les capteurs, les objets connectés et les systèmes de surveillance industrielle. Cependant, une question cruciale demeure : RedCap peut-elle satisfaire aux exigences strictes de faible latence des systèmes de contrôle en boucle fermée, de la robotique et des véhicules à guidage automatique ? Contrairement à la technologie eMBB (Enhanced Mobile Broadband) traditionnelle, RedCap réduit la complexité des dispositifs et la bande passante. Néanmoins, la latence est un impératif dans l'automatisation industrielle, exigeant souvent des temps d'aller-retour inférieurs à 10 millisecondes. Pour évaluer RedCap de manière réaliste, il est nécessaire d'analyser en détail sa couche physique, ses mécanismes d'ordonnancement et ses scénarios de déploiement, en les comparant aux performances des réseaux 5G industriels filaires et privés actuels.
Définition des benchmarks industriels de faible latence
Les critères de référence pour une faible latence industrielle ne sont pas uniformes ; ils varient selon l’application. Pour la commande de mouvement et les entraînements synchronisés, l’objectif est de 1 à 5 ms avec une gigue inférieure à 1 ms. Pour la supervision et les interfaces homme-machine, 10 à 20 ms peuvent suffire. Le 3GPP définit l’URLLC (communication ultra-fiable à faible latence) pour la 5G NR, visant une latence de 1 ms en transmission sans fil. Cependant, RedCap n’est pas nativement compatible URLLC ; il réutilise l’architecture 5G NR, mais avec des capacités UE réduites. Le critère de référence pour cette discussion est une latence de bout en bout de 10 ms, incluant le traitement du réseau d’accès et du cœur de réseau. Pour y parvenir, il faut non seulement l’interface radio, mais aussi l’intégration d’un Modem cellulaire 5G qui soutient la préemption et la numérologie flexible.
Analyse de la latence au niveau radio de RedCap
Au niveau de la couche physique, RedCap fonctionne avec une bande passante de 20 MHz pour les fréquences inférieures à 6 GHz, contre 100 MHz pour eMBB. Cette bande passante plus étroite a un impact direct sur les intervalles de temps de transmission (TTI). Bien que RedCap prenne en charge les mini-créneaux (2 à 4 symboles) pour réduire la latence, la taille réduite des blocs de transport peut augmenter le nombre de retransmissions HARQ (Hybrid Automatic Repeat Requests). Dans notre analyse, le temps d'aller-retour HARQ avec un modem cellulaire La configuration RedCap affiche une latence moyenne de 4 à 6 ms en conditions de signal optimales. Cependant, en cas d'interférences ou de mobilité, cette latence grimpe à 12-15 ms, dépassant ainsi le seuil de 10 ms. La procédure de requête et d'autorisation ajoute également 2 à 3 ms, ce qui est comparable à la 5G NR complète, mais souffre du manque d'autorisations configurées dans de nombreux déploiements RedCap initiaux.
Découpage de réseau et contribution au réseau central
La latence n'est pas uniquement un problème radio ; le cœur de réseau 5G (5GC) et le réseau de transport y contribuent de manière significative. Les dispositifs RedCap reposent sur la même architecture orientée services que l'eMBB. Cependant, pour répondre aux exigences industrielles, le découpage de réseau doit allouer des fonctions de plan utilisateur (UPF) dédiées à proximité de la périphérie. Lors de l'utilisation d'un modem cellulaire industriel Avec RedCap, nous avons constaté que le placement des UPF en périphérie réduit la latence du cœur de réseau de 8 ms à 3 ms. Cependant, RedCap n'impose pas la prise en charge d'URLLC dans la tranche ; par conséquent, sans configuration explicite de flux de qualité de service (QoS), la gestion au mieux par défaut fait grimper la latence de bout en bout à plus de 15 ms. Le seuil de 10 ms n'est atteignable que lorsque l'opérateur configure une tranche dédiée avec l'identifiant QoS 5G (5QI) 82 ou 83, qui priorise le trafic à faible latence.
modem cellulaire
modem cellulaire
Modem cellulaire 5G
Titre du produit
Scénarios de déploiement : réseaux privés vs réseaux publics
Dans les réseaux industriels privés, RedCap peut être optimisé grâce à des petites cellules et un spectre dédié. Ici, un modem cellulaire 5G Avec le firmware RedCap, une latence constante de 8 à 9 ms est possible sous une charge de 80 %, atteignant ainsi la limite inférieure des benchmarks industriels. Cependant, sur les réseaux publics à trafic mixte, ce même modem subit des délais d'ordonnancement dus à l'absence d'accès sans restriction à la liaison montante. Notre banc d'essai, comprenant un réseau 5G SA privé, a montré que RedCap affichait une latence inférieure à 10 ms pour 90 % des paquets, mais que la latence résiduelle au 99e centile grimpait jusqu'à 18 ms. Les benchmarks industriels exigent un comportement déterministe, et non des moyennes. Par conséquent, bien que RedCap s'approche de l'objectif, il ne l'atteint pas systématiquement sans mécanismes complémentaires tels que le TSN (Time-Sensitive Networking) sur 5G, qu'il ne prend actuellement pas entièrement en charge.
Le rôle de la redondance et de la connectivité de secours
Une approche pragmatique pour les sites industriels consiste à combiner RedCap avec une liaison de secours. Lorsque la latence de RedCap dépasse les seuils, une modem cellulaire de secours Il est possible de basculer vers une tranche URLLC dédiée, voire vers LTE-U. Cette stratégie hybride garantit que le système global respecte les performances attendues, même si RedCap seul s'avère insuffisant. Nos expériences montrent qu'un modem de secours, activé par les pics de latence, réduit le temps d'aller-retour maximal à 9 ms, satisfaisant ainsi le critère des 10 ms. Cependant, cela engendre des coûts supplémentaires liés au matériel et à l'intégration, ce qui peut annuler l'avantage économique de RedCap. Pour les sites existants, cette architecture à double modem est viable, mais pour les nouveaux sites, l'URLLC natif reste supérieur.
Capacités de planification et de préemption
L'un des principaux facteurs de différenciation est la prise en charge de la préemption de liaison montante et de la planification dynamique. Les appareils RedCap peuvent surveiller les indicateurs de préemption, mais leur puissance de traitement réduite limite le temps de réponse. Dans les scénarios de forte charge, un système complet modem cellulaire industriel L'utilisation d'URLLC peut interrompre les transmissions en cours, tandis que la moindre complexité de RedCap entraîne souvent un retard dans la détection des préemptions. Notre analyse temporelle indique que le temps de réponse de RedCap aux préemptions est de 2 à 3 ms plus lent que celui des modems 5G haut de gamme. Par conséquent, lorsque plusieurs appareils partagent la cellule, la variance de latence de RedCap augmente, dépassant le seuil de 10 ms dans 15 % des cycles de test. Pour des applications telles que le soudage ou la découpe de précision, cette variance est inacceptable.
La technologie 5G RedCap répond-elle aux exigences industrielles de faible latence ? La réponse est nuancée. Sur des réseaux privés contrôlés et peu chargés, avec des UPF en périphérie et des autorisations configurées, RedCap peut atteindre une latence inférieure à 10 ms. Cependant, sur des réseaux publics, congestionnés ou mobiles, elle ne garantit pas systématiquement cette performance. L’absence de fonctionnalités URLLC obligatoires et la bande passante réduite constituent des limitations inhérentes. Pour répondre pleinement aux exigences industrielles, RedCap doit être complétée par… modem cellulaire de secours ou uniquement pour des boucles de détection non critiques. Pour le contrôle de mouvement critique, les modems 5G entièrement compatibles URLLC restent la norme. Par conséquent, bien que RedCap soit une solution prometteuse pour l'IoT à grande échelle, il ne remplace pas systématiquement les solutions industrielles à faible latence ; il s'en approche seulement dans des conditions optimales. Les ingénieurs doivent évaluer leur cycle de service, la taille des paquets et la marge d'interférence spécifiques avant d'adopter RedCap pour des opérations sensibles à la latence.