FR2949030A1 - Procede et dispositif de synchronisation d'applications dans un reseau - Google Patents

Abstract

Le procédé de synchronisation s'applique à un réseau comportant des sous-réseaux synchrones reliés entre eux par des commutateurs, pour la communication de données transmises sur une pluralité de chemins allant, chacun, d'une application source à une application destination. Le procédé comporte : - pour chaque dit chemin, une étape de détermination de la somme des déphasages successifs introduits par les commutateurs présents sur ledit chemin, et - lors d'au moins une réception de données, par un noeud hébergeant une application destination desdites données, une étape d'application d'une compensation de déphasage au cours de laquelle ledit noeud destination retarde la présentation de données à ladite application destination en fonction de ladite somme de déphasages pour chaque chemin suivi par des dites données. De cette manière, les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination sont égales lorsque l'une des applications, source ou destination, est commune pour lesdites données.

Description

La présente invention concerne un procédé et un dispositif de synchronisation de réception de données dans un réseau. Plus particulièrement, la présente invention concerne les réseaux présentant des sous-réseaux à fréquences liées ( frequency locked subnetworks ) et les réseaux de communications multimédia, en particulier les réseaux de type TDM (acronyme de Time Division Multiplexing pour multiplexage à division temporelle) synchrones et les réseaux isochrones. On parle de réseaux synchrones lorsque les horloges d'un réseau sont strictement synchronisées en phase et en fréquence avec une horloge de référence. On peut citer, à titre d'exemples, les réseaux de télécommunication de type SDH (acronyme de Synchronous Digital Hierarchy pour hiérarchie numérique synchrone) et les réseaux AudioNidéo domestiques, pour le grand public, basés sur l'interconnexion de plusieurs bus IEEE Std 1394a-2000 tel que définis par le standard IEEE1394.1-2004 ( Standard for High Performance Serial Bus Bridges ).

On note que, dans le cas où l'on observe une différence de phase relative constante, on parle de réseau mésochrone ( mesochronous en anglais) bien que, par abus de langage, ce type de réseaux soit aussi appelé réseaux synchrones . Un réseau de type TDM est un réseau permettant de véhiculer plusieurs canaux sur un même support de communication (par agrégation de canaux) en utilisant un multiplexage temporel sur les échantillons élémentaires de chacun de ces canaux. Ainsi le temps est divisé en intervalles de temps ( time slot en anglais) de durées égales et fixes, successivement attribués aux différents canaux pour transporter, chacun, un échantillon élémentaire.

Une trame TDM est constituée de l'agrégation des canaux virtuels de données destinées à être transmises pendant un cycle TDM. Une trame TDM comporte un intervalle de temps par canal véhiculé sur le support de communication. Ainsi, le cycle se répète avec une nouvelle trame TDM comportant de nouveaux échantillons élémentaires pour chacun des canaux. Un réseau de type TDM synchrone bénéficie donc des caractéristiques et propriétés d'un réseau de type TDM et d'un réseau de type synchrone. Un réseau isochrone est un réseau synchrone qui, comme le bus IEEE selon le standard 1394a-2000, a la capacité de transmettre des échantillons élémentaires ayant une taille différente pour différents canaux mais fixe dans le temps pour chaque canal, à une fréquence appropriée pour obtenir un débit d'information constant. On peut donc voir un réseau TDM synchrone comme un réseau isochrone dont tous les échantillons élémentaires ont la même taille et la même fréquence d'apparition sur le support de communication. La présente invention concerne, en particulier, une technique 15 d'interconnexion de réseaux de type TDM synchrones. La présente invention se rapporte donc plus particulièrement à un réseau synchrone adapté à la présentation simultanée soit d'une information sur plusieurs terminaux (application de type un-vers-plusieurs , ou one-tomany en anglais), par exemple un système d'affichage distribué, soit de 20 plusieurs informations synchrones issues de plusieurs terminaux à destination d'un terminal commun (application de type plusieurs-vers-un , ou many-toone en anglais), par exemple un système de capture multi-caméras. Par exemple, plusieurs sous-réseaux de type TDM synchrones (ou PAN pour Personal Area Network ou réseaux domestiques) sont 25 interconnectés par l'intermédiaire de PBN (acronyme de PAN Bridge Network pour réseau de passerelles PAN), afin de pouvoir établir des connexions et de pouvoir transmettre des données entre les terminaux hébergés par les différents sous réseaux. Chaque sous réseau étant cadencé par un cycle TDM généré par 30 une horloge qui lui est propre, lors de l'interconnexion de deux sous-réseaux, une technique connue consiste à réaliser une étape transitoire afin de resynchroniser les cycles TDM en phase, en asservissant l'horloge d'un sous réseaux, dit esclave à l'horloge de l'autre sous réseau, dit maître . Cependant, cette étape transitoire perturbe les cycles des sous-réseaux esclaves, et perturbe donc les échanges de données en cours sur les sous-réseaux au moment de l'interconnexion. En effet, un cycle TDM peut être perdu, générant des débordements ou des manques dans les mémoires tampons utilisées pour le transfert de données. Le document US 2005/0175037 décrit un réseau composé de plusieurs modules connectés entre eux par l'intermédiaire de fibres optiques et de communications radio. Les horloges des entrées et des sorties de chaque module ne sont pas synchronisées, mais l'horloge applicative de sortie de réseau doit être synchronisée en phase nulle avec l'horloge applicative d'entrée du réseau. Pour ce faire, chaque module calcule une valeur de déphasage entre son horloge de sortie et son horloge d'entrée. Ces déphasages sont ensuite cumulés par le module de sortie afin d'alimenter une PLL (acronyme de phase-locked loop pour boucle à verrouillage de phase) qui asservit l'horloge de sortie du réseau sur l'horloge d'entrée du réseau. Cette technique n'est pas applicable à tous les cas particuliers décrits ci-dessus, car elle ne décrit par comment synchroniser les instants de présentation des données, et ne prend pas en compte les scénarios dans lesquels plusieurs sources fournissent des données à un même destinataire. La présente invention vise à remédier à ces inconvénients. A cet effet, selon un premier aspect, la présente invention vise un procédé de synchronisation dans un réseau comportant des sous-réseaux synchrones reliés entre eux par des commutateurs, pour la communication de données transmises sur une pluralité de chemins allant, chacun, d'une application source à une application destination, qui comporte : - pour chaque dit chemin, une étape de détermination de la somme des déphasages successifs introduits par les commutateurs présents sur ledit 30 chemin, et - lors d'au moins une réception de données, par un noeud hébergeant une application destination desdites données, une étape d'application d'une compensation de déphasage au cours de laquelle ledit noeud destination retarde la présentation de données à ladite application destination en fonction de ladite somme de déphasages pour chaque chemin suivi par des dites données, de telle manière que les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination soient égales lorsque l'une des applications, source ou destination, est commune pour lesdites données. Ainsi, les cycles des différentes applications, ou des différents sous-réseaux, ont la même période, mais ne commencent pas simultanément. Grâce à la mise en oeuvre de la présente invention, on ne perturbe pas les applications tournant localement sur les sous-réseaux au moment de leur connexion, en ne re-synchronisant pas les cycles de ces sous-réseaux en phase nulle. Au contraire, la différence de phases est maintenue constante et un décalage constant existe entre les impulsions des horloges des différents sous-réseaux qui correspondent à un même cycle TDM. Malgré ce décalage, les données transitant d'une source vers plusieurs destinations ( one-tomany ) sont présentées à ces destinations de façon synchronisée. De même, les données transitant de plusieurs sources vers une même destination ( many-to-one ) sont présentées à cette destination de façon synchronisée.

La mise en oeuvre de la présente invention offre l'avantage d'être transparente pour l'application destination, c'est-à-dire qu'aucun protocole particulier n'est à implémenter au niveau applicatif. De plus, cette mise en oeuvre ne dépend pas du nombre de sous réseaux connectés ni du nombre de destinations (dans le cas d'une source vers plusieurs destinations) ou de sources (dans le cas de plusieurs sources vers une destination). La présente invention est ainsi adaptée aux différentes topologies du réseau. Selon des caractéristiques particulières, au cours de l'étape de détermination de sommes de déphasages, on fait parcourir chaque dit chemin par un message comportant un champ dont la valeur est incrémentée des déphasages successifs introduits par les commutateurs présents sur ledit chemin. Grâce à ces dispositions, la mesure de la somme de déphasages est très précise puisqu'elle est réalisée par les commutateurs effectivement présents sur les chemins considérés. Selon des caractéristiques particulières, au cours de l'étape de détermination de sommes de déphasages, on fait parcourir chaque dit chemin par ledit message depuis l'application source vers l'application destination définies par ledit chemin. Grâce à ces dispositions, la mesure de la somme de déphasages est très précise puisqu'elle est réalisée en faisant suivre le chemin, par le message, dans le sens effectivement suivi par les données auxquelles s'appliquera la compensation de déphasage.

Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus, comporte, en outre, une étape de sélection d'un chemin de référence et au cours de l'étape d'application d'une compensation de déphasage, pour chaque donnée véhiculée sur un chemin à l'exception du chemin de référence, on retarde la présentation de données d'une durée égale à la différence entre la somme des déphasages pour ledit chemin et la somme des déphasages pour le chemin de référence. Selon des caractéristiques particulières, au cours de l'étape de sélection d'un chemin de référence, on sélectionne le chemin présentant la 20 somme de déphasages la plus importante. Ainsi, pour le chemin de référence, aucun retard n'est réalisé pour la présentation de données et, pour les autres chemins, le retard est minimisé. Selon des caractéristiques particulières, au cours de l'étape de détermination de sommes de déphasages, on détermine une somme de 25 déphasages entre les fronts montants de cycles de sous-réseau liés aux commutateurs présents sur un chemin. Selon des caractéristiques particulières, au cours de l'étape de détermination de sommes de déphasages, chaque port d'un commutateur présent sur un dit chemin mesure un déphasage de fronts montants entre le 30 sous réseau auquel il est connecté et ledit commutateur. Selon des caractéristiques particulières, au cours de l'étape de détermination de sommes de déphasage, chaque dit port ajoute le déphasage de fronts qu'il mesure et une somme de déphasages transmise dans un message en provenance d'une application source. Selon des caractéristiques particulières, l'application commune étant une application destination, au cours de l'étape de détermination de sommes de déphasage, ladite application destination émet à destination de chaque application source, un message requérant une mesure de somme de déphasages. Grâce à ces dispositions, la mesure de sommes de déphasages est effectuée en suivant le chemin dans le même sens que les données allant d'une application source à une application destination. Selon des caractéristiques particulières, au cours de l'étape d'application d'une compensation de déphasage, on retarde un instant de présentation de données à une application destination dans une couche présentation des données .

Selon des caractéristiques particulières, au cours de l'étape de détermination de décalage, on détermine un décalage entre les fronts montants de cycles TDM, ou cycles SDPC (acronyme de Synchronous Data Processing Cycle pour cycle de traitement de données synchrone). Selon un deuxième aspect, la présente invention vise un dispositif de synchronisation dans un réseau comportant des sous-réseaux synchrones reliés entre eux par des commutateurs, pour la communication de données transmises sur une pluralité de chemins allant, chacun, d'une application source à une application destination, qui comporte : - des moyens de détermination, pour chaque dit chemin, de la 25 somme des déphasages successifs introduits par les commutateurs présents sur ledit chemin, et - des moyens d'application d'une compensation de déphasage adapté, lors d'au moins une réception de données, par un noeud hébergeant une application destination desdites données, à retarder la présentation de 30 données à ladite application destination en fonction de ladite somme de déphasages pour chaque chemin suivi par des dites données, de telle manière que les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination soient égales lorsque l'une des applications, source ou destination, est commune pour lesdites données. Selon un troisième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé objet de la présente invention, tel que succinctement exposé ci-dessus. Selon un quatrième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé objet de la présente invention, tel que succinctement exposé ci-dessus. Les avantages, buts et caractéristiques de ce dispositif, de ce programme d'ordinateur et de ce support d'information étant similaires à ceux du procédé objet de la présente invention, tel que succinctement exposé ci- dessus, ils ne sont pas rappelés ici. D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif en regard des dessins annexés, dans lesquels : - les figures la et 1 b représentent, schématiquement, une interconnexion de deux sous réseaux et une désynchronisation de signaux entre ces sous réseaux, - la figure 2 représente, schématiquement, un dispositif de type commutateur TDM, - la figure 3 représente un diagramme illustrant un cycle TDM, - la figure 4 représente un diagramme bloc illustrant un commutateur TDM, - les figures 5a et 5b forment un diagramme bloc illustrant un port de communication de type liaison d'interconnexion série, - la figure 6 décrit, sous forme d'un logigramme, des étapes d'initialisation d'un module de gestion de décalages, - les figures 7a et 7b représentent, sous forme d'un logigramme, des étapes de mesure du décalage et génération du signal SDPC décalé, - les figures 8a et 8b représentent, sous forme d'un logigramme, le fonctionnement d'un tampon, - les figures 9a et 9b représentent, sous forme d'un logigramme, le fonctionnement d'un tampon, - la figure 10 illustre un exemple de topologie de réseau avec une source et plusieurs destinations ( one to many ), - la figure 11 illustration des compensations à effectuer dans le cas d'une source et plusieurs destinations, - la figure 12 représente, sous forme d'un logigramme, des étapes mises en oeuvre sur le noeud hébergeant la source de la figure 10, - la figure 13 représente, sous forme d'un logigramme, des étapes de traitement de messages de cumul de latence par des ports d'éléments de la figure 10, - les figures 14 et 15 représentent, sous forme d'un logigramme, des étapes de traitement effectuées par les noeuds hébergeant une destination de la figure 10, - la figure 16 représente un exemple de topologie de réseau avec plusieurs sources et une destination ( many to one ), - la figure 17 est une illustration des compensations à effectuer dans le cas illustré en figure 16, - les figures 18a et 18b représentent, sous forme de logigrammes, des étapes mises en oeuvre sur le noeud hébergeant la destination de la figure 16, - la figure 19 représente, sous forme d'un logigramme, des étapes mises en oeuvre sur les noeuds hébergeant les sources de la figure 16, - la figure 20 représente, sous forme d'un logigramme, des étapes de traitement de messages de cumul de latence par des ports d'éléments illustrés en figure 16 et - la figure 21 représente, sous forme d'un logigramme, des étapes de compensations dans le mode de réalisation illustré aux figures 16 à 20.

On observe, en figure 1 a, deux sous réseaux TDM sans fil, ou PAN, 100 et 106 connectés entre eux par deux équipements d'interconnexion de type commutateur ( switch , en anglais) 102 et 104 reliés par un câble multibrins 103 sur lequel sont véhiculées les données et les horloges cadençant ces données. Outre les équipements d'interconnexion 102, 103 et 104, chaque PAN héberge un ou plusieurs noeuds (ne sont représentés, en figure 1 a, que les noeuds 101 et 105, respectivement hébergés par les PAN 100 et 106) pouvant faire office de source 101 ou de destination 105 de flux de données. Les sources et destinations de chacun de ces flux audio/vidéo peuvent être hébergées par le même PAN ou par des PAN différents. Dans ce dernier cas, les données sont transmises d'un PAN à l'autre par le biais des équipements d'interconnexion 102 et 104 et du câble 103. Les PAN 100 et 106 ayant chacun sa propre horloge, avant l'établissement de l'interconnexion, leurs cycles TDM ne sont ni en phase ni exactement de la même période. Conformément à la présente invention et comme illustré en figure 1 b, lors de l'interconnexion des PAN 100 et 106, le décalage d 109 entre les cycles TDM 107, du PAN 100, et 110 du PAN 106, est mesuré puis maintenu constant, tout en assurant le transfert correct des données entre ces deux cycles TDM.

Pour plus de clarté, la figure 1 a ne représente que deux PAN 100 et 106 interconnectés entre eux. Cependant, dans le cadre de l'invention, comme illustré en figure 10, l'interconnexion ne se limite pas à deux PAN, chaque équipement d'interconnexion 102 et 104 pouvant, par exemple, accueillir jusqu'à trois câbles 103 reliés à trois autres équipements d'interconnexion.

Lorsqu'une source émet un flux de données audio/vidéo vers plusieurs destinations, on peut, selon l'application émettant ce flux de données, souhaiter qu'une même donnée soit remise aux différentes applications destination de façon synchrone, c'est-à-dire simultanément. L'utilisation de certaines topologies d'interconnexion (telle que celle décrite en figure 10) permet de garantir que cette donnée est remise aux différentes applications destinataires dans le même cycle TDM. Ce qui revient à dire en même temps , dans le cas où tous les cycles TDM sont synchronisés en phase nulle.

Cependant, conformément à la présente invention, un décalage constant existe entre les débuts des cycles TDM des différents PAN (inférieur à la période des cycles TDM). Afin de maintenir une présentation synchrone des données aux applications destinations, une compensation des différences de décalage entre le cycle TDM de la source et ceux des destinations est effectuée. Comme détaillé par la suite, il en est de même dans le cas où plusieurs sources émettent un flux audio/vidéo vers une même destination comme dans la topologie de réseau illustrée en figure 16 (par exemple dans le cas d'une régie vidéo). On décrit ci-dessous, en référence à la figure 2, un dispositif de communication 200 qui met en oeuvre la présente invention dans les équipements d'interconnexion 102 et 104. Ce dispositif de communication 200 comporte un bus interne 201 permettant l'échange d'information entre des composants référencés 202 à 209. Une unité centrale 202 permet l'exécution des instructions d'un programme sauvegardé dans une mémoire non programmable 204 ou sur un système de mémorisation non volatile, comme par exemple un disque dur 206. Ce programme permet d'implémenter, notamment, tout ou partie des étapes des logigrammes décrits ci-après. En outre, la mémoire non volatile 206 contient les données de configuration qui peuvent être mises à jour par l'utilisateur grâce à une interface 205. Une mémoire vive (RAM) 203 constitue la mémoire principale de l'unité centrale 202 qui y exécute les instructions du programme après leur transfert en provenance de la mémoire non programmable (ROM) 204 ou de la mémoire non volatile 206 après la mise sous tension. Le dispositif de communication 200 dispose d'une interface de connectivité locale 209 adaptée à connecter des équipements audio vidéo, comme par exemple une interface HDMI (acronyme de high definition multimedia interface pour interface multimédia haute définition). Le dispositif de communication 200 dispose aussi d'une connectivité étendue vers un réseau TDM, par l'intermédiaire d'un module d'interface 208 qui met en forme les informations devant être échangées entre un bus interne 201 (en provenance ou à destination d'une application s'exécutant sur l'unité centrale 202) ou de l'interface de connectivité locale 209 et des ports de communication 210, 211 et 212 avec le réseau TDM. Un module de commutation 207 réalise notamment des opérations de filtrage et d'établissement de circuits entre des ports de communication 210, 211 et 212 et le module d'interface 208 (routage). Le module de commutation 207 est, bien entendu, configurable par l'unité centrale 202, par l'intermédiaire du bus interne 201. On note que le module d'interface 208 est un port de communication qui permet l'adaptation de trafic (par exemple en effectuant des opérations de segmentation et ré-assemblage) avec les applications hébergées localement, alors que les ports de communication 210, 211 et 212 ne font qu'émettre et recevoir les informations de manière adéquate sur un médium. Le nombre de ports de communication et le nombre de modules d'interface 208, ici respectivement trois et un, ne sont en aucune manière limitatifs et sont, au contraire dimensionnés en fonction des caractéristiques du système. Dans la suite de la description, on utilise indifféremment les termes commutateur et dispositif de communication de type commutateur tel que décrit au regard de la figure 2. On décrit ci-après, en regard de la figure 3, les mécanismes régissant le fonctionnement des communications dans d'un réseau TDM. A chaque port de communication des commutateurs (ou noeuds) du réseau TDM, l'ensemble de la bande passante disponible est partagée en canaux dit virtuels (en anglais VC pour Virtual chanel ) synchrones 302. Les échantillons de canaux 303 numérotés 1 à N, de tailles identiques m, sont entrelacés dans le temps et forment ainsi une séquence TDM, aussi appelée cycle TDM . A chacun des canaux virtuels est assigné un sens de communication, entrée ou sortie . On parle aussi, respectivement, de lecture ou d' écriture . La bande passante ainsi allouée à chaque canal virtuel est donc constante et caractérisée par la fréquence d'apparition du cycle TDM et de la taille des échantillons.

A titre d'exemple, pour une fréquence du cycle TDM de 8 kHz soit une période 304 de 125 ps et une taille des échantillons de 48 bits, chaque canal virtuel offre une bande passante de 8.000 x 48 = 384 Kbps (kilobits par seconde). Ainsi, un cycle TDM comportant 1024 canaux virtuels offre une bande passante globale de 384 Mbps (acronyme de mégabits par seconde). Le signal SDPC (acronyme de Synchronous Data Processing Cycle pour cycle de traitement de données synchrone) 300 marque l'apparition du premier symbole représentatif du premier échantillon du cycle TDM. La période 304 de ce signal est égale à la période du cycle TDM.

On note que tous les appareils connectés à un même PAN sont synchronisés entre eux. Ainsi, tous les ports des commutateurs d'un même PAN débutent de manière simultanée le traitement d'une nouvelle séquence TDM. En référence à la figure 4, on décrit, ci-après, le commutateur TDM 207 à l'aide d'un bloc-diagramme. Le commutateur TDM 207 est composé de quatre ports A, B, C et D référencés respectivement 401 à 404. On note que, pour des raisons de clarté, n'ont été représentés de manière détaillée que les ports A 401 et B 402. Chaque port est connecté à une unité de commutation 405 qui peut, par exemple, prendre la forme d'un bus de données partagé. Le port A est connecté au module d'interface avec l'application 208, le port B au port de communication 210, le port C au port 211 et le port D au port 212 (voir figure 2). Un sélecteur de cycle TDM de référence 406 permet de choisir une horloge de référence, soit générée localement par une horloge 407, soit issue du signal de SDPC 300 de l'un des ports A, B, C ou D, le signal SDPC de chacun des autres ports étant alors asservi à cette horloge de référence. Dans un réseau TDM tel que celui qui supporte les systèmes décrits au regard des figures 1 ou 9, on a un et un seul commutateur TDM 207 dont le cycle TDM de référence est l'horloge locale 407 (commutateur maître ). L'horloge des autres commutateurs (commutateurs esclaves ) est générée à partir de l'horloge maître, comme détaillé en figures 5b, 6 et 7.

L'utilisateur choisit la configuration du sélecteur de cycle de référence 406 de chacun des équipements d'interconnexion par l'intermédiaire de l'interface utilisateur 205, grâce à un programme exécuté par l'unité centrale 202 qui permet de modifier la configuration d'un commutateur TDM avec un processeur d'interface 450. Chacun des ports 401 à 404, comporte des éléments de configuration 410 qui sont statiques ou modifiables dynamiquement. Parmi ces éléments de configuration 410, on peut citer les informations de routage permettant d'établir des circuits de communication à travers l'unité de commutation 405, le sens de communication de chacun des canaux virtuel et les informations relatives à la mise en oeuvre de l'invention. Chaque port comporte, en outre, un module de réception, ou récepteur, 412 et un module d'émission, ou émetteur, 411, chacun de ces modules étant adapté à communiquer avec un module auquel il est attaché en respectant les mécanismes décrits en regard de la figure 3. Ainsi, durant un cycle TDM (entre deux impulsions 301 du signal SDPC 300), chaque port reçoit des données ( Out_Data ) que le module de réception 412 stocke avant qu'elles soient transférées vers un ou plusieurs ports. Dans le même temps, le module d'émission 411 de chaque port écrit dans le port de communication auquel il est attaché (ici 208 pour le port A et 210 pour le port B), des données ( In_Data ) qu'il a préalablement stockées, comme exposé plus en détail en regard de la figure 6. Le diagramme-bloc de la figure 5a présente un exemple de port de communication 210 pour réaliser une liaison d'interconnexion série (appelée aussi InterConnect ). Une liaison d'interconnexion telle que la liaison d'interconnexion 103 est obtenue en reliant, en point à point, deux ports de communication à l'aide d'un câble qui transporte les signaux 520 à 526 sur une courte distance (typiquement, quelques mètres au maximum). Ainsi, les données issues du commutateur 207 sont, dans un premier temps, stockées dans une mémoire tampon (en anglais, buffer ) 514 avant d'être encapsulées par une fonction d'encapsulation 501 pour former une trame de données. Puis ces données sont sérialisées et encodées, par une fonction de sérialisation et d'encodage 502. Les données ainsi mises en forme sont ensuite transférées dans une mémoire tampon d'émission LVDS (acronyme de Low Voltage Differential Signaling pour signal différentiel de faible voltage) 505 offrant ainsi une transmission haut débit à travers le signal Data_out 521. La chaîne de réception de ce port de communication 210 réalise les opérations successives inverses, à savoir la réception de données à travers le signal Data_in 522 dans la mémoire tampon ( buffer ) de réception LVDS 505. Une fonction 504 inverse à la fonction 502, dite de dé-sérialisation et décodage et une fonction d'extraction 503 des données s'exécutent avant de remettre, par l'intermédiaire du tampon 515, les données au commutateur 207 comme exposé en regard de la figure 3. On note que le signal 520 relié à la mémoire tampon LVDS 505 est l'horloge bit (horloge de cadencement des données par bit de données) des données émises ou reçues par l'intermédiaire des signaux 521 et 522. Le signal 520 est configurable en entrée ou en sortie, en fonction de la distribution d'horloge configurée par l'utilisateur comme précisé en regard de la figure 4. De plus, le port de communication 210 possède un module de signalisation 510 permettant d'échanger des informations de contrôle avec le port distant. Une opération de sérialisation 511 est appliquée avant émission sur le signal CTL_OUT 523. En réception, on réalise l'opération inverse (désérialisation) 512 sur le signal CTL_IN 524 pour traitement par le module de signalisation 510. Ce module de signalisation 510 contribue notamment à la diffusion de l'information pour la distribution de l'horloge dans le réseau, et vérifie que la liaison entre les deux ports de communication connectés en point à point est toujours active. Le port de communication 210 permet aussi de délivrer : - d'une part, par l'intermédiaire d'un module de gestion de décalage SDPC 513, le signal d'horloge de référence du cycle TDM 300 issue du commutateur 207 sur le signal de sortie 526 et, - d'autre part, à ce même commutateur 207, le signal d'horloge de référence du cycle TDM 300 reçu du terminal distant à travers le signal SDPC_IN 525. En fonction de la distribution d'horloge configurée par l'utilisateur, un seul de ces deux signaux est pris comme référence. Le bloc-diagramme de la figure 5b présente, plus en détail, le fonctionnent des blocs tampons 514 et 515 et du module de gestion de décalage SDPC 513. Ces blocs tampons 514 et 515 permettent la transmission des données malgré le décalage temporel pouvant exister entre les signaux SDPC provenant du commutateur 207 et du port distant de l'InterConnect. Dans le cas où le commutateur 207 fournit l'horloge SDPC à l'InterConnect par le port courant de l'InterConnect, un signal SDPC_décalés 538 vaut faux (ce qui signifie qu'il n'existe pas de décalage entre les signaux SDPC du commutateur connecté au port courant de l'InterConnect et ceux de l'InterConnect). Les données sont donc échangées entre les modules d'encapsulation et de dé-encapsulation 501 et 503, d'une part, et le commutateur 207, d'autre part, sans passer par les mémoires tampons 514 et 515. De même, les signaux SDPC 525 et 537 ne sont pas modifiés par le module de gestion de décalage SDPC 513. Dans les cas où l'horloge SDPC est fournie à l'InterConnect par le port distant de l'InterConnect, un décalage existe entre le signal SDPC reçu par le port depuis l'InterConnect et le signal reçu par le port depuis le commutateur (connecté au port local de l'InterConnect). Le signal SDPC_décalés 538 vaut alors vrai . Le signal In_SDPC 536 à destination du commutateur est donc généré par le bloc 533 selon l'algorithme détaillé en regard de la figure 7b, sur la base du signal InterConnect_SDPC 525 et du décalage mesuré par le bloc 534. Le signal SDPC 526 reçoit une copie du signal 525.

De plus, la mémoire tampon 514 reçoit et stocke une trame TDM en provenance du commutateur 207 à chaque front montant du signal in_SDPC 536 correspondant au cycle TDM du commutateur 207. Cette même trame TDM est ensuite délivrée au module 501 sur le front montant du signal SDPC IN 525 correspondant au cycle TDM de l'InterConnect. De même, la mémoire tampon 515 reçoit et stocke une trame TDM en provenance de l'InterConnect à chaque front montant du signal SDPC IN 525 correspondant au cycle TDM de l'InterConnect. Cette même trame TDM est ensuite délivrée au commutateur sur le front montant du signal in_SDPC 536 correspondant au cycle TDM du commutateur. Les tampons 514 et 515 fonctionnent suivant l'algorithme détaillé en regard de la figure 8. Lors de la connexion d'un câble 103, les ports qu'il relie sont initialisés comme illustré en figure 6. Lors d'une étape 601, on vérifie la configuration du port pour déterminer si l'horloge SDPC du port est fournie par le commutateur ou par le port distant de l'InterConnect. Dans le premier cas, il n'y a pas de décalage entre les cycles TDM du commutateur et du port. Il n'y a donc rien de particulier à faire au niveau du port et, au cours d'une étape 602, le port utilise l'horloge fournie par le commutateur. Dans le second cas, le bloc 534 mesure le décalage suivant l'algorithme détaillé en regard de la figure 7a au cours d'une étape 603, puis la génération du signal SDPC à destination du commutateur démarre, au cours d'une étape 604, suivant l'algorithme détaillé figure 7b. Au cours d'une étape 605, on re-paramètre le commutateur pour qu'il prenne le port courant comme référence pour son cycle TDM, par le biais de registres de configuration. La figure 7a illustre la méthode utilisée pour mesurer le décalage existant entre le cycle SDPC de l'InterConnect et celui du commutateur 207. Au cours d'une étape 700, on attend un front montant du signal SDPC IN 525 de l'InterConnect. Ce front montant déclenche le démarrage d'un compteur à 0 , au cours d'une étape 701. Puis on attend le prochain front montant sur le signal Out_SDPC 537 provenant du commutateur, au cours d'une étape 702. Au cours d'une étape 703, ce nouveau front montant provoque l'arrêt du compteur, dont la valeur représente le décalage. Au cours d'une étape 704, on détermine si cette valeur est supérieure ou égale à la période du signal SDPC. Si oui, on se trouve dans le cas où les deux signaux SDPC sont très peu décalés (décalage inférieur à la période de l'horloge utilisée pour le compteur). On considère donc que la valeur du décalage est de 0 , au cours d'une étape 705. La valeur de décalage mesurée est ensuite mise en mémoire au cours d'une étape 706. Puis le signal prêt 539 est validé pour informer le générateur de signal SDPC qu'il peut démarrer, au cours d'une étape 707.

La figure 7b illustre la méthode utilisée pour générer le signal SDPC décalé In_SDPC 536 à destination du commutateur 207. Dans un premier temps, on attend la validation du signal prêt 539 , au cours d'une étape 710. Puis, on attend le prochain front montant sur le signal SDPC IN 525 de l'InterConnect, au cours d'une étape 711. Une fois ce front montant reçu, on attend, au cours d'une étape 712, une durée égale à la valeur du décalage mesuré (par exemple en utilisant un compteur utilisant la même horloge que celle utilisée pour mesurer le décalage). Une fois cette durée écoulée, on génère, au cours d'une étape 713, un front montant sur le signal In_SDPC 536, avant de se remettre en attende du prochain front montant sur le signal SDPC IN 525 de l'InterConnect pour recommencer le cycle à l'étape 711. La figure 8a illustre le processus régissant l'écriture dans la mémoire tampon 515. Au cours d'une étape 800, un compteur d'indice N est initialisé à 0 . Au cours d'une étape 801, on attend le prochain front montant sur le signal SDPC IN 525 de l'InterConnect. Au cours d'une étape 802, ce nouveau front montant déclenche l'incrémentation de l'indice N et, au cours d'une étape 803, le début de réception et de mémorisation d'une trame TDM. On revient ensuite à l'étape 801. La figure 8b illustre le processus régissant la lecture des données stockées dans la mémoire tampon 515. Au cours d'une étape 810, on attend le prochain front montant sur le signal In_SDPC 536 du commutateur. Dans l'implémentation décrite, une variation de la période des cycles SDPC d'une micro seconde est tolérée. Lors de la transmission d'une trame TDM, on ne dispose donc pas de toute la période du cycle pour transmettre les données. Un intervalle dit de garde est défini à la fin de chaque cycle pour assurer que toutes les donnés sont correctement transmises malgré les variations de la période SDPC. On détermine, au cours d'une étape 811, si le décalage mesuré entre les cycles SDPC est inférieur à la différence période SDPC ù intervalle de garde . Si non, au cours d'une étape 812, on détermine si la valeur de N est strictement supérieure à 1. Si non, toutes les données d'une trame n'ont peut être pas pu être stockées dans la mémoire tampon au moment du début du cycle SDPC du commutateur. On attend alors le cycle suivant en retournant à l'étape 810. Si la valeur de N est strictement supérieure à 1, on peut transmettre les données reçues au cours du cycle précédent (N-1) de l'InterConnect, au cours d'une étape 813. L'étape 812 permet ainsi d'assurer qu'une trame d'indice N-1 est bien présente dans la mémoire tampon 515 pour que l'étape 813 puisse se dérouler correctement. On note que l'étape 812 sert surtout à l'initialisation. Si le décalage mesuré entre les cycles SDPC est supérieur ou égal à la différence période SDPC û intervalle de garde , toutes les données d'une trame ont été stockées dans la mémoire tampon au début du cycle SDPC du commutateur. On peut donc les transmettre vers le commutateur, au cours d'une étape 814. A la suite de l'une des étapes 813 ou 814, on retourne à l'étape 810. La figure 9a illustre le processus régissant l'écriture dans la mémoire tampon 514. Au cours d'une étape 900, on initialise un compteur d'indice N à 0 . On attend ensuite le prochain front montant sur le signal SDPC 536 du commutateur, au cours d'une étape 901. Ce front montant déclenche l'incrémentation de l'indice N, au cours d'une étape 902, et le début de réception et de mémorisation d'une trame TDM, au cours d'une étape 903. On revient ensuite à l'étape 901. La figure 9b illustre le processus régissant la lecture des données stockées dans la mémoire tampon 514. Au cours d'une étape 910, on attend le prochain front montant sur le signal SDPC 525 de l'InterConnect. Dans le cas du tampon 514, les données viennent du commutateur et sont transmises vers l'InterConnect. Pour que toutes les données transmises au cours d'un cycle du commutateur aient été correctement stockées dans la mémoire tampon 514, il faut que le décalage entre les cycles soit inférieur à la période de garde. Au cours d'une étape 911, on détermine si le décalage entre les cycles est inférieur à l'intervalle de garde. Si oui, les données reçues au cours du cycle courant du commutateur sont transmises à l'InterConnect, au cours d'une étape 914. Sinon, au cours d'une étape 912, on détermine si la valeur de N est strictement supérieure à 1. Si non, toutes les données d'une trame n'ont peut être pas pu être stockées dans la mémoire tampon au moment du début du cycle SDPC du commutateur. On attend alors le cycle suivant en retournant à l'étape 910. Si la valeur de N est strictement supérieure à 1, on transmet les données correspondant au cycle précédent, au cours d'une étape 913.

A la suite de l'une des étapes 913 ou 914, on retourne à l'étape 910. La figure 10 illustre une application de l'invention aux cas où les données émises par une source sont transmises vers plusieurs destinations. En figure 10 sont représentés quatre sous réseaux PAN1 1000, PAN2 1014, PAN3 1018 et PAN4 1022, interconnectés par le biais de ports d'interconnexion 1003, 1004, 1006, 1007, 1008, 1010, 1011, 1012, 1016, et 1020, et de commutateurs 1002, 1005, 1009, 1013, 1017, et 1021. Une source 1001, aussi appelée application commune , est connectée au PAN1 1000, et émet un flux audio/vidéo vers les destinations 1015, 1019 et 1023 connectées respectivement aux PAN2 1014, PAN3 1018 et PAN4 1022.

L'un des noeuds contenant l'un de ces commutateurs ou, de manière équivalente, le sous-réseau correspondant puisque ce noeud définit l'horloge du sous réseau qui lui est rattaché, est élu comme référence pour les autres pour la synchronisation des cycles TDM (ce commutateur est dit maître ). A titre d'exemple, si le noeud contenant le commutateur 1005 est élu maître : - le signal SDPC du commutateur 1002 (rattaché au PAN 1000) est asservi au signal SDPC du commutateur 1005, - le signal SDPC du commutateur 1013 (rattaché au PAN 1014) est asservi au signal SDPC du commutateur 1005, - le signal SDPC du commutateur 1017 (rattaché au PAN 1018) est 25 asservi au signal SDPC du commutateur 1005, - le signal SDPC du commutateur 1009 est asservi au signal SDPC du commutateur 1002 (lui-même asservi au signal SDPC du commutateur 1005) et - le signal SDPC du commutateur 1021 (rattaché au PAN 1022) est 30 asservi au signal SDPC du commutateur 1009 (lui-même asservi indirectement au signal SDPC du commutateur 1005).

Un décalage des cycles TDM impliquant la mise en oeuvre des mécanismes décrits ci-dessus est donc observé : - à l'interface entre le port 1003 et le commutateur 1002, - à l'interface entre le port 1012 et le commutateur 1013, - à l'interface entre le port 1016 et le commutateur 1018, - à l'interface entre le port 1010 et le commutateur 1009 et - à l'interface entre le port 1020 et le commutateur 1021. Sur la figure 10, sont aussi représentés, par des lignes courbes, trois flux de données qui partent de la source 1001 hébergée par le PAN 1000, et sont, chacun, acheminés à l'une des destinations 1015 hébergée par le PAN2 1014, 1019 hébergée par le PAN3 1018 et 1023 hébergée par le PAN4 1022. Lorsque des flux de données audio/vidéo sont transmis par une même source vers plusieurs destinations, les différents chemins qu'ils empruntent engendrent des différences de temps de transport (différences de latences) et donc des instants de présentation d'une même donnée différents d'une destination à l'autre. Dans le cas où tous les PAN sont synchronisés en phase nulle, ce qui n'est pas nécessairement le cas pour la mise en oeuvre de la présente invention, ces différences de latences s'expriment en nombre entier de cycles TDM. L'utilisation d'une topologie appropriée (telle que celle décrite figure 10, dans le cas où la latence est identique sur chaque lien d'InterConnect) permet de résoudre ce problème. Les décalages existants entre les cycles TDM des différents PAN et les mécanismes qu'ils impliquent, décrits ci-dessus, induisent de la latence, ou déphasage, supplémentaire, propre à chaque chemin. Pour un chemin particulier, cette latence supplémentaire est la somme des latences induites par la traversée des différentes interfaces port/commutateur rencontrées sur le chemin, pour lesquelles on observe un décalage entre les signaux SDPC du commutateur et du port. Cette latence supplémentaire peut se décomposer sous la forme a*période SDPC + b, formule dans laquelle a est un entier représentant le nombre de cycles entiers SDPC de latence induite par les traitements précédemment cités, et b représente la latence due au décalage existant entre les cycles 5 SDPC de la source et ceux de la destination. La valeur de b est donc inférieure à la période d'un cycle SDPC. Pour assurer une présentation simultanée des données aux différentes applications destinataires, on calcule et applique une compensation plus précise que la période SDPC, au niveau de certaines applications 10 destinations, compensation qui pallie les différences entre les latences supplémentaires des différents chemins. La figure 11 présente une illustration de cette dernière compensation. Les axes temporels 1100, 1101, 1102 et 1103 correspondent respectivement aux évènements relatifs au PAN1 1000 hébergeant la source 15 du flux audio/vidéo, au PAN2 1014 hébergeant l'application destination 1015, au PAN3 1018 hébergeant l'application destination 1019, et au PAN4 1022 hébergeant l'application destination 1023. L'évènement 1109 correspond au début du cycle d'arrivée des données aux applications destinations dans le cas où les PAN seraient 20 synchronisés en phase nulle. L'évènement 1110 correspond au début du cycle d'arrivée réelle, c'est-à-dire en prenant en compte le décalage des cycles SDPC, des données à la destination 1015 connectée au PAN2 1114. L'évènement 1111 correspond au début du cycle d'arrivée réelle des données à la destination 1019 connectée au PAN3 1018. L'évènement 1112 correspond 25 au début du cycle d'arrivée réelle des données à la destination 1023 connectée au PAN4 1022. Les différentes valeurs de latences supplémentaires correspondantes sont représentées respectivement par les durées 1104, 1106 et 1105. Dans le cadre d'une mise en oeuvre où des flux de données 30 audio/vidéo sont transmis par une même source vers plusieurs destinations, les latences induites par les décalages de cycles TDM entre la source 1001 et chacune des destinations 1005, 1016 et 1022 sont déterminées.

Puis, préférentiellement, on sélectionne la destination pour laquelle la latence supplémentaire (le décalage de chemin par la suite) est la plus grande comme destination de référence et le chemin correspondant chemin de référence . Le noeud hébergeant cette destination, ici l'application destination 1019, n'a pas besoin d'appliquer de compensation. En revanche les autres noeuds hébergeant une destination appliquent une compensation pour ajuster leur temps de présentation des données aux applications destinations sur celui de présentation à l'application destination de référence. Cette compensation est calculée comme exposé en regard de la figure 12, et correspond, pour chaque noeud hébergeant une application destination, à la différence entre le décalage de chemin déterminé pour l'application destination de référence, sur le chemin de référence, et celui déterminé pour l'application destination concernée, sur les autres chemins. Sur la figure 11, ces différences sont la durée 1107 pour le noeud hébergeant la destination 1005, et la durée 1108 pour le noeud hébergeant la destination 1022. Ainsi, les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination sont égales lorsque l'application source est commune pour lesdites données.

La figure 12 illustre le processus mis en oeuvre par le noeud hébergeant l'application commune, ici la source 1001 ( noeud source dans la suite). Au cours d'une étape 1201, le noeud source construit un message de mesure de décalage par noeud hébergeant une destination (appelé noeud destination dans la suite) et envoie ce message aux noeuds destinations, afin de déterminer la latence induite par le parcours du chemin entre le noeud source et le noeud destination concerné. Ces messages contiennent, en plus des informations nécessaires à leur acheminement, un champ type_flux , prenant dans le cas présent la valeur un_vers_plusieurs , et un champ cumul_de_latence , qui est mis à jour par les différents ports traversés.

Chacun de ces messages est intercepté par chaque port traversé sur le chemin vers leur destination, et chaque port additionne la latence induite par sa traversée à la valeur de cumul déjà contenue dans le champ cumul_de_latence du message. Les réponses provenant des noeuds destinations sont reçues au cours d'une étape 1202. Une fois les valeurs de décalage de chemin pour chaque noeud destination extraites de ces réponses, le noeud destination correspondant au décalage de chemin le plus élevé ( décalage_ref dans la suite) est élu noeud destination de référence et le chemin correspondant est élu chemin de référence au cours de l'étape 1203. Pour chaque chemin identifié au cours d'une itération 1204, à l'exception du chemin de référence, la compensation à appliquer est calculée au cours d'une étape 1205 comme suit : compensation_de_décalage_dest_i = décalage_ref ù décalage_dest_i. décalage_dest_i est la valeur du décalage de chemin calculé pour le chemin considéré (cette valeur vaut 0 pour le chemin de référence).

La valeur compensation_de_décalage_dest_i est ensuite envoyée au noeud destination concerné par le biais d'un message de compensation de décalage au cours d'une étape 1206. Une fois toutes les compensations calculées et envoyées, l'algorithme s'achève au cours d'une étape 1207. La figure 13 présente les opérations effectuées par les ports lorsqu'ils interceptent un message de mesure de décalage (ces messages sont, par exemple, identifiés par le canal virtuel sur lequel ils circulent en fonction de leur entête). Lorsque, au cours d'une étape 1300, un de ces messages est intercepté, on détermine si le signal SDPC_décalé vaut vrai et si la valeur du champ type_flux extraite du message est égale à un_vers_plusieurs , au cours d'une étape 1301. Sinon, il n'y a pas de traitement particulier à faire. Le message est donc transmis vers sa destination au cours d'une étape 1302. Dans le cas contraire, la valeur de cumul de décalage contenue dans le message est extraite au cours d'une étape 1303. Puis, au cours d'une étape 1304, on détermine si le message arrive du commutateur. Sinon, au cours d'une étape 1305, on détermine si le décalage entre les cycles SDPC du port et du commutateur est supérieur ou égal à la valeur période SDPC ù intervalle de garde . Sinon, au cours d'une étape 1306, à la valeur extraite du message est ajoutée la valeur d'une période SDPC additionnée à la valeur du décalage entre les cycles SDPC du port et du commutateur (en figures 8a et 8b, on attend un cycle plus le décalage avant de sortir les données du tampon). Puis la valeur de cumul de latence ainsi calculée est réinsérée dans le message, au cours d'une étape 1308, avant que ce message soit transmis vers sa destination, au cours de l'étape 1302. Si le résultat de l'étape 1305 est positif, au cours d'une étape 1309, à la valeur extraite du message est ajoutée la valeur du décalage entre les cycles SDPC du port et du commutateur (en figures 8a et 8b, on attend le décalage avant de sortir les données du tampon). Puis on passe à l'étape 1308. Si le résultat de l'étape 1304 est positif, au cours d'une étape 1310, on détermine si le décalage entre les cycles SDPC du port et du commutateur est inférieur à la valeur de l'intervalle de garde. Sinon, à la valeur extraite du message est ajoutée, au cours d'une étape 1311, la valeur de deux périodes SDPC moins la valeur du décalage entre les cycles SDPC du port et du commutateur (en figures 9a et 9b, on attend un cycle plus le complément du décalage avant de sortir les données du tampon, le décalage étant toujours mesuré entre un front montant du signal SDPC du port et le front montant suivant du signal SDPC du commutateur). Puis on passe à l'étape 1308.

Enfin, si le résultat de l'étape 1310 est positif, à la valeur extraite du message est ajoutée, au cours d'une étape 1312, la valeur d'une période SDPC moins la valeur du décalage entre les cycles SDPC du port et du commutateur (en figures 9a et 9b, on attend le complément du décalage avant de sortir les données du tampon; le décalage étant toujours mesuré entre un front montant du signal SDPC du port et le front montant suivant du signal SDPC du commutateur). Puis, on passe à l'étape 1308. La figure 14 présente le traitement, déclenché par la réception d'un message de mesure de décalage au cours d'une étape 1500, effectué par un noeud auquel est connectée une destination (ou application destination). Au cours d'une étape 1501, on détermine si le champ type_flux est égal à un_vers_plusieurs . Sinon, on effectue les étapes décrites en figure 19, au cours d'une étape 1506. Si oui, la valeur de cumul de latence contenue dans le message est extraite, au cours d'une étape 1502, puis est incluse dans une réponse renvoyée vers le noeud hébergeant la source, au cours d'une étape 1503. Cette réponse comporte, notamment, un champ type_flux , prenant dans le cas présent la valeur un_vers_plusieurs . Un message de compensation de décalage est alors attendu, au cours d'une étape 1504, message dont est extraite une valeur de compensation de décalage (cette valeur vaut zéro pour la destination et le chemin de référence), utilisée lors de la réception du flux audio/vidéo, au cours d'une étape 1505. La figure 15 présente le traitement fait à la réception d'un flux audio/vidéo. Dans un premier temps on attend l'arrivée des première données audio/vidéo, au cours d'une étape 1510. Ces données sont transmises par l'intermédiaire d'un ou de plusieurs canaux virtuels, qui sont vides (c'est-à-dire que le contenu du canal virtuel est NULL ) jusqu'a ce que le début du flux atteigne le noeud destination hébergeant l'application destination. On attend, d'abord, l'arrivée d'un front montant de signal SDPC, au cours d'une étape 1511. Puis, au cours d'une étape 1512, on détermine si le contenu du canal virtuel est NULL . Si oui, on retourne à l'étape 1511. Sinon, à l'arrivée des premières données, ces données sont stockées dans une mémoire tampon de type FIFO (acronyme de first in first out en anglais, pour premier entré, premier sorti ) au cours d'une étape 1513. Puis, on attend une durée égale à la valeur de compensation de décalage reçue, au cours de l'étape 1503, avant de générer l'horloge applicative permettant à l'application de lire les données, au cours d'une étape 1515.

Ainsi, chaque noeud destination retarde la présentation de données à l'application destination correspondante en fonction des sommes de déphasages introduits par les commutateurs présents sur les chemins de données, de telle manière que les durées totales écoulées entre émission de données par l'application source et présentation des dites données aux applications destinations soient égales. L'application de l'invention aux cas où des données émises par plusieurs sources sont transmises à une unique destination est illustrée en figure 16, qui présente la même topologie que celle de la figure 10, si ce n'est que le PAN1 1000 héberge, à présent, une application destination, dite application commune 1601, le PAN2 1014 héberge une source 1615, le PAN3 1018 héberge une source 1619, et le PAN4 1022 héberge une source 1623. En figure 16 sont aussi représentés trois flux de données pour lesquels est appliquée la présente invention. Ces flux arrivent tous à l'application destination 1601 hébergée par le PAN1 1000, et sont, chacun, originaires de l'une des sources 1615 hébergée par le PAN2 1014, 1619 hébergée par le PAN3 1018 et 1623 hébergée par le PAN4 1022. Lorsqu'un ensemble de flux de données audio/vidéo est transmis par un ensemble de sources vers une même destination, les différents chemins qu'ils empruntent engendrent des différences de temps de transport (différences de latences) et donc des instants de présentation, pour des données capturées (ou générées) à un même instant, différents sur la destination. Dans le cas où tous les PAN sont synchronisés en phase nulle, ce qui n'est pas nécessairement le cas pour la mise en oeuvre de la présente invention, ces différences de latences s'expriment en nombre entier de cycles TDM. L'utilisation d'une topologie appropriée, telle que celle décrite en figure 16, dans le cas où la latence est identique sur chaque lien d'InterConnect, permet de résoudre ce problème. Les décalages existants entre les cycles TDM des différents PAN et les mécanismes qu'ils impliquent induisent de la latence, ou déphasage, supplémentaire, propre à chaque chemin. Pour un chemin particulier, cette latence supplémentaire est la somme des latences induites par la traversée des différentes interfaces port/commutateur rencontrées sur le chemin, pour lesquelles on observe un décalage entre les signaux SDPC du commutateur et du port. Elle peut se décomposer sous la forme a*période SDPC + b, où a est un entier représentant le nombre de cycles entiers SDPC de latence induite par les traitements précédemment cités, et où b représente la latence due au décalage existant entre les cycles SDPC de la source et ceux de la destination. La valeur de b est donc inférieure à la période d'un cycle SDPC. Pour assurer une présentation simultanée des données à l'application destination, on calcule et applique une compensation supplémentaire différente pour chaque flux, plus précise que la période SDPC, au niveau de l'application destination, compensation qui palie les différences entre les latences supplémentaires des différent chemins. La figure 17 présente une illustration de cette compensation. Les axes temporels 1700, 1701, 1702 et 1703 correspondent respectivement aux évènements relatifs au PAN1 1000 hébergeant l'application destination 1601 des flux audio/vidéo, au PAN2 1014 hébergeant l'application source 1615, au PAN3 1018 hébergeant l'application source 1619, et au PAN4 1022 hébergeant l'application source 1623. Dans le cadre d'une mise en oeuvre où des flux de données audio/vidéo sont transmis par plusieurs destinations vers une même source, on réalise, dans un premier temps, une phase de détermination des latences induites par les décalages de cycles TDM entre chacune des applications sources 1615, 1619 et 1623, et l'application destination 1601. L'évènement 1709 correspond au début du cycle de départ virtuel des données des applications sources dans le cas où tous les cycles TDM auraient été en phase. L'évènement 1710 correspond au début du cycle de départ réel, c'est-à-dire en prenant en compte le décalage des cycles SDPC, des données de la source 1615 connectée au PAN2 1014, l'évènement 1711 correspond au début du cycle de départ réel des données de la source 1619 connectée au PAN3 1018, l'évènement 1712 correspond au début du cycle de départ réel des données de la source 1623 connectée au PAN4 1022. Les différentes valeurs de latence supplémentaire correspondantes sont représentées respectivement par les durées 1704, 1706 et 1705. On mesure, dans un premier temps, les latences induites par les décalages de cycles TDM entre chacune des applications sources 1615, 1619 et 1623 et la destination 1601. Puis, on sélectionne le noeud du PAN hébergeant l'application source pour laquelle la latence supplémentaire (le décalage de chemin par la suite) est la plus grande comme application source de référence et le chemin correspondant comme chemin de référence . Le flux généré par cette application source de référence n'a pas besoin de compensation. En revanche, les flux issus des autres applications sources ont besoin d'une compensation pour ajuster leurs temps de présentation aux applications sur celui de présentation du flux de la source de référence. Cette compensation est déterminée dans un deuxième temps, comme exposé en regard de la figure 19 et correspond, pour chaque flux, à la différence entre le décalage de chemin déterminé pour le flux de données issu de la source de référence transitant sur le chemin de référence et celui déterminé pour le flux issu de la source concernée. En figure 17, on observe la durée de compensation 1707 pour le flux issu de la source 1619, et la durée de compensation 1708 pour le flux issu de la source 1623. Ainsi, les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination sont égales lorsque l'application destination est commune pour lesdites données. La figure 18a illustre le processus mis en oeuvre par le noeud hébergeant la destination ( noeud destination dans la suite). Au cours d'une étape 1801, le noeud destination construit un message de mesure de décalage et l'envoie à chaque noeud ( noeud source dans la suite) hébergeant une source, afin de déterminer la latence induite par le parcours du chemin entre le noeud source concerné et le noeud destination. Ces messages contiennent, en plus des informations nécessaires à leur acheminement, un champ type_flux , prenant dans le cas présent la valeur plusieurs_vers_un . Les réponses à ces messages sont interceptées par chaque port traversé sur leur chemin de retour, donc dans le sens que suit le flux de données, de chaque source vers la destination, et chaque port additionne la latence induite par sa traversée à la valeur de cumul déjà contenue dans la réponse. Les réponses, une par noeud hébergeant une source, sont reçues par la destination commune, au cours d'une étape 1802. Une fois les valeurs de décalage de chemin pour chaque source extraites de ces réponses, la source correspondant au décalage de chemin le plus élevé ( décalage_ref dans la suite) est élue source de référence et le chemin correspondant est élu chemin de référence , au cours d'une étape 1803.

Pour chaque chemin identifié au cours d'une itération 1804, à l'exception du chemin de référence, la compensation à appliquer est calculée au cours d'une étape 1805 comme suit : compensation_de_décalage_src_i = décalage_ref û décalage_src_i. décalage_src_i est la valeur du décalage de chemin, calculée pour le chemin considéré. Cette valeur vaut 0 pour le chemin de référence. La valeur compensation_de_décalage_src_i est ensuite mémorisée dans une table des compensations 1810 illustrée en figure 18b. Chaque entrée de cette table 1810 correspond à un flux, repéré par le champ 1811 contenant la liste des canaux virtuels par lesquels les données arriveront. Chaque entrée de cette table 1810 comporte aussi un champ compensation de décalage 1812, qui reçoit la valeur calculée au cours de l'étape 1805. La figure 19 présente le traitement déclenché par la réception d'un message de mesure de décalage par un noeud auquel est connectée une source, au cours d'une étape 1900. Au cours d'une étape 1901, on détermine si le champ type_flux vaut un_vers_plusieurs . Si oui, le traitement est celui décrit en figure 14. Sinon, un message de réponse au message de mesure de décalage est construit et renvoyé vers la destination au cours d'une étape 1902. Cette réponse comporte notamment un champ type_flux , prenant dans le cas présent la valeur plusieurs_vers_un et un champ cumul_de_latence , qui est mis à jour par les différents ports traversés. La figure 20 présente les opérations effectuées par les ports lorsqu'ils interceptent une réponse à un message de mesure de décalage au cours d'une étape 2000. Ces messages sont détectés par le canal virtuel sur lequel ils circulent en fonction de leur entête. Lorsqu'un de ces messages est intercepté, au cours d'une étape 2001, on détermine si le signal SDPC_décalé vaut vrai , c'est-à-dire si le signal SDPC du port n'est pas en phase avec celui du commutateur auquel il est connecté, et si la valeur de type_flux extraite du message est égale à plusieurs_vers_un . Si oui, il n'y a pas de traitement particulier à faire. Le message est donc transmis vers sa destination, au cours d'une étape 2002. Dans le cas contraire, la valeur de cumul de décalage contenue par le message est extraite, au cours d'une étape 2003. Au cours d'une étape 2004, on détermine si le message arrive du commutateur. Sinon, au cours d'une étape 2005, on détermine si le décalage entre les cycles SDPC du port et du commutateur est supérieur ou égal à la valeur période SDPC ù intervalle de garde . Sinon, on ajoute à la valeur extraite du message la valeur d'une période SDPC additionnée à la valeur du décalage entre les cycles SDPC du port et du commutateur au cours d'une étape 2006 (en figure 8a et 8b, on attend un cycle plus le décalage avant de sortir les données du tampon). Puis la valeur de cumul de latence ainsi calculée est réinsérée dans le message, au cours d'une étape 2008, avant que ce message ne soit transmis vers sa destination au cours d'une étape 2002. Si le décalage entre les cycles SDPC du port et du commutateur est supérieur ou égal à la valeur période SDPC ù intervalle de garde , on ajoute à la valeur extraite du message, la valeur du décalage entre les cycles SDPC du port et du commutateur, au cours d'une étape 2009 (en figure 8a et 8b, on attend le décalage avant de sortir les données du tampon). Puis on passe à l'étape 2008. Si le résultat de l'étape 2004 est positif, au cours d'une étape 2010, on détermine si le décalage entre les cycles SDPC du port et du commutateur est inférieur à la valeur de l'intervalle de garde. Sinon, au cours d'une étape 2011, on ajoute à la valeur extraite du message, la valeur de deux périodes SDPC moins la valeur du décalage entre les cycles SDPC du port et du commutateur (en figure 9a et 9b, on attend un cycle plus le complément du décalage avant de sortir les données du tampon; le décalage étant toujours mesuré entre un front montant du signal SDPC du port et le front montant suivant du signal SDPC du commutateur). Puis on passe à l'étape 2008. Enfin, si le résultat de l'étape 2010 est positif, au cours d'une étape 2012, on ajoute à la valeur extraite du message la valeur d'une période SDPC moins la valeur du décalage entre les cycles SDPC du port et du commutateur (en figure 9a et 9b, on attend le complément du décalage avant de sortir les données du tampon; le décalage étant toujours mesuré entre un front montant du signal SDPC du port et le front montant suivant du signal SDPC du commutateur). Puis on passe à l'étape 2008. La figure 21 présente le traitement fait à la réception d'un flux de données par l'application destination commune. Ce traitement est fait pour chaque flux reçu, indépendamment des autres flux. Au cours d'une étape 2100, on attend l'arrivée des premières données. Ces données sont transmises par l'intermédiaire d'un ou de plusieurs canaux virtuels, qui sont vides (c'est-à-dire que le contenu du canal virtuel est NULL ) jusqu'à ce que le début du flux atteigne le noeud hébergeant la destination. Au cours d'une étape 2101, on attend un front montant du signal SDPC. Puis, au cours d'une étape 2102, on détermine si le contenu du canal virtuel est NULL (c'est-à-dire si le canal virtuel est vide). Si oui, on retourne à l'étape 2101. Sinon, à l'arrivée des premières données, ces premières données sont stockées dans une mémoire tampon de type FIFO, au cours d'une étape 2103. Puis, on attend une durée égale à la valeur de compensation de décalage calculée au cours de l'étape 1805, avant de générer l'horloge applicative permettant à l'application de lire les données, au cours d'une étape 2105. Ainsi, le noeud destination retarde la présentation de données à l'application destination en fonction des sommes de déphasages introduits par les commutateurs présents sur les chemins de données, de telle manière que les durées totales écoulées entre émission de données par une application source et présentation des dites données à l'application destination soient égales.

Claims (1)

1. REVENDICATIONS1. Procédé de synchronisation dans un réseau comportant des sous-réseaux synchrones reliés entre eux par des commutateurs, pour la communication de données transmises sur une pluralité de chemins allant, chacun, d'une application source à une application destination, caractérisé en ce qu'il comporte : - pour chaque dit chemin, une étape de détermination de la somme des déphasages successifs introduits par les commutateurs présents sur ledit chemin, et - lors d'au moins une réception de données, par un noeud hébergeant une application destination desdites données, une étape d'application d'une compensation de déphasage au cours de laquelle ledit noeud destination retarde la présentation de données à ladite application destination en fonction de ladite somme de déphasages pour chaque chemin suivi par des dites données, de telle manière que les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination soient égales lorsque l'une des applications, source ou destination, est commune pour lesdites données. 2 û Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de détermination de sommes de déphasages, on fait parcourir chaque dit chemin par un message comportant un champ dont la valeur est incrémentée des déphasages successifs introduits par les commutateurs présents sur ledit chemin. 3 û Procédé selon la revendication 2, caractérisé en ce que, au cours de l'étape de détermination de sommes de déphasages, on fait parcourir chaque dit chemin par ledit message depuis l'application source vers l'application destination définies par ledit chemin. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte, en outre, une étape de sélection d'un cheminde référence et au cours de l'étape d'application d'une compensation de déphasage, pour chaque donnée véhiculée sur un chemin à l'exception du chemin de référence, on retarde la présentation de données d'une durée égale à la différence entre la somme des déphasages pour ledit chemin et la somme des déphasages pour le chemin de référence. 5. Procédé selon la revendication 4, caractérisé en ce que, au cours de l'étape de sélection d'un chemin de référence, on sélectionne le chemin présentant la somme de déphasages la plus importante. 6. Procédé selon l'une quelconque des revendications 1 ou 5, caractérisé en ce que, au cours de l'étape de détermination de sommes de déphasages, on détermine une somme de déphasages entre les fronts montants de cycles de sous-réseau liés aux commutateurs présents sur un chemin. 7. Procédé selon la revendication 6, caractérisé en ce que, au cours de l'étape de détermination de sommes de déphasages, chaque port d'un commutateur présent sur un dit chemin mesure un déphasage de fronts montants entre le sous réseau auquel il est connecté et ledit commutateur. 8. Procédé selon la revendication 7, caractérisé en ce que, au cours de l'étape de détermination de sommes de déphasage, chaque dit port ajoute le déphasage de fronts qu'il mesure et une somme de déphasages transmise dans un message en provenance d'une application source. 9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, l'application commune étant une application destination, au cours de l'étape de détermination de sommes de déphasage, ladite application destination émet à destination de chaque application source, un message requérant une mesure de somme de déphasages. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que, au cours de l'étape d'application d'une compensation de déphasage, on retarde un instant de présentation de données à une application destination dans une couche présentation des données . 11. Dispositif de synchronisation dans un réseau comportant des sous-réseaux synchrones reliés entre eux par des commutateurs, pour lacommunication de données transmises sur une pluralité de chemins allant, chacun, d'une application source à une application destination, caractérisé en ce qu'il comporte : - des moyens de détermination, pour chaque dit chemin, de la 5 somme des déphasages successifs introduits par les commutateurs présents sur ledit chemin, et - des moyens d'application d'une compensation de déphasage adapté, lors d'au moins une réception de données, par un noeud hébergeant une application destination desdites données, à retarder la présentation de 10 données à ladite application destination en fonction de ladite somme de déphasages pour chaque chemin suivi par des dites données, de telle manière que les durées totales écoulées entre émission de données par une application source et présentation de données à une application destination soient égales lorsque l'une des applications, source ou destination, est commune pour 15 lesdites données. 12. Programme d'ordinateur chargeable dans un système informatique (100), ledit programme contenant des instructions permettant la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 10. 13. Support d'informations lisibles par un ordinateur (100) ou un 20 microprocesseur (120), amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 10.