Un système NTN tire ses données de synchronisation de plusieurs sources. Les équipements d’utilisateur (UE), y compris les appareils IoT, se synchronisent sur l’heure GPS via des récepteurs GNSS. Les données orbitales et les prévisions d’éphémérides sont généralement fournies en UTC. L’infrastructure informatique peut, en interne, horodater les données en TAI. Les opérateurs planifient les faisceaux et analysent les journaux en UTC ou en heure locale. Chacun de ces systèmes de temps présente un décalage de quelques secondes (et non de quelques millisecondes) par rapport aux autres, et ces décalages ne sont pas fixes. Lorsqu’un ingénieur introduit une donnée orbitale horodatée en UTC dans un calcul qui repose sur l’heure GPS, le résultat présente une erreur de 18 secondes. Le système ne signale pas cette anomalie. Il n’y a ni erreur de format, ni échec d’analyse syntaxique, ni exception. Les chiffres indiquent simplement qu’un satellite ne se trouve pas là où le système le situe.
Il s'agit d'un problème d'intégration structurelle. Dans les déploiements NTN où la précision temporelle détermine directement la précision de positionnement, la planification et l'acquisition de la liaison, un décalage non détecté de cette ampleur entraîne de véritables défaillances qui se manifestent sous une forme totalement différente.
Les fuseaux horaires et leurs décalages
Le temps GPS est une échelle de temps atomique continue dont l'époque correspond à minuit UTC le 6 janvier 1980. Il n'intègre pas de secondes intercalaires. Le décalage entre le temps TAI et le temps GPS est exactement de 19 secondes, valeur fixée par définition à l'époque GPS.
Le TAI ( temps atomique international) est la référence atomique de base issue d'environ 400 horloges atomiques réparties dans le monde entier. Il s'agit par ailleurs d'un temps continu qui ne comporte pas de secondes intercalaires.
L'UTC est calculé à partir du TAI en soustrayant un nombre entier de secondes intercalaires, introduites par le Service international de la rotation terrestre et des systèmes de référence afin de maintenir l'UTC en phase avec la rotation de la Terre. Depuis janvier 2017, le décalage est de TAI moins UTC, soit 37 secondes, aucune seconde intercalaire supplémentaire n'étant prévue jusqu'au début de l'année 2026.
D'après ces définitions : l'heure GPS est actuellement en avance de 18 secondes sur l'UTC, le TAI est en avance de 37 secondes sur l'UTC, et l'heure GPS est en retard de 19 secondes exactement sur le TAI. L'heure de l'horloge murale ou l'heure locale ajoute les décalages horaires à l'UTC, ce qui entraîne un décalage supplémentaire en fonction de la localisation de l'opérateur.
Il s'agit de décalages précis et déterministes qui se répercutent sur tous les calculs auxquels ils interviennent.
Pourquoi NTN aggrave la situation
Dans les réseaux cellulaires terrestres, ce type de décalage temporel est moins susceptible d'entraîner des défaillances opérationnelles. Les stations de base et les terminaux sont proches les uns des autres, les délais de propagation sont faibles et l'infrastructure de synchronisation est étroitement contrôlée au sein du domaine d'un même opérateur.
La technologie NTN modifie tous ces aspects. Les délais de propagation vers LEO satellites sont de l’ordre de quelques dizaines de millisecondes. Pour les GEO constellations, le temps aller-retour de la liaison radio entre l’appareil et la station au sol via le satellite atteint environ 240 millisecondes. Les valeurs d’avance temporelle dans les réseaux NTN atteignent des ordres de grandeur bien supérieurs à ceux observés sur Terre. Les décalages Doppler dus aux vitesses orbitales de l’ LEO s peuvent dépasser plusieurs dizaines de kilohertz. Les empreintes des faisceaux se déplacent en continu, et la planification doit tenir compte de la position future des satellites.
Tout cela repose sur la connaissance de la position du satellite et du moment où il se trouve. Les calculs de mécanique orbitale s'appuient sur des données d'éphémérides qui décrivent la position du satellite en fonction du temps. Si le système de temps des éphémérides ne correspond pas à celui de l'utilisateur, toutes les grandeurs dérivées subissent un décalage correspondant à la différence totale : position du satellite, vitesse, prédiction Doppler, orientation du faisceau et précompensation de l'avance temporelle. Une erreur de 18 secondes sur une orbite de LEO s correspond à un décalage de la trajectoire au sol d’environ 135 kilomètres. Le satellite ne se trouve tout simplement pas à l’endroit où le système l’avait calculé.
Ce mode de défaillance est silencieux. Les données d'éphémérides sont valides d'un point de vue structurel. Le calcul s'exécute sans erreur. Les résultats se situent dans des plages numériques plausibles. La position prévue du satellite est erronée, et toutes les fonctions en aval qui en dépendent subissent une dégradation ou échouent : planification des faisceaux, précompensation Doppler, calcul de l'avance de synchronisation.
Où ces décalages se manifestent-ils dans la pratique ?
L'exemple le plus parlant est celui de l'interface entre les données des terminaux d'utilisateur (UE) et les données orbitales. Un appareil récupère l'heure à partir de son récepteur GNSS, qui fonctionne selon le temps GPS. Les satellites GPS diffusent un paramètre de décalage par rapport à l'UTC dans le message de navigation, ce qui permet aux récepteurs de calculer l'UTC si nécessaire, mais l'échelle de temps native reste le temps GPS.
Les données orbitales sont toutefois généralement transmises et stockées en UTC. Les prévisions d'éphémérides, les tableaux de position des satellites et les plans de programmation des faisceaux sont généralement horodatés en UTC, car il s'agit de la convention en vigueur dans le domaine des opérations spatiales et de la référence standard pour la plupart des infrastructures au sol.
Lorsqu’un système utilise des données d’éphémérides horodatées en UTC et les recoupe avec l’horloge d’un appareil synchronisé au GPS sans appliquer la correction de 18 secondes, la position du satellite utilisée pour la précompensation Doppler et l’avance de synchronisation est évaluée à une époque erronée. L’appareil tente alors d’acquérir un signal en se basant sur des paramètres dérivés d’une position de satellite qui est soit obsolète de 18 secondes, soit située 18 secondes dans le futur. Dans un scénario de « LEO », cela peut signifier que le satellite s’est déplacé bien au-delà de la plage angulaire dans laquelle les paramètres calculés sont valides.
Le symptôme observé par un ingénieur est une tentative d'accès aléatoire qui échoue, un signal de synchronisation qui semble faible ou absent, ou une pré-compensation Doppler qui ne converge pas. La défaillance se présente comme un problème radio ou un problème de budget de liaison, et rien dans les résultats du diagnostic n'indique un décalage entre les systèmes de temps.
Un deuxième décalage courant se produit dans les environnements de validation et de test. Certaines bibliothèques de synchronisation et certains composants d’infrastructure peuvent être configurés pour utiliser le TAI ou peuvent, par défaut, utiliser une échelle de temps atomique sans ajustement de seconde intercalaire. Si ces journaux sont comparés au comportement des appareils en temps GPS, il en résulte un décalage de 19 secondes. S’ils sont comparés à des événements programmés en UTC, le décalage est de 37 secondes. La corrélation entre ces journaux peut générer des anomalies de synchronisation apparentes, des mesures de latence erronées ou des séquences de défaillances mal attribuées. Un décalage de 18 ou 37 secondes dans l’alignement des journaux peut faire apparaître un événement correctement chronométré comme s’il s’était produit en dehors de sa fenêtre valide, ou masquer une véritable défaillance de synchronisation en la déplaçant vers une zone apparemment inoffensive.
Un troisième domaine concerne la gestion des secondes intercalaires. Le décalage GPS-UTC n'est pas en permanence de 18 secondes. Il varie à chaque fois qu'une seconde intercalaire est introduite. Les secondes intercalaires sont annoncées par l'IERS au moins six mois à l'avance ; le changement lui-même est donc prévisible. Le risque réside dans le fait qu'un logiciel comportant une valeur de décalage codée en dur ne soit pas mis à jour lorsque le changement prend effet. Les satellites GPS diffusent le décalage actuel, et les récepteurs correctement implémentés l'appliquent automatiquement. En revanche, les logiciels qui intègrent ce décalage de manière fixe, ou les bases de données qui stockent un facteur de conversion GPS-UTC sans le mettre à jour, subiront une dérive silencieuse d’une seconde à chaque fois qu’une seconde intercalaire est ajoutée. Les systèmes validés avant l’introduction d’une seconde intercalaire peuvent tomber en panne après celle-ci sans qu’aucun changement de configuration n’ait été effectué, et cette panne ne fera aucune mention des secondes intercalaires dans les journaux d’événements ou les rapports de diagnostic.
Les mesures d'atténuation dans la pratique
L'idéal serait que tous les composants d'un système NTN fonctionnent selon un système de temps unique. Le temps GPS s'impose naturellement, étant donné que les appareils s'y synchronisent par défaut. Dans la pratique, cela n'est pas toujours possible. Les fournisseurs de données orbitales, l'infrastructure du segment sol, les éléments centraux du réseau et les outils opérationnels ont chacun leurs propres conventions, et l'intégrateur n'a pas toujours la possibilité de les modifier.
Ce qui relève du contrôle de l’intégrateur, c’est l’étiquetage explicite du système de temps et la conversion à chaque interface. Chaque entrée temporelle doit comporter une déclaration sans ambiguïté de son système de temps. Chaque transfert entre des composants fonctionnant dans des systèmes de temps différents doit appliquer le décalage correct, issu d’une référence mise à jour régulièrement plutôt que d’une constante codée en dur. La validation doit inclure l’injection délibérée d’un décalage, afin de tester le comportement du système lorsqu’une entrée temporelle arrive dans un système de temps inattendu, et de s’assurer que cette incompatibilité est bien détectée plutôt que d’être absorbée silencieusement.
Le point de vue de l’ Gatehouse Satcom
Chez Gatehouse Satcom, l'alignement des systèmes de temps constitue un enjeu pratique d'intégration rencontré dans l'ensemble des programmes NTN. Travailler avec des données orbitales, la synchronisation des équipements d'utilisateur (UE) et l'intégration de systèmes satellitaires implique de passer régulièrement d'un système de temps à un autre : GPS, UTC et TAI. Nous avons constaté qu’une éphéméride fournie dans un système de temps et utilisée dans un autre peut entraîner des défaillances qui se manifestent sous forme d’anomalies radio ou de planification plutôt que d’erreurs de synchronisation. L’identification et la résolution de ces décalages font partie intégrante de notre travail d’intégration et de validation, et constituent l’un des domaines où l’expérience acquise sur de multiples configurations de systèmes NTN apporte une valeur ajoutée directe en matière d’ingénierie.
Nos environnements de test sont conçus pour mettre en évidence les hypothèses relatives au système de temps et pour détecter les incohérences avant qu'elles n'atteignent la phase de déploiement. Le coût lié à leur détection en production se mesure en semaines de débogage passées à chercher au mauvais endroit.
Le décalage entre l'heure GPS, l'UTC et le TAI est déterministe, bien documenté et facile à corriger. Aucun élément du système n'indique que la correction n'a pas été appliquée. Dans NTN, où chaque donnée temporelle alimente directement le positionnement, la planification et la synchronisation, un décalage non détecté de 18 secondes entraîne l'échec d'un déploiement pour des raisons qui semblent sans rapport avec la synchronisation.
Au niveau de l' 3GPP niveau de l'interface radio, la synchronisation est dérivée de l'heure GPS. Le réseau diffuse le décalage actuel de la seconde intercalaire aux appareils via les informations système, ce qui permet de dériver l'heure UTC. L'interface radio elle-même fonctionne selon une échelle de temps basée sur le GPS. La frontière entre le GPS et l'UTC est donc franchie à un point défini de l'architecture. Considérer l'alignement des systèmes horaires comme une exigence d'intégration explicite, plutôt que comme un détail implicite, commence par déterminer où se situe cette frontière.
