Vous n'êtes pas ingénieur ? Lisez le résumé ↓
Une charge utile NTN régénérative embarquant un gNB complet ou un gNB-DU est un nœud de télécommunications auquel on ne peut pas accéder physiquement. Une fois opérationnelle, elle doit être configurée, mise à niveau et entretenue comme n’importe quel élément d’ RAN , mais dans des conditions qui invalident la plupart des hypothèses relatives au cycle de vie des systèmes terrestres. Le principal défi technique consiste à maintenir la cohérence au niveau des protocoles au sein d’une constellation en service, où les satellites fonctionnent inévitablement avec des versions logicielles différentes, desservent des zones de couverture qui se chevauchent et se transfèrent mutuellement le trafic, alors qu’il est impossible de tous les mettre à jour simultanément.
Cet article utilise NR cette terminologie tout au long du texte, mais les mêmes contraintes de cycle de vie s’appliquent aux NB-IoT les charges utiles régénératives transportant un eNB. Le défi technique est le même : comment maintenir une constellation de nœuds de télécommunications à jour, conformes et interopérables lorsqu’il est impossible de tous les mettre à jour en même temps ?
Cet article examine en quoi la gestion du cycle de vie des logiciels destinés aux charges utiles gNB embarquées diffère fondamentalement de celle des déploiements terrestres, et quelles contraintes techniques déterminent la manière dont les mises à jour à l'échelle de la constellation doivent être conçues.
La référence terrestre et les raisons pour lesquelles elle n'est pas valable
Dans l’ RAN terrestre, les mises à jour logicielles des gNB suivent des schémas bien établis : déploiements par étapes sur les stations de base, indicateurs de fonctionnalité (feature flags) bloquant les nouveaux comportements jusqu’à la fin de la validation, retour rapide à la version précédente via des partitions de démarrage redondantes, et suites de tests de régression exécutées sur le trafic en production dans le cadre de déploiements « canary ». Les hypothèses sous-jacentes sont une bande passante montante généreuse vers le nœud, un accès physique pour la récupération, un matériel homogène au sein d’une phase de déploiement, et la capacité de faire converger l’ensemble d’un cluster vers une seule version logicielle en quelques heures ou quelques jours.
Une LEO constellation remet en cause chacune de ces hypothèses. La bande passante de téléchargement est limitée à la capacité de la liaison TT&C, généralement des liaisons de commande en bande S ou en bande Ka à bande étroite, conçues pour la télémétrie et la gestion interne, et non pour le transfert de données en masse. Une image logicielle gNB complète peut devoir être segmentée sur plusieurs passages, chaque fenêtre de contact avec la station au sol ne durant que quelques minutes. Les révisions matérielles divergent selon les phases de construction de la constellation, qui s’étendent sur plusieurs années. Les satellites lancés en 2025 pourraient être équipés d’architectures de processeurs ou de générations de FPGA différentes de celles des satellites lancés en 2028, mais ils devront néanmoins coexister au sein du même réseau de services. La restauration d’une version antérieure, bien que possible en principe, comporte des risques auxquels les déploiements terrestres ne sont jamais confrontés : un échec de la séquence de démarrage sur un satellite ne disposant d’aucun chemin de calcul redondant entraîne la perte du nœud.
Bande passante TT&C et planification des transferts en amont
La liaison d’alimentation transportant le trafic du plan utilisateur n’est pas la même que celle utilisée pour la gestion de la plateforme. Les liaisons montantes de commandes TT&C sont, de par leur conception, limitées en bande passante, la priorité étant donnée à la fiabilité et à la marge de la liaison plutôt qu’au débit. Le téléchargement d’une image logicielle de plusieurs dizaines ou centaines de mégaoctets via une liaison prévue pour des flux de commandes de l’ordre du kilobit par seconde, ou aux débits de quelques mégabits par seconde disponibles sur les plateformes plus récentes, nécessite toujours une planification minutieuse sur plusieurs passages de la station au sol.
Les mises à jour ne peuvent pas être appliquées à la demande. Elles doivent être planifiées, mises en file d’attente et séquencées à l’échelle de la constellation. Le délai entre le premier téléchargement (T0) et la mise à jour du dernier satellite (T0+n) dépend de la taille de la constellation, de la couverture des stations au sol et du débit TT&C, mais n s’exprime en semaines ou en mois, et non en heures. Les retransmissions, les préemptions prioritaires pour la gestion des anomalies et les conflits avec les opérations des charges utiles allongent encore davantage la durée de la campagne. La mise à jour est une campagne, pas un événement ponctuel.
Conséquence : à tout moment au cours d'une campagne de déploiement, le réseau fonctionne avec des versions logicielles hétérogènes. Il ne s'agit pas d'un cas exceptionnel. C'est la situation normale pour tout réseau faisant l'objet d'une maintenance active.
Divergence entre les révisions matérielles
Les constellations sont fabriquées et lancées par tranches. Chaque tranche reflète le matériel de calcul, la matrice FPGA et les interfaces périphériques disponibles au moment de l’intégration du satellite, souvent 18 à 36 mois avant le lancement. Au cours de la durée de vie opérationnelle d’une constellation, les plateformes matérielles évolueront. Le logiciel gNB doit soit masquer ces différences derrière une couche d’adaptation matérielle, soit maintenir des cibles de compilation parallèles pour chaque révision matérielle.
Les interfaces critiques et le routage matériel sont verrouillés au moment du lancement et ne peuvent plus être modifiés par la suite. Cela impose des exigences très strictes en matière de validation pré-lancement, tant au niveau matériel que logiciel, bien au-delà de la 3GPP la simple conformité aux protocoles. La capacité du satellite à revenir à un état de bon fonctionnement après un échec de mise à jour, ainsi que la stabilité de ses procédures de démarrage et de récupération, doivent être vérifiées avant son lancement.
Une fois en orbite, chaque version logicielle doit être validée par rapport à toutes les révisions matérielles encore opérationnelles au sein de la constellation. Cela pose un problème de tests de régression combinatoires. Une version qui utilise une accélération matérielle disponible uniquement sur les charges utiles les plus récentes doit fonctionner de manière dégradée sur les plates-formes plus anciennes. Dans la pratique, les satellites dotés de révisions matérielles et logicielles différentes sont regroupés en niveaux de capacités, chacun desservant des populations d’utilisateurs finaux (UE) correspondant aux fonctionnalités prises en charge. Le segment sol doit suivre ces niveaux et en tenir compte dans ses décisions relatives à la mobilité et à l’équilibrage de charge.
LEO La durée de vie des satellites, comprise entre trois et cinq ans, constitue un cycle de renouvellement naturel. Les équipements obsolètes sont mis hors orbite et remplacés par des plateformes plus récentes, ce qui limite la période de divergence entre les versions. Mais au sein de cette période, le problème combinatoire demeure.
Coexistence des versions et interaction au niveau de la couche de protocole
La contrainte la plus déterminante est d’ordre architectural. Lorsque deux satellites fonctionnant avec des versions logicielles différentes desservent la même population d’appareils utilisateurs (UE) et participent à un transfert inter-satellites ou inter-faisceaux, trois couches de protocole sont les plus sensibles au décalage de version : la synchronisation MAC et HARQ, la gestion des états RRC et le calcul de l’avance de synchronisation. Chacune d’entre elles engendre une catégorie différente de problèmes à la frontière du transfert.
Imaginons qu’un UE passe du satellite A, fonctionnant sous la version N, au satellite B, fonctionnant sous la version N+1. Si la version N+1 a modifié le comportement de planification MAC, en changeant la gestion des compteurs du processus HARQ, en ajustant l’alignement du cycle DRX ou en modifiant l’interprétation du BSR, l’UE subit une discontinuité lors du transfert. Le message de reconfiguration RRC doit transmettre des paramètres cohérents avec ce que la cellule cible met effectivement en œuvre. Si les cellules source et cible ne s’accordent pas sur les relations de synchronisation, la machine à états de l’UE peut rencontrer des situations inattendues.
3GPP Les spécifications sont conçues pour des environnements hétérogènes. L'échange de capacités lors de l'accès aléatoire et de l'établissement de la connexion permet aux équipements d'utilisateur (UE) et aux nœuds du réseau de négocier les fonctionnalités prises en charge, tandis que les conteneurs d'extension critiques et non critiques de la norme TS 38.331 permettent d'introduire de nouveaux éléments d'extension (IE) sans compromettre la rétrocompatibilité. Les réseaux terrestres comportant des nœuds de différents fournisseurs sont confrontés à des défis d'interopérabilité similaires liés aux différences entre les implémentations et les interprétations des spécifications.
Ces mécanismes traitent de la compatibilité entre l'UE et le réseau, mais ils ne résolvent que la moitié du problème. L'interface orientée vers l'UE peut être conforme aux spécifications dans les deux versions, tandis que le comportement entre les nœuds diffère. Si le planificateur du satellite A suppose un profil de synchronisation HARQ et que celui du satellite B en suppose un autre, la signalisation Xn ou F1 entre eux, ou entre chacun d'eux et une unité de commande (CU) terrestre partagée, doit tenir compte de cette différence.
Pour les architectures utilisant une gNB-CU au sol avec des gNB-DU embarquées, telles que définies dans la norme TS 38.401, l'interface F1 devient la principale limite de version. Une CU doit rester compatible avec les DU exécutant différentes versions logicielles. L'interface E1 entre la CU-CP et la CU-UP introduit une deuxième limite liée à la version si la gestion du plan utilisateur évolue indépendamment d'une version à l'autre. Ce problème existe dans les déploiements terrestres d'O-RAN, mais il est bien plus contraignant lorsqu'il n'est pas possible de faire converger rapidement les versions. Les procédures F1AP, la gestion du contexte UE et les séquences d'établissement de la liaison doivent rester stables malgré la diversité des versions présentes dans la constellation à un moment donné.
Le nombre de processus HARQ, les algorithmes de planification et la synchronisation des retours d'information, tels que spécifiés dans la norme TS 38.213, ont une incidence directe sur la latence perçue par l'UE et le BLER. Les adaptations spécifiques au NTN pour les RTT longs, notamment l'allongement des fenêtres de retour d'information et la modification du nombre de processus, continuent d'être affinées au fil des versions d'3GPP . Les implémentations qui suivent les versions successives héritent de ces changements, ce qui fait du comportement HARQ une source persistante de divergences entre les versions.
Toute modification apportée à la gestion des états « RRC Inactive » ou « RRC Connected », ou encore aux seuils de signalement des mesures et de déclenchement des transferts, a une incidence sur les performances de mobilité au sein de la constellation. Un satellite doté de seuils de transfert plus agressifs se comportera différemment en tant que cellule source par rapport à un satellite utilisant une configuration plus prudente, même si les deux restent conformes aux spécifications.
Le calcul de l'avance de synchronisation (TA) du réseau NTN dépend des éphémérides des satellites et de l'estimation de la position des terminaux utilisateurs (UE). Si une nouvelle version affine le calcul de la TA, en améliorant la précompensation Doppler ou en ajustant la TA commune diffusée dans le SIB, les terminaux utilisateurs passant d'un ancien satellite à un nouveau constatent un changement brusque dans la gestion de la TA lors du transfert.
Mises à jour progressives, activation progressive des fonctionnalités et retour en arrière
La réponse pratique à ces contraintes consiste à associer des stratégies de mise à jour progressive et une activation sélective des fonctionnalités par satellite. Les nouveaux comportements du protocole sont implémentés mais désactivés par des indicateurs de configuration jusqu’à ce qu’une masse critique de la constellation ait reçu la mise à jour. Ce n’est qu’à ce moment-là que les nouveaux comportements sont activés à l’échelle de la constellation, ou par région, si le chevauchement des zones de couverture permet une activation progressive.
La restauration en orbite est possible mais soumise à des contraintes. Les schémas de démarrage à double partition restent courants, permettant de revenir à l’image précédente dont le bon fonctionnement est avéré. Les architectures de charge utile plus récentes intègrent une isolation des processus par conteneurs ou un confinement des défaillances basé sur un hyperviseur, ce qui permet une récupération plus fine au niveau des fonctions plutôt qu’un remplacement complet de l’image. Dans les deux cas, les conditions de déclenchement doivent être soigneusement définies. Un satellite qui effectue une restauration pendant une fenêtre de service peut perturber les connexions actives des terminaux d’utilisateurs (UE). Un satellite qui ne parvient pas à démarrer la nouvelle image et ne peut pas revenir en arrière de manière autonome devient un nœud inactif jusqu’au prochain contact TT&C, ce qui peut prendre plusieurs heures pour un satellite « LEO » situé hors de la zone de couverture d’une station au sol.
Le segment sol doit donc suivre, pour chaque satellite : la version actuelle du logiciel, la révision du matériel, les indicateurs de fonctionnalités actives et l'état de restauration. La gestion de la mobilité, l'équilibrage de charge et les décisions de transfert doivent tenir compte des différences de capacités. Il ne s'agit pas d'une complexité facultative. C'est la base opérationnelle d'une constellation régénérative maintenue en état de fonctionnement.
Point de vue depuis la guérite
En travaillant directement avec les piles de protocoles NTN, nous constatons que les modifications apportées à une couche interagissent avec les hypothèses d’autres couches d’une manière difficile à prévoir à partir de la seule analyse des spécifications. Une modification de la planification MAC, bien que correcte au niveau local, peut altérer les schémas de retransmission HARQ de manière à mettre à rude épreuve les temporisateurs de réassemblage RLC ou à modifier le comportement d'inactivité RRC. Ces interactions sont reproductibles lors des tests d'intégration lorsque vous exécutez des nœuds de versions mixtes avec des profils de retard et d'effet Doppler réalistes, mais elles restent invisibles si votre suite de tests de régression ne valide que le comportement d'un nœud unique avec une seule version.
Notre expérience en matière de tests de coexistence des versions, consistant à exécuter différentes combinaisons de versions sur des segments de constellation simulés, confirme que c’est à la frontière entre les versions que les problèmes se concentrent. Non pas au sein d’un nœud unique exécutant le nouveau code, mais au niveau du transfert, à l’interface F1, là où deux nœuds ayant des interprétations légèrement différentes de la synchronisation ou de l’ordonnancement doivent coopérer sur un contexte UE partagé. En tenir compte dès la conception, définir des contrats de compatibilité entre versions, établir des matrices de régression couvrant des combinaisons de versions plutôt que des versions individuelles, et instrumenter les interactions au niveau de la couche protocolaire pour assurer une surveillance inter-versions, n’est pas faire preuve d’une prudence excessive. Cela reflète ce que nous observons lorsque ces contraintes se présentent sans que l’on y soit préparé.
Conclusion
Le principal défi de la gestion du cycle de vie logiciel pour les charges utiles NTN régénératives réside dans la coexistence durable de multiples versions logicielles au sein d’une constellation qui ne peut pas être mise à jour de manière atomique, où le comportement au niveau de la couche protocole doit rester suffisamment cohérent pour préserver l’expérience de l’utilisateur (UE) lors des transferts inter-satellites, et où les options de retour en arrière sont réelles mais ont un coût. Les équipes qui considèrent la gestion du cycle de vie comme une préoccupation opérationnelle post-déploiement se heurteront à ces contraintes, qui se traduiront par un impact sur le service. La durée de vie des satellites « LEO » (de trois à cinq ans) offre un cycle de renouvellement naturel qui conduit à terme au retrait du matériel le plus ancien ; mais pendant cette période, les choix architecturaux, les stratégies de validation et les conceptions du segment sol permettant un fonctionnement avec des versions mixtes doivent être en place. Ils doivent être définis avant que le premier satellite n’atteigne son orbite.
En bref, pour les non-ingénieurs
Lorsqu’un satellite intègre son propre logiciel de station de base cellulaire (une « charge utile régénérative »), la mise à jour de ce logiciel après le lancement ne se déroule en rien comme celle d’une antenne-relais au sol. Il est impossible d’envoyer un technicien sur place. La bande passante en amont est très faible. Et il n’est pas possible de mettre à jour tous les satellites en même temps : il faut plusieurs semaines pour déployer une seule mise à jour sur l’ensemble d’une constellation.
Cela signifie qu'à tout moment, différents satellites utilisent différentes versions logicielles. C'est tout à fait normal, mais cela pose un véritable défi opérationnel : lorsqu'un téléphone passe d'un satellite à un autre utilisant des versions différentes, le transfert doit s'effectuer sans heurts malgré les différences dans la manière dont chaque satellite gère la synchronisation, la planification et la gestion des connexions.
La solution technique consiste à mettre en place des déploiements contrôlés, un « feature gating » (qui consiste à n’activer les nouvelles fonctionnalités qu’une fois qu’un nombre suffisant de satellites a reçu la mise à jour) et des tests rigoureux sur toutes les combinaisons de versions. La solution architecturale consiste à concevoir dès le départ un système capable de fonctionner avec des versions mixtes, plutôt que de considérer cela comme un problème à résoudre après le lancement.
Pour les responsables de programme et de mise en œuvre, cela signifie que la gestion du cycle de vie doit être intégrée dès le départ à l’architecture et à la conception du segment sol, et non pas constituer une préoccupation opérationnelle postérieure au déploiement. Pour les dirigeants, le principal enseignement à retenir est que l’analyse de rentabilité d’une constellation régénérative doit tenir compte d’une gouvernance logicielle pérenne, et pas seulement du déploiement initial.
