FR 2934746 A1 20100205 FR 0855286 A 20080731 Procédé et dispositif de transmission dans un réseau de communication synchrone maillé, signal, produit programme d'ordinateur et moyen de stockage correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des transmissions de données dans des réseaux de communication synchrone maillés comprenant une pluralité de noeuds. Il peut, par exemple, s'agir de réseaux domestiques sans fil, dont les noeuds comprennent notamment des éléments de décodage et/ou de transmission et des éléments de restitution de signaux audio et/ou vidéo. Plus précisément, l'invention concerne les techniques de transmission de données dans les réseaux de communication synchrone, et notamment les réseaux pouvant être soumis à des évanouissements (� fading � en anglais) et des masquages causés par des obstacles fixes ou mobiles. L'invention s'applique notamment dans le cadre de la diffusion de paquets de données, c'est-à-dire les cas où un noeud du réseau, appelé noeud source ou noeud émetteur, diffuse des paquets de données destinés à un autre noeud, appelé noeud destinataire ou noeud récepteur final, ou une pluralité de noeuds, à travers le réseau de communication. L'invention s'applique ainsi aux cas des réseaux dans lesquels les paquets 20 de données sont relayés par un ou plusieurs noeuds du réseau, appelés noeuds relais, vers le ou les noeuds destinataires. L'invention s'applique indifféremment aux réseaux de communication synchrones maillés filaires ou sans fil. 2. ARRIÈRE-PLAN TECHNOLOGIQUE 25 Dans un réseau de communication synchrone, l'accès au réseau se fait suivant un mode TDM (pour � Time Division Multiplexing � en anglais, ou � Multiplexage par Division Temporelle �), c'est-à-dire que le temps est divisé en cycles de traitement de données synchrones, dits SDPC (pour � Synchronous Data Processing Cycle � en anglais, ou � Cycle de Traitement de Données Synchrone � 30 en français). Chaque cycle est lui-même divisé en intervalles de temps, correspondant à des canaux virtuels (ou � virtual channel � en anglais) et définissant un temps d'accès, ou temps de parole, chaque canal virtuel étant diffusé au travers du réseau synchrone vers tous les noeuds du réseau en temps constant. De plus, dans un tel réseau, chaque noeud dispose, à l'intérieur d'un cycle SDPC, d'au moins un temps de parole dédié à la transmission d'informations de contrôle, dit canal virtuel de contrôle ou canal de contrôle (ou � control channel � en anglais). Ce canal de contrôle est adapté au transport d'informations de protocole de gestion du réseau synchrone, notamment de protocoles de diffusion fiables (ou � reliable broadcast � en anglais). Ces informations de contrôle sont transmises sous la forme de paquets, appelés paquets de type �broadcast �, ou paquets de � braoadcast �, par la suite. La diffusion de ces paquets de � broadcast � dans le réseau est garantie par un mécanisme de relais : chaque noeud recevant un paquet � broadcast � relaie le paquet, en utilisant son canal de contrôle. Un tel relais constitue un saut (ou � hop � en anglais) dans la transmission du paquet. A la première réception d'un paquet � broadcast �, un acquittement est généré par le noeud relais, chaque acquittement étant lui aussi relayé par tous les noeuds du réseau vers le noeud émetteur du paquet � broadcast � en question. A la réception de tous les acquittements, le noeud émetteur considère que la transmission a été réussie, et peut par exemple délivrer un signal de succès à l'application cliente. Si, au bout d'un temps prédéterminé, le noeud émetteur n'a pas reçu tous les acquittements, il peut émettre un signal d'échec à l'application qui avait requis la diffusion de l'information de contrôle. Les communications dans un réseau de communication synchrone sans-fil sont très fréquemment sujettes à des interférences et à des masquages, qui peuvent altérer sensiblement la qualité des données reçues. De tels réseaux sont donc confrontés à des problèmes de fiabilité. Il existe actuellement des techniques d'amélioration de la fiabilité de tels réseaux, mises en oeuvre au niveau des couches physiques des réseaux, comme par exemple des techniques utilisant la redondance (transmettre certains paquets plusieurs fois), des codes correcteurs d'erreurs, ... Cependant, ces techniques mises en oeuvre au niveau de la couche physique nécessitent que cette couche physique soit initialisée, ou réinitialisée (par exemple lors de changements de topologie du réseau). Pendant ces phases d'initialisation, ou phases transitoires (par exemple, des phases de reconfiguration du réseau suite à un changement de conditions de transmission), la fiabilité du réseau n'est donc pas optimale, car les techniques d'amélioration par la couche physique ne peuvent pas être appliquées. Cependant, des informations de contrôle importantes (par exemple pour l'initialisation et la configuration de différents noeuds) sont généralement transmises sur le réseau pendant ces phases transitoires et il est donc nécessaire de trouver des techniques d'amélioration de la fiabilité du réseau, par exemple en utilisant des mécanismes implémentés par une couche supérieure à la couche physique. Une technique connue d'amélioration de la fiabilité du réseau est la mise en oeuvre de redondances, au niveau d'une couche supérieure à la couche physique. Ceci se traduit par exemple par l'utilisation de plusieurs canaux de contrôle par noeud pour transmettre une même information de contrôle. Un inconvénient de cette technique réside donc dans une consommation importante de la bande passante pour des informations de contrôle. Ainsi, une bande passante moins importante peut être consacrée à la transmission de données utiles, même quand aucune information de contrôle n' est émise. Une technique permettant d'optimiser l'utilisation de la bande passante consiste à n'allouer qu'un canal virtuel de contrôle par noeud. Ce canal de contrôle est donc utilisé par un noeud à la fois pour émettre ses propres informations de contrôle (c'est-à-dire générées par le noeud) et pour relayer les informations de contrôle reçues d'autres noeuds du réseau. Un inconvénient de cette deuxième technique tient au fait qu' elle engendre des conflits d'accès aux canaux virtuels de contrôle, encore appelés collisions, et nécessite donc une gestion de ces collisions. Il existe par ailleurs des techniques mettant en oeuvre des compteurs de sauts, par exemple pour interrompre la diffusion de paquets de � broadcast �, dans un réseau avec une topologie libre, ou encore pour gérer des collisions, telles que décrites précédemment. Une telle technique est notamment décrite dans le document de brevet US 4,692,761. Dans ce système, chaque noeud possède et gère un compteur de saut qui lui est propre. Ce compteur est mis à jour lors de l'initialisation du système et lors de changement de conditions, et sa valeur représente la distance de ce noeud à un noeud maître. Les noeuds qui sont en communication directe avec le maître, appelés noeuds de niveau 1, ont un compteur de saut égal à 1, ceux qui sont en communication directe avec les noeuds de niveau 1 ont un compteur de saut égal à 2, et ainsi de suite. Chaque noeud insère son propre compteur de saut, noté � Hop Count � en anglais, dans chaque message qu'il envoie, ce qui permet aux noeuds qui reçoivent directement ces messages de détecter un éventuel changement de conditions. En effet, chaque noeud détermine son compteur de saut par rapport à son ou ses voisins le(s) plus proche(s) du noeud maître. Si le voisin le plus proche du maître change de valeur de compteur de saut � Hop Count �, le noeud doit trouver un autre voisin proche du maître ou alors mettre à jour son propre compteur de saut � Hop Count �. Deux principaux modes de communication sont définis dans ce document 25 de brevet : des noeuds esclaves vers le maître, du maître vers un ou plusieurs noeuds esclaves. Les noeuds qui sont à une distance supérieure à 1 saut du maître adressent leur message à un noeud intermédiaire prédéterminé, ce noeud étant chargé de relayer le message soit directement au maître s'il le peut, soit vers un autre noeud relais. Sur le chemin appelé � downstream � (voie descendante), qui va des noeuds esclaves vers le noeud maître, les messages sont relayés, et sont acheminés de proche en proche vers le noeud maître. A chaque passage, les champs d'adresses intermédiaires et le champ compteur de saut � Hop Count � du message relayé sont modifiés. Les champs d'adresses intermédiaires permettent d'identifier le couple � émetteur-récepteur � du relais. Le champ compteur de saut � Hop Count � est renseigné par chaque noeud émetteur ou relais avec son propre compteur de saut. Ce compteur représente la distance entre le noeud émetteur ou relais et le noeud maître du réseau. Chaque noeud relayant un paquet remplace la valeur du champ compteur de saut � Hop Count � du message reçu par sa propre valeur du compteur de saut � Hop Count �, c'est-à-dire sa distance vis-à-vis du noeud maître. Ainsi, même en cas de changement de topologie du réseau, le message est toujours représentatif de la distance qui lui reste à parcourir pour atteindre le noeud maître. Un message émis d'un noeud esclave vers le maître peut être acquitté par le maître. Sur le chemin appelé � upstream � (voie montante), qui va du noeud maître 20 vers les noeuds esclaves, les acquittements générés par le noeud maître sont relayés, et sont acheminés de proche en proche vers le noeud esclave. La différence avec le mode � downstream � réside dans la gestion du compteur de saut � Hop Count �. Ainsi, dans le mode � upstream �, le compteur de saut est incrémenté à chaque passage par un noeud intermédiaire, sa valeur 25 initiale lors de l'émission par le noeud maître étant de 0. Pour éviter les collisions dans ce type de réseau, le système prévoit de retarder l'émission de données par un noeud si celui-ci détecte une transaction en cours. Un noeud détecte une transaction en cours par la réception de messages ou d'acquittements, soit parce qu'il est désigné comme relais, soit parce qu'il reçoit 30 un message bien que celui-ci soit à relayer par un autre noeud. Lors de la réception d'un message, un noeud intermédiaire lit la valeur du champ compteur de saut � Hop Count � et en déduit un temps d'attente. Ce temps d'attente est représentatif du délai nécessaire à ce message pour atteindre le noeud maître et, si besoin, pour revenir sous forme d'acquittement. Pendant tout ce temps, le noeud relais s'interdit toute communication non liée à la transaction en cours. Cette technique présente un certain nombre d'inconvénients dont les principaux sont : la non robustesse aux changements de topologie du réseau, et son application impossible à la diffusion (� broadcast � en anglais). En effet, un changement de topologie intervenant après le calcul d'un temps d'attente par un noeud intermédiaire fausse le calcul de temps d'attente, ce qui peut introduire des collisions, et donc des erreurs de transmission. De plus, le temps d'attente calculé ne prend en compte qu'un chemin direct du noeud relais vers le noeud maître, avec un chemin retour si besoin. Or, ce temps d'attente calculé n'est pas significatif de la durée effective de toute la transaction, mais d'une partie seulement de la transaction. En effet, un message transmis dans un mode de type � broadcast �, ou diffusé, emprunte des chemins différents pour atteindre l'ensemble des noeuds du réseau. 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 transmission des données qui combine une optimisation de l'occupation de bande passante par des informations de contrôle et une fiabilité de transmission, notamment pendant des phases d'initialisation du réseau de transmission et les phases transitoires (par exemple, des phases de reconfiguration du réseau suite à un changement de conditions de transmission). Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui permette de minimiser le risque de collisions pour l'accès aux canaux virtuels de contrôle. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique de transmission qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de transmission de paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre une division du temps en cycles temporels divisés en intervalles de temps correspondant à des canaux virtuels, un noeud pouvant initier une transaction via au moins un canal virtuel de contrôle qui lui est alloué, les paquets de données d'une transaction étant relayés par au moins un noeud via le ou lesdits canaux virtuels de contrôle qui lui sont alloués. Un tel procédé est mis en oeuvre par un premier noeud du réseau et comprend des étapes consistant à : - recevoir, par un canal virtuel de contrôle, un premier paquet de données émis par un second noeud dans le cadre d'une première transaction ; - obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite première transaction ; - bloquer l'initiation, par ledit premier noeud, d'une deuxième transaction, via le ou lesdits canaux virtuels de contrôle alloués audit premier noeud, pendant au moins ladite durée de vie restante de ladite première transaction. Le principe général de l'invention s'appuie donc sur la détermination de la durée de vie d'une transaction pour mettre en attente ou non une autre transaction. L'invention permet ainsi de minimiser le risque de collisions aux accès aux canaux virtuels de contrôle, en mettant en attente une nouvelle transaction tant qu'une transaction en cours n'est pas terminée. Plus précisément, l'invention prévoit d'insérer, dans un paquet de données, une information représentative de la durée de vie de la transaction concernant le paquet en cours de transmission, et de tenir compte de cette information pour retarder ou non l'émission d'un autre paquet. Cette information est destinée à être manipulée par les noeuds devant relayer le paquet de données, que celui-ci soit un paquet de diffusion (� broadcast �) ou un acquittement d'un tel paquet. De façon avantageuse, le procédé de transmission comprend en outre des étapes consistant à : - décrémenter ladite information de durée de vie restante pour ladite première transaction, d'une valeur représentative de la durée d'un desdits cycles ; - si ladite durée de vie décrémentée est non nulle, relayer ledit premier paquet de données, mis à jour avec ladite information décrémentée. Ainsi, le noeud considéré met à jour l'information représentative de la durée de vie de la transaction avant d'effectuer un relais du paquet de données dans le réseau de communication. Les noeuds récepteurs de ce paquet de données peuvent ainsi obtenir une information mise à jour, et déterminer eux-mêmes la durée restante de la transaction en cours. Le paquet n'est pas relayé dans le cas où la durée de vie de la transaction arrive à expiration. Ainsi, l'influence de la transaction dans les conflits d'accès aux canaux virtuels de contrôle est maîtrisée, et est limitée à la durée de vie de la transaction telle qu'indiquée dans le paquet et partagée par les noeuds récepteurs du paquet. Avantageusement, ladite étape consistant à relayer ledit premier paquet comprend une étape consistant à vérifier si ledit premier paquet reçu a déjà été relayé par ledit premier noeud, et ladite étape consistant à relayer ledit premier paquet est mise en oeuvre si ladite vérification est négative. Ainsi, l'invention permet d'optimiser l'occupation de la bande passante dans le réseau de communication synchrone en ce qu'un même noeud ne relaie pas plusieurs fois un même paquet. En effet, l'invention prévoit de tracer, ou suivre, les paquets déjà relayés par chaque noeud, de façon à pouvoir vérifier si un paquet a déjà été relayé ou non. Cette traçabilité des paquets déjà relayés par un noeud peut être faite sous la forme d'une table stockant des informations sur les paquets relayés. Avantageusement, ladite étape consistant à bloquer l'initiation d'une seconde transaction comprend une sous-étape consistant à mettre en attente un deuxième paquet de données, pendant une durée égale à ladite durée de vie restante de ladite première transaction majorée d'une valeur déterminée, ledit deuxième paquet appartenant à ladite deuxième transaction. Ainsi, dans le cas où le noeud relais est confronté à une situation dans laquelle il doit relayer un paquet reçu tout en ayant des données propres à émettre, ce noeud relais peut mettre en attente, en les stockant, ces données propres, pendant la durée de vie de la transaction du paquet reçu, majorée d'un valeur déterminée, qui peut être aléatoire ou pseudo-aléatoire. De cette manière, si plusieurs noeuds mettent en attente leur propre transaction à cause d'une transaction en cours, ils vont tenter d'initier leur propre transaction une fois la transaction en cours terminée et un délai supplémentaire écoulé, différent pour chaque noeud. Ainsi, les différents noeuds ne vont pas tenter d'initier leur propre transaction au même moment, et les collisions seront limitées pour les prochaines transactions. De façon avantageuse, le procédé de transmission comprend des étapes consistant à : - recevoir, par un canal virtuel de contrôle, un troisième paquet de données émis par un troisième noeud dans le cadre d'une troisième transaction ; - obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite troisième transaction ; - comparer ladite durée de vie restante de ladite troisième transaction à ladite durée de vie restante de ladite deuxième transaction ; - bloquer l'initiation, par ledit premier noeud, de ladite deuxième transaction, pendant au moins ladite durée de vie restante de ladite troisième transaction, si ladite comparaison est positive. Ainsi, la durée de mise en attente (ou de non émission) d'une transaction devant être initiée par le noeud considéré est mise à jour suite à la réception d'un paquet issu d'une autre transaction de durée supérieure. Il est en effet possible que plusieurs transactions soient en diffusion concurrente sur le réseau de communication : les noeuds initiateurs des transactions les ont initiées dans le même cycle de transmission, ou le noeud ayant initié la transaction ultérieure n' avait pas encore connaissance de l'existence de la transaction antérieure (par exemple à cause d'un masquage) avant d'initier la transaction ultérieure. Selon une caractéristique avantageuse, ladite information de durée de vie de transaction restante correspond à un nombre de cycles. Ainsi, l'information de durée de vie d'une transaction est directement interprétable comme un nombre de cycles de transmission du réseau synchrone. Ces cycles étant identiques pour tous les noeuds du réseau (les noeuds esclaves sont synchronisés sur une horloge générée par le noeud maître), l'information de durée de vie correspond donc à une même valeur pour tous les noeuds du réseau qui l'interprètent. De plus, c'est une information simple à déterminer (contrairement à l'horodatage des données ou � time stamping � en anglais) et à exploiter, qui nécessite un champ de taille minime pour être transmise dans le réseau. Dans un mode de réalisation avantageux de l'invention, une durée de vie d'une transaction correspond, pour un paquet, à un nombre de cycles comprenant : - un nombre minimal de cycles nécessaires à la transmission dudit paquet à partir d'un noeud source vers au moins un noeud destinataire ; et - un nombre minimal de cycles nécessaires à la transmission d'un acquittement dudit noeud destinataire vers ledit noeud source. Ainsi, une transaction prend en compte, pour un paquet, le ou les relais du paquet d'origine (effectués par le ou les noeuds relais du réseau), jusqu'à la réception par le ou les noeuds destinataires, ainsi que les acquittements (effectués par les noeuds destinataires ayant reçu le paquet d'origine) et relais de ces acquittements. De cette manière, une transaction englobe non seulement les différentes étapes de la transmission d'un paquet, mais aussi les étapes de la transmission des acquittements de ce paquet, qui sont nécessaires pour déterminer le succès ou non de la transmission d'un paquet. De façon avantageuse, une valeur initiale de la durée de vie restante de la transaction est déterminée par ledit noeud source. Ainsi, on considère que le noeud source a une connaissance suffisante de la topologie du réseau pour pouvoir estimer le nombre de cycles nécessaires à la transmission d'un paquet et au retour d'un acquittement pour ce paquet. De plus, dans le cas où une transaction a échoué, le noeud émetteur a la possibilité de réévaluer la durée de vie nécessaire à la transaction et peut initier à nouveau la transaction en augmentant la durée de vie indiquée dans le paquet émis. Dans un mode de réalisation particulier de l'invention, le procédé de 20 transmission met en oeuvre une gestion des collisions tenant compte d'au moins un critère de décision appartenant au groupe comprenant : - un acquittement est prioritaire par rapport à un paquet de données ; - la transaction de durée de vie la plus courte est prioritaire ; - une relation de priorité déterminée des noeuds entre eux. 25 Ainsi, l'invention permet également de gérer les éventuelles collisions non évitées pour des raisons de dysfonctionnement quelconques, et notamment dans une phase nominale d'initialisation, dans laquelle le réseau n'étant pas complètement stable, des problèmes de transmission peuvent intervenir. Dans un autre mode de réalisation, l'invention concerne un signal formé de 30 paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, caractérisé en ce qu'au moins un desdits paquets porte une information de durée de vie restante de transaction à laquelle ledit paquet appartient. 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, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission tel que décrit précédemment, 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 transmission tel que décrit précédemment. Dans autre un mode de réalisation particulier de l'invention, il est proposé un dispositif de transmission de paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre une division du temps en cycles temporels divisés en intervalles de temps correspondant à des canaux virtuels, un noeud pouvant initier une transaction via au moins un canal virtuel de contrôle qui lui est alloué, les paquets de données d'une transaction étant relayés par au moins un noeud via le ou lesdits canaux virtuels de contrôle qui lui sont alloués. Un tel dispositif est mis en oeuvre par un premier noeud du réseau et comprend : - des moyens pour recevoir, par un canal virtuel de contrôle, un premier 25 paquet de données émis par un second noeud dans le cadre d'une première transaction ; - des moyens pour obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite première transaction ; - des moyens pour bloquer l'initiation, par ledit premier noeud, d'une 30 deuxième transaction, via le ou lesdits canaux virtuels de contrôle alloués audit premier noeud, pendant au moins ladite durée de vie restante de ladite première transaction. De façon avantageuse, le dispositif de transmission comprend en outre : - des moyens pour décrémenter ladite information de durée de vie restante pour ladite première transaction, d'une valeur représentative de la durée d'un desdits cycles ; - si ladite durée de vie décrémentée est non nulle, des moyens pour relayer ledit premier paquet de données, mis à jour avec ladite information décrémentée. Avantageusement, lesdits moyens pour relayer ledit premier paquet comprennent : - des moyens pour vérifier si ledit premier paquet reçu a déjà été relayé par ledit premier noeud ; et lesdits moyens pour relayer ledit premier paquet sont activés si ladite 15 vérification est négative. Selon une caractéristique avantageuse de l'invention, lesdits moyens pour bloquer l'initiation d'une seconde transaction comprennent des moyens pour mettre en attente un deuxième paquet de données, pendant une durée égale à ladite durée de vie restante de ladite première transaction majorée d'une valeur 20 déterminée, ledit deuxième paquet appartenant à ladite deuxième transaction. Préférentiellement, le dispositif de transmission comprend : - des moyens pour recevoir, par un canal virtuel de contrôle, un troisième paquet de données émis par un troisième noeud dans le cadre d'une troisième transaction ; 25 - des moyens pour obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite troisième transaction ; - des moyens pour comparer ladite durée de vie restante de ladite troisième transaction à ladite durée de vie restante de ladite deuxième transaction ; - des moyens pour bloquer l'initiation, par ledit premier noeud, de ladite deuxième transaction, pendant au moins ladite durée de vie restante de ladite troisième transaction, si ladite comparaison est positive. De façon préférentielle, ladite information de durée de vie de transaction 5 restante correspond à un nombre de cycles. Avantageusement, une durée de vie d'une transaction correspond, pour un paquet, à un nombre de cycles comprenant : - un nombre minimal de cycles nécessaires à la transmission dudit paquet à partir d'un noeud source vers au moins un noeud destinataire ; et 10 - un nombre minimal de cycles nécessaires à la transmission d'un acquittement dudit noeud destinataire vers ledit noeud source. Selon une caractéristique avantageuse de l'invention, une valeur initiale de la durée de vie restante de la transaction est déterminée par ledit noeud source. Selon un mode de réalisation avantageux, le dispositif de transmission met 15 en oeuvre une gestion des collisions tenant compte d'au moins un critère de décision appartenant au groupe comprenant : - un acquittement est prioritaire par rapport à un paquet de données ; - la transaction de durée de vie la plus courte est prioritaire ; - une relation de priorité déterminée des noeuds entre eux. 20 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 25 décrits ci-après), et des dessins annexés, dans lesquels : - la figure 1 présente un exemple d'un système de communication à 60 GHz dans lequel peut être mis en oeuvre le procédé de transmission selon l'invention ; - la figure 2 présente un exemple d'architecture d'un module de communication synchrone (SCM) selon un mode de réalisation particulier de l'invention ; - la figure 3 décrit un exemple de la structure d'un canal virtuel � VC �, mis en oeuvre dans un système tel qu'illustré en figure 1, selon un mode de réalisation particulier de l'invention ; - la figure 4 décrit un exemple de format d'un paquet de type � broadcast � et d'un acquittement, transmis selon un mode de réalisation particulier du procédé de transmission de l'invention ; - la figure 5 présente des exemples de structures de données utilisées dans un mode de réalisation du procédé de transmission de l'invention, et pouvant être stockées dans la mémoire RAM 86 du module de communication de la figure 2 ; - la figure 6 présente un organigramme détaillant les étapes de transmission d'un paquet de � broadcast � selon un mode de réalisation du procédé de transmission de l'invention ; - la figure 7 présente un organigramme détaillant les étapes mises en oeuvre par le procédé de transmission selon un mode de réalisation de l'invention, pour une émission sur un canal virtuel de contrôle ; - la figure 8 présente un organigramme détaillant les étapes mises en oeuvre par le procédé de transmission selon un mode de réalisation de l'invention, pour une réception sur un canal virtuel de contrôle. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes 25 identiques sont désignés par une même référence numérique. On présente ci-après un exemple d'implémentation de l'invention pour un système audio 8 voies, mettant en oeuvre un système de communication à 60 GHz, constitué de neuf noeuds de transmission selon l'invention. Un tel système est représenté par la figure 1. 30 Plus particulièrement, dans un exemple d'implémentation, le système comprend : - 8 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 � en français), dont chacun est équipé de moyens de restitution de canal audio numérique (� Digital Audio Channel Amplifier � en anglais), respectivement lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b, qui intègrent un haut-parleur (� speaker � en anglais), et - un noeud 5a de type WAD (pour � Wireless Audio Decoder � en anglais, ou � décodeur audio sans fil � en français), comprenant un décodeur audio multi voies (� Surround Sound Decoder � en anglais), respectivement 5b, par exemple intégré dans un écran plat et susceptible de transmettre via le système de communication 60GHz, de manière parfaitement synchronisée, 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, intègre un module de communication synchrone, SCM, (pour � Synchronous Communication Module � en anglais), qui intègre différents moyens conformément à l'invention. On présente maintenant, en relation avec la figure 2, un exemple d'architecture du module de communication SCM, dans lequel celui-ci comprend : - un microprocesseur CPU (pour � Central Processing Unit � en anglais) 87 à qui sont associés un bloc de mémoire d'exécution RAM 86 et un bloc de mémoire non volatile ROM 85 ; - un module de communication 84. Le CPU 87 communique avec le module de communication 84 au travers d'un bloc d'interface 93 qui gère notamment les interruptions à destination du CPU 87, ainsi que les échanges de données entre les différents blocs du dispositif de communication 84 et le CPU 87. Ainsi, à l'initialisation du système, le CPU 87 effectue le transfert des informations de configuration depuis la mémoire 85 vers le bloc d'interface 93. Un choix de configuration peut éventuellement être effectué parmi plusieurs configurations, toutes stockées en ROM 85, en fonction d'informations utilisateur sur l'application et l'environnement du système. Ces informations de configuration peuvent être par exemple le nombre de sauts (HOP) maximum autorisés pour une transaction. Le module de communication 84 assure le transfert des données synchrones entre le bloc d'interface radio 60 GHz 99 et le bloc d'interface synchrone 98 vers/depuis le module de traitement des canaux audio 82, qui se trouve être soit un moyen de restitution de canal audio numérique (pour � Digital Audio Channel Amplifier � en anglais), soit un décodeur audio multi voies (pour � Surround Sound Decoder � en anglais). Le bloc d'interface synchrone 98 comprend notamment un module de présentation de données chargé d'obtenir des données auprès d'une application émettrice (ou génératrice) de données et de fournir ou présenter des données à une application réceptrice (ou consommatrice) de données. Le bloc d'interface radio 99 correspond à la partie analogique de l'accès au média. Il est adapté pour communiquer (émettre / recevoir) au moyen d'ondes millimétriques. Le module de communication 84 assure aussi le transfert des données synchrones entre le bloc d'interface radio 60 GHz 99 et le CPU 87, sur lequel sont exécutés des programmes de gestions des canaux virtuels de contrôle. Ces programmes sont par exemple le programme, ou module, noté �TXvc � décrit en figure 7, et plusieurs occurrences du programme, ou module, noté � RXvc � décrit en figure 8. Des programmes utilisant les services de diffusion fiable offerts par les programmes � TXvc � (contrôlant l'émission) et � RXvc � (contrôlant la réception) peuvent également être exécutés par le CPU 87. Un exemple d'utilisation de ses services est décrit ci-après, en relation avec la figure 6. Il y a autant d'occurrences du programme � RXvc � qu'il y a de canaux virtuels de contrôle en réception. Le module de communication 84 assure une communication synchrone de type � TDM � avec une interface d'écriture et de lecture de canal virtuel vers le module de traitement audio et vers le CPU. Ce module peut être par exemple implémenté avec les composants 5 suivants : - un module de gestion TDM chargé d'implémenter un multiplexage temporel de type TDM au sein du noeud du réseau maillé (ce module de gestion TDM est utilisé comme une couche de transport par le module de présentation de données décrit ci-dessus) ; 10 - un module d'adaptation � MAC � permettant l'implémentation du réseau maillé sans fil et réalisant l'adaptation entre l'arrangement sous forme de canaux virtuels du module de gestion TDM décrit ci-dessus et l'arrangement sous forme de trames MAC d'un module de synchronisation MAC ci-après décrit ; 15 - un module de synchronisation MAC implémentant le protocole d'accès au média. Il est en charge de la correction d'erreurs de retransmission et de la synchronisation de l'accès au média. Dans le cas d'un noeud esclave, il fournit de la synchronisation temporelle au module de gestion TDM. Il réalise également de la modulation et de la démodulation sur les données à 20 destination d'un ou provenant d'un module radio ci-après décrit. Ce module de communication 84 peut également être implémenté sous forme de composant synchrone comme le composant � PacketTrunk-4 Plus TXC- 06010 � de la société TranSwitch (marques déposées). La mémoire RAM 86 abrite des structures de données partagées par les 25 deux modules � TXvc � et � RXvc �, décrites ci-après, en relation avec la figure 5. Ces structures de données servent à gérer la réception et le relais des différents paquets. La mémoire RAM 86 abrite aussi le compteur TA qui représente le temps d'attente avant que le noeud considéré puisse initier la prochaine transaction. Ce 30 compteur compte en nombre de cycles TDM et est décrémenté à chaque nouveau cycle TDM. Une fois arrivé à zéro, il n'est plus décrémenté. Ce compteur TA est initialisé par les modules � TXvc � et � RXvc �, comme décrit ci-après en relation avec les figures 7 et 8. Dans un système tel que décrit ci-dessus, l'ensemble de la bande passante disponible 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. Ainsi, un canal virtuel a un débit constant de 384 Kbps (kilobits par seconde). La séquence complète comprenant un échantillon de chacun des canaux virtuels disponibles constitue un cycle complet de traitement de données synchrone SDPC, dont la durée est égale à 125 �s dans le cas d'une fréquence de traitement de 8KHz des canaux virtuels. Le cycle SDPC est aussi appelé cycle TDM dans le reste de la description. Un canal audio de résolution � 96 KHz-24 bits � utilise 6 canaux virtuels, soit par exemple, pour un système complet 8 voies tel qu'illustré en figure 1 et classiquement appelé 7.1, un total de 48 canaux virtuels. Le débit utile nécessaire est alors de 18,432 Mbps (mégabit par seconde) uniquement pour le transfert de l'information audio. On ajoute, pour le transfert d'informations de contrôle, 9 canaux virtuels 20 alloués à l'ensemble des noeuds de transmission du système. Dans un tel système, un cycle TDM est donc composé de 57 canaux virtuels, soit un débit utile de 21,888 Mbps. Les canaux virtuels 48 à 56 sont utilisés pour l'échange de données relatives aux protocoles de contrôle, appelées information de contrôle, et décodés 25 puis traités par tous les noeuds de manière synchrone. Ainsi, au moins un canal virtuel est alloué à chaque module de communication synchrone, pour l'émission de ces informations de contrôle à destination de tous les autres noeuds du système. Par exemple, les canaux 48 à 56 sont alloués de la manière suivante, dans 30 le système de la figure 1 : - pour le noeud SCM#0, le - pour le noeud SCM#1, le - pour le noeud SCM#2, le - pour le noeud SCM#3, le - pour le noeud SCM#4, le - pour le noeud SCM#5, le - pour le noeud SCM#6, le - pour le noeud SCM#7, le - pour le noeud SCM#8, lecanal virtuel 48, canal virtuel 49, canal virtuel 50, canal virtuel 51, canal virtuel 52, canal virtuel 53, canal virtuel 54, canal virtuel 55, canal virtuel 56. Par exemple, un canal virtuel, tel qu'illustré en figure 3, est composé de deux champs 304 et 305. Le champ �flag � 304 commande la sémantique du champ �payload � 305. Ainsi, le champ � flag � 304 égal à 1 indique que le canal virtuel transporte 15 un symbole spécial 306. Il existe deux symboles spéciaux : le symbole � NULL � 301 et le symbole � MISSING � 302. Le symbole NULL a son champ � payload � 305 entièrement à 0, et est envoyé par le système en tant que bourrage quand aucune donnée n'est envoyée sur le canal virtuel. Ceci sert entre autre à indiquer au noeud récepteur l'absence de 20 donnée pour un cycle donné. Le symbole �MISSING � 302 a son champ � payload � 305 égal à la valeur hexadécimale � 0x555555555555 �. Ce symbole est inséré en cas de perte de donnée, c'est-à-dire en l'absence de réception pour un cycle donné (suite à un masquage par exemple). Le noeud relais ne peut alors pas relayer la donnée et 25 insère une symbole � MISSING � 302 à la place de cette donnée. Le champ � flag � 304 égal à 0 indique que le canal virtuel contient des données 303. Pour le transport des informations de contrôle et des acquittements, le système utilise le canal virtuel en mode � données utiles � (ou mode � data �) 303 30 pour segmenter et envoyer les paquets et acquittements, comme décrit ci-dessous en relation avec les figures 7 et 8. Un acquittement peut être transmis dans un seul canal virtuel � data � 303, comme illustré en figure 4. Ainsi, sur chaque noeud, à chaque cycle TDM, le module de communication synchrone SCM collecte les données écrites par le noeud local sur le ou les canaux virtuels qui lui sont alloués. Si le noeud n'a pas généré de données pour un canal virtuel donné, le module SCM y substitue un symbole de bourrage (NULL). Les données ainsi collectées à chaque cycle TDM sont émises sur le réseau synchrone, et l'acheminement de ces données est donc effectué en temps constant, 10 noté � SL � (pour � Synchronous Latency � en anglais). Ce temps constant comprend : - une étape de réception des données envoyées par l'ensemble des noeuds du réseau pendant un cycle TDM donné, - une étape de reconstitution des canaux virtuels à partir des données 15 reçues dans le cycle TDM donné, - une étape de présentation, au niveau de chaque noeud récepteur du réseau, des canaux virtuels reconstitués. Le mode de transport sans fil étant peu fiable, des données peuvent être perdues. La contrainte de latence fixe liée au réseau synchrone interdit tout 20 mécanisme de retransmission par la source, dans la mesure où cela rendrait la latence variable. Ainsi, toute donnée non reçue à temps est perdue. Pour remédier à ce manque de fiabilité, un protocole de diffusion fiable, utilisant les canaux virtuels de contrôle, est implémenté. Selon ce protocole, un paquet émis débute une transaction. Toute 25 transaction a une durée de vie fixée par le système, et se décompose de la manière suivante : - envoi d'un paquet par un noeud émetteur sur son canal virtuel de contrôle, - génération et envoi de paquets d'acquittement par les noeuds ayant 30 reçu correctement le paquet original, - envoi de copies du paquet original, c'est-à-dire relais du paquet original, par les noeuds l'ayant correctement reçu, afin d'atteindre les noeuds qui n'ont pas reçu le paquet original, - envoi de copies d'acquittements et de copies du paquet original selon la règle suivante : chaque noeud recevant le paquet original ou une copie du paquet original se doit de le retransmettre au plus une fois et de l'acquitter au plus une fois. De même, chaque noeud recevant un acquittement ou une copie d'acquittement se doit de le retransmettre au plus une fois. Une transaction est considérée comme terminée lorsque : - le noeud émetteur a reçu les acquittements de tous les noeuds du réseau, ou - le temps imparti à la transaction (sa durée de vie) est écoulé. Une transaction est donc l'ensemble formé par le paquet original, les copies du paquet original, les acquittements et les copies des acquittements. Dans un tel système, une collision apparaît si un noeud doit relayer au moins deux paquets reçus pendant le même cycle. Ces paquets étant reçus sur des canaux virtuels de contrôle distincts, chacun correspond à un noeud distinct (noeud émetteur ou noeud relais). Dans le cas d'une collision, seul un des paquets est relayé, un seul canal virtuel de contrôle étant alloué au noeud relais. Dans un mode de réalisation particulier, les autres paquets sont effacés. Dans un mode de réalisation alternatif, les autres paquets sont stockés en vue d'être relayés dans un cycle ultérieur. Cet effacement de certains paquets dans le cas de collisions diminue la probabilité que les transactions associées aux paquets effacés réussissent. Cela augmente donc la probabilité de renouvellement des transactions non réussies et augmente donc encore le risque de collisions, et ainsi de suite. La présente invention a notamment pour objectif, selon au moins un mode de réalisation, de diminuer fortement le risque de collisions dans un tel système. Le principe général de l'invention repose donc, pour chaque noeud, sur les moyens suivants : - détermination de la durée de vie des transactions ; - mémorisation de la durée de vie la plus longue ; - autorisation pour le noeud de générer une nouvelle transaction uniquement si : o aucune transaction en cours n'est observée ; o la durée de vie la plus longue des transactions observées est révolue. Le temps imparti à une transaction, ou durée de vie, est fixé en termes de nombre cycles d'existence autorisés pour une transaction donnée, ce qui correspond, dans le mode de réalisation particulier détaillé ici, à un maximum de sauts (HOP) ou relais autorisés pour une transaction donnée. Ceci est matérialisé par le champ � Hop Credit � présent dans les entêtes du paquet original, des copies du paquet original, des acquittements et des copies des acquittements. Par exemple, dans un mode de réalisation, la valeur du champ � Hop Credit � est représentative du nombre de relais successifs que le paquet et un acquittement de ce paquet peuvent subir. Elle est aussi représentative du nombre de cycles (un relais par cycle) successifs pendant lesquels le paquet et un acquittement de ce paquet peuvent transiter dans le réseau. Dans un autre mode de réalisation, dans lequel des paquets sont mis en attente pour être relayés ultérieurement, la valeur du champ � Hop Credit � doit être mise à jour en conséquence avant transmission (relais) du paquet : la valeur du champ � Hop Credit � doit être décrémentée du nombre de cycles d'attente que le paquet a subi avant d'être relayé par le noeud relais. La valeur du champ � Hop Credit � est alors uniquement représentative du nombre de cycles, et non du nombre de relais (un relais peut prendre plusieurs cycles), successifs pendant lesquels le paquet et un acquittement de ce paquet peuvent transiter dans le réseau. On présente maintenant, en relation avec la figure 4, un exemple de format d'un paquet d'informations de contrôle et d'acquittement. Un paquet d'informations de contrôle est un paquet constitué d'un entête de 24 bits 400 et d'une partie utile (ou �payload � en anglais) 401 de taille variable, la taille maximum étant limitée par la capacité des mémoires tampons (ou � buffers � en anglais) de la RAM 86 (figure 2) et par la taille du champ � size � 405. Pour un paquet d'acquittement, l'entête 400 est identique à l'entête du paquet qu'il acquitte, sauf pour le champ � packet type � 402. La � payload � 401 d'un paquet d'acquittement est de taille 6 bits et contient l'identifiant du noeud émetteur de l'acquittement. Les champs de l'entête 400 sont les suivants : - � Packet type � 402: 1 bit (pour un paquet d'informations de contrôle ou un acquittement) ; - � Node ID � 403 : 6 bits : il représente l'identifiant du noeud qui a émis le paquet d'informations de contrôle à l'origine. Il ne s'agit ni de l'identifiant du noeud qui relaie le paquet ni de l'identifiant du noeud qui l'acquitte ; - � Unique ID � 404 : 6 bits : il représente l'identifiant généré par le noeud à l'origine du paquet d'informations de contrôle. Cet identifiant est attribué de manière unique localement par le noeud à l'origine du paquet d'informations de contrôle et, combiné à l'identifiant du noeud émetteur (� Node ID �), il constitue un identifiant unique dans le réseau pour la transaction ; - � Size � 405 : 7 bits : il représente la taille du paquet en nombre de canaux virtuels (48 bits) ; - � Hop Credit � 406 : 4 bits : il représente la durée de vie restante de la transaction. Le paquet original comprend donc, dans son entête, le champ � Hop 30 Credit �, représentatif de la durée de vie restante de la transaction. Dans un mode de réalisation particulier de l'invention, ce champ indique le nombre maximum de sauts (ou � hops �) autorisés restants pour la transaction à laquelle le paquet appartient. Chaque copie de paquet reprend la valeur du champ � Hop Credit � du 5 paquet reçu, décrémentée de un. Ainsi, à chaque relais (ou saut), la valeur du champ � Hop Credit � diminue. Chaque acquittement reprend également la valeur du champ � Hop Credit � du paquet à acquitter, décrémentée de un. 10 Chaque copie d'acquittement reprend la valeur du champ � Hop Credit � de l'acquittement reçu, décrémentée de un. Tout paquet ou acquittement reçu avec un champ � Hop Credit � égal à 1 n'est pas relayé, car après décrémentation, sa valeur est égale à 0, et donc sa durée de vie restante est nulle. La transaction est donc terminée. 15 Ainsi, quel que soit le nombre de paquets et d'acquittements générés par une transaction, elle est achevée après un temps connu et maîtrisé qui correspond à un nombre fixe de sauts autorisés, ou de cycles TDM autorisés, selon le mode de réalisation mise en oeuvre. Comme indiquée précédemment, une transaction est identifiée de manière 20 unique dans le réseau par la combinaison de deux identifiants notés �Node Id � et � Unique Id �. � Node Id � est l'identifiant du noeud émetteur du paquet original et � Unique Id � est un identifiant unique au niveau (localement) de ce même noeud émetteur. 25 Toute copie du paquet original, ainsi que tout acquittement et copie d'acquittement, reprend dans son entête ces deux identifiants. Pour un acquittement, l'identifiant du noeud émetteur de l'acquittement se trouve non pas dans l'entête mais dans la partie utile (notée �payload �) du paquet d'acquittement (comme précisé ci-dessus en relation avec la figure 4). Tous les paquets sont transmis par un noeud donné au travers de son canal virtuel de contrôle. Comme indiqué précédemment, un canal virtuel a une capacité de 48 bits et peut être écrit à chaque cycle TDM. Pour envoyer un paquet de plus de 48 bits sur un canal virtuel, il faut le segmenter en plusieurs portions de 48 bits qui sont envoyées sur autant de cycles TDM successifs que nécessaire. L'envoi d'un paquet en plusieurs cycles ne doit pas être interrompu par un autre envoi. Quand un canal virtuel est utilisé pour l'envoi d'un paquet, il doit donc être inaccessible pour d'autres usages. En réception, pour reconstituer un paquet, on détecte d'abord le début du paquet, afin d'en lire l'entête, qui contient l'information de taille du paquet, exprimée en nombre de cycles TDM. Dans le cas où plusieurs canaux virtuels de contrôle seraient affectés à un même noeud, ce champ serait alors représentatif d'un nombre d'instances de canaux virtuels utilisés dans le temps pour la transmission du paquet par un même noeud. Le début d'un paquet n'est pas marqué ou signalé d'une façon particulière. Par contre, un canal virtuel inutilisé dans un cycle TDM présente quand même des symboles de bourrage (symboles � NULL � comme illustré en figure 3), insérés par le module de communication SCM. Ces symboles NULL forment donc un séparateur de paquet, et un noeud va pouvoir par exemple détecter un premier début de paquet en guettant ces symboles NULL. Une fois le premier symbole NULL reçu, il suffit d'attendre de recevoir une première donnée sur le canal virtuel, pendant les cycles TDM suivants, cette première donnée correspondant au début d'un paquet. Cependant, les paquets de données peuvent également être envoyés les uns à la suite des autres et ne sont donc pas nécessairement séparés par des symboles NULL. Dans ce cas, un noeud peut détecter le début du paquet suivant grâce à sa 30 connaissance de la longueur du paquet en cours de réception, et peut donc ainsi identifier la dernière donnée du paquet en cours de réception. Si cette dernière donnée est suivie d'une autre donnée, celle-ci correspond donc au début d'un autre paquet. Ainsi, une fois détecté un début de paquet, un noeud peut détecter le début des prochains paquets comme étant la donnée qui suit la dernière donnée reçue pour le paquet en cours de réception, ou bien la donnée qui suit un ou plusieurs symboles NULL. On présente maintenant, en relation avec la figure 5, des exemples de structures de données utilisées dans un mode de réalisation du procédé de transmission de l'invention, notamment dans les programmes décrits ci-après en relation avec les figures 7 et 8, et pouvant par exemple être stockées dans la mémoire RAM 86 d'un module de communication SCM. La table de relais 500 est une structure gérée par les deux modules � TXvc � et � RXvc � et sert à mémoriser les paquets déjà relayés par le noeud 15 considéré. En effet, un même paquet peut être relayé par différents noeuds du réseau synchrone et peut donc être reçu plusieurs fois par un même noeud. Afin de ne pas surcharger le réseau par des relais multiples d'un même paquet, il est important qu'un noeud ne relaye qu'une seule fois un même paquet. 20 Cette table possède donc plusieurs entrées identiques 506, 507 et 508. Chaque entrée correspond à un paquet et est validée lorsque que le paquet correspondant est relayé par le noeud considéré. Cette même entrée est invalidée à l'expiration d'une temporisation (ou � timer � en anglais) 505, correspondant à la durée de vie de la transaction dont fait partie le paquet relayé. 25 Le nombre maximum d'entrées de cette table définit donc le nombre maximum de transactions concurrentes que peut gérer le noeud considéré. Pour une entrée donnée : - le champ 501 est un bit qui indique la validité de l'entrée (1 valide, 0 libre) ; - les champs 502, 503 et 504 sont directement issus des champs 402, 403 et 404 de l'entête du paquet (illustré en figure 4) ; - le champ � timer � 505 est déterminé par le module �TXvc � à partir du champ � Hop Credit � 406 du paquet qui a permis de détecter la transaction, comme décrit ci-après en relation avec la figure 7. La requête de relais 510 est une structure de données échangée entre les modules � RXvc � et � TXvc �, au travers de FIFOs 530 (une par module � RXvc �). Une requête de relais comporte les champs nécessaires au module � TXvc � pour gérer le relais d'un paquet. Les champs 513, 514, 515 et 511 sont directement les champs 403, 404, 406 et 405 de l'entête du paquet à relayer. Le champ � buffer @ � 517 contient l'adresse de la mémoire � buffer RAM � dans laquelle le module � RXvc � a stocké le paquet à relayer. Les FIFOs 530 (mémoires du type � premier entré, premier sorti �), utilisées en plusieurs exemplaires entre le module � TXvc � et les différentes occurrences du module � RXvc �, sont des FIFOs qui suivent le rythme du cycle TDM, c'est-à-dire qu'elles rendent disponible une requête écrite lors d'un cycle TDM N uniquement au cycle suivant N+l. On présente maintenant, en relation avec la figure 6, un exemple des principales étapes d'un envoi d'un paquet de diffusion (ou �broadcast � en anglais), selon un mode de réalisation de l'invention, dans le cadre de protocole fiable tel que des protocoles d'allocation de canaux virtuels dans un système synchrone. Lors d'une étape 600, un paquet de � broadcast � synchrone, ou � broadcast �, est généré. Lors de l'étape suivante 601, une demande de diffusion de ce � broadcast � est générée vers le module d'émission qui gère le canal virtuel de contrôle, par l'intermédiaire du module � TXvc �. Au bout d'un cycle TDM au maximum, une réponse est générée par le module �TXvc �, qui examine les demandes de transfert à chaque nouveau cycle TDM, et les rejette en cas d'occupation du canal virtuel de contrôle par un autre transfert (comme précisé ci-après en relation avec la figure 7). Lors du test 602, la réponse du module � TXvc � est examinée : - si la réponse est positive, on passe à l'étape 605, - sinon, lors de l'étape 603, on obtient de la part du module � TXvc � le temps d'attente avant la fin de la transaction en cours. La détermination du temps d'attente est décrite ci-dessous en relation avec la figure 7. Ce temps d'attente est représentatif du temps total que doit durer la transaction en cours dans le réseau synchrone (et non pas du temps d'occupation du canal virtuel de contrôle). De ce fait, le �broadcast � généré lors de l'étape 600 n'est pas transmis sur le réseau synchrone tant que la transaction en cours n'est pas finie, ce qui a pour avantage de diminuer fortement le risque de collision dans les noeuds relais du réseau. Une fois le temps d'attente obtenu, celui-ci est modifié afin d'obtenir un temps d'attente différent sur chaque noeud du réseau (par exemple le temps d'attente peut être augmenté d'une valeur choisie aléatoirement, ou bien d'une valeur dépendant du numéro du noeud courant), de manière à ce que les noeuds relais n'émettent pas tous en même temps, à la fin d'un même temps d'attente, les différents � broadcast � mis en attente. Le � broadcast � est donc mis en attente lors de l'étape 604, et une nouvelle tentative de transfert du � broadcast � est effectuée à l'étape 601, à l'expiration du temps d'attente. En cas de réponse positive lors du test 602, la transaction est acceptée par le module � TXvc � et la durée de vie de la transaction est notifiée par le module � TXvc � (comme décrit en relation avec la figure 7). Lors de l'étape 605, le noeud considéré se met en attente des acquittements, cette attente étant bornée par la durée de vie de la transaction. On détermine, lors du test 606, si la durée de vie de la transaction a expiré ou si le noeud considéré a reçu un acquittement. Le cas où la durée de vie de la transaction a expiré indique que la transaction a échoué, et une notification d' erreur est générée vers l'application cliente, lors de l'étape 608. Si le test 606 détermine qu'un acquittement envoyé par le module � RXvc � (comme décrit en relation avec la figure 8) a été reçu, alors l'acquittement est sauvegardé en mémoire RAM lors d'une étape 607. Il s'agit ensuite de déterminer si tous les noeuds du réseau ont bien reçu le � broadcast � émis, en analysant (par exemple en comptant), lors du test 609, les acquittements reçus. Si tous les acquittements ont été reçus, la transaction est achevée et une notification est envoyée à l'application cliente lors de l'étape 610. Si tous les acquittements n'ont pas été reçus, le noeud considéré se remet en attente d'une indication de fin de transaction ou d'une réception d'acquittement (étape 605). La figure 7 illustre un exemple d'algorithme mis en oeuvre par un module � TXvc � pour une émission sur un canal virtuel de contrôle, selon un mode de réalisation de l'invention. Ce module � TXvc � est en charge de la gestion du canal virtuel de contrôle. Il gère d'une part la segmentation des paquets produits par le noeud courant, et d'autre part la retransmission de paquets ou d'acquittements reçus sur les canaux virtuels de contrôle. Ce module est cadencé au rythme du cycle TDM : à chaque cycle TDM, le canal virtuel de contrôle est écrit et envoyé sur le réseau synchrone. Par défaut, chaque noeud du réseau gère un canal virtuel de contrôle en mode écriture et autant de canaux virtuels de contrôle en lecture qu'il y a de noeuds distants. Lors de l'étape 700, le module � TXvc � est en attente d'un nouveau cycle TDM. Une fois le nouveau cycle TDM commencé, lors du test 701, les FIFOs 530 (figure 5) sont inspectées, afin de savoir si des requêtes de relais sont à traiter. Ces requêtes correspondent par exemple à des � broadcast � ou des acquittements reçus pendant le cycle TDM précédent, comme décrit ci-dessous en relation avec la figure 8. L'état des requêtes de relais est testé en priorité par rapport aux requêtes de transfert, car le principe est de terminer en priorité les transactions en cours avant d'en initier de nouvelles. Donc, en cas de présence d'une requête de relais dans une des FIFO de 10 relais 530, le module �TXvc � obtient, à l'étape 702, la valeur du champ � Hop Credit � 512 de la requête de relais. Cette valeur est décrémentée de un (ceci correspond à la durée du traitement effectué par le noeud considéré pour effectuer le relais), puis comparée à zéro lors du test 703, afin de savoir si la transaction en cours est arrivée en fin de 15 vie ou non. Si la nouvelle valeur de � Hop Credit � ainsi déterminée est nulle, cela veut dire que la transaction en cours a atteint la fin de sa durée de vie et la mémoire tampon (buffer RAM) associée est libérée lors de l'étape 704. Le module � TXvc � reboucle sur le test 701 pour déterminer s'il y a 20 d'autres requêtes de relais. En effet, à chaque cycle TDM, il peut y avoir autant de requêtes de relais qu'il y a de canaux virtuels de contrôle en mode réception. Le test 701 permet donc de détecter toutes les requêtes correspondant à chaque canal virtuel de contrôle en réception lors d'un même cycle TDM. 25 Dans un mode d'implémentation avantageux, les requêtes de relais peuvent être triées selon leur durée de vie, indiquée par le champ � Hop Credit � 406. Le module � TXvc � peut alors choisir par exemple de favoriser les paquets en fin de vie afin de maximiser les chances de réussite de la transaction associée. Dans un autre mode d'implémentation, on peut envisager en plus de favoriser les relais de paquets plutôt que les relais d'acquittements afin de privilégier la diffusion du paquet. Dans le cas où le test 703 est positif, la transaction est encore active et donc la requête de relais en cours est à traiter, c'est-à-dire à envoyer sur le canal virtuel de contrôle du noeud courant (décrit ci-dessous à partir du test 728). Dans le cas où le test 701 indique qu'aucune requête de relais n'est à traiter, alors le module � TXvc � vérifie, par le test 705, si une requête de transfert d'un � broadcast � synchrone par le noeud considéré est à traiter. S'il n'y a pas de requête de transfert, le module �TXvc � se remet en attente d'un nouveau cycle TDM, à l'étape 700. Dans le cas où le test 705 est positif, c'est-à-dire qu'il y a une requête de transfert à traiter, le module � TXvc � vérifie, par le test 706, si une transaction en cours, non terminée, a été enregistrée. Cette information de transaction en cours est matérialisée par un compteur de temps d'attente TA, remis à jour lors de l'envoi d'un nouveau �broadcast� synchrone, ou lors de la réception d'un paquet, comme décrit en figure 8. La règle de mise à jour du compteur TA est simple : si la nouvelle transaction a une durée de vie supérieure à la dernière durée de vie enregistrée, alors le compteur TA est mis à jour (étapes 708 de la figure 7 et 809 de la figure 8). Dans le cas où le test 706 indique une transaction en cours (TA > 0), la requête de transfert est rejetée lors de l'étape 709, et le module �TXvc� notifie comme temps d'attente TA la durée de vie restante de la transaction en cours. Si le test 706 indique qu'il n'y a pas de transaction en cours, alors le demandeur est notifié, à l'étape 707, que la requête de transfert est acceptée, et que la transaction est initiée. Lors de l'étape 708, la durée de vie de cette nouvelle transaction est obtenue en fonction de la taille du � broadcast � synchrone et de la valeur � Hop Credit � qui va lui être attribuée. La taille du �broadcast � synchrone définit le nombre de cycles qu'il faut pour envoyer le paquet (comme indiqué précédemment, le canal virtuel étant de taille fixe, il se peut que plusieurs cycles soient nécessaires pour envoyer un paquet, portion par portion). Dans cet exemple de la figure 7, on considère que le nombre de cycles pendant lesquels une transaction est active est un paramètre du système et est fixé à 7 pour toutes les transactions. La durée de vie de la transaction est donc donnée par la formule suivante : {Durée de vie = (taille + Synchronous Latency + 1) * � Hop Credit �}, la taille étant exprimée en multiple de 48 bits, ce qui correspond dans cet exemple à la taille des données transportées dans un canal virtuel à chaque cycle TDM. Cette durée de vie correspond au cas où le � broadcast � est effectivement relayé 7 fois. La durée de vie de la transaction est communiquée au module qui a émis la requête (comme indiqué ci-dessus en relation avec les étapes 602 et 605 de la figure 6). A ce stade, le � broadcast � requis par le noeud courant, appelé � broadcast local �, est prêt à être envoyé. Cet envoi est décrit ci-après, à partir de l'étape 712. On revient maintenant au cas d'un relais d'un � broadcast �, dont la fin de vie n'est pas atteinte, c'est-à-dire dans le cas où le résultat du test 703 est positif. Le module � TXvc � doit donc relayer un paquet faisant partie d'une transaction en cours. Dans ce cas, le test 728 permet de déterminer si le paquet doit effectivement être relayé, et consiste à parcourir la table de relais 500 et à vérifier, pour les entrés valides (bit 501=1), si les identifiants 502, 503, 504 sont égaux aux identifiants de la requête de relais 513, 514, 515. Si aucune entrée ne correspond à la présente requête de relais (le paquet n'a pas déjà été relayé), et s'il reste une entrée non utilisée dans la table (bit 501=0), alors le paquet peut être relayé. Si le résultat du test est négatif (soit le paquet a déjà été relayé soit il n'y 30 plus de place dans la table de relais 500 pour enregistrer les identifiants d'un nouveau paquet), le module � TXvc � repasse à l'étape 704 précédemment décrite. Si le résultat du test 728 est positif, la table de relais 500 est mise à jour lors de l'étape 726, pour indiquer qu'un paquet va être relayé, afin qu'il ne soit pas à nouveau relayé par le noeud considéré ultérieurement. La mise à jour consiste à : - remplir les champs 502, 503, 504 d'une entrée non utilisée avec les champs 513, 514, 515 de la requête de relais ; - renseigner le champ � timer � par la durée de vie maximale de la 10 transaction représentée par le paquet en cours soit {� Hop Credit � 512 * [ � size � 516 + Synchronous Latency + 1]1 ; - mettre le bit 501 à 1. Comme décrit précédemment en relation avec la figure 5, à l'expiration de la temporisation (ou �timer �) 505, le bit 501 repasse à 0, libérant ainsi l'entrée 15 correspondante dans la table. L'étape suivante 710 consiste à déterminer si une requête de transfert d'un �broadcast � local (c'est-à-dire initié par le noeud considéré) est formulée. Si c'est le cas, cette requête est refusée, lors de l'étape 711, le relais d'un � broadcast � étant prioritaire. Comme décrit ci-après en relation avec la figure 8, 20 le temps d'attente correspondant TA déjà déterminé par le module �RXvc� est passé en argument du refus. Lors de l'étape 720, toutes les autres requêtes de relais effectuées durant le même cycle sont � purgées �, c'est-à-dire que les FIFOs de requêtes 530 sont parcourues et si elles sont non vides, la requête est lue et la mémoire tampon 25 (buffer RAM) indiquée par le champ 517 est libérée. Ensuite, le test 727 permet de déterminer s'il est nécessaire d'acquitter le paquet qui va être relayé. Si le type du paquet 513 indique un acquittement, alors l'étape 712 est directement mise en oeuvre. Si le type du paquet 513 indique un �broadcast �, alors un acquittement est généré, lors de l'étape 721. Pour générer un acquittement correspondant au paquet à relayer, un entête 400 est construit, de la manière suivante : - � message type � 402 : � acquittement � ; - � Node ID � 403 : le champ � node ID � 514 du paquet à relayer ; - � Unique ID � 404: le champ � Unique ID � 515 du paquet à relayer ; - � Size � 405 : le champ � Size � 516 du paquet à relayer ; - � Hop Credit � 406 : résultat du calcul effectué à l'étape 702 et qui correspond à la traversée du noeud courant (ce qui revient à � Hop Credit� 512 décrémenté de 1). Ensuite, le noeud considéré insère, dans le champ � NodelD � 407, son propre identifiant, en guise de données utiles (ou � payload �) de l'acquittement. Une fois l'acquittement envoyé, le module � TXvc � se met en attente d'un 15 nouveau cycle TDM, à l'étape 722. Une fois un nouveau cycle commencé, toute nouvelle demande concernant le nouveau cycle en cours doit être rejetée. Ceci est fait lors des étapes 723, 724 et 725, qui consistent à rejeter une éventuelle requête de transfert et les requêtes de relais générées lors du cycle précédent. Nous ne revenons pas sur la description 20 détaillée de ces étapes, qui est la même que celle des étapes déjà décrites 710, 711 et 720. On repasse donc à l'étape 712, qui correspond soit à l'envoi d'un �broadcast� local (c'est-à-dire initié par le noeud considéré) qui vient d'être autorisé (on vient alors de l'étape 708), soit au relais d'un acquittement (à partir 25 du test 727), soit encore au relais d'un � broadcast � (à partir de l'étape 725). Les étapes suivantes, à partir de l'étape 712, sont donc indépendantes du type de paquet émis (� broadcast � local, � broadcast � relayé, acquittement relayé). Lors de l'étape 712, l'entête de message (tel que décrit en figure 4) est 30 généré de la façon suivante, s'il s'agit d'un � broadcast � local : - le champ � Message type � 402 prend la valeur � broadcast � ; - le champ � Node ID � 403 prend la valeur de l'identifiant du noeud considéré ; - le champ � Unique ID � 404 est obtenu à partir d'un compteur local, qui démarre à zéro lors de la mise sous tension du noeud considéré et qui est incrémenté à chaque nouveau �broadcast � généré par le noeud considéré ; - le champ � Size � 405 est renseigné avec la taille du � broadcast � ; - le champ � Hop Credit � 406 est mis à 7 par défaut. S'il s'agit d'un paquet relayé, alors les champs 402, 403, 404 et 405 sont repris tel que renseignés par le module � RXvc � dans la requête de relais, c'est-à-dire qu'ils correspondent aux champs 513, 514, 515, et 516. Le champ 406 est le résultat du calcul effectué à l'étape 702 (qui correspond à la durée du traitement effectué par le noeud considéré pour effectuer le relais), à savoir � Hop Credit � 512 décrémenté de un. Une fois l'entête de message écrit (24 bits), le reste du canal virtuel (24 bits) est complété par le début des données utiles (ou � payload �) 401 du paquet. Ces données utiles sont issues de la mémoire tampon (ou � buffer �) dont l'adresse est donnée soit par le champ 517 soit par le noeud considéré (en fonction de l'envoi à effectuer). Ensuite, le test 713 sert à vérifier si le paquet à été entièrement transmis. Si oui, le module � TXvc � se remet en attente d'un nouveau cycle et d'un nouveau transfert, à l'étape 700. Si le paquet n'a pas été entièrement transmis, il faut attendre au moins le 25 prochain cycle TDM (étape 714) pour continuer à envoyer le paquet par portions de 48 bits (taille d'un canal virtuel). La fin de transfert est immédiate pour un acquittement, dont la taille est toujours inférieure à 48 bits. Pour un � broadcast �, la fin de transfert est dépendante de la taille du paquet. Lors de l'avènement du nouveau cycle TDM à l'étape 714, une purge des nouvelles requêtes de relais est effectuée à l'étape 716, car la transmission en cours ne doit pas être interrompue. Lors du test 717, on vérifie si le noeud considéré n'a pas généré une nouvelle requête de transfert. Si le résultat du test est positif, cette requête est refusée à l'étape 718, et le temps d'attente TA est notifié. Une fois ces vérifications effectuées, la suite du paquet est écrite dans le canal virtuel de contrôle, avant de reboucler sur le test de fin de transfert 713. On présente maintenant, en relation avec la figure 8, un exemple d'algorithme mis en oeuvre par un module � RXvc � pour une réception sur un canal virtuel de contrôle, selon un mode de réalisation de l'invention. Pour chaque canal virtuel de contrôle en mode réception, ce module � RXvc � reconstitue les �broadcast � et acquittements reçus par bloc de 48 bits à chaque cycle TDM. Une fois le � broadcast � ou acquittement reconstitué, le résultat est communiqué à la couche supérieure et au module � TXvc � pour un relais si nécessaire (paquet non encore relayé par le noeud). Par la suite, on parlera de �paquets en cours de réception �, qu'il s'agisse de � broadcast � ou d'acquittement, et la nature du paquet sera précisée quand un traitement spécifique à l'un ou l'autre des types de paquets sera décrit. Au démarrage du système, le module � RXvc � se synchronise sur un début de � broadcast � ou d'acquittement, lors des étapes 880, 800 et 801. Pour ce faire, le module � RXvc � lit le canal virtuel cycle TDM après cycle TDM, jusqu'à détecter un premier symbole de bourrage de type NULL 301. Comme indiqué précédemment (en relation avec la figure 4), une fois ce premier NULL reçu, le module � RXvc � sait que le prochain canal virtuel de données 303 correspond à un début de paquet. Une fois détecté le premier symbole NULL, le module � RXvc � lit le canal virtuel de contrôle tant qu'il reçoit un NULL (étapes 802, 803, 804). A réception d'un canal virtuel non NULL, le test 805 vérifie s'il s'agit d'un symbole MISSING 302. Si tel est le cas, une donnée ou un symbole NULL a été perdue, et le module � RXvc � doit se resynchroniser sur un début de paquet (étape 880 déjà décrite). Si le test 805 est négatif, alors une donnée a été reçue, et le module � RXvc � lit l'entête 400 reçue, lors de l'étape 806. Les champs � Hop Credit � 406 et � Size � 405 de l'entête sont extraits, de façon à déterminer le temps de vie restant de la transaction liée à la donnée reçue, 10 par exemple par calcul selon la formule suivante : temps restant = (� taille �+l+Synchronous Latency) * � Hop Credit � +1. Le temps de vie restant déterminé est stocké dans la variable TR. Lors du test 808, cette variable TR est comparée au compteur TA, qui indique la durée restante de la transaction en cours la plus longue détectée par le 15 noeud considéré. Si le registre TR est supérieur au compteur TA, cela indique que la nouvelle transaction en cours de réception est plus longue, et qu'il faut mettre à jour la valeur TA. Lors de l'étape 809, la valeur TR est donc affectée au compteur TA, enregistrant ainsi la transaction en cours de réception comme étant la transaction en cours la plus longue. 20 Si le test 808 est négatif, la valeur du compteur TA reste inchangée. Lors du test 810 suivant, la table 500 des �broadcast �/acquittements déjà relayés est parcourue, afin de savoir si le �broadcast �/acquittement en cours de réception doit être relayé, ou l'a déjà été. Dans un système qui relaie les � broadcast � et les acquittements, un noeud 25 relais peut potentiellement recevoir plusieurs copies d'un même paquet. Ceci est détectable grâce aux identifiants � Packet Type � 402, � Node Id � 403 et � Unique Id � 404, identiques pour toutes les copies. Or, comme déjà indiqué, il est important de s'assurer que chaque paquet n'est relayé qu'une fois, qu'il soit de type � broadcast � ou acquittement. Si le résultat du test 810 est positif, cela indique que le paquet en cours de réception a déjà été relayé, et il doit être purgé. Ceci est effectué lors des étapes 818, 823, 824 et 825. Dans le cas d'un acquittement, la fin de paquet est atteinte dès le premier canal virtuel lu. Dans le cas d'un � broadcast �, la fin de paquet est atteinte lors de la dernière lecture du canal virtuel, le nombre de cycles de lecture du canal virtuel étant défini par la taille renseignée dans l'entête 400. Une fois la fin de paquet atteinte, le module se remet en attente d'un nouveau cycle, à l'étape 802. Dans le cas où le résultat du test 810 est négatif, c'est-à-dire que le paquet en cours de réception n'a pas déjà été relayé (les identifiants � Packet Type � 402, � Node Id � 403 et � Unique ID � 404 ne sont pas trouvés dans la table 500), il faut sauvegarder le paquet en cours de réception pour pouvoir le relayer. Cette sauvegarde consiste en une allocation de mémoire tampon (ou �buffer �) en RAM, lors de l'étape 811. Le contenu du canal virtuel est sauvegardé, entête inclus, dans la mémoire tampon ainsi obtenue. Lors du test 812, on détecte la fin du paquet (comme déjà décrit, pour un acquittement la taille correspond à un canal virtuel, pour un � broadcast �, il faut avoir lu le canal virtuel pendant un nombre de cycles TDM correspondant à la valeur indiquée dans le champ � size � 405 de l'entête 400). Si la fin du paquet n'est pas détectée, le module � RXvc � effectue les étapes 813 et 814, dans lesquelles il attend un nouveau cycle, puis lit à nouveau le canal virtuel. Si le test 816 détecte un symbole MISSING 302, et donc une perte de donnée du paquet, il faut le purger, lors de l'étape 818. Pour ce faire, la mémoire tampon précédemment allouée est libérée, puis le module � RXvc � passe à l'étape 823 pour finir de purger le paquet. Si le canal virtuel lu n'est pas un symbole MISSING 302, son contenu est sauvegardé, lors de l'étape 817, dans la mémoire tampon précédemment allouée, à la suite des données du paquet déjà reçues. On reboucle ainsi au test 812 jusqu'à réception complète du paquet. Quand la fin du paquet est détectée, une requête de relais est envoyée au module � TXvc �, lors de l'étape 815, avec en paramètre l'adresse en RAM de la mémoire tampon de réception. Le test 820 permet de déterminer la nature du paquet reçu, grâce au champ � Packet Type � 402 de l'entête 400. S'il s'agit d'un �broadcast �, la réception d'un nouveau � broadcast � est notifiée à l'application cliente lors de l'étape 821, et le module � RXvc � se remet en attente d'un nouveau cycle, à l'étape 802. S'il y a plusieurs applications clientes, l'homme de métier saura aisément ajouter un module d'aiguillage des � broadcast � entre le module �TXvc � et les applications génératrices et entre le module � RXvc � et les applications réceptrices. S'il s'agit d'un acquittement, le test 819 permet de déterminer si l'acquittement concerne un � broadcast � local (généré par le noeud considéré). Ceci est possible grâce au champ � NodelD � 404 de l'entête 400. Si l'acquittement ne concerne pas un � broadcast � local, il n'y aucun traitement supplémentaire à faire et le module � RXvc � se remet en attente d'un nouveau cycle, l'étape 802. Si l'acquittement concerne un � broadcast � local, le module � TXvc � est 20 notifié de la réception de l'acquittement, à l'étape 822, comme décrit précédemment en relation avec la figure 6. REVENDICATIONS1. Procédé de transmission de paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre une division du temps en cycles temporels divisés en intervalles de temps correspondant à des canaux virtuels, un noeud pouvant initier une transaction via au moins un canal virtuel de contrôle qui lui est alloué, les paquets de données d'une transaction étant relayés par au moins un noeud via le ou lesdits canaux virtuels de contrôle qui lui sont alloués, ledit procédé étant mis en oeuvre par un premier noeud du réseau et caractérisé en 10 ce qu'il comprend des étapes consistant à : - recevoir (701), par un canal virtuel de contrôle, un premier paquet de données émis par un second noeud dans le cadre d'une première transaction ; - obtenir, à partir dudit paquet, une information (406) de durée de vie 15 restante pour ladite première transaction ; - bloquer (711) l'initiation, par ledit premier noeud, d'une deuxième transaction, via le ou lesdits canaux virtuels de contrôle alloués audit premier noeud, pendant au moins ladite durée de vie restante de ladite première transaction. 20 2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'il comprend en outre des étapes consistant à : - décrémenter (702) ladite information de durée de vie restante pour ladite première transaction, d'une valeur représentative de la durée d'un desdits cycles ; 25 - si ladite durée de vie décrémentée est non nulle (703), relayer ledit premier paquet de données, mis à jour avec ladite information décrémentée. 3. Procédé de transmission selon la revendication 2, caractérisé en ce que ladite étape consistant à relayer ledit premier paquet comprend une étape consistant à :- vérifier (728) si ledit premier paquet reçu a déjà été relayé par ledit premier noeud ; et en ce que ladite étape consistant à relayer ledit premier paquet est mise en oeuvre si ladite vérification est négative. 4. Procédé de transmission selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite étape consistant à bloquer l'initiation d'une seconde transaction comprend une sous-étape consistant à mettre en attente un deuxième paquet de données, pendant une durée égale à ladite durée de vie restante de ladite première transaction majorée d'une valeur déterminée, ledit deuxième paquet appartenant à ladite deuxième transaction. 5. Procédé de transmission selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend des étapes consistant à : - recevoir, par un canal virtuel de contrôle, un troisième paquet de données émis par un troisième noeud dans le cadre d'une troisième transaction ; - obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite troisième transaction ; - comparer ladite durée de vie restante de ladite troisième transaction à ladite durée de vie restante de ladite deuxième transaction ; - bloquer l'initiation, par ledit premier noeud, de ladite deuxième transaction, pendant au moins ladite durée de vie restante de ladite troisième transaction, si ladite comparaison est positive. 6. Procédé de transmission selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite information de durée de vie de transaction restante correspond à un nombre de cycles. 7. Procédé de transmission selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'une durée de vie d'une transaction correspond, pour un paquet, à un nombre de cycles comprenant : - un nombre minimal de cycles nécessaires à la transmission dudit paquet à partir d'un noeud source vers au moins un noeud destinataire ; et- un nombre minimal de cycles nécessaires à la transmission d'un acquittement dudit noeud destinataire vers ledit noeud source. 8. Procédé de transmission selon la revendication 7, caractérisé en ce qu'une valeur initiale de la durée de vie restante de la transaction est déterminée par ledit noeud source. 9. Procédé de transmission selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il met en oeuvre une gestion des collisions tenant compte d'au moins un critère de décision appartenant au groupe comprenant : - un acquittement est prioritaire par rapport à un paquet de données ; - la transaction de durée de vie la plus courte est prioritaire ; - une relation de priorité déterminée des noeuds entre eux. 12. Signal transmis selon le procédé de transmission selon l'une quelconque des revendications 1 à 9, formé de paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, caractérisé en ce qu'au moins un desdits paquets porte une information (406) de durée de vie restante de transaction à laquelle ledit paquet appartient. 13. 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 la mise en oeuvre du procédé de transmission selon au moins une des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur. 14. 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 transmission selon au moins une des revendications 1 à 9. 15. Dispositif de transmission de paquets de données dans un réseau de communication synchrone comprenant une pluralité de noeuds, ledit réseau mettant en oeuvre une division du temps en cycles temporels divisés 30 en intervalles de temps correspondant à des canaux virtuels, un noeud pouvantinitier une transaction via au moins un canal virtuel de contrôle qui lui est alloué, les paquets de données d'une transaction étant relayés par au moins un noeud via le ou lesdits canaux virtuels de contrôle qui lui sont alloués, ledit dispositif étant mis en oeuvre par un premier noeud du réseau et caractérisé en 5 ce qu'il comprend : - des moyens pour recevoir, par un canal virtuel de contrôle, un premier paquet de données émis par un second noeud dans le cadre d'une première transaction ; - des moyens pour obtenir, à partir dudit paquet, une information de durée 10 de vie restante pour ladite première transaction ; - des moyens pour bloquer l'initiation, par ledit premier noeud, d'une deuxième transaction, via le ou lesdits canaux virtuels de contrôle alloués audit premier noeud, pendant au moins ladite durée de vie restante de ladite première transaction. 15 14. Dispositif de transmission selon la revendication 13, caractérisé en ce qu'il comprend en outre : - des moyens pour décrémenter ladite information de durée de vie restante pour ladite première transaction, d'une valeur représentative de la durée d'un desdits cycles ; 20 - si ladite durée de vie décrémentée est non nulle, des moyens pour relayer ledit premier paquet de données, mis à jour avec ladite information décrémentée. 15. Dispositif de transmission selon la revendication 14, caractérisé en ce que lesdits moyens pour relayer ledit premier paquet comprennent : 25 - des moyens pour vérifier si ledit premier paquet reçu a déjà été relayé par ledit premier noeud ; et en ce que lesdits moyens pour relayer ledit premier paquet sont activés si ladite vérification est négative. 16. Dispositif de transmission selon l'une quelconque des revendications 13 à 30 15, caractérisé en ce que lesdits moyens pour bloquer l'initiation d'une secondetransaction comprennent des moyens pour mettre en attente un deuxième paquet de données, pendant une durée égale à ladite durée de vie restante de ladite première transaction majorée d'une valeur déterminée, ledit deuxième paquet appartenant à ladite deuxième transaction. 17. Dispositif de transmission selon l'une quelconque des revendications 13 à 16, caractérisé en ce qu'il comprend : - des moyens pour recevoir, par un canal virtuel de contrôle, un troisième paquet de données émis par un troisième noeud dans le cadre d'une troisième transaction ; - des moyens pour obtenir, à partir dudit paquet, une information de durée de vie restante pour ladite troisième transaction ; - des moyens pour comparer ladite durée de vie restante de ladite troisième transaction à ladite durée de vie restante de ladite deuxième transaction ; - des moyens pour bloquer l'initiation, par ledit premier noeud, de ladite deuxième transaction, pendant au moins ladite durée de vie restante de ladite troisième transaction, si ladite comparaison est positive. 18. Dispositif de transmission selon l'une quelconque des revendications 13 à 17, caractérisé en ce que ladite information de durée de vie de transaction restante correspond à un nombre de cycles. 19. Dispositif de transmission selon l'une quelconque des revendications 13 à 18, caractérisé en ce qu'une durée de vie d'une transaction correspond, pour un paquet, à un nombre de cycles comprenant : - un nombre minimal de cycles nécessaires à la transmission dudit paquet à partir d'un noeud source vers au moins un noeud destinataire ; et - un nombre minimal de cycles nécessaires à la transmission d'un acquittement dudit noeud destinataire vers ledit noeud source. 20. Dispositif de transmission selon la revendication 19, caractérisé en ce qu'une valeur initiale de la durée de vie restante de la transaction est déterminée par ledit noeud source.21. Dispositif de transmission selon l'une quelconque des revendications 13 à 20, caractérisé en ce qu'il met en oeuvre une gestion des collisions tenant compte d'au moins un critère de décision appartenant au groupe comprenant : - un acquittement est prioritaire par rapport à un paquet de données ; - la transaction de durée de vie la plus courte est prioritaire ; - une relation de priorité déterminée des noeuds entre eux.