Brevet FR2926423A1 — publié le 20090717

Procédé de synchronisation d'un noeud esclave dans un cycle de transmission de données d'un réseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et noeud esclave. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication synchrone sans-fil par exemple du type maillé (ou MESH en anglais), comprenant une pluralité de noeuds disposant, par exemple, chacun d'une antenne en réception et d'une antenne en émission. Plus précisément, l'invention concerne une technique permettant de synchroniser un noeud donné sur un autre noeud avec une précision fine. 2. ART ANTÉRIEUR Les systèmes de transmission radio à 60 GHz (bande d'ondes RF millimétriques) sont particulièrement bien adaptés pour la transmission de données à très haut débit sur courtes distances. Par exemple, un tel système de transmission est bien adapté à la connectivité entre les différents éléments d'un � home cinema � (ou � cinéma à domicile en français). En effet, pour ce cas d'utilisation, la portée de la transmission est limitée à une dizaine de mètres, mais les débits mis en jeux sont très élevés, parfois au-delà du gigabit par seconde, de par la nature (aussi bien audio que vidéo) et la haute résolution de l'information transmise. On se place dans la suite dans le cadre d'un réseau de communication synchrone sans-fil par exemple du type maillé comprenant une pluralité de noeuds. Les noeuds opèrent dans la bande d'onde millimétrique (c'est-à-dire autour de 60GHz). Pour permettre à chaque noeud du réseau de transmettre de l'information dans des intervalles de temps régulièrement espacés, on peut utiliser un medium (aussi appelé support de transmission) à accès multiplexé suivant un mode de multiplexage du type TDMA (pour � Time Division Multiple Access � en anglais, et � accès multiple à répartition dans le temps � en français). Selon le multiplexage TDMA, le domaine temporel est divisé en une pluralité de cycles de transmission de données synchrone (ou cycle � SDTC � pour � Synchronous Data Transmission Cycle � en anglais). Chaque cycle SDTC est divisé en une pluralité d'intervalles de temps. Dans un réseau sans-fil utilisant un multiplexage TDMA, chaque noeud émet et reçoit dans des intervalles de temps déterminés (aussi appelés par la suite durées de temps de parole) et doit orienter son antenne en réception à chacun de ces intervalles de temps (ou � Time slot � en anglais). Du fait du caractère aléatoire du support de transmission, il est nécessaire d'effectuer de multiples transmissions des données afin d'en garantir la bonne réception au-delà d'un taux d'erreur résiduel prédéfini. En effet, ce type de support de transmission est notamment sensible aux masquages causés, par exemple, par un individu traversant le champ de transmission. Un tel réseau de communication requiert donc un synchronisme parfait entre le ou les émetteurs et les récepteurs, notamment dans le cas d'un système de diffusion de contenus audio à canaux multiples (� surround sound system � en anglais). A titre d'exemple, un système de diffusion du type � surround sound system � peut comprendre huit hauts parleurs. Généralement dans un système de diffusion du type � surround sound system �, l'émetteur (comprenant aussi un décodeur audio) transmet de manière parfaitement synchrone différents canaux audio (issus d'une seule source) à un ensemble de récepteurs, comprenant chacun un haut parleur. Cet ensemble de récepteurs doit restituer globalement le son de manière parfaitement synchronisée afin d'apporter au son un effet de spatialisation. Le synchronisme au niveau de la couche applicative peut être obtenu grâce au synchronisme des noeuds au niveau de la couche physique. En raison du mode d'accès au medium (de type TDMA), il est impératif de synchroniser les noeuds du réseau afin qu'ils puissent accéder au medium sans perturber le système. En particulier, il faut éviter les collisions entre des paquets de données (aussi appelés trames de données) émis par des noeuds distincts. Pour assurer la synchronisation du système, un des noeuds du réseau, appelé noeud maître, est chargé de cadencer les cycles SDTC, en émettant des paquets de données à intervalle de temps régulier. Les autres noeuds du réseau, appelés noeuds esclaves, sont capables de reproduire le cadencement du noeud maître à partir de la réception des paquets de données émis par le noeud maître. En cas de masquage, un noeud esclave peut ne pas recevoir les paquets de données du noeud maître. Dans un tel cas, le noeud esclave masqué doit récupérer le cadencement du noeud maître par l'intermédiaire d'un autre noeud esclave synchronisé sur le noeud maître, appelé noeud de référence. Le phénomène de masquage varie en fonction du temps, ainsi un noeud esclave ne se référencera pas continûment avec le même noeud de référence. On note que cette caractéristique du réseau interdit l'utilisation de la technique consistant à détecter la fin de réception d'un paquet, puis d'attendre qu'un intervalle de temps entre deux paquets se soit écoulé pour commencer à transmettre. On choisit pour noeud de référence le noeud du réseau qui offre la meilleure précision de synchronisation. Le basculement d'un noeud de référence vers un autre noeud de référence peut être déclenché de façon très fréquente (de l'ordre de la milliseconde) et dépend de la durée maximale que l'on s'autorise entre deux opérations de synchronisation. Cette première étape de synchronisation, bien que nécessaire, n'est pas suffisante dès lors que l'on cherche à atteindre un niveau de précision fin (de l'ordre de la microseconde). La difficulté réside dans le fait que chaque noeud du réseau est cadencé par sa propre horloge locale issue d'un oscillateur possédant des caractéristiques qui lui sont propres. En effet, un oscillateur délivre un signal à une fréquence nominale qui peut fluctuer, au cours du temps et en fonction de l'environnement, entre une valeur minimale et une valeur maximale. Il est donc nécessaire que chaque noeud du réseau connaisse en permanence la dérive de sa propre horloge locale par rapport à celle du noeud maître. Dans le cas où les conditions du réseau le permettraient, il est possible d'obtenir la valeur d'une dérive à un instant donné, par exemple, en mesurant le nombre de coups d'horloge locale entre deux réceptions successives de paquets de données émis par un noeud donné. Dans ce cas, la dérive est l'écart entre le nombre théorique de coups d'horloge locale calculé entre les deux réceptions successives de paquets de données et le nombre de coups d'horloge locale mesuré. Généralement, cette dérive comprend une erreur induite par les variations aléatoires des différents oscillateurs. En conséquence, un noeud esclave introduit une erreur dans la restitution du cadencement du noeud maître, et donc dans la détermination de son début de temps de parole à l'intérieur d'un cycle SDTC. Cette erreur est fluctuante au cours du temps et crée une gigue (� jitter � en anglais) qui s'ajoute à la gigue initiale du cadencement du noeud maître. Cette gigue est d'autant plus grande qu'il y a de noeuds intermédiaires entre le noeud maître et le noeud esclave (masqué), ce qui affecte d'autant plus la précision globale du système. Suivant l'importance de la gigue, il sera nécessaire de prévoir un intervalle de garde suffisamment large entre les paquets de données successifs pour permettre, par exemple dans le cas d'un réseau de communication sans fil, la configuration d'un module de radiocommunication, et notamment l'orientation d'une antenne directive dans la direction d'un émetteur. Par ailleurs, une marge de temps supplémentaire doit être prise en compte pour couvrir l'incertitude portant sur le début effectif de transmission et ainsi écarter tout risque de collision entre paquets. L'utilisation de tels intervalles de gardes et marges de temps supplémentaires entraîne une perte de bande passante. Il existe donc un réel besoin de synchroniser ce type de système tout en limitant la perte de bande passante. On connaît plusieurs techniques permettant d'assurer une synchronisation d'un noeud esclave sur un noeud maître avec une précision fine et garantie. Une première technique connue consiste à conserver dans un historique les multiples échanges de données de synchronisation entre le noeud maître et le noeud esclave. Plus précisément, ces données de synchronisation sont utilisées par un algorithme qui met en oeuvre un calcul complexe permettant de récupérer avec précision l'horloge du noeud maître. Cette première technique est notamment présentée dans le document de brevet US 6,157,957. Cette première technique présente deux inconvénients majeurs. Tout d'abord, l'échange de données de synchronisation réduit la bande passante utile disponible, ce qui est préjudiciable dans un réseau de communication sans fil destiné à supporter des applications très haut débit. Un autre inconvénient de cette première technique connue réside dans le fait qu'elle nécessite des moyens et des temps de calcul importants. Ceci n'est donc pas compatible avec un système où le noeud de référence peut changer très souvent suivant les conditions du canal de transmission. Dans le document de brevet US 7,072,432, il est proposé une amélioration de la technique précitée. Cependant, cette deuxième technique connue ne permet pas non plus de sélectionner rapidement un nouveau noeud de référence. En effet, un échange de messages est nécessaire avant d'obtenir des mesures précises du décalage (� offset � en anglais) et de la dérive (� drift � en anglais) entre l'horloge du noeud esclave et l'horloge du noeud de référence. Une troisième technique, notamment présentée dans le document de brevet US 7,103,124, prévoit d'augmenter la précision de la synchronisation en autorisant des noeuds esclaves, qui se synchronisent sur un même noeud de référence, à s'échanger des résultats d'estimation. Outre les inconvénients des techniques précitées, cette troisième technique présente l'inconvénient majeur de ne pas améliorer la précision de la synchronisation lorsqu'un noeud esclave ne peut pas échanger d'informations avec un autre noeud esclave, par exemple à cause d'un masquage. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de synchronisation de noeuds dans un réseau de communication synchrone, permettant d'améliorer la synchronisation des noeuds esclaves sur le noeud maître du réseau. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette de minimiser les erreurs de précision induites par les variations aléatoires des oscillateurs locaux des noeuds du réseau. Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui soit notamment bien adaptée aux réseaux mettant en oeuvre un medium à accès multiplexé suivant un mode de multiplexage du type TDMA. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui permette d'améliorer la détermination du début de temps de parole de chaque noeud esclave à l'intérieur d'un cycle SDTC. Ainsi, l'invention vise à minimiser l'intervalle de garde entre deux paquets de données successifs tout en écartant tout risque de collision. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de mettre en oeuvre une telle technique qui soit telle que le traitement des données au 30 sein des noeuds soit raccourci de manière modérée, suite à une correction de dérive. En effet, la génération d'un signal de début d'émission de paquet par un noeud implique que tous les traitements à appliquer aux données à transmettre ont bien été accomplis par ce noeud. Si le signal de début de transmission doit être généré plus tôt qu'initialement prévu pour corriger une dérive, il est nécessaire que la réduction du temps disponible pour le traitement préalable des données avant transmission n'entraîne pas l'inachèvement de ce traitement. Par ailleurs, l'invention a un objectif analogue dans le cas où la couche applicative utilise la synchronisation de la couche physique, c'est à dire que la présentation des données en sortie du noeud est synchronisée par le signal de début de cycle de transmission. Si le signal de début de transmission doit être généré plus tôt qu'initialement prévu pour corriger une dérive, cela entraînant que la présentation des données en sortie du noeud s'effectue aussi plus tôt, il est nécessaire que la réduction du temps disponible pour le traitement préalable des données avant délivrance à l'application consommatrice n'entraîne pas l'inachèvement de ce traitement. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de fournir une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de synchronisation d'un noeud esclave dans un cycle de transmission de données d'un réseau de communication synchrone comprenant au moins un noeud esclave et un noeud maître mettant en oeuvre un cadencement qui définit ledit cycle de transmission, chaque noeud esclave gérant une représentation locale dudit cadencement, ledit cycle de transmission de données comprenant un nombre prédéterminé d'intervalles de temps. Selon l'invention, le noeud esclave à synchroniser effectue les étapes suivantes, pour un cycle de transmission courant dans lequel ledit noeud esclave à synchroniser reçoit un paquet émis par un autre noeud dudit réseau, dit noeud de référence : - obtention d'un instant effectif de réception dudit paquet et d'un instant estimé de réception dudit paquet ; - à partir desdits instants estimé et effectif, détermination d'une dérive moyenne entre le cadencement défini par le noeud maître et la représentation locale dudit cadencement ; - répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission. Le principe général de l'invention repose donc sur la mesure et l'estimation d'instants de réception de paquet pour le calcul d'une valeur de dérive moyenne. Ainsi, l'invention permet de compenser les erreurs de précision induites par les variations aléatoires des oscillateurs locaux des noeuds du réseau et d'améliorer la détermination du début de chaque intervalle de temps du cycle de transmission. L'invention propose de répartir le poids de la dérive de façon uniforme sur chaque intervalle de temps. Le fait d'utiliser une valeur moyenne permet de minimiser les effets de gigue introduits par les différents noeuds. On note par ailleurs que lorsque le noeud esclave décide de se synchroniser sur le noeud de référence, il ne prendra pas comme référence la valeur instantanée de dérive, mais une valeur moyenne. Dans le cas d'un intervalle de temps en réception, l'instant estimé de réception du paquet est l'instant estimé du début de transmission du paquet pour le noeud de référence. Dans le cas d'un intervalle de temps en émission, l'instant estimé de réception du paquet est l'instant estimé du début de temps de transmission le plus précis possible pour le noeud esclave. On note également que le noeud de référence peut être sélectionné selon un mécanisme de sélection permettant de sélectionner le premier noeud visible d'une liste prédéterminée de noeuds. Selon un premier mode de réalisation particulier de l'invention, ledit cycle de transmission de données comprend un nombre prédéterminé de premiers intervalles de temps, dits temps de parole, chacun desdits noeuds pouvant transmettre des données sur ledit réseau pendant au moins un temps de parole qui lui est associé. Dans l'étape de répartition, la dérive moyenne est répartie sur chacun des temps de paroles, pour obtenir une nouvelle représentation locale dudit cadencement. Le procédé comprend une étape de détermination d'un instant de début de temps de parole pour ledit noeud esclave à synchroniser, dans ladite nouvelle représentation locale dudit cadencement. Ainsi, il est possible de calculer un début de temps de parole précis pour chaque noeud esclave à l'intérieur d'un cycle SDTC. On obtient donc un meilleur accès au medium et une réduction des risques de collision entre noeuds. Selon un second mode de réalisation particulier, ledit cycle de transmission de données comprend un nombre prédéterminé de seconds intervalles de temps correspondant chacun à un cycle de traitement de données synchrones par lesdits noeuds. Dans l'étape de répartition, la dérive moyenne est répartie sur chacun des cycles de traitement, pour obtenir une nouvelle représentation locale dudit cadencement. Le procédé comprend une étape de détermination d'un instant de début de traitement pour ledit noeud esclave à synchroniser, dans ladite nouvelle représentation locale dudit cadencement. Ainsi, l'invention permet d'uniformiser la durée des cycles de traitement (cycles SDPC) et d'éviter un allongement ou un raccourcissement conséquent du dernier cycle de traitement qui précède un début de cycle complet de transmission de données synchrone (cycle SDTC). L'invention permet donc que le traitement des données au sein des noeuds soit achevé avant que le noeud ne doive délivrer les données à la couche applicative. Avantageusement, l'étape de détermination d'une dérive moyenne comprend les étapes suivantes : - calcul d'une dérive courante à partir des instants estimé et effectif ; - calcul de ladite dérive moyenne à partir de ladite dérive courante et d'au moins une dérive précédente déterminée pour un cycle de transmission précédent ; Les dérives sont par exemple calculées et enregistrées dans un ensemble de registres. De façon avantageuse, l'étape de répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission est précédée d'une étape préalable de sélection d'un noeud dit noeud de référence comprenant elle-même les étapes suivantes : - lecture, dans chaque paquet d'un ensemble de paquets reçus, d'une information de synchronisation relative à un niveau de synchronisation par rapport au noeud maître du noeud en provenance duquel ledit paquet a été reçu ; -sélection dudit noeud de référence parmi les noeuds en provenance desquels un paquet dudit ensemble de paquets reçus a été reçu, ladite sélection étant effectuée en fonction desdites informations de synchronisation. Ainsi, quand le procédé est mis en oeuvre : - dans le cas où il n'y a pas de masquage, on effectue une synchronisation directe sur le noeud maître, en d'autres termes, le noeud de référence sélectionné est le noeud maître ; - dans le cas où il y a un masquage, on sélectionne un noeud distinct du noeud maître, ce qui revient à effectuer une synchronisation indirecte sur le noeud maître. En effet, on utilise des informations de synchronisation pour sélectionner un noeud de référence, qui est synchronisé (directement ou indirectement) sur le noeud maître, parmi une pluralité de noeuds visibles dans le réseau. Cette technique permet de conserver le caractère synchrone du réseau et d'améliorer la fiabilité de la transmission (en cas d'interférences et/ou de masquage). De façon avantageuse, les étapes d'obtention d'un instant effectif de réception et 20 d'un instant estimé de réception sont effectuées pour un ensemble de noeuds de référence du réseau de communication synchrone. Suite à ladite étape de sélection, l'étape de répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission est effectuée à partir des instants effectif et estimé précédemment obtenus pour ledit noeud de référence sélectionné. 25 Ainsi, lorsqu'on bascule rapidement sur un nouveau noeud de référence (c'est-à-dire en cas de changement de noeud de référence) on a déjà une dérive moyenne que l'on peut utiliser. Avantageusement, ladite étape d'obtention d'un instant effectif de réception dudit paquet comprend une étape de détection d'un préambule compris dans ledit paquet. 30 Ainsi, on peut dater le début d'un intervalle de temps de manière simple et efficace. 10 15 Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre du procédé de synchronisation précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de synchronisation précité. Dans un autre mode de réalisation, l'invention concerne un noeud esclave destiné à être synchronisé dans un cycle de transmission de données (SDTC) d'un réseau de communication synchrone comprenant au moins ledit noeud esclave et un noeud maître mettant en oeuvre un cadencement qui définit ledit cycle de transmission, ledit noeud esclave gérant une représentation locale dudit cadencement, ledit cycle de transmission de données comprenant un nombre prédéterminé d'intervalles de temps. Selon l'invention, le noeud esclave comprend : - des moyens de réception d'un paquet émis par un autre noeud dudit réseau, dit noeud de référence : - des moyens d'obtention d'un instant effectif de réception dudit paquet et d'un instant estimé de réception dudit paquet ; - des moyens de détermination, à partir desdits instants estimé et effectif, d'une dérive moyenne entre le cadencement défini par le noeud maître et la représentation locale dudit cadencement ; - des moyens de répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission. Les avantages des produit programme d'ordinateur, moyen de stockage et noeud esclave sont sensiblement les mêmes que ceux du procédé de synchronisation et ne sont donc pas repris ci-après. Dans un premier mode de réalisation avantageux, ledit cycle de transmission de données comprend un nombre prédéterminé de premiers intervalles de temps, dits temps 25 30 de parole. Les moyens de répartition répartissent ladite dérive moyenne sur chacun des temps de paroles, pour obtenir une nouvelle représentation locale dudit cadencement. Le noeud esclave comprend des moyens de détermination d'un instant de début de temps de parole dans ladite nouvelle représentation locale dudit cadencement. Dans un deuxième mode de réalisation avantageux, ledit cycle de transmission de données comprend un nombre prédéterminé de seconds intervalles de temps correspondant chacun à un cycle de traitement de données synchrones. Les moyens de répartition répartissent ladite dérive moyenne sur chacun des cycles de traitement, pour obtenir une nouvelle représentation locale dudit cadencement. Le noeud esclave comprend des moyens de détermination d'un instant de début de traitement dans ladite nouvelle représentation locale dudit cadencement. Selon un mode de réalisation préférentiel de l'invention, lesdits moyens de détermination d'une dérive moyenne comprennent : - des moyens de calcul d'une dérive courante (D) à partir des instants estimé et effectif ; - des moyens de calcul de ladite dérive moyenne (Dmean) à partir de ladite dérive courante et d'au moins une dérive précédente déterminée pour un cycle de transmission précédent. Avantageusement, ledit noeud esclave comprend des moyens de sélection d'un noeud de référence comprenant : - des moyens de lecture, dans chaque paquet d'un ensemble de paquets reçus, d'une information de synchronisation relative à un niveau de synchronisation par rapport au noeud maître du noeud en provenance duquel ledit paquet a été reçu ; - des moyens de sélection dudit noeud de référence parmi les noeuds en provenance desquels un paquet dudit ensemble de paquets reçus a été reçu. Préférentiellement, lesdits moyens d'obtention d'un instant effectif de réception dudit paquet comprennent des moyens de détection d'un préambule compris dans ledit paquet. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 présente un exemple de système de communication radio à 60 GHz selon un mode de réalisation préférentiel de l'invention ; - la figure 2 présente un schéma d'un cycle complet de transmission de données synchrone, selon un mode de réalisation particulier de l'invention ; - la figure 3 présente un exemple d'architecture du module de communication synchrone apparaissant sur la figure 1, selon un mode de réalisation particulier de l'invention ; - la figure 4 présente un exemple d'architecture du premier bloc de synchronisation apparaissant sur la figure 3, selon un mode de réalisation particulier de l'invention ; - la figure 5 présente un exemple de contenu des registres de surveillance apparaissant sur la figure 4, selon un mode de réalisation particulier de l'invention ; - la figure 6a présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'émission, compris dans un noeud esclave et apparaissant sur la figure 3, selon un mode de réalisation particulier de l'invention ; - la figure 6b présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc de réception, compris dans un noeud esclave et apparaissant sur la figure 3, selon un mode de réalisation particulier de l'invention ; - les figures 7a et 7b présentent les étapes principales d'un algorithme de traitement mis en oeuvre par le contrôleur de synchronisation, compris dans un noeud esclave et apparaissant sur la figure 4, selon un mode de réalisation particulier de l'invention ; - la figure 8 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc de calcul SDTC, compris dans un noeud esclave et apparaissant sur la figure 4, selon un mode de réalisation particulier de l'invention ; 25 30 - la figure 9 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc de calcul de début transmission, compris dans un noeud esclave et apparaissant sur la figure 4, selon un mode de réalisation particulier de l'invention ; - la figure 10 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le contrôleur SDPC, compris dans un noeud esclave et apparaissant sur la figure 4, selon un mode de réalisation particulier de l'invention ; - la figure Il a présente un exemple d'architecture d'un compteur de cycles SDTC, selon un mode de réalisation particulier de l'invention ; - la figure 1 lb présente un exemple d'architecture du compteur temps avant transmission, selon un mode de réalisation particulier de l'invention ; et - la figure llc présente un exemple d'architecture du compteur de cycles SDPC, selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 6.1 Exemple de système de communication radio à 60 GHz (système audio 8 voies) On décrit, en relation avec la figure 1, un exemple de système de 20 communication radio à 60 GHz selon un mode de réalisation préférentiel de l'invention. Dans ce mode de réalisation, le système de communication 2000 selon l'invention comprend neuf noeuds de communication. Plus précisément, le système de communication 2000 comprend huit noeuds la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type � WAR � (pour � Wireless Audio Renderer � en anglais ou � récepteur audio sans fil � 25 en français) comprenant chacun des moyens de restitution de canal audio numérique (ou � Digital Audio Channel Amplifier � en anglais) lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b. Ces moyens de restitution comprennent, par exemple, un haut-parleur (ou � speaker � en anglais). Le système de communication 2000 comprend en outre un noeud 5a de type 30 � WAD � (pour � Wireless Audio Decoder � en anglais ou � décodeur audio sans fil � en français) comprenant lui-même un décodeur audio multi voies (ou � Surround sound 10 15 decoder � en anglais) 5b. Ce décodeur audio multi voies 5b est intégré, par exemple, dans un écran plat et est susceptible de transmettre de manière synchronisée, via le système de communication 2000, les différents canaux audio associés à la vidéo affichée sur l'écran. Chacun des noeuds la, 2a, 3a, 4a, 5a, 6a, 7a, 8a, et 9a comprend un module de communication synchrone, noté � SCM � (pour � Synchronous Communication Module � en anglais). 6.2 Principe général du système L'ensemble de la bande passante disponible délivrée par le système est découpé en canaux virtuels synchrones. Le débit utile est caractérisé par la fréquence de traitement des canaux virtuels (par exemple 8KHz) ainsi que par la taille des échantillons (par exemple 48 bits). Dans le présent exemple, un canal virtuel (� VC � pour � Virtual Channel � en anglais) a un débit constant de 384 Kbps (kilobits par seconde). La séquence complète, qui comprend un échantillon de chacun des canaux virtuels disponibles, constitue un cycle complet de traitement de données synchrone (appelé cycle SDPC). Dans le présent exemple, où la fréquence de traitement des canaux virtuels est de 8KHz, la durée d'un cycle SDPC est de 125�s. Un canal audio de résolution 96KHz-24bits utilisera donc 6 canaux virtuels soit, par exemple pour un système audio 8 voies (classiquement appelé 7.1), un total de 48 canaux virtuels. Le débit utile nécessaire pour le transfert de l'information audio est donc de 18,432 Mbps (mégabit par seconde). Si l'on ajoute 10 canaux virtuels supplémentaires (alloués à l'ensemble des noeuds de transmission du système) pour le transfert d'informations supplémentaires (contrôle du système, protocole, commande utilisateur,...), alors le cycle SDPC comprend 58 canaux virtuels, soit un débit utile de 22,272 Mbps. Une séquence de traitement d'un conteneur de canal virtuel (� VC Chunk � pour � Virtual Channel Chunk � en anglais) comprend un ensemble d'échantillons d'un même canal virtuel (� Virtual Channel Samples � en anglais). Cette séquence de traitement doit être effectuée pendant un cycle complet de transmission de données synchrone (appelé cycle SDTC). La séquence de transmission de ce conteneur de canal virtuel (� VC Chunk �) doit être effectuée pendant la durée du cycle SDTC suivant. En conséquence, la durée d'un cycle SDTC est un multiple de la durée d'un cycle SDPC. Le rapport du cycle de transmission synchrone (cycle SDTC) sur le cycle de traitement synchrone (cycle SDPC) est appelé � STPR � (pour � Synchronous Transmission to Processing Ratio � en anglais). Ce rapport (nombre entier) définit ainsi la taille de la séquence de transmission d'un conteneur de canal virtuel, de manière commune quels que soient les canaux virtuels. Dans un mode de réalisation particulier, le rapport � STPR � est égal à 16. Dans ce cas, la séquence de transmission d'un conteneur de canal virtuel est constituée de 96 octets (c'est-à-dire la taille des échantillons (48 bits) que multiplie le rapport � STPR � (16)). Pendant un cycle SDTC, chaque noeud de transmission envoie au moins un paquet de données (aussi appelé trame de données). Dans un mode de réalisation particulier, dix paquets de données (de taille égale) sont émis selon la séquence suivante : - les deux premiers paquets de données du cycle SDTC sont émis par le module de communication synchrone (SCM#0) du noeud 5a de type � WAD � ; - les huit paquets de données suivants sont émis par les huit noeuds la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type � WAR � (un paquet de données par noeud � WAR �), par exemple, selon l'ordre suivant : SCM#1, SCM#2, SCM#3, SCM#4, SCM#5, SCM#6, SCM#7 et SCM#8. 6.3 Structure des paquets de données découpés en blocs de données radio On présente maintenant, en relation avec la figure 2, un schéma d'un cycle complet de transmission de données synchrone (cycle SDTC). Dans le présent mode de réalisation, dix paquets de données 10 à 19 (pas tous représentés sur la figure 2) (générés par les modules de communication synchrone (SCM) embarqués dans les noeuds du système) sont transmis pendant un cycle SDTC d'une durée de 2ms. La durée de temps de parole (ou temps de transmission de paquet de données) est légèrement inférieure à 200pts (par exemple, elle est de 198�s), ce qui permet de transmettre 3384 octets de données utiles (soit un débit moyen de 136,479Mbps) pendant cette durée. Cette durée tient compte de l'intervalle de garde (aussi appelé temps � inter paquet �) qui est prévu pour la configuration du module de radiocommunication et la réduction de l'incertitude portant sur le début du prochain intervalle de temps. En supposant des horloges locales précises à �100ppm, mais avec une valeur nominale stable, l'écart (c'est-à-dire la dérive) possible sur 2ms est de �200ns, ce qui correspond à une différence de 400ns entre l'horloge du noeud maître et celle du noeud esclave. Ainsi, pour dix intervalles de temps il faut prévoir un intervalle de garde de l'ordre de 4pts. Bien entendu, l'invention n'est pas limitée à l'exemple de réalisation mentionné ci-dessus. Dans d'autres exemples de réalisation, les valeurs des fréquences de traitement, des durées de temps de parole, des intervalles de garde,... peuvent être différentes de celles données dans le cas du mode de réalisation particulier exposé ci- dessus. Comme illustré sur la figure 2, chaque paquet de données 11 comprend : - un préambule 54 ; - un champ en-tête 49, noté � RPH � (pour � Radio Packet Header � en anglais) ; et - un champ de données utiles 50, noté � RPP � (pour� Radio Packet Payload � en anglais). Le champ de données utiles 50 comprend un ensemble de blocs de données radio (� RDB � pour � Radio Data Block � en anglais). Plus précisément, le champ en-tête 49 comprend : - un champ � hop_id � 51. Le champ � hop_id � indique le numéro de l'intervalle de temps affecté au paquet de données ; - un champ � synchro_cpt � 52. Le champ � synchro_cpt � indique le niveau de synchronisation du noeud qui émet le paquet de données ; et - un champ 53 réservé aux autres informations de protocoles nécessaires au fonctionnement du système. On s'intéresse désormais au traitement des données. Dans le cas où le rapport � STPR � est égal à 16, chaque module de communication synchrone (SCM) doit traiter 16 cycles SDPC 1058 à 2558 (pas tous représentés sur la figure 2) pendant un même cycle SDTC. Dans le présent exemple, la durée de chaque cycle SDPC est de 125�s. Pendant chaque cycle SDPC, le module de communication synchrone (SCM) effectue le traitement des 58 échantillons des canaux virtuels. Comme illustré sur la figure 2, les échantillons 1000, 1030, 1031 et 1057 sont traités pendant le cycle SDPC 1058, l'échantillon 1100 pendant le cycle SDPC 1158, et les échantillons 2500, 2530 et 2557 pendant le cycle SDPC 2558. 6.4 Architecture d'un module de communication synchrone On présente, en relation avec la figure 3, un exemple d'architecture du module de communication synchrone (SCM) selon un mode de réalisation particulier de l'invention. Comme illustré, le module de communication synchrone 3000 comprend une unité centrale de traitement 87 (qui est par exemple un microprocesseur référencé CPU) coopérant avec un bloc de mémoire d'exécution 86 (RAM) et un bloc de mémoire non volatile 85 (ROM). L'unité centrale 87 communique avec un module radio 84 via une interface 93 (CPU IF). L'interface 93 gère notamment les interruptions à destination du microprocesseur (CPU), ainsi que les échanges de données entre les différents blocs du module radio 84 et l'unité centrale 87. On note également qu'à l'initialisation du système, l'interface 93 comprend la séquence d'émission des paquets de données, l'affectation des intervalles de temps aux différents noeuds du réseau, la durée des paquets de données et la durée du temps inter paquet. Ainsi, à l'initialisation du système, l'unité centrale 87 effectue le transfert des informations de configuration depuis la mémoire non volatile 85 vers l'interface 93. Dans une variante de réalisation, il est possible d'envisager de sélectionner une configuration parmi une pluralité de configurations système (par exemple, stockée préalablement dans la mémoire non volatile 85), en fonction d'informations (par exemple, sur l'application et l'environnement du système) provenant d'un utilisateur. Le module radio 84 coopère avec un bloc d'interface radio 60GHz 99 et un bloc d'interface audio synchrone 98. Le bloc d'interface audio synchrone 98 communique avec un module de traitement de canaux audio 82. Le module radio 84 permet donc de transférer des données synchrones depuis le bloc d'interface radio 60GHz 99 vers le module de traitement de canaux audio 82, et inversement. Dans un premier mode de réalisation, le module de traitement de canaux audio 82 est un moyen de restitution de canal audio numérique (� Digital Audio Channel Amplifier � en anglais). Dans un deuxième mode de réalisation, le module de traitement de canaux audio 82 est un décodeur audio multi voies (� Surround sound decoder � en anglais). Dans le module radio 84 on trouve, côté traitement des données synchrones, des blocs d'écriture 89 et de lecture 88 de conteneurs de canal virtuel (� VC Chunk �). Le bloc d'écriture 89 est chargé de construire les blocs de données radio (RDB) associés à un canal virtuel, au fur et à mesure de l'écriture de chacun des échantillons du canal virtuel (� VC sample � en anglais) pendant le cycle SDPC auquel l'échantillon est associé. A l'inverse, le bloc de lecture 88 est chargé de l'écriture de chaque échantillon extrait des blocs de données radio (RDB) reçus pendant le cycle SDPC. Dans le cas où le rapport � STPR � est égal à 16, le module radio 84 doit effectuer, pendant un cycle SDTC, la lecture et l'écriture des échantillons associés aux canaux virtuels qu'il doit traiter pendant les 16 cycles SDPC. Dans le module radio 84 on trouve, côté transmission des données synchrones, des blocs d'émission 95 et de réception 94 de paquets de données. Le bloc d'émission 95 intègre notamment les fonctions de modulation (par exemple, une modulation du type OFDM) et d'insertion de préambule, celui-ci permettant d'indiquer le début d'émission d'un paquet de données. Le bloc de réception 94 réalise les fonctions inverses de celles mises en oeuvre dans le bloc d'émission 95, à savoir notamment les fonctions de démodulation et de détection de préambule. Dans le mode de réalisation illustré, le module radio 84 comprend en outre : - un bloc d'encodage 92 permettant de coder les blocs de données radio (RDB) à transmettre. Après codage, les blocs de données radio codés sont stockés dans un buffer (ou mémoire tampon) d'émission de paquets de données. Ce buffer est, par exemple, compris dans le bloc d'émission 95 ; - un bloc de décodage 90 permettant de décoder les blocs de données radio (RDB) reçus. Après décodage, les blocs de données radio décodés sont stockés dans un buffer (ou mémoire tampon) de réception de paquets de données. Ce buffer est, par exemple, compris dans le bloc de réception 94 ; - un bloc de retransmission 91 de blocs de données radio (RDB) permettant d'extraire des blocs de données radio stockés dans le buffer de réception de 5 10 15 20 25 30 paquets de données précité, puis de les stocker dans le buffer d'émission de paquets de données précité ; - un premier bloc de synchronisation 97 permettant de contrôler l'enchaînement régulier des cycles SDTC. Le premier bloc de synchronisation 97 permet également de définir l'instant d'accès (c'est-à-dire le début de temps de parole) au canal de transmission (ou médium) pour l'envoi de paquets de données (par le bloc d'émission 95). Dans le présent exemple, ce premier bloc de synchronisation 97 permet le traitement en émission/réception de 10 paquets de données pendant un cycle SDTC. On note que le premier bloc de synchronisation 97 contrôle un second bloc de synchronisation 96 qui permet de contrôler l'enchaînement régulier des cycles SDPC. Ainsi, on obtient pour chaque canal virtuel un transfert parfaitement synchrone des échantillons entre les blocs d'écriture 89 et de lecture 88 et le bloc d'interface audio synchrone 98. Dans un mode de réalisation particulier, le module de communication synchrone 3000 comprend, pour un noeud esclave donné : - des moyens de détection de début effectif du temps de parole des autres noeuds du système (lorsqu'ils sont visibles). Ces moyens sont par exemple des moyens de détection de préambule radio. Ils permettent de déterminer l'instant effectif de début de réception d'un paquet radio. Ces moyens permettent donc de dater le début d'un intervalle de temps ; - des moyens de surveillance (aussi appelés moyens de monitoring) du système. Dans un mode de réalisation particulier, ces moyens de surveillance sont mis en oeuvre sous la forme d'un ensemble de registres mémoire. Cet ensemble de registres permet de calculer et sauvegarder, pour chaque paquet radio, une dérive correspondant à l'écart entre l'instant attendu de réception du paquet et l'instant effectif de réception du paquet. Il est en outre possible d'envisager de mettre en oeuvre un autre ensemble de registres pour calculer et sauvegarder, pour chaque intervalle de temps, une valeur moyenne des dérives mesurées. Il est important de noter que le fait d'utiliser une valeur moyenne permet de minimiser les effets de gigue introduits par les différents noeuds. Comme on le verra par la suite, 10 15 20 25 lorsqu'un noeud esclave décide de se synchroniser sur un autre noeud esclave (appelé par la suite noeud distant), il prend comme référence une valeur moyenne de dérive, et non pas une valeur instantanée de dérive ; - des moyens de décision de se synchroniser sur un noeud distant. Ces moyens de décision permettent au noeud esclave de sélectionner le noeud distant visible qui offre la meilleure précision pour restituer le cadencement du cycle SDTC (c'est-à-dire le cadencement défini par le noeud maître) ; - des moyens d'estimation de la durée des temps de parole (ou temps de transmission) pendant un cycle SDTC. Ces moyens d'estimation permettent de calculer la valeur nominale du début de chaque intervalle de temps. On note que dans le cas d'un intervalle de temps en réception, il s'agit de la valeur prédite du début de transmission pour le noeud distant. Dans le cas d'un intervalle de temps en émission, il s'agit de la valeur prédite du début de transmission pour le noeud esclave ; - des moyens de génération d'un signal marquant le début d'un cycle SDTC. Ces moyens de génération permettent de calculer la durée d'un cycle SDTC en tenant compte de la dérive moyenne du noeud esclave par rapport au noeud maître ; - des moyens de génération d'un signal marquant le début des cycles de traitement des données synchrone (appelés cycles � SDPC �, ou � Synchronous Data Processing Cycle � en anglais) (comme on le verra par la suite, un cycle SDTC comprend plusieurs cycles SDPC). Ces moyens de génération permettent de calculer la durée d'un cycle SDPC en tenant compte de la dérive moyenne du noeud esclave par rapport au noeud maître. Ils permettent d'uniformiser la durée des cycles et d'éviter un allongement ou un raccourcissement important du dernier cycle SDPC. 6.5 Architecture des blocs de synchronisation On présente maintenant, en relation avec la figure 4, un exemple d'architecture du premier bloc de synchronisation 97 (embarqué dans chaque noeud esclave) selon un mode de réalisation particulier de l'invention. Le premier bloc de synchronisation 97 comprend un contrôleur de synchronisation 400 permettant notamment de réaliser les opérations suivantes : (pour un noeud esclave donné) o gestion de l'état de synchronisation du noeud esclave ; o décision du lancement de la procédure de synchronisation suite à la réception d'un paquet de données ; o gestion de registres de surveillance (� monitoring registers � en anglais) 404 du réseau ; o gestion de registres de configuration 405 ; o calcul et stockage de la valeur de la dérive estimée du noeud esclave par rapport au noeud maître ; o calcul et stockage des durées nominales estimées des intervalles de temps ; o pilotage d'un contrôleur SDPC 96 et de blocs de calcul 401 et 402. Le contrôleur de synchronisation 400 permet également de calculer le niveau de synchronisation du noeud esclave par rapport au noeud maître et de transférer le résultat du calcul vers le bloc d'émission 95, au moyen d'un signal Tx_synchro_cpt 409. Le bloc de calcul transmission 401 permet de calculer le temps restant avant la prochaine transmission. Le calcul tient compte de la dérive du noeud esclave par rapport au noeud maître. Le calcul est déclenché par une requête émise par le contrôleur de synchronisation 400 via un signal Req_tx 413. Après avoir effectué ce calcul, le bloc de calcul transmission 401 génère un signal Tx_start 411 permettant de notifier le début de la transmission. Par ailleurs, on note que le bloc de calcul transmission 401 permet de transférer vers le bloc d'émission 95 le numéro de l'intervalle de temps d'émission, au moyen d'un signal Tx_hop_id 417. Le bloc de calcul SDTC 402 permet de calculer le temps restant avant la fin du cycle de transmission SDTC. Le calcul tient compte de la dérive du noeud esclave par rapport au noeud maître. Le calcul est déclenché par une requête émise par le contrôleur de synchronisation 400 via un signal Req_SDTC 414. Après avoir effectué ce calcul, le bloc de calcul SDTC 402 génère un signal SDTC_start 410 permettant de notifier le début d'un nouveau cycle de transmission (nouveau cycle SDTC). Par ailleurs, on note que le bloc de calcul SDTC 402 compte le nombre de signaux SDTC_start 410 générés sans qu'il n'y ait eu de synchronisation. Ce nombre est mis à disposition auprès du bloc de calcul transmission 401 et du contrôleur de synchronisation 400 via un signal nb_SDTC_no_sync 416. Le contrôleur SDPC 96 permet de calculer la durée du cycle de traitement de données synchrone (cycle SDPC). Le calcul tient compte de la dérive du noeud esclave par rapport au noeud maître. Le calcul est déclenché soit par une requête émise par le contrôleur de synchronisation 400 via un signal Req_SDPC 415, soit par la détection d'un nouveau cycle de transmission synchrone (nouveau cycle SDTC) via le signal SDTC_start 410 (généré par le bloc de calcul SDTC 402). Après avoir effectué ce calcul, le contrôleur SDPC 96 génère un signal SDPC_start permettant de notifier le début d'un nouveau cycle de traitement de données synchrone (nouveau cycle SDPC). Comme illustré sur la figure 3, ce signal SDPC_start est utilisé par les blocs d'écriture 89 et de lecture 88 de conteneurs de canal virtuel. Le contrôleur de synchronisation 400, les blocs de calcul 401 et 402 et le contrôleur SDPC 96 ont accès aux registres de configuration 405, dans lesquels sont stockés : des paramètres statiques, par exemple : o le nombre d'intervalles de temps par cycle SDTC ; o les numéros des intervalles de temps affectés en transmission ; o la durée théorique d'un cycle SDTC ; o la durée théorique d'un cycle SDPC ; o la durée théorique des intervalles de temps ; o le nombre de cycle SDPC par cycle SDTC (c'est-à-dire le rapport STPR) ; o le nombre maximal autorisé de cycles SDTC sans synchronisation, et - des paramètres dynamiques, par exemple : o l'identifiant du dernier intervalle de temps sur lequel le noeud esclave s'est synchronisé ; o la date de réception du dernier paquet de données ayant permis la synchronisation ; o la dérive estimée du noeud esclave par rapport au noeud maître ; o les durées nominales estimées des intervalles de temps. 25 30 La figure 6a présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc d'émission 95 (décrit en relation avec la figure 3), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 600), on attend dans une étape 601 un signal (aussi appelé événement) Tx_start 411 indiquant le début d'une transmission. Comme indiqué précédemment (en relation avec la figure 4), le signal Tx_start 411 est généré par le bloc de calcul transmission 401. Dans une étape 602, on reçoit le signal Tx_start 411. Puis, dans une étape 603, on construit le champ en-tête 49 du paquet de données à transmettre. Dans cette étape 603, le bloc d'émission 95 construit le champ en-tête 49 en copiant la valeur du signal Tx_synchro_cpt 409 dans le champ � synchro_cpt � 52 (le champ � synchro_cpt � indique le niveau de synchronisation sur le noeud maître du noeud qui émet le paquet de données), et la valeur du signal Tx_hop_id 417 dans le champ � hop_id � 51 (le champ � hop_id � indique le numéro de l'intervalle de temps affecté au paquet de données). Ensuite, on revient à l'étape 601. La figure 6b présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc de réception 94 (décrit en relation avec la figure 3), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 610), on attend dans une étape 611 un préambule radio 54 marquant le début d'un paquet de données. Dans une étape 612, on détecte le préambule radio 54. Dans une étape 613, on récupère l'identifiant de l'intervalle de temps dans l'en-tête du paquet de données reçu. En d'autres termes, le signal Rx_hop_id 406 (généré par le bloc de réception 94) prend la valeur du champ � hop_id � 51 du paquet de données reçu. Dans une étape 614, on récupère le niveau de synchronisation du noeud distant dans l'en-tête du paquet de données reçu. En d'autres termes, le signal Rx_synchro_cpt 408 (généré par le bloc de réception 94) prend la valeur du champ � synchro_cpt � 52 du paquet de données reçu. Puis, dans une étape 615, on notifie la réception d'un paquet de données au contrôleur de synchronisation 400. Pour ce faire, le bloc de réception 94 génère et transmet un signal Rx_start 407 vers le contrôleur de synchronisation 400. On note également que le bloc de réception 94 extrait les identifiants de l'en-tête 49 du paquet de données reçu et les met à disposition auprès du premier bloc de synchronisation 97 via les signaux Rx_hop_id 406 et Rx_synchro_cpt 408. Ensuite, on revient à l'étape 611. 6.6 Description des registres de surveillance On présente désormais, en relation avec la figure 5, un exemple de contenu des registres de surveillance 404 (cf. figure 4) selon un mode de réalisation particulier de l'invention. Sur la figure 5 est représenté un ensemble de registres regroupés par intervalles de temps. Dans le mode de réalisation illustré, on considère les hypothèses suivantes : - le système comprend 10 intervalles de temps. Ces intervalles de temps sont représentés par les lignes 500 à 509 ; - l'intervalle de temps 503 est affecté en transmission ; - les paquets de données, associés au intervalle de temps 506, ne sont jamais reçus en raison d'un masquage permanent ; - les intervalles de temps 508 et 509 ne sont pas utilisés. Chaque intervalle de temps comprend un ensemble de registres permettant de stocker un ensemble de mesures plus une valeur moyenne. En prenant l'exemple de l'intervalle de temps 502, chacun des registres 502.0 à 502.19 est associé à une mesure. Dans cet exemple, on suppose un maximum de 20 mesures par intervalle de temps. Chaque registre 502.0 à 502.19 est divisé en deux champs. Le premier champ comprend une dérive mesurée en nombre de tics d'horloge par rapport au noeud utilisant ce intervalle de temps. Le second champ comprend un nombre de cycles SDTC écoulés depuis l'enregistrement de la mesure dans le premier champ. Le registre 502.20 comprend un résultat de calcul de la moyenne des mesures enregistrées dans les registres 502.0 à 502.19. Le registre 502.20 est également divisé en deux champs. Le premier champ comprend une dérive moyenne calculée. Cette dérive est recalculée lors de l'enregistrement d'une nouvelle mesure. Le second champ comprend un nombre de mesures existantes pour cet intervalle de temps. Cet ensemble de registres est géré par le contrôleur de synchronisation 400. Lorsque le noeud esclave n'est pas synchronisé sur le noeud maître, on initialise les registres avec des valeurs nulles. Lorsque le noeud esclave est synchronisé sur le noeud maître, on démarre la surveillance (ou monitoring) du réseau, puis on remplit les registres au fur et à mesure qu'on reçoit des paquets de données. Lors de la réception d'un paquet de données, la mesure de la dérive est enregistrée dans le premier champ d'un registre vide (par exemple le registre 501.18) d'un intervalle de temps donné (par exemple l'intervalle de temps 501). Le second champ de ce même registre (par exemple le registre 501.18) est initialisé avec la valeur � 1 �. Il est important de noter que si tous les registres sont déjà remplis (par exemple les registres 502.0 à 502.19), alors on choisit le registre (par exemple le registre 502.2) qui contient la plus ancienne mesure pour stocker la nouvelle donnée. La valeur moyenne calculée de la dérive et le nombre de mesures sont ensuite mis à jour dans les premier et second champs du dernier registre de l'intervalle de temps donné (par exemple le registre 501.20). On note qu'à chaque début de cycle SDTC, le second champ des registres de mesure (registres 50x.0 à 50x.1x) est incrémenté de � 1 �. Lorsque la valeur de ce second champ dépasse une valeur seuil préalablement définie, la mesure associée est effacée du fait qu'elle est trop ancienne pour être pertinente. En outre, on modifie le nombre de mesures associé (ce nombre est stocké dans le second champ d'un dernier registre 50x.20). 6.7 Fonctionnement du contrôleur de synchronisation On présente, en relation avec les figures 7a et 7b, les étapes principales d'un algorithme de traitement mis en oeuvre par le contrôleur de synchronisation 400 (décrit en relation avec la figure 4), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 700), le contrôleur de synchronisation 400 réalise dans une étape 701 les opérations suivantes : - initialisation d'un compteur de tics d'horloge locale. Comme on le verra par la suite, ce compteur est utilisé pour dater la réception des différents paquets de données ; - initialisation d'une valeur de dérive stockée dans les registres de configuration 405 avec la valeur � 0 � ; -initialisation des durées nominales des intervalles de temps avec des valeurs théoriques de démarrage. La durée d'un intervalle de temps (Ttheo_slot) est définie par : Ttheo slot = Ttheo _ sdtc Nb _ slot _ per _ sdtc où : - Ttheo_sdtc est la durée théorique d'un cycle SDTC ; -Nb_slot_per_sdtc est le nombre de intervalle de temps par cycle SDTC. Du fait que l'on ne gère que des nombres entiers, il convient de prendre la partie entière du résultat de l'équation ci-dessus et de répartir le reste � r � sur quelques intervalles de temps. On a donc � r � intervalles de temps qui ont une durée égale à Int(Ttheo _ slot), en revanche les autres intervalles de temps ont une durée égale à Int(Ttheo _ slot) + 1. Ces valeurs sont stockées dans les registres de configuration 405. Dans une étape 702, le contrôleur de synchronisation 400 attend l'un des trois événements suivants : - SDTC_start 410: signal permettant de notifier le début d'un nouveau cycle de transmission ; - Rx_start 407 : signal permettant de notifier la réception d'un paquet de données ; ou - Tx_start 411: signal permettant de notifier le début de la transmission. 6.7.1 Réception d'un événement � SDTC start � Dans une étape 703, on reçoit le signal SDTC_start 410 (émis par le bloc de calcul SDTC 402). Dans une étape 705, le contrôleur de synchronisation 400 effectue un test pour connaître la durée écoulée depuis la dernière synchronisation. Cette durée est exprimée en nombre de cycles SDTC et est fournie par le bloc de calcul SDTC 402 via le signal nb_SDTC_no_sync 416. En d'autres termes, le contrôleur de synchronisation 400 vérifie si le nombre de cycles SDTC sans synchronisation est inférieur ou égal à un seuil prédéterminé (par exemple 3). En cas de vérification positive, on passe à une étape 750. En revanche, en cas de vérification négative, on passe à une étape 706. Dans l'étape 750, c'est-à-dire si le nombre de cycles SDTC sans synchronisation est toujours acceptable, les registres de surveillance 404 sont mis à jour. Plus précisément, on incrémente de � 1 � le second champ des registres de mesure (numérotés 50x.0 à 50x.lx sur la figure 5). Ensuite, on revient à l'étape 702. Comme indiqué précédemment, lorsque la valeur de ce second champ dépasse une valeur seuil préalablement définie, la mesure associée est effacée du fait qu'elle est trop ancienne pour être pertinente. Dans l'étape 706, c'est-à-dire si le nombre de cycles SDTC sans synchronisation est supérieur au seuil prédéterminé, le contrôleur de synchronisation 400 déclare l'état du noeud escalve comme étant � non synchronisé �. En conséquence, les registres de surveillance 404 sont réinitialisés, c'est-à-dire que la valeur de la dérive du registre de configuration 405 est réinitialisée avec la valeur � 0 �, et les durées nominales des intervalles de temps reprennent les valeurs théoriques de démarrage. Ensuite, on revient à l'étape 702. 6.7.2 Réception d'un événement � Rx start � Dans une étape 710, on reçoit le signal Rx start 407 (émis par le bloc de réception 94). Dans une étape 711, le contrôleur de synchronisation 400 mémorise la valeur du compteur de tics d'horloge locale pour dater l'arrivée du paquet de données. Cette valeur est stockée dans une variable notée Trx . Dans une étape 712, on vérifie l'état de synchronisation actuel du noeud. Si l'état actuel est � non synchronisé �, c'est-à-dire si le noeud a la possibilité de démarrer la procédure de synchronisation, alors on passe à une étape 713, sinon on passe à une étape 718. Dans l'étape 713, le contrôleur de synchronisation 400 effectue l'analyse du niveau de synchronisation du noeud ayant émis le paquet de données. En d'autres termes, le contrôleur de synchronisation 400 compare la valeur du niveau de synchronisation reçu Rx_synchro_cpt 408 avec la valeur du niveau de synchronisation local Tx_synchro_cpt 409. On note que, du fait de l'état actuel � non synchronisé �, la valeur Tx_synchro_cpt 409 est égale soit à une valeur initiale prédéterminée (par exemple 3) soit à la valeur issue d'une réception radio précédente. Dans une étape 714, on analyse le résultat de la comparaison (obtenu à l'étape 713) de façon à vérifier si la synchronisation est possible sur le noeud émetteur. En cas de vérification positive (c'est-à-dire si la valeur Rx_synchro_cpt 408 est strictement inférieure à la valeur Tx_synchro_cpt 409), on passe à une étape 715 (la procédure de synchronisation est déclenchée). En revanche, en cas de vérification négative (c'est-à-dire si la valeur Rx_synchro_cpt 408 est supérieure ou égale à la valeur Tx_synchro_cpt 409), on revient à l'étape 702 (la procédure de synchronisation n'est pas déclenchée). Dans l'étape 715, on génère et envoie une requête de calcul de prochain cycle SDTC au bloc de calcul SDTC 402. Cette requête est transmise via le signal Req_SDTC 414. Dans une étape 716, on effectue les opérations suivantes : - on initialise la valeur du niveau de synchronisation local Tx_synchro_cpt 409 avec la valeur du niveau de synchronisation reçu Rx_synchro_cpt 408 ; - on enregistre l'identifiant de l'intervalle de temps reçu � rx_hop_id � dans un champ � sync_rx_hop_id � des registres de configuration 405 ; - on enregistre la date de réception du paquet de données dans un champ � Tref des registres de configuration 405 ; - on déclare le noeud comme étant synchronisé. Ensuite, on revient à l'étape 702. Dans l'étape 718, on ajoute une nouvelle mesure (c'est-à-dire une nouvelle valeur de dérive) aux registres de surveillance 404. Pour ce faire, on calcule tout d'abord la dérive � d� du noeud esclave par rapport au noeud distant sur la durée écoulée depuis la dernière synchronisation, puis on calcule la nouvelle dérive � D � sur un cycle SDTC. Le temps écoulé mesuré depuis la dernière synchronisation est défini par : Tmes = Trx û Tref où : - Trx est la valeur du compteur de tics d'horloge locale indiquant l'arrivée du paquet de données, - Tref est la valeur du compteur de tics d'horloge locale indiquant la date de la dernière synchronisation. La dérive � d� du noeud esclave par rapport au noeud distant est définie par : d = Tmes û Ttheo 5 10 15 20 où : Ttheo est le temps écoulé estimé depuis la dernière synchronisation ; Tmes est le temps écoulé mesuré depuis la dernière synchronisation. Le temps écoulé estimé depuis la dernière synchronisation est défini par : nb_sdtc no_sync sync_Rx hop idù1 Rx hop idù1 Ttheo = Ttheo sdtc û Ttheo slot(j) + Ttheo _ slot(k) i=0 j=0 k=0 où : nb_sdtc _no_sync Ttheo _ sdtc est la somme des périodes complètes SDTC écoulées i=o (chaque cycle SDTC ayant une durée Ttheo _ sdtc) ; sync_Rx_hop_idù1 Ttheo _ slot(j) est le temps écoulé entre la dernière synchronisation et le début du cycle SDTC suivant cette synchronisation ; Rx hop idù1 - Ttheo _ slot(k) est le temps écoulé depuis le début du dernier cycle k=0 SDTC. La nouvelle dérive � D � est définie par : D = Int(d x Ttheo _ sdtc) Tmes où : - Int désigne la partie entière ; - Ttheo sdtc est la durée théorique d'un cycle SDTC ; -Tmes est le temps écoulé mesuré depuis la dernière synchronisation. Comme indiqué ci-dessus, la valeur de la nouvelle dérive � D� est enregistrée dans les registres de surveillance 404. Avec cette nouvelle mesure � D �, on calcule une nouvelle valeur moyenne Dmean pour l'intervalle de temps concernée. Ensuite, on enregistre cette nouvelle valeur moyenne Dmean dans les registres de surveillance 404. Dans une étape 719, le contrôleur de synchronisation 400 effectue l'analyse du niveau de synchronisation du noeud ayant émis le paquet de données. En d'autres termes, le contrôleur de synchronisation 400 compare la valeur du niveau de synchronisation reçu Rx_synchro_cpt 408 avec la valeur du niveau de synchronisation local Tx_synchro_cpt 409 et une valeur de niveau maximal acceptable prédéterminée. Afin de pouvoir déclencher la synchronisation sur le noeud distant, la valeur Rx_synchro_cpt 408 doit vérifier une double condition : elle doit tout d'abord être strictement inférieure à la valeur de niveau maximal (par exemple 3), puis elle doit être strictement inférieure à la valeur Tx_synchro_cpt 409. Si les deux conditions sont vérifiées, alors on passe à une étape 721, sinon on revient à l'étape 702. Dans l'étape 721, le contrôleur de synchronisation 400 stocke dans les registres de configuration 405 la dérive moyenne Dmean calculée à l'étape 718. La durée nominale d'un cycle SDTC Tnom _ sdtc est égale à la durée théorique Ttheo _ sdtc ajoutée de la dérive moyenne Dmean . Ensuite, le contrôleur de synchronisation 400 calcule la nouvelle durée nominale � Thom slot � de chaque intervalle de temps. La valeur de cette nouvelle durée est Tnom slot = Tnom sdtc Nb slot per sdtc définie par : où Tnom _ sdtc est la durée nominale d'un cycle SDTC ; Nb_slot per_sdtc est le nombre de intervalle de temps par cycle SDTC. Du fait que l'on ne gère que des nombres entiers, il convient de prendre la partie entière du résultat de l'équation ci-dessus et de répartir le reste � r � sur quelques intervalles de temps. On a donc � r � intervalles de temps qui ont une durée égale à Int(Tnom _ slot) , en revanche les autres intervalles de temps ont une durée égale à Int(Tnom _ slot) +1. Ces valeurs sont stockées dans les registres de configuration 405. Dans une étape 722, on génère et envoie une requête de calcul de prochain cycle SDTC au bloc de calcul SDTC 402. Cette requête est transmise via le signal Req_SDTC 414. Dans une étape 723, on génère et envoie une requête de calcul de temps de 5 transmission au bloc de calcul transmission 401. Cette requête est transmise via le signal Req_tx 413. Dans une étape 724, on génère et envoie une requête de calcul de la durée de cycle SDPC au contrôleur SDPC 96. Cette requête est transmise via le signal Req_SDPC 415. Dans une étape 725, on effectue les opérations suivantes : - on initialise la valeur du niveau de synchronisation local Tx_synchro_cpt 409 avec la valeur du niveau de synchronisation reçu Rx_synchro_cpt 408 ; - on enregistre l'identifiant de l'intervalle de temps reçu � rx_hop_id � dans un champ � sync_rx_hop_id � des registres de configuration 405 ; - on enregistre la date de réception du paquet de données dans un champ � Tref des registres de configuration 405. Ensuite, on revient à l'étape 702. 6.7.3 Réception d'un événement � Tx start � Dans une étape 730, on reçoit le signal Tx start 411 (émis par le bloc de calcul transmission 401). 20 Dans une étape 731, le contrôleur de synchronisation 400 incrémente d'une unité le niveau de synchronisation local, c'est-à-dire qu'il incrémente de � 1 � la valeur du signal Tx_synchro_cpt 409. Ensuite, on revient à l'étape 702. 6.8 Fonctionnement du bloc de calcul SDTC La figure 8 présente les étapes principales d'un algorithme de traitement mis en 25 oeuvre par le bloc de calcul SDTC 402 (décrit en relation avec la figure 4), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 800), le contrôleur de synchronisation 400 attend dans une étape 801 l'un des deux événements suivants : - � Requête calcul SDTC � ; 30 - SDTC start 410: signal permettant de notifier le début d'un nouveau cycle de transmission. 10 15 6.8.1 Réception d'un événement � Requête calcul SDTC � Dans une étape 802, on détecte l'événement � Requête calcul SDTC � correspondant à une requête de calcul de la durée du cycle SDTC. Comme indiqué précédemment, cette requête est transmise via le signal Req_SDTC 414 (émis par le contrôleur de synchronisation 400). On note que cette requête intervient après la réception d'un paquet de données permettant au noeud esclave d'être synchronisé sur le noeud maître. Ainsi, il est possible d'affiner le calcul de la durée du cycle SDTC à partir de la dérive moyenne Dmean calculée à l'étape 718. Dans une étape 803, le bloc de calcul SDTC 402 réalise les opérations suivantes : - lecture de la valeur de la dérive moyenne Dmean et de la durée nominale des intervalles de temps. Ces informations sont stockées dans les registres de configurations 405 ; - lecture et enregistrement de l'identifiant de l'intervalle de temps reçu � rx_hop_id � ; - calcul, en nombre de tics d'horloge locale, de la durée restante avant le début du prochain cycle SDTC. Cette durée est définie par : Rx hop idù1 Time _ before _ sdtc = Ttheo _ sdtc + Dmean ù Tnom _ slot(k) ù correction k=0 où : o Ttheo sdtc est la durée théorique d'un cycle SDTC ; o Dmean est la dérive moyenne ; Rx hop idù1 o 1Tnom _ slot(k) est le temps écoulé depuis le début du cycle SDTC ; k=0 o correction est la constante de correction permettant de tenir compte du temps écoulé depuis la réception du signal Rx_start 407. En d'autres termes, il s'agit de la différence entre la valeur actuelle du compteur de tics d'horloge locale et la valeur mémorisée à la réception du paquet de données (étape 20 25 711), de manière à prendre en compte les délais de traitements inhérents à la réception de données. - initialisation d'un compteur de cycles SDTC sans synchronisation à la valeur � 0 �. Comme on le verra par la suite, ce compteur est incrémenté d'une unité chaque fois qu'un cycle SDTC est généré sans qu'il n'y ait eu de requête provenant du contrôleur de synchronisation 400. La valeur de ce compteur (correspondant au nombre de cycles SDTC générés sans synchronisation du noeud esclave) est mise à disposition auprès du bloc de calcul transmission 401 et du contrôleur de synchronisation 400 via le signal nb_SDTC_no_sync 416. On présente, en relation avec la figure 11a, un exemple d'architecture du compteur de cycles SDTC selon un mode de réalisation particulier de l'invention. Le compteur de cycles SDTC 3000 génère le signal SDTC_start 410 indiquant le début d'un nouveau cycle SDTC. Le compteur de cycles SDTC 3000 comprend : - un compteur 1101 qui délivre en sortie � Out � un signal de sortie 1106, représentatif d'une durée exprimée en nombre de tics d'horloge. Plus précisément, le compteur 1101 reçoit sur une première entrée � Reset � un signal de réinitialisation � Resetl � 1102, sur une deuxième entrée � Clock ENA � un signal de commande � CENa1 � 1103, et sur une troisième entrée � Clock � un signal d'horloge � Clk � 1104 ; - un comparateur 1105 recevant sur une première entrée le signal de sortie 1106 et sur une deuxième entrée le signal � time_before_SDTC � représentatif de la durée restante avant le début du prochain cycle SDTC (exprimée en nombre de tics d'horloge locale). Le comparateur 1105 délivre en sortie le signal SDTC_start 410 correspondant au résultat de la soustraction entre le signal de sortie 1106 et le signal � time_before_SDTC �. Ainsi, le comparateur 1105 génère en sortie une impulsion lorsque la valeur du compteur 1101 a atteint la valeur � time before sdtc �. De nouveau en référence à la figure 8, dans une étape 804, on démarre le compteur de cycles SDTC 3000 (décrit précédemment en relation avec la figure 1la). Plus précisément, le bloc de calcul SDTC 402 initialise le compteur 1101 en envoyant une impulsion sur le signal de réinitialisation � Resetl � 1102, puis il démarre ce compteur en positionnant le signal de commande � CENa1 � 1103 à la valeur logique � 1 �. Ensuite, on revient à l'étape 801. 6.8.2 Réception d'un événement � SDTC start � Dans une étape 810, on reçoit le signal SDTC start 410 (émis par le bloc de calcul SDTC 402). Dans une étape 811, le bloc de calcul SDTC 402 incrémente de � 1 � le compteur de cycles SDTC sans synchronisation. Dans une étape 812, le bloc de calcul SDTC 402 vérifie si le noeud est toujours en droit de se considérer comme synchronisé. En d'autres termes, le bloc de calcul SDTC 402 vérifie si le nombre de cycles SDTC sans synchronisation est inférieur ou égal à un seuil prédéterminé (par exemple 3). En cas de vérification positive, on passe à une étape 813. En revanche, en cas de vérification négative, on passe à une étape 814. Dans l'étape 813, on initialise la durée du prochain cycle SDTC time before SDTC � de la manière suivante : Time _ before _ sdtc = Ttheo _ sdtc + Dmean où : o Ttheo sdtc est la durée théorique d'un cycle SDTC ; o Dmean est la dérive moyenne. Ensuite, on passe à l'étape 804. Dans l'étape 814, on arrête le compteur de cycles SDTC 3000. Ensuite, on revient à l'étape 801. 6.9 Fonctionnement du bloc de calcul de début de transmission La figure 9 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le bloc de calcul de début transmission SDTC 401 (décrit en relation avec la figure 4), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 900), le bloc de calcul transmission 401 attend dans une étape 901 une requête de calcul de début transmission 902. Cette requête est transmise via le signal Req_tx 413 (émis par le bloc de calcul SDTC 402). Dans une étape 902, on détecte le signal � Req_tx 413 �. 5 10 15 20 25 Dans une étape 903, le bloc de calcul transmission 401 réalise les opérations suivantes : - lecture de la valeur de la dérive moyenne Dmean , de la valeur nominale des intervalles de temps et de l'identifiant des intervalles de temps en émission. Ces informations sont stockées dans les registres de configurations 405 ; - lecture et enregistrement de l'identifiant de l'intervalle de temps reçu rx_hop_id � ; - calcul, en nombre de tics d'horloge locale, de la nouvelle durée (c'est-à-dire le temps restant) avant la prochaine transmission � Time_before_tx �. o Si une transmission a lieu dans le cycle SDTC courant, c'est-à-dire si le numéro du prochain intervalle de temps en émission � next_tx_hop_id � est supérieur à la valeur Rx_hop_id, alors : la nouvelle durée avant la prochaine transmission � Time_before_tx � est définie par : next_tx hop idù1 1 Tnom _ slot(i) ù correction i=rx hop id next_ x_hop_idù1 Tnom _ slot(i) est le temps entre le début de i=rx_hop_id l'intervalle de temps de réception du paquet permettant la synchronisation et le début de l'intervalle de temps de transmission. correction est la constante de correction permettant de tenir compte du temps écoulé depuis la réception du signal Rx_start 407. En d'autres termes, il s'agit de la différence entre la valeur actuelle du compteur de tics d'horloge locale et la valeur mémorisée à la réception du paquet de données (étape 711), de manière à prendre en compte les délais de traitements inhérents à la réception de données ; initialisation d'un compteur temps avant transmission 4000. Comme on le verra par la suite (figure l lb), le bloc de calcul transmission 401 Time before tx = où : initialise le compteur 4000 en envoyant une impulsion sur le signal de réinitialisation � Reset2 � 1112, puis il démarre ce compteur en positionnant le signal de commande � CENa2 � 1113 à la valeur logique � 1 �. Ensuite, on passe à une étape 904 ; o En revanche, si aucune transmission n'a lieu dans le cycle SDTC courant, c'est-à-dire si tous les numéros des intervalles de temps en émission sont inférieurs ou égaux à la valeur Rx_hop_id, alors le bloc de calcul transmission 401 passe directement à l'étape 904 sans démarrer le compteur 4000. On présente désormais, en relation avec la figure llb, un exemple d'architecture du compteur temps avant transmission 4000 selon un mode de réalisation particulier de l'invention. Le compteur temps avant transmission 4000 génère le signal Tx_start 411 indiquant le début de la transmission. Le compteur temps avant transmission 4000 comprend : - un compteur 1111 qui délivre en sortie � Out � un signal de sortie 1116, représentatif d'une durée exprimée en nombre de tics d'horloge. Plus précisément, le compteur 1111 reçoit sur une première entrée � Reset � un signal de réinitialisation � Reset2 � 1112, sur une deuxième entrée � Clock ENA � un signal de commande � CENa2 � 1113, et sur une troisième entrée � Clock � un signal d'horloge � Clk � 1114 ; - un comparateur 1115 recevant sur une première entrée le signal de sortie 1116 et sur une deuxième entrée le signal � Time_before_tx � représentatif de la durée avant la prochaine transmission (exprimée en nombre de tics d'horloge locale). Le comparateur 1115 délivre en sortie le signal Tx_start 411 correspondant au résultat de la soustraction entre le signal de sortie 1116 et le signal � Time_before_tx �. Ainsi, le comparateur 1115 génère en sortie une impulsion lorsque la valeur du compteur 1111 a atteint la valeur � Time_before_tx �. De nouveau en référence à la figure 9, dans une étape 904, le bloc de calcul transmission 401 attend l'un des trois événements suivants : - Req_tx 413 : signal associé à une requête de calcul de début transmission 902 ; - SDTC_start 410: signal permettant de notifier le début d'un nouveau cycle de transmission ; - Tx_start 411: signal permettant de notifier le début de la transmission. 6.9.1 Réception d'un événement � Req tx � Dans une étape 930, on détecte l'événement � Req tx �. Ensuite, on retourne à l'étape 903. 6.9.2 Réception d'un événement � SDTC start � Dans une étape 910 (cas d'un début de cycle SDTC), on reçoit le signal SDTC_start 410 (émis par le bloc de calcul SDTC 402). Dans une étape 911, le bloc de calcul transmission 401 vérifie si le noeud est toujours en droit de se considérer comme synchronisé. En d'autres termes, le bloc de calcul transmission 401 vérifie si le nombre de cycles SDTC sans synchronisation est inférieur ou égal à un seuil prédéterminé (par exemple 3). En cas de vérification positive, on passe à une étape 912. En revanche, en cas de vérification négative, on passe à une étape 913. Dans l'étape 912, on arrête le compteur temps avant transmission 4000. Ensuite, on revient à l'étape 901. Dans l'étape 913, le bloc de calcul transmission 401 initialise un compteur indiquant le nombre de transmission effectuée dans le cycle SDTC courant avec la valeur � 0 �. Comme on le verra ci-après, ce compteur est incrémenté d'une unité chaque fois qu'un signal Tx_start 411 est généré. Dans une étape 914, le bloc de calcul transmission 401 réalise les opérations suivantes : - calcul, en nombre de tics d'horloge locale, de la nouvelle durée (c'est-à-dire le temps restant) avant la prochaine transmission � Time_before_tx �. Cette durée� Time_before_tx � est définie par : nexttx hop idù1 Time _ before _ Ix = Tnom _ slot(i) i=previous _ tx _ hop _ id où tx hop idù1 o Tnom _ slot(i) est le temps entre le début de l'intervalle de i=previoushop_id temps de la transmission précédente et le début de l'intervalle de temps de la prochaine transmission . Il s'agit de considérer que le numéro de l'intervalle de temps précédent en émission (previous_tx_hop_id) est égal à � 0 �. - initialisation et démarrage du compteur temps avant transmission 4000. Ensuite, on revient à l'étape 904. 6.9.3 Réception d'un événement � Tx start � Dans une étape 920, on reçoit le signal Tx start 411 (émis par le bloc de calcul transmission 401). Dans une étape 921, le bloc de calcul transmission 401 incrémente de � 1 � le compteur indiquant le nombre de transmission effectuée dans le cycle SDTC courant. Dans une étape 922, le bloc de calcul transmission 401 vérifie s'il s'agit de la dernière transmission du cycle SDTC. En cas de vérification positive, on passe à une étape 923. En revanche, en cas de vérification négative, on passe à l'étape 914 (décrite précédemment). Dans l'étape 923, on arrête le compteur temps avant transmission 4000. Ensuite, on revient à l'étape 904. 6.10 Fonctionnement du bloc de calcul de début de durée de cycle SDPC La figure 10 présente les étapes principales d'un algorithme de traitement mis en oeuvre par le contrôleur SDPC 96 (décrit en relation avec la figure 4), compris dans un noeud esclave, selon un mode de réalisation particulier de l'invention. Après démarrage du noeud esclave (étape 1000), le contrôleur SDPC 96 attend dans une étape 1001 l'un des trois événements suivants : - � Requête calcul SDPC � ; - SDPC start : signal permettant de notifier le début d'un nouveau cycle SDPC ; - SDTC start 410 : signal permettant de notifier le début d'un nouveau cycle de transmission. 6.10.1 Réception d'un événement � Requête calcul SDPC � Dans une étape 1002, on détecte l'événement � Requête calcul SDPC � correspondant à une requête de calcul de la durée du cycle SDPC. Comme indiqué précédemment, cette requête est transmise via le signal Req_SDPC 415 (émis par le bloc de calcul SDTC 402). On note que cette requête intervient après la réception d'un paquet de données permettant au noeud esclave d'être synchronisé sur le noeud maître. Ainsi, il est possible d'affiner le calcul de la durée des cycles SDPC à partir de la dérive moyenne Dmean calculée à l'étape 718. Dans une étape 1003, le contrôleur SDPC 96 réalise les opérations suivantes : - lecture de la valeur de la dérive moyenne Dmean , stockée dans les registres de configurations 405 ; - lecture et enregistrement de la valeur d'un compteur de cycles SDPC par cycle SDTC. Cette valeur indique le nombre � nb_SDPC � de cycles SDPC écoulés depuis le début du cycle SDTC ; - calcul, en nombre de tics d'horloge locale, de la nouvelle durée � SDPC duration � des cycles SDPC restants avant la fin du cycle SDTC. Pour ce faire, il faut connaître la valeur � Time_remaining � qui est le temps restant avant la fin du cycle SDTC courant lors du prochain événement SDPC start. Ensuite, on revient à l'étape 1001. La valeur � Time_remaining � est définie par : nb sdpc Time _ remaining = Ttheo _ sdtc + Dmean ù SDPC _ duration (i) i=o où - Ttheo sdtc est la durée théorique d'un cycle SDTC ; - Dmean est la dérive moyenne ; nb _sdpc - SDPC _ duration(i) est la durée écoulée depuis le début du cycle SDTC =o courant. Ainsi, la nouvelle durée d'un cycle SDPC est définie par : SDPC duration = Int(Time remaining) STPR ù nb _ sdpc où - Int désigne la partie entière ; - Time_remaining est le temps restant avant le prochain cycle SDTC ; - nb_SDPC est le nombre de cycles SDPC restants ; - STPR désigne le nombre total de cycles SDPC par cycle SDTC. On note que pour être encore plus précis, le reste � r � de la division ci-dessus peut être pris en compte. Dans ce cas, on a � r � cycles SDPC qui ont une durée égale à SDPC_duration + 1, en revanche les autres cycles SDPC ont une durée égale à SDPC duration. On note également qu'à l'initialisation du système, la durée SDPC_duration est égale à la valeur théorique de la durée d'un cycle SDPC : Ttheo _ sdpc . On présente désormais, en relation avec la figure 11c, un exemple d'architecture du compteur de cycles SDPC 5000 selon un mode de réalisation particulier de l'invention. Le compteur de cycles SDPC 5000 génère le signal SDPC_ start 1131 indiquant le début d'un nouveau cycle SDPC. Le compteur de cycles SDPC 5000 comprend : - un compteur 1121 qui délivre en sortie � Out � un signal de sortie 1126, représentatif d'une durée exprimée en nombre de tics d'horloge. Plus précisément, le compteur 1121 reçoit sur une première entrée � Reset � un signal de réinitialisation � Reset3 � 1122, sur une deuxième entrée � Clock ENA � un signal de commande � CENa3 � 1123, et sur une troisième entrée � Clock � un signal d'horloge � Clk � 1124 ; - un comparateur 1125 recevant sur une première entrée le signal de sortie 1126 et sur une deuxième entrée le signal � SDPC_duration � 1127 représentatif de la nouvelle durée des cycles SDPC restants avant la fin du cycle SDTC. Le comparateur 1125 délivre en sortie un signal résultant 1129 correspondant au résultat de la soustraction entre le signal de sortie 1126 et le signal � SDPC_duration �. Ainsi, le comparateur 1125 génère en sortie une impulsion lorsque la valeur du compteur 1121 a atteint la valeur � SDPC_duration � ; - une porte logique de type � OU � 1130 recevant sur une première entrée le signal de sortie 1129 et sur une deuxième entrée le signal � SDTC start � 410 indiquant le début d'un nouveau cycle SDTC. La porte logique 1130 délivre en sortie le signal SDPC_ start 1131. On note que le début du premier cycle SDPC correspond au début de cycle SDTC. 6.10.1 Réception d'un événement � SDPC start � 20 25 30 Dans une étape 1010, on reçoit le signal SDPC start 1131 (généré en sortie du compteur de cycles SDPC 5000 décrit en relation avec la figure l lc). Dans une étape 1011, le contrôleur SDPC 96 incrémente de � 1 � le compteur de cycles SDPC par cycle SDTC. Dans une étape 1012, le contrôleur SDPC 96 vérifie s'il s'agit du dernier cycle SDPC du cycle SDTC courant. En cas de vérification positive, on passe à une étape 1013. En revanche, en cas de vérification négative, on passe à une étape 1014. Dans l'étape 1013, on arrête le compteur de cycles SDPC 5000. Ensuite, on revient à l'étape 1001. Dans l'étape 1014, on met à jour la durée du prochain cycle SDPC à partir du calcul effectué à l'étape 1003, et on redémarre le compteur de cycles SDPC 5000. Ensuite, on revient à l'étape 1001. 6.10.1 Réception d'un événement � SDTC start � Dans une étape 1020, on reçoit le signal SDTC start 410 (émis par le bloc de calcul SDTC 402). Dans une étape 1021, le contrôleur SDPC 96 effectue les opérations suivantes : - lecture de la valeur de la dérive moyenne Dmean , stockée dans les registres de configurations 405 ; - calcul, en nombre de tics d'horloge locale, de la nouvelle durée � SDPC_duration � en utilisant les équations précitées (permettant d'obtenir la valeur � Time_remaining � et la nouvelle durée d'un cycle SDPC � SDPC_duration �), et en considérant un nombre de cycles SDPC écoulés � nb_SDPC � égal à � 0 �. ; - initialisation (à la valeur � 0 �) et démarrage du compteur de cycles SDPC 5000. Ensuite, on revient à l'étape 1001. REVENDICATIONS 1. Procédé de synchronisation d'un noeud esclave dans un cycle de transmission de données (SDTC) d'un réseau de communication synchrone comprenant au moins un noeud esclave (la) et un noeud maître (5a) mettant en oeuvre un cadencement qui définit ledit cycle de transmission, chaque noeud esclave gérant une représentation locale dudit cadencement, ledit cycle de transmission de données comprenant un nombre prédéterminé d'intervalles de temps, caractérisé en ce que ledit noeud esclave à synchroniser effectue les étapes suivantes, pour un cycle de transmission courant dans lequel ledit noeud esclave à synchroniser reçoit un paquet émis par un autre noeud dudit réseau, dit noeud de référence : - obtention (718) d'un instant effectif de réception dudit paquet et d'un instant estimé de réception dudit paquet ; - à partir desdits instants estimé et effectif, détermination (718) d'une dérive moyenne entre le cadencement défini par le noeud maître et la représentation locale dudit cadencement ; - répartition (813) de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission. 2. Procédé selon la revendication 1, caractérisé en ce que ledit cycle de transmission de données comprend un nombre prédéterminé de premiers intervalles de temps, dits temps de parole, chacun desdits noeuds pouvant transmettre des données sur ledit réseau pendant au moins un temps de parole qui lui est associé, en ce que, dans ladite étape de répartition, ladite dérive moyenne est répartie sur chacun des temps de paroles, pour obtenir une nouvelle représentation locale dudit cadencement, et en ce que le procédé comprend une étape de détermination d'un instant de début de temps de parole pour ledit noeud esclave à synchroniser, dans ladite nouvelle représentation locale dudit cadencement. 3. Procédé selon la revendication 1, caractérisé en ce que ledit cycle de transmission de données comprend un nombre prédéterminé de seconds intervalles de temps correspondant chacun à un cycle de traitement de données synchrones (SDPC)par lesdits noeuds, en ce que, dans ladite étape de répartition, ladite dérive moyenne est répartie sur chacun des cycles de traitement, pour obtenir une nouvelle représentation locale dudit cadencement, et en ce que le procédé comprend une étape de détermination d'un instant de début de traitement pour ledit noeud esclave à synchroniser, dans ladite nouvelle représentation locale dudit cadencement. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'étape de détermination (718) d'une dérive moyenne comprend les étapes suivantes : - calcul d'une dérive courante (D) à partir des instants estimé et effectif ; - calcul de ladite dérive moyenne (Dmean) à partir de ladite dérive courante et d'au moins une dérive précédente déterminée pour un cycle de transmission précédent; 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape de répartition (813) de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission est précédée d'une étape préalable de sélection d'un noeud dit noeud de référence comprenant elle-même les étapes suivantes : - lecture, dans chaque paquet d'un ensemble de paquets reçus, d'une information de synchronisation relative à un niveau de synchronisation par rapport au noeud maître du noeud en provenance duquel ledit paquet a été reçu ; -sélection dudit noeud de référence parmi les noeuds en provenance desquels un paquet dudit ensemble de paquets reçus a été reçu, ladite sélection étant effectuée en fonction desdites informations de synchronisation. 6. Procédé selon les revendications 1 et 5, caractérisé en ce que les étapes d'obtention d'un instant effectif de réception et d'un instant estimé de réception sont effectuées pour un ensemble de noeuds de référence du réseau de communication synchrone, et en ce que suite à ladite étape de sélection, l'étape de répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmissionest effectuée à partir des instants effectif et estimé précédemment obtenus pour ledit noeud de référence sélectionné. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape d'obtention d'un instant effectif de réception dudit paquet comprend une étape de détection d'un préambule compris dans ledit paquet. 8. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé de synchronisation selon au moins une des revendications 1 à 7, lorsque ledit programme est exécuté sur un ordinateur. 9. Moyen de stockage lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de synchronisation selon au moins une des revendications 1 à 7. 10. Noeud esclave destiné à être synchronisé dans un cycle de transmission de données (SDTC) d'un réseau de communication synchrone comprenant au moins ledit noeud esclave et un noeud maître mettant en oeuvre un cadencement qui définit ledit cycle de transmission, ledit noeud esclave gérant une représentation locale dudit cadencement, ledit cycle de transmission de données comprenant un nombre prédéterminé d'intervalles de temps, caractérisé en ce que ledit noeud esclave comprend : - - - - 11. des moyens de réception d'un paquet émis par un autre noeud dudit réseau, dit noeud de référence : des moyens d'obtention d'un instant effectif de réception dudit paquet et d'un instant estimé de réception dudit paquet ; des moyens de détermination, à partir desdits instants estimé et effectif, d'une dérive moyenne entre le cadencement défini par le noeud maître et la représentation locale dudit cadencement ; des moyens de répartition de ladite dérive moyenne sur chacun des intervalles de temps compris dans ledit cycle de transmission. Noeud esclave selon la revendication 10, caractérisé en ce que ledit cycle detransmission de données comprend un nombre prédéterminé de premiers intervalles de temps, dits temps de parole, en ce que, lesdits moyens de répartition répartissent ladite dérive moyenne sur chacun des temps de paroles, pour obtenir une nouvelle représentation locale dudit cadencement, et en ce que ledit noeud esclave comprend des moyens de détermination d'un instant de début de temps de parole dans ladite nouvelle représentation locale dudit cadencement. 12. Noeud esclave selon la revendication 10, caractérisé en ce que ledit cycle de transmission de données comprend un nombre prédéterminé de seconds intervalles de temps correspondant chacun à un cycle de traitement de données synchrones (SDPC), en ce que lesdits moyens de répartition répartissent ladite dérive moyenne sur chacun des cycles de traitement, pour obtenir une nouvelle représentation locale dudit cadencement, et en ce que ledit noeud esclave comprend des moyens de détermination d'un instant de début de traitement dans ladite nouvelle représentation locale dudit cadencement. 13. Noeud esclave selon l'une quelconque des revendications 10 à 12, caractérisé en ce que lesdits moyens de détermination d'une dérive moyenne comprennent : - des moyens de calcul d'une dérive courante (D) à partir des instants estimé et effectif ; - des moyens de calcul de ladite dérive moyenne (Dmean) à partir de ladite dérive courante et d'au moins une dérive précédente déterminée pour un cycle de transmission précédent. 14. Noeud esclave selon l'une quelconque des revendications 10 à 13, caractérisé en ce que ledit noeud esclave comprend des moyens de sélection d'un noeud de référence comprenant : - des moyens de lecture, dans chaque paquet d'un ensemble de paquets reçus, d'une information de synchronisation relative à un niveau de synchronisation par rapport au noeud maître du noeud en provenance duquel ledit paquet a été reçu ;- des moyens de sélection dudit noeud de référence parmi les noeuds en provenance desquels un paquet dudit ensemble de paquets reçus a été reçu. 15. Noeud esclave selon l'une quelconque des revendications 10 à 14, caractérisé en ce que lesdits moyens d'obtention d'un instant effectif de réception dudit paquet comprennent des moyens de détection d'un préambule compris dans ledit paquet.