Brevet FR3062538A1 — publié le 20180803

PROCEDE ET SYSTEME POUR TRANSPORTER DES SIGNAUX DANS UN SYSTEME SATELLITAIRE L'invention concerne un système et un procédé pour transmettre 5 des signaux dans un système satellitaire. Elle se situe notamment dans le cadre des réseaux utilisateurs satellites pour la transmission de signaux radiofréquences. L'accroissement des débits notamment dans le cadre des satellites dit VHTS (abrégé anglo-saxon de Very High Throughput Satellite) 10 entraîne la multiplication des infrastructures avec des coûts de maintenance et d'interconnexion qui sont corrélés. Pour des besoins de capacité et donc de ressources fréquentielles, il est nécessaire d'utiliser des bandes de fréquence de plus en plus hautes (QN du spectre électromagnétique) comportant des variations d'atténuation liées aux conditions météorologiques 15 importantes. Quand les conditions météorologiques sont trop dégradées, il est nécessaire d'utiliser une stratégie de diversité de site consistant à passer par un autre site d'ancrage connu sous l'expression anglo-saxonne « gateway ». Une « gateway » est localisée à divers endroits sous la couverture d'un satellite. La diversité de site consiste en l'utilisation de lieux 20 suffisamment éloignés pour que la corrélation entre les conditions météorologiques soit négligeable. L'inconvénient qui en résulte est la multiplication des localisations et donc des infrastructures avec l'accroissement des coûts qui l'accompagne. La figure 1 illustre un réseau utilisateur 1 selon l'art antérieur dans 25 lequel un Hub 10 et un module RF 11 sont colocalisés dans une gateway 12. Une telle architecture conduit à des tailles de gateway importantes car ces dernières doivent être dimensionnées de façon à pouvoir distribuer vers le satellite le maximum de capacité. De plus, le trafic doit être rerouté d'une gateway à une autre en cas de diversité de site. 30 L'idée mise en oeuvre dans la présente invention consiste notamment à localiser les hubs au niveau d'un point de collecte, plus connu 3062538 2 dans le domaine des satellites sous l'abréviation PoP, réduisant ainsi la taille des gateways qui conservent uniquement la partie RF, en fonctionnement normal. L'invention concerne un système de transmission de données 5 dans un réseau de communication comprenant un lien de transmission satellite, une partie fournisseur de services, une partie utilisateur et un réseau d'accès satellite comprenant un point de collecte PoP adapté à dispatcher les flux de données, plusieurs gateways comprenant la partie radiofréquence caractérisé en ce qu'il comporte un modulateur de données à 10 transmettre comprenant au moins deux parties : - Une première partie positionnée au niveau de la partie point de collecte PoP et comportant les modules suivants : - un module NCR adapté à prendre en compte une référence de temps absolue externe pour reconstituer une horloge de réseau 15 pour une synchronisation dans la transmission des données, - un module émetteur recevant la valeur d'une référence temporelle à insérer dans le paquet de données à transmettre et émettant en direction du module NCR une information sur un instant de synchronisation pour le récepteur, 20 - Une deuxième partie positionnée au niveau de la partie radiofréquence d'une gateway et comportant les modules suivants : - un module récepteur, - un module de reconstruction d'une horloge en local, à partir des informations de synchronisation contenues dans les données 25 transmises, - un module d'insertion d'une référence temporelle dans un paquet de données reçues par le récepteur avant transmission des données via le satellite, 3062538 3 - La première partie et la deuxième partie échangent des données encapsulées selon le protocole utilisé pour la transmission dans le système. Le système peut comporter un démodulateur constitué de deux parties : Une première partie située au niveau de la partie gateway du système comportant les modules suivants : - Un module de réduction du nombre de bits transportant l'information, avant transmission via un module émetteur, Une deuxième partie située au niveau d'un point de collecte PoP et comportant au moins le module suivant : - Un module récepteur. Le module récepteur de la partie située au niveau radiofréquence d'une gateway est, par exemple, adapté à générer les informations suivantes : une information sur la latence du lien de transmission des données, une information sur le déclenchement de l'émission des données H.F.Rx trigger, une information H.F.Rx NCR correspondant à la valeur d'une date correspondant au début d'une Hyper-trame à prendre en compte sur réception de l'information « H.F Rx trigger » afin de reconstituer localement 20 au niveau de la partie radiofréquence une horloge corrigée de la latence de transmission entre la première partie et la deuxième partie du modulateur. Le module de reconstitution d'horloge est, par exemple, adapté à reconstituer une synchronisation réseau et à fournir une date courante à insérer dans un champ de données d'une hyper-trame en construction. 25 La partie « Front-End » peut comporter en plus les éléments suivants : - un module d'adaptation du flux de données, - un module de codage, 3062538 4 - un module de mapping adapté à transformer les données sous forme de bits codés en symboles, - un module adapté à insérer un en-tête et des pilotes, - un module de modulation des données numériques, 5 un module Tuner, et un module M&C Handler assurant la configuration et la surveillance des différents éléments du modulateur. Le modulateur peut être un modulateur de type DVB-S2, ou de type DVB-RCS2. Le protocole mis en oeuvre est par exemple le protocole 10 CPRI. L'invention concerne aussi un procédé de transmission de signaux dans un réseau de communication comprenant un lien de transmission satellite comportant une partie fournisseur de services, une partie utilisateur et un réseau d'accès satellite comprenant un point de collecte PoP adapté à 15 dispatcher les flux de données, plusieurs gateways comprenant la partie RF caractérisé en ce qu'il comporte au moins les étapes suivantes : - Une partie située au niveau d'un point de collecte du système construit une trame bande de base comprenant un champ de données incluant des informations de synchronisation et/ou un identifiant d'un utilisateur et un champ contenant des données provenant d'un fournisseur de services et destinées à l'utilisateur, afin de générer des données encapsulées avant transmission vers une deuxième partie du système adapté à moduler lesdites données, - La deuxième partie reconstruit une horloge locale à partir des informations de synchronisation contenues dans les données encapsulées, avant modulation des données, - Les données modulées sont ensuite transmises par satellite. Le procédé peut comporter une étape de reconstruction d'une valeur d'horloge en tenant compte de la valeur de la latence du lien de 30 transmission, de l'instant de déclenchement d'émission des données, de la valeur d'une date correspondant au début d'une hyper-trame reçue. 3062538 5 Le format des données est le format CPRI pour la transmission des données encapsulées ou encore le format de trames DVB-S2. D'autres caractéristiques et avantages de la présente invention apparaîtront mieux à la lecture de la description qui suit d'exemples de 5 réalisation donnés à titre illustratif et nullement limitatifs, annexée des figures qui représentent : - Figure 1, un schéma d'un réseau selon l'art antérieur, - Figure 2, un exemple d'architecture réseau selon l'invention, - Figure 3, un exemple d'architecture du modulateur selon l'invention, 10 - Figure 4, un exemple d'architecture du démodulateur selon l'invention, et - Figure 5, un exemple de mutualisation des modules. Afin de bien faire comprendre l'invention, l'exemple qui suit est donné dans le cadre d'un réseau utilisateur mettant en oeuvre un transport 15 radiofréquence RF et une interface connue de l'homme du métier sous les initiales anglo-saxonnes CPRI (Common Public Radio Interface) et pour un modulateur de type DVB-S2(x) et un démodulateur de type DVB-RCS2 connus de l'homme du métier. Sans sortir du cadre de l'invention, tout homme du métier pourra adapter les modules explicités ci-après pour leur 20 mise en oeuvre dans un système satellitaire quelque soit le protocole de transmission et de modulation/démodulation utilisé. La figure 2 illustre un exemple d'architecture selon l'invention comprenant une partie 20 fournisseur de services qui ne sera pas détaillée car son fonctionnement est connue de l'homme du métier, un module 21 ou 25 point de collecte PoP ayant notamment pour fonction de dispatcher les flux de données à partir des fournisseurs vers les utilisateurs, via les gateways. Ce module point de collecte, PoP, va inclure les différents hubs habituellement localisés dans l'art antérieur au niveau des gateways. La partie réseau satellite, 23, s'organise autour du « backbone » opérateur 25 qui permet de faire transiter les données entre le PoP, 21, et les gateways 261, 262, mais aussi les informations de gestion entre un ou plusieurs centres 3062538 d'exploitation réseau NOC (Networks Operations Center) 24 qui, reliés aux différentes gateways, permettent la gestion du système d'accès par satellite. En fonctionnement normal du dispositif selon l'art antérieur, dans les gateways 26j, se trouve la partie Hub 10 qui communique avec la partie RF 5 27j qui communique via le satellite ST vers des terminaux 28k de réception liés à différents utilisateurs 291. L'idée de base de l'invention est notamment de découper le modulateur et le démodulateur utilisés dans le système satellitaire au niveau du point de collecte PoP et au niveau des gateways du système afin de 10 minimiser le débit nécessaire à la transmission des données. Les parties Hub 10 étant disposées au niveau du point de collecte PoP, elles pourront être mutualisées. En effet, une gateway dans l'art antérieur est dimensionnée en considérant le cas le plus défavorable (nombre maximum de demandes et de débits simultanés en provenance de 15 plusieurs utilisateurs) ; ainsi la somme de la capacité des différentes gateways se trouvait être largement supérieure à celle du satellite. Dans le cas du procédé selon l'invention, la co-localisation des Hubs 10 au niveau du point de collecte PoP, 21, permet de dimensionner des Hubs 10 à la juste capacité du satellite. 20 La figure 3 illustre un exemple de modulateur 30 selon l'invention qui est distribué entre le point de collecte PoP et une gateway. Une première partie ou Back-End 30BE est située au niveau du Hub 10 et une partie Front- End 30FE se trouve dans le module RF 27j. L'idée consiste notamment à transporter la trame bande de base ou BB-Frame sur le lien CPRI. Cette 25 trame comporte un champ de données incluant des informations de synchronisation et/ou d'identification (identifiant) du demandeur ou de l'utilisateur et un champ pour des données issues du fournisseur de services à transmettre à un utilisateur demandeur. La partie Back-End 30BE comporte au moins les éléments 30 suivants : 3062538 7 - un module gestionnaire de trafic ou Trafic Handler 301 qui reçoit les données Di à moduler sur une interface ad'hoc par exemple GbE, connue de l'homme du métier, - un module Mode Adaptation 302, dont le contenu est par exemple, décrit 5 au paragraphe §5.1 du document ETSI EN 302 307 définissant le standard DVB-S2 dans sa version 1.4.1. Son rôle est de préparer les données Di afin de pouvoir les insérer dans la partie en-tête BB-Header, un module NCR 303 qui prend en compte une référence de temps absolue externe te't pour reconstituer une horloge de réseau NCR 10 (Network Clock Reference) pour permettre une synchronisation des différents équipements du réseau d'accès, en particulier l'envoi des trames RCS2 par les terminaux afin de pouvoir mettre en oeuvre un accès multiplexé en temps. Lors du début d'une nouvelle Hyper-trame CPRI à envoyer, indiqué par le paramètre déclencheur « H.F Tx 15 Trigger » explicité ci-après, ce module NCR fournit la date NCR courante (correspondant à un instant donné, information temporelle) afin qu'elle soit insérée dans le champ données propriétaires ou « proprietary data » de l'Hyper-trame en cours de construction, un module émetteur CPRI 304: ce module reçoit la valeur de la date 20 NCR à insérer dans le paquet de données à transmettre qui va permettre la synchronisation et la lecture des données et émet en direction du module NCR 303 une information H.F.TX trigger sur l'instant de synchronisation tsync pour le récepteur. Le fonctionnement de ces différents modules sera décrit plus loin. 25 La partie Front-End 30FE comporte les modules suivants : - Un module récepteur CPRI 310 qui émet plusieurs informations vers un module de reconstruction d'une horloge NCR, nécessaire à la synchronisation et à la lecture des données; ces informations contiennent une information sur la latence r du lien de transmission, une 30 information de déclenchement de réception de début d'une nouvelle 3062538 8 Hyper-Trame de données, H.F.Rx trigger, une information H.F.Rx.NCR qui correspond à la valeur NCR (date NCR) correspondant au début de l'Hyper-Trame reçue et donc à prendre en compte sur réception du « H.F Rx trigger » afin de reconstituer localement l'horloge NCR corrigée de la 5 latence de transmission; le module récepteur transmet aussi les données numériques radiofréquence transmises par la partie Back-End, - Un module de reconstruction de la valeur de l'horloge locale NCR, 311, à partir des informations de synchronisation contenues dans le paquet de données reçues par le récepteur CPRI (valeur de la date et valeur de la 10 latence), - Un module d'insertion, 312, de la date exacte (valeur NCR) dans un paquet de données, comme il est décrit, par exemple au paragraphe §6.2.1 ETSI EN 301-545-2, - Un module d'adaptation du flux de données, 313, dont le fonctionnement 15 est, par exemple, décrit au paragraphe §5.2 - ETSI EN 302 307. Son rôle est d'opérer un bourrage de la trame, si besoin, ainsi que d'insérer un en-tête BB-Header. Les données à émettre sont aussi embrouillées à ce niveau, - Un module de codage 314 : le contenu de ce bloc est décrit au 20 paragraphe §5.3 - ETSI EN 302 307. Son rôle est d'encoder les données avec un code correcteur d'erreur. Dans le cadre du standard de transmission DVB-S2(x), il s'agit d'un code BCH suivit d'un code vérification de parité à faible densité ou LDPC (Low Density Parity Code), - Un module de mise en cohérence ou mapping 315: le contenu de ce bloc 25 est décrit au paragraphe §5.4 - ETSI EN 302 307. Il transforme les données sous forme de bits encodés en symboles en fonction du type de constellation désiré. Dans certains cas, un entrelaçage des données est ajouté, - Un module 316 - PL-Framing : le contenu de ce bloc est décrit au 30 paragraphe §5.5 - ETSI EN 302 307. Il insère un en-tête, des pilotes 3062538 9 optionnels et procède à une dispersion de l'énergie en utilisant un code d'étalement, - Un module de modulation des données numériques 317 qui met en forme le signal à l'aide d'un filtre en racine de cosinus surélevé, par 5 exemple, et procède en fonction du débit symbole du protocole de transmission à une conversion de débit afin de nourrir un convertisseur numérique/analogique, - Un module Tuner 318: les signaux en sortie du convertisseur numérique analogique DAC sont transposés en fréquence intermédiaire afin d'être 10 émis vers les utilisateurs, RF Tx, - Un module 319 de contrôle et gestion, M&C Handler, assurant la configuration et la surveillance des différents éléments du modulateur. Ce module reçoit les informations de contrôle et de gestion. La gestion des informations d'horloge et de synchronisation (date 15 insérée dans la trame des données et latence) pour la partie modulateur située au niveau du Back-End et pour la partie modulateur située au niveau du Front-End va maintenant être décrite. Le module émetteur CPRI, 304, va encapsuler les données Di à transmettre en respectant le format CPRI. Ce format comprend une première partie contenant une information NCR 20 (informations pour la synchronisation des différents récepteurs) et des données Di à transmettre à la partie Front-End pour être modulées. Les données encapsulées sont transmises via un lien CPRI au niveau d'une ou de plusieurs gateways en fonction des demandes des utilisateurs. Un exemple de schéma de mutualisation des hubs et des 25 gateways est donné dans la suite de la description. La transmission des signaux RF numérisés se fera sur le lien CPRI évitant ainsi l'utilisation de câbles RF pour la transmission des données, la norme CPRI dans sa version 6.1 étant définie par le consortium du même nom sur le site internet www.cpri.info. 30 La figure 3 illustre aussi les étapes de reconstruction de la valeur de NCR. 3062538 10 Côté Back-End (30BE), un signal de déclenchement de réception des données Rx (H.F. Rx trigger) est généré par le module de réception CPRI 310 en début de l'hyper-trame, 401. Il est envoyé par le bloc émetteur CPRI au module de reconstruction du NCR 311. Ce signal est accompagné 5 de la valeur de la date NCR récupérée de la partie « émanant du fournisseur » extraite des données pour former le signal « H.F. Rx NCR ». L'instant d'arrivée ta du paquet de données est signalé par un signal « H.F. Rx trigger », 402, ainsi que la valeur de date NCR correspondante par « H.F. Rx NCR », 403. Ces deux signaux (valeur de la 10 date et instant d'arrivée du paquet des données) permettent au module de reconstruction « Local NCR reconstruction » 311 de reconstituer localement l'horloge NCR grâce à une boucle de type PLL numérique, par exemple. En utilisant la fonction native du CPRI permettant de mesurer la latence entre les deux extrémités de la chaîne de transmission (instant 15 d'émission - instant de réception côté récepteur du modulateur), cette valeur locale de l'horloge NCR, NCRIocal, peut être compensée NCRoemp pour représenter une valeur identique à la valeur de l'horloge au niveau du BackEnd. Cette information est passée du bloc « CPRI receiver » au bloc « Local NCR reconstruction » par le signal « Link latency », Th 404. 20 Au final, cette horloge NCR reconstituée va pouvoir servir à l'insertion d'une date NCR dans les trames DVB-S2(x) selon les recommandations de la norme DVB-RCS2 (§6.2.1) connue de l'homme du métier. Le format CPRI est par exemple utilisé dans le format l&Q (phase 25 et quadrature de phase) de huit bits. Les données issues d'un Back-End vers un Front-End sont encapsulées dans un container AxC de 16 bits, par exemple, en utilisant le format indiqué. Ceci permettra notamment de pouvoir transporter les données de plusieurs Back-End vers les Front-End respectifs sur un même lien physique CPRI en multiplexant dans le même flux CPRI, 30 les données à destination de plusieurs Front-End. Les containers des données sont pas exemple codés de façon consécutive dans les hyper- 3062538 11 trames CPRI et des données de remplissage ou « padding » sont ajoutées en fin d'hyper-trame si elle n'est pas complètement remplie. Pour chaque container AxC, deux mots de contrôle sont ajoutés dans les données «Vendor Specific » définies par le standard CPRI. 5 Ces deux mots sont par exemple découpés comme suit, en partant du bit le plus faible LSB du second mot : - 12 bits donnent la distance en mots de 16 bits entre le début du container AxC et le prochain en-tête BB-Header, - 17 bits indiquent la taille de l'AxC container en mots de 16 bits, 10 - Les bits restant indiquent le numéro logique de l'AxC container. Le descripteur d'un AxC container DVB-S2(x) peut se représenter de la façon suivante : Identificateur émetteur Taille container AxC Position BB-Header Back-End (n bits) (17 bits) dans container AxC (12 bits) L'indication u nombre de bits restants permet d'ajouter et d'enlever à la volée sur un lien CPRI les flux provenant de différents Back15 End. La taille des containers AxC permet de les délimiter dans l'hypertrame. Enfin, la distance au prochain en-tête BB-Header permet, lors du démarrage du lien, une synchronisation sur les frontières des BB-trames. En effet, lorsque la première BB-trame est trouvée, les champs DFL du BB- 20 Header permettent de déterminer la trame suivante et ainsi de suite jusqu'à la fin de l'AxC container. La figure 4 illustre un exemple de démodulateur 50 selon l'invention qui se trouve réparti entre le Back-End 50BE et le Front-End 50FE. Cet exemple de démodulateur permet de traiter une forme d'onde de 25 type DVB-RCS2 définie par le standard ETSI EN 301 545-2 dans sa version 1.2.1. C'est une forme d'onde de type MFTDMA, accès multiple par répartition de temps multi-fréquence (Multiple Frequency Time Division Multiplexing Access). Cela veut dire que chaque émetteur envoie une 3062538 12 quantité de données codées appelée burst et que ces bursts sont multiplexés en fréquence et en temps selon un système de grilles fréquentielles et temporelles appelées trames. Au niveau de la partie Front-End 50FE, le dispositif comporte par exemple 5 les éléments suivants : - Un Tuner 501 qui reçoit le signal RF Rx contenant les données et les informations de synchronisation et le rapporte dans une bande propre pouvant être digitalisée selon des techniques connues de l'homme du métier, 10 - Un module de contrôle automatique de gain AGC, 502, qui permet de régler le niveau du signal afin d'optimiser son niveau et optimiser la quantification numérique qui serait faite par un convertisseur analogique numérique ADC, 503 transformant le signal analogique en signal numérique, 15 - Un module d'ajustement du gain, 504, qui normalise l'amplitude du signal afin que l'amplitude maximale du signal soit codée par la valeur maximale admissible, - Un module de mesure dynamique du rapport signal sur bruit SNR, 505: Le niveau du signal numérisé par le convertisseur numérique- 20 analogique ADC ainsi que le rapport signal sur bruit des bursts décodés sont mesurés et utilisés pour générer une consigne vers le module AGC et le module d'ajustement de gain. Dans le cas d'un démodulateur multi-porteuse, le palier de bruit est estimé et un recul par rapport à la pleine échelle de l'ADC est pris en compte pour à la 25 fois tenir compte de la dynamique maximale de la densité spectrale des signaux utiles par rapport à celle du bruit, de l'erreur sur la correction en puissance des bursts ainsi que du rapport crête à moyenne puissance PAPR envisagé, 3062538 13 - Un module de réduction de manipulation de bits ou « bitwise », 506 qui permet la réduction du nombre de bits transportant l'information. Les bits les plus significatifs sont retenus, - Un module émetteur CPRI, 507, qui va émettre les données vers la 5 partie point de collecte PoP. Du côté du Back-End 50BE au niveau du point de collecte PoP du système, le démodulateur est composé des modules suivants : - Un récepteur CPRI, 508, - Un module MF-TDMA burst extraction, 509, du signal reçu, les bursts 10 sont extraits aussi bien dans la dimension fréquentielle que temporelle, - Un module de synchronisation 510 : chaque burst est alors démodulé. Pour cela, on commence par une synchronisation en temps, puis en fréquence et en phase, 15 - Un module Demapper, 511 : le signal reçu est alors « démappé » pour en extraire les bits encodés et les symboles de synchronisation sont retirés, - Un décodeur 512: les bits sont décodés et désembrouillés afin d'en extraire les données utiles corrigées ou de les rejeter si elles ne 20 peuvent être corrigées. Identificateur de l'émetteur Back-End (n bits) Taille du container AxC (29 bits) La figure 5 décrit un exemple de multiplexage/démultiplexage des flux de plusieurs Back-End à destination de plusieurs Front-End. Dans l'exemple, six BE sont considérés dans la partie PoP et utilisent pour transmettre leur flux respectifs les identifiants de 1 à 6. Un 25 multiplexeur CPRI, 60, conforme à l'état de l'art de cette norme est configuré pour multiplexer les flux des Back-Ends BEI, BE3 et BE4 dans le lien CPRI à destination de la première gateway 61. De même les flux des Back-Ends BE2, BE5 et BE6 sont envoyés à destination de la deuxième gateway 62. 3062538 14 Du côté de la première gateway 61, trois Front-Ends sont configurés respectivement pour traiter en compte les flux identifiés F1, F3 et F4. De même, la deuxième gateway 62 a trois Front-Ends configurés pour traiter les flux identifiés F2, F5 et F6. 5 Grâce à l'identifiant du Back-End émetteur « Back-End transmitter identifier », les flux sont bien multiplexés, transmis vers les gateways respectives, puis extraits. Lorsqu'un Front-End est défaillant, il est alors aisé de mettre en service un autre Front-End traitant le même identifiant de Back-End et de 10 substituer ce deuxième Front-End au premier. Enfin, en cas de besoin de diversité géographique, le multiplexeur CPRI doit être reconfiguré afin que le flux d'un Back-End à re-router change de destination et un Front-End dans la nouvelle gateway de destination doit être configuré avec le bon identifiant pour prendre en compte ce nouveau 15 flux. Le système selon l'invention permet de réduire les coûts d'infrastructure et de maintenance des sites gateways. La diversité de site ne nécessite plus de changer de routage des signaux entre le Hub et la partie radiofréquence RF. 20 REVENDICATIONS1 - Système de transmission de données dans un réseau de communication comprenant un lien de transmission satellite, une partie fournisseur de services (20), une partie utilisateur et un réseau d'accès satellite comprenant un point de collecte PoP (21) adapté à dispatcher les flux de données, plusieurs gateways (26i) comprenant la partie radiofréquence (27j) caractérisé en ce qu'il comporte un modulateur (30) de données à transmettre comprenant au moins deux parties : - Une première partie (30BE) positionnée au niveau de la partie point de collecte PoP (21) et comportant les modules suivants : - un module NCR (303) adapté à prendre en compte une référence de temps absolue externe pour reconstituer une horloge de réseau pour une synchronisation dans la transmission des données, - un module émetteur (304) recevant la valeur d'une référence temporelle à insérer dans le paquet de données à transmettre et émettant en direction du module NCR une information sur un instant de synchronisation pour le récepteur, - Une deuxième partie (30FE) positionnée au niveau de la partie radiofréquence d'une gateway et comportant les modules suivants : - un module récepteur (310), - un module de reconstruction (311) d'une horloge en local, à partir des informations de synchronisation contenues dans les données transmises, - un module d'insertion (312) d'une référence temporelle dans un paquet de données reçues par le récepteur avant transmission des données via le satellite, 3062538 16 - La première partie (30BE) et la deuxième partie (30FE) échangent des données encapsulées selon le protocole utilisé pour la transmission de données dans le système. 5 2 - Système selon la revendication 1 caractérisé en ce qu'il comporte un démodulateur (50) constitué de deux parties : - Une première partie (50FE) située au niveau de la partie gateway du système comportant les modules suivants : - Un module (506) de réduction du nombre de bits transportant 10 l'information, avant transmission via un module émetteur (507), - Une deuxième partie (50BE) située au niveau d'un point de collecte PoP et comportant au moins le module suivant : - Un module récepteur (508). 15 3 - Système selon l'une des revendications 1 ou 2 caractérisé en ce que le module récepteur (310) de la partie située au niveau radiofréquence d'une gateway est adapté à générer les informations suivantes : une information sur la latence du lien de transmission des données, une information sur le déclenchement de l'émission des données H.F.Rx trigger (402), une 20 information H.F.Rx NCR (403) correspondant à la valeur d'une date correspondant au début d'une hyper-trame à prendre en compte sur réception de l'information « H.F Rx trigger » afin de reconstituer localement au niveau de la partie radiofréquence une horloge corrigée de la latence de transmission entre la première partie et la deuxième partie du modulateur. 25 4 - Système selon l'une des revendications 1 à 3 caractérisé en ce que le module de reconstitution d'horloge (303) est adapté à reconstituer une synchronisation réseau et à fournir une date courante à insérer dans un champ de données d'une hyper-trame en construction. 3062538 17 5 - Système selon l'une des revendications 1 à 4 caractérisé en ce que la partie « Front-End » comporte en plus les éléments suivants : - un module d'adaptation du flux de données, (313), - un module de codage (314), 5 - un module de mapping (315) adapté à transformer les données sous forme de bits codés en symboles, un module (316) adapté à insérer un en-tête et des pilotes, un module de modulation des données numériques (317), un module Tuner (318), et 10 - un module (319) M&C Handler assurant la configuration et la surveillance des différents éléments du modulateur. 6 - Système selon l'une des revendications 1 à 5 caractérisé en ce que le modulateur est un modulateur de type DVB-S2. 15 7 - Système selon l'une des revendications 1 à 5 caractérisé en ce que le démodulateur est un démodulateur de type DVB-RCS2. 8 - Système selon l'une des revendications 1 à 7 caractérisé en ce que le 20 protocole utilisé est le protocole CPRI. 9 - Procédé de transmission de signaux dans un réseau de communication comprenant un lien de transmission satellite comportant une partie fournisseur de services, une partie utilisateur et un réseau d'accès satellite 25 comprenant un point de collecte PoP adapté à dispatcher les flux de données, plusieurs gateways comprenant la partie RF caractérisé en ce qu'il comporte au moins les étapes suivantes : - Une partie située au niveau d'un point de collecte du système construit une trame bande de base comprenant un champ de données 30 incluant des informations de synchronisation et/ou un identifiant d'un 3062538 18 utilisateur et un champ contenant des données provenant d'un fournisseur de services et destinées à l'utilisateur, afin de générer des données encapsulées avant transmission vers une deuxième partie du système adapté à moduler lesdites données, 5 - La deuxième partie reconstruit une horloge locale à partir des informations de synchronisation contenues dans les données encapsulées, avant modulation des données, - Les données modulées sont ensuite transmises par satellite. 10 10 - Procédé selon la revendication 9 caractérisé en ce qu'il comporte une étape de reconstruction d'une valeur d'horloge en tenant compte de la valeur de la latence du lien de transmission, de l'instant de déclenchement d'émission des données, de la valeur d'une date correspondant au début d'une hyper-trame reçue. 15 11 - Procédé selon l'une des revendications 9 à 10 caractérisé en ce que l'on utilise le format CPRI pour la transmission des données encapsulées. 12 - Procédé selon l'une des revendications 9 à 11 caractérisé en ce que 20 l'on utilise le format de trames DVB-S2.