NTRIP Caster : protocole, architecture, sécurité et performances

Qu’est-ce qu’un NTRIP Caster ?

NTRIP signifie Networked Transport of RTCM via Internet Protocol. Le protocole a été conçu pour transporter des données GNSS, notamment les corrections RTCM, sur des réseaux IP à l’aide de mécanismes proches de HTTP. Le NTRIP Caster reçoit des flux provenant de NTRIP Servers ou de sources historiques, les associe à des points de montage, puis les redistribue aux NTRIP Clients qui possèdent les autorisations nécessaires.

Le mot caster décrit bien le rôle de diffusion. Le serveur ne calcule pas nécessairement les corrections : une station, un moteur de réseau ou un service amont les produit. Le caster organise les sessions, contrôle les identifiants, fournit le catalogue des flux et copie les octets vers les clients. Un même caster peut héberger une base unique, plusieurs stations CORS, des solutions VRS ou MAC, et des points relayés depuis d’autres infrastructures.

Dans un déploiement professionnel, le caster est aussi un composant de sécurité et d’exploitation. Il limite le nombre de sources et de clients, empêche l’utilisation simultanée d’un compte, journalise les refus, surveille l’activité et expose des métriques. L’administration doit être séparée du port NTRIP, placée derrière HTTPS et protégée par des comptes tenant ou des clés techniques.

XYZRVB associe le moteur NTRIP Caster à un centre de contrôle GNSS. Cette combinaison permet de voir la station qui alimente un flux, le rover qui le consomme, les coordonnées reçues, le mode RTK déclaré et les événements de la session. Elle transforme un relais réseau en service observable.

Architecture source, caster, client et rover

La station de référence doit connaître des coordonnées cohérentes avec le repère de travail. Elle génère des messages décrivant sa position, ses observations et parfois son équipement. Le lien entre la station et le caster peut être établi par un protocole SOURCE historique ou par une requête NTRIP Server plus moderne. Après validation du mot de passe et du point de montage, le serveur répond et commence à lire le flux binaire.

Le rover commence généralement par obtenir le sourcetable ou utilise un point de montage déjà configuré. Il envoie une requête GET avec une authentification Basic, un User-Agent et, en NTRIP v2, des en-têtes HTTP/1.1. Une fois accepté, il reçoit une réponse de succès puis les messages RTCM en continu. Pour un service VRS ou pour la sélection de la station la plus proche, il peut envoyer périodiquement une phrase NMEA GGA sur la même connexion.

La latence cumulée comprend la production du message, l’envoi de la base, le traitement éventuel par un moteur réseau, la distribution du caster et la liaison mobile du rover. Le caster doit limiter les copies, éviter les conversions et écrire de façon asynchrone. Un client lent ou déconnecté ne doit pas bloquer la lecture de la source ni les autres rovers.

Lorsqu’un flux amont est importé, le caster local devient lui-même client d’un autre caster. Il faut alors séparer les identifiants amont des comptes rover locaux. Le point importé est publié au tenant, puis le relais est ouvert à la demande. Le caster local conserve l’autorité sur les utilisateurs autorisés à voir et consommer ce flux.

Un abonnement au caster externe peut alimenter plusieurs rovers sur un même point de montage grâce au relais partagé. Chaque point externe différent ouvre cependant une connexion amont distincte. Si le fournisseur refuse plusieurs connexions simultanées avec le même identifiant, deux points demandent deux identifiants ou abonnements et trois points en demandent trois. Si la réutilisation est permise, le même accès peut servir plusieurs points selon le contrat.

NTRIP v1 et NTRIP v2

NTRIP version 1

NTRIP v1 s’appuie sur des échanges proches de HTTP/1.0, avec des particularités historiques. De nombreux clients attendent la ligne de réponse ICY 200 OK lorsqu’un point de montage est accepté. Les sources anciennes peuvent envoyer une première ligne de type SOURCE suivie d’un mot de passe et du mountpoint. Ces comportements restent très présents dans les récepteurs GNSS et expliquent pourquoi un serveur strictement web ne suffit pas.

NTRIP version 2

NTRIP v2 aligne davantage les échanges sur HTTP/1.1. Le client peut annoncer Ntrip-Version: Ntrip/2.0, utiliser Host et recevoir un statut HTTP 200. Les serveurs et clients doivent gérer correctement les en-têtes, la fin de l’en-tête et le maintien de la connexion. Le corps reste un flux binaire continu et ne doit pas être interprété comme une page web.

La compatibilité pragmatique consiste à reconnaître les deux styles sans confondre une négociation TLS avec une requête NTRIP en clair. Les premiers octets d’un ClientHello TLS sont binaires. Si le port attend du NTRIP non chiffré, le serveur doit signaler clairement que le client utilise HTTPS sur un port HTTP. Pour accepter TLS, on peut ajouter un écouteur sécurisé dédié ou une terminaison adaptée qui préserve les connexions longues.

Sourcetable, mountpoints et découverte des flux

Le sourcetable est la réponse textuelle obtenue lorsque le client demande la racine du caster. Les lignes STR décrivent les streams, les lignes CAS d’autres casters et les lignes NET des réseaux. Une entrée STR contient notamment le point de montage, un identifiant, le format, la liste de messages, les constellations, le pays, les coordonnées approximatives, le besoin de GGA et d’autres paramètres.

Le point de montage est un identifiant contractuel. Son orthographe, sa casse et sa disponibilité doivent être stables. Une station physique peut porter un nom court, tandis qu’un service réseau peut annoncer VRS, NEAR ou MAC. Le client ne doit voir que les points autorisés pour son tenant. Publier un flux puis le refuser systématiquement crée une mauvaise expérience ; accepter un flux absent du sourcetable crée au contraire une ressource invisible et difficile à administrer.

Les coordonnées du sourcetable sont utiles pour la découverte, mais elles ne remplacent pas la position RTCM. Elles peuvent être statiques ou arrondies. Le serveur peut enrichir son monitoring lorsqu’il décode RTCM 1005 ou 1006, puis signaler une incohérence importante entre la déclaration et les coordonnées reçues. Une telle comparaison doit tenir compte du repère et de la nature du service réseau.

Lors de l’import d’un caster externe, XYZRVB analyse le sourcetable amont et présente les points disponibles à l’utilisateur. Celui-ci peut tout importer ou sélectionner un sous-ensemble. Les entrées sont enregistrées dans un fichier propre au tenant, avec les coordonnées et la description nécessaires, puis fusionnées au sourcetable local sans dupliquer un point déjà déclaré.

Transport des corrections RTCM

RTCM 3 est un format binaire encadré. Une trame commence par le préambule 0xD3, annonce une longueur de charge utile puis se termine par un contrôle CRC de 24 bits. Le flux TCP ne respecte pas forcément les limites des trames : une lecture peut contenir une partie de message, plusieurs messages complets ou la fin d’un message suivie du début du suivant. Un parseur doit donc conserver un tampon entre les lectures.

Le caster n’a pas besoin de décoder chaque observation pour la redistribuer. Il peut transférer les octets immédiatement, puis utiliser un analyseur parallèle pour extraire les messages utiles au monitoring. Les types 1005 et 1006 décrivent la station, 1007 et 1008 l’antenne, 1033 peut fournir des informations de récepteur, et les familles MSM transportent les observations multi-constellations. L’ensemble exact dépend de la station et de la stratégie de diffusion.

L’encodage de texte du système d’exploitation ne doit jamais intervenir dans ce chemin. Sur Windows comme sur Debian, le flux est un tableau d’octets. Les seules chaînes concernent la requête initiale, les en-têtes, le sourcetable et les phrases NMEA. Cette séparation est fondamentale pour éviter qu’un octet RTCM soit remplacé ou interprété comme un caractère.

Le volume dépend du nombre de constellations, de satellites, de signaux et de la fréquence des messages. La bande passante d’un rover reste généralement modérée, mais elle se multiplie par le nombre de clients. Le partage d’un tampon immuable ou une diffusion asynchrone contrôlée réduit la consommation CPU. Le serveur doit aussi retirer rapidement les sockets qui échouent afin de ne pas répéter des écritures coûteuses.

Authentification, isolation et sécurité

L’authentification Basic encode le couple utilisateur-mot de passe en Base64, mais ne le chiffre pas. Sur un réseau public, TLS est donc recommandé lorsque les récepteurs le prennent en charge. À défaut, un VPN ou un réseau privé peut protéger le transport. Le port d’administration doit toujours utiliser HTTPS, car il permet de modifier les comptes, les sources et les secrets.

Le serveur applique à chaque identifiant rover un nombre maximal de connexions simultanées défini par l’administrateur. Un compte partagé peut donc servir plusieurs rovers tout en conservant des numéros de session distincts. Pour rendre les journaux immédiatement attribuables à un matériel, permettre une révocation ciblée et éviter les ambiguïtés, la configuration recommandée reste un identifiant par rover avec une limite de 1.

L’adresse IP n’est pas une identité matérielle. Une connexion mobile peut changer d’adresse ou passer par un NAT. L’adresse MAC ne traverse pas les routeurs et reste invisible au serveur Internet. Un certificat client TLS unique peut fournir une identité cryptographique forte, mais seulement si l’opérateur contrôle l’émission, l’installation et la révocation des certificats sur les récepteurs.

Dans une plateforme multi-tenant, l’autorisation doit associer le domaine demandé, le compte et la ressource. Il ne suffit pas de masquer les points d’un autre tenant dans l’interface. Le serveur doit filtrer le sourcetable et refuser toute requête directe vers un mountpoint externe au tenant. Pour les appareils sans Host, l’utilisation d’une adresse IP dédiée par entreprise peut fournir le contexte manquant.

La configuration d’un caster amont crée un autre risque : la requête sortante. Le serveur doit résoudre le domaine, refuser les adresses loopback, link-local et privées, limiter la taille du sourcetable, appliquer des délais et ne jamais retourner le mot de passe amont dans les réponses API. Le secret peut être conservé dans un fichier tenant protégé par les permissions du système.

Performances, disponibilité et exploitation

Une boucle de lecture par source et des écritures asynchrones vers les clients conviennent à un nombre modéré de sessions. Les opérations critiques sont la copie des buffers, le traitement des clients lents et la journalisation. Les logs Debug sont utiles pendant le diagnostic, mais afficher chaque paquet pour des centaines de rovers peut produire plus de charge disque que le transport RTCM lui-même. En production, les niveaux doivent être ciblés.

Le serveur doit imposer des limites : nombre total de clients, clients par source, sources, taille d’en-tête, délai de lecture initiale et taille du sourcetable externe. Ces limites protègent la mémoire et les descripteurs de fichiers. Les files d’attente d’écriture doivent rester bornées pour qu’un rover avec une mauvaise liaison ne retarde pas le service entier.

La disponibilité comprend le redémarrage automatique par systemd, mais aussi la fermeture propre des sessions. Lors d’un déploiement, un arrêt peut attendre des connexions longues. Il faut donc définir un délai d’arrêt cohérent, publier l’événement de déconnexion puis laisser systemd terminer le processus si nécessaire. Les rovers se reconnectent généralement automatiquement.

Les métriques utiles incluent clients actifs, sources actives, octets reçus et envoyés, erreurs d’authentification, âge du dernier paquet, durée des sessions et latence d’événement. Le suivi CPU, mémoire, charge système, espace disque et sockets complète les métriques GNSS. Sur un VPS, la mémoire disponible est plus pertinente que la mémoire libre brute, car Linux utilise le cache pour accélérer les accès.

Un plan de sauvegarde doit couvrir les fichiers de configuration, les sourcetables tenant, les casters externes, la base d’abonnements et les archives RINEX selon leur valeur. Les exécutables peuvent être reconstruits, mais les secrets et données d’exploitation nécessitent une procédure sécurisée. Les sauvegardes doivent être testées, pas seulement créées.

Mise en production d’un NTRIP Caster

La mise en production commence par un inventaire précis : domaines, adresses IP, ports, certificats, stations, mountpoints, comptes clients, secrets sources et responsabilités. Chaque valeur doit avoir un propriétaire et une procédure de modification. Les environnements de test et de production utilisent des ports, fichiers de données et identifiants séparés afin qu’un essai ne coupe pas un service terrain.

Le DNS doit pointer vers l’adresse réellement attachée au serveur. Pour les récepteurs qui envoient Host, plusieurs tenants peuvent partager une adresse. Pour les matériels qui ne l’envoient pas, une adresse IP additionnelle liée au tenant permet de résoudre l’entreprise à partir de l’adresse locale de la connexion. Cette association est testée avec le matériel réel, car un logiciel de bureau et un récepteur embarqué ne construisent pas toujours la même requête.

Nginx protège l’API web par HTTPS et prend en charge la montée WebSocket. Le port NTRIP peut rester directement servi par l’application ou utiliser un écouteur TLS conçu pour les connexions longues. Une configuration web standard qui tamponne ou ferme les réponses peut interrompre le RTCM. Les délais du proxy, les en-têtes Upgrade et la taille des requêtes doivent donc correspondre aux endpoints.

Le service systemd définit le répertoire de travail, l’exécutable, l’utilisateur non privilégié et la politique de redémarrage. Le répertoire de travail est particulièrement important : il détermine le fichier appsettings, le sourcetable et les données tenant réellement utilisés. Une confusion entre deux dossiers de publication peut expliquer qu’une modification visible sur disque ne soit pas chargée par le processus.

Avant l’ouverture commerciale, un test de bout en bout connecte une source, vérifie sa présence dans le sourcetable, ouvre un rover avec les identifiants du tenant, confirme la réponse NTRIP et inspecte les premiers octets RTCM. Le test inclut la déconnexion, la reconnexion, un mauvais mot de passe, un point inconnu, une GGA correcte et, si applicable, un flux amont.

Après le déploiement, les contrôles automatiques vérifient le service systemd, les ports, l’API, le certificat, le téléchargement du logiciel et les erreurs récentes. Les journaux Debug peuvent être temporairement activés pour l’investigation, puis ramenés à un niveau adapté. Un plan de retour utilise les sauvegardes des binaires et de la configuration prises juste avant la mise à jour.

FAQ NTRIP Caster

Quelle est la différence entre une source, un caster et un client NTRIP ?

La source envoie un flux de corrections, le caster l’authentifie et le redistribue, tandis que le client NTRIP sélectionne un point de montage et reçoit le flux. Dans un réseau RTK, la source est généralement une station de référence et le client un rover.

NTRIP v1 et NTRIP v2 peuvent-ils fonctionner sur le même serveur ?

Oui. Un caster moderne peut accepter les échanges historiques de NTRIP v1 et les requêtes HTTP/1.1 de NTRIP v2. La compatibilité doit être vérifiée avec les récepteurs réellement utilisés, notamment pour les en-têtes, l’authentification et la réponse de connexion.

Qu’est-ce qu’un point de montage NTRIP ?

Un point de montage, ou mountpoint, est le nom logique d’un flux proposé par le caster. Il peut correspondre à une station physique, à une solution réseau, à un flux VRS ou à un flux relayé depuis un autre caster.

Le protocole NTRIP chiffre-t-il automatiquement les corrections ?

Non. Une session NTRIP classique sur TCP ne chiffre pas son contenu. Le chiffrement nécessite TLS, souvent publié directement par le caster ou placé derrière un proxy compatible. Le choix doit tenir compte des capacités des récepteurs GNSS.

Pourquoi le sourcetable est-il important ?

Le sourcetable décrit les flux disponibles : nom, format, messages RTCM, constellations, coordonnées, besoin éventuel de GGA et autres propriétés. Il permet au client de choisir un service compatible avant d’ouvrir le flux binaire.

Combien d’abonnements faut-il pour relayer un caster externe ?

Dans le modèle de relais XYZRVB, un abonnement et son identifiant amont peuvent alimenter plusieurs rovers sur un même point de montage grâce à une connexion amont partagée. Chaque point différent nécessite une connexion amont distincte. Si le caster externe interdit plusieurs connexions simultanées avec le même identifiant, il faut autant d’identifiants ou d’abonnements que de points ouverts. S’il autorise la réutilisation, le même accès peut être utilisé dans les limites du contrat.

Comment identifier plusieurs rovers qui partagent un compte ?

Chaque session conserve un numéro de connexion distinct, même lorsque plusieurs rovers partagent un identifiant. Pour attribuer immédiatement chaque position et événement à un matériel déterminé, il est recommandé de créer un identifiant par rover et de fixer son quota de connexions simultanées à 1.