FR2931021A1 - Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. - Google Patents
Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. Download PDFInfo
- Publication number
- FR2931021A1 FR2931021A1 FR0853057A FR0853057A FR2931021A1 FR 2931021 A1 FR2931021 A1 FR 2931021A1 FR 0853057 A FR0853057 A FR 0853057A FR 0853057 A FR0853057 A FR 0853057A FR 2931021 A1 FR2931021 A1 FR 2931021A1
- Authority
- FR
- France
- Prior art keywords
- data
- synchronization
- symbol
- application
- symbols
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
- H04J3/1605—Fixed allocated frame structures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0602—Systems characterised by the synchronising information used
- H04J3/0605—Special codes used as synchronising signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/07—Synchronising arrangements using pulse stuffing for systems with different or fluctuating information rates or bit rates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
- H04L1/0079—Formats for control data
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Il est proposé un procédé de synchronisation d'un flux de données transmis sur un réseau de communication depuis un dispositif émetteur recevant des données applicatives d'une application émettrice, et transmettant à un dispositif récepteur des conteneurs de données comprenant des données applicatives ainsi que des données de bourrage dites symboles de synchronisation.Plus précisément, sur détection d'un symbole de perte de données pendant un cycle réseau courant, l'invention permet de déterminer de manière instantanée la nature des données perdues, applicative ou de bourrage, et ce afin de réaliser le remplacement dans ledit flux dudit symbole de perte par un symbole de marquage de données applicatives erronées, s'il résulte de ladite prédiction que les données perdues correspondent à des données applicatives, ou par un symbole de synchronisation, s'il résulte de ladite prédiction que les données perdues correspondent à un symbole de synchronisation. Le synchronisme entre les différents dispositifs récepteurs est ainsi conservé.
Description
Procédé de synchronisation d'un flux de données transmis sur un réseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif récepteur correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des systèmes de communications synchrones. Plus précisément, l'invention concerne une technique permettant de gérer, suite à la perte de données applicatives, le synchronisme entre au moins deux noeuds récepteurs d'un même système de communication, tel que par exemple un système audio à n voies. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Pour un système de communication synchrone sans fil, ou plus généralement pour un système de communication synchrone doté d'un mode de transport non fiable, une bande passante fixe est réservée pour le transport d'un flux isochrone à débit constant. La réservation se fait au travers de canaux virtuels à débit constant.
De manière classique, l'agrégation des débits des canaux virtuels est toujours supérieure au débit nécessaire au transport du flux isochrone à débit constant. En effet, si le débit du flux isochrone n'est pas entièrement divisible par le débit d'un canal virtuel, alors un débit supérieur est réservé afin de garantir le transport du flux isochrone. Si le débit du flux isochrone est exactement divisible par le débit d'un canal virtuel, alors le transport du flux isochrone est théoriquement possible au travers du nombre de canaux virtuels obtenu par la division du débit du flux synchrone par le débit d'un canal virtuel. Mais pour une application multi-canal audio par exemple, le fait que l'horloge applicative régissant la génération du flux isochrone et l'horloge réseau cadençant un cycle TDM (pour Time Division Multiplexing en anglais) du réseau sont indépendantes l'une de l'autre ne permet pas de garantir l'exacte concordance des débits à chaque cycle TDM du réseau synchrone. Il est alors nécessaire de réserver de la bande passante supplémentaire afin de garantir le transport certain de la totalité du flux isochrone.
De ce fait, sur l'ensemble des canaux virtuels alloués au transport d'un flux isochrone à débit constant, le dernier canal virtuel n'est pas utilisé systématiquement à chaque cycle TDM du réseau synchrone. Classiquement, des données de bourrage ( padding en anglais), encore appelées symboles de synchronisation ou symboles NULL dans la suite de la description, sont insérées dans ces canaux virtuels non utilisés. Ces données de bourrage sont explicitement marquées en tant que telle et servent uniquement à s'assurer qu'un nombre identique de données est envoyé à chaque cycle TDM.
Ainsi, toute la séquence des canaux virtuels à chaque cycle TDM est transportée en insérant ces symboles de bourrage à l'emplacement des canaux vides. Le cadencement des données d'un flux sur un noeud récepteur est ainsi simplifié. Cependant, dans le cadre d'un système de transport non fiable et en cas de pertes de données, il est impossible de savoir si le contenu d'un canal virtuel perdu lors d'un cycle TDM correspondait à des données réelles fournies par une application et destinées à être transportées, ou bien si ces données étaient simplement des données de bourrage. Le problème de ne pas connaître la nature du contenu des canaux virtuels perdus (présence ou non de données) est particulièrement sensible dans le cas d'un ensemble de flux de données devant être synchronisés entre eux, comme c'est le cas pour une application à multi-canal audio du type home cinéma 5.1. En effet, dans une telle application, un canal audio peut être envoyé à plusieurs destinations différentes, ce qui nécessite que les échantillons audio de chaque flux isochrone émis au même instant doivent être traités en même temps et dans le même ordre par chaque destination.
La garantie de synchronisme est ainsi obtenue par le fait d'envoyer le même nombre de données à chaque noeud destinataire (chaque noeud traite le même nombre de données). Des méthodes de synchronisation de flux de données connues de l'Homme du Métier sont basées sur des couches protocolaires, au sein des dispositifs générateurs de données isochrones, qui utilisent des techniques d'horodatage des données qui permettent de définir à quel moment les données doivent être fournies, au niveau du dispositif récepteur, à la couche protocolaire supérieure. Cependant, ces mécanismes nécessitent le calcul de ces données d'horodatage et augmentent ainsi la latence de transport. De plus, ces mécanismes nécessitent une synchronisation précise et absolue des horloges internes des dispositifs émetteur et récepteur(s) afin que ceux-ci disposent de la même référence temporelle. Or, en l'absence d'horodatage, si un noeud perd des données sans savoir combien de données ont été perdues (en présence de symboles de synchronisation ou non), alors ce noeud risque de décaler la restitution de son flux isochrone par rapport à d'autres noeuds ayant correctement reçu les données. Dans le cas d'une application multi-canal audio, la restitution sonore des récepteurs risque alors de générer un écho sonore. Actuellement, plusieurs techniques utilisent des symboles de synchronisation. Ainsi, des réseaux de communications synchrones tels que SONET (pour Synchronous Optical Networking en anglais) à base de fibres optiques utilisent des symboles de synchronisation pour indiquer une absence de flux. Cependant, les transmissions par fibres optiques sont très fiables et les pertes de données sur de tels supports sont rares. Ainsi, des techniques de gestion des pertes de symboles de synchronisation n'ont pas lieu d'être. Des technologies telles que HDLC (pour High Level Data Link Control en anglais) utilisent également un symbole NULL , pour compléter une trame de données lorsqu'un transmetteur est à cours de données, tel que décrit dans un document de brevet US 5,410,536. Dans ce document US 5,410,536, la perte de données est gérée par un système d'acquittement et de retransmission. Un tel système de gestion d'erreur n'implique pas le besoin de déterminer la nature des données perdues, c'est-à-dire de savoir si la donnée perdue est une donnée réelle d'une trame de données ou bien un symbole NULL . Egalement, du fait des délais causés par la retransmission, cette technique n'est pas adaptée pour un transport de données de type audio et/ou vidéo nécessitant un transport de données en flux synchrone et constant.
Un autre document US 5,896,388 décrit un mode transport de données synchrones sur un réseau asynchrone utilisant une boucle à verrouillage de phase (ou PLL pour Phase-Locked Loop en anglais ) afin de reconstituer l'horloge d'émission au niveau du noeud récepteur. Cette technique permet de gommer les variations de délais de transmission inhérentes au réseau asynchrone, d'une part en stockant temporairement une certaine quantité de données en réception, et d'autre part en lisant les données à partir du stockage temporaire à un rythme quasi constant, le rythme étant accéléré si le stockage se remplit trop vite ou bien ralentit si le stockage se vide trop vite. Cette technique permet de reconstituer approximativement l'horloge de transmission s'il n'y a pas de perte de données dans le réseau asynchrone. Cette technique insère des données système lorsqu'une perte de données applicatives est détectée, ceci afin de compenser la perte de données et respecter le taux de remplissage du stockage temporaire. Cependant, cette technique ne permet pas de déterminer la nature des données perdues (données applicatives ou système). Un autre système tel que décrit dans le document US 6658027 permet de gérer le stockage temporaire de réception en supprimant ou en ajoutant des données selon que le stockage se vide trop ou pas assez vite, afin de corriger le synchronisme du réseau Cependant, ces systèmes n'utilisent pas de méthodes de détermination du type des pertes de données. 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. La présente invention a notamment pour objectif d'assurer le synchronisme des données par identification des données perdues lors du transport d'une séquence systématique de canaux virtuels servant au transport d'un flux isochrone à débit constant. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de synchronisation d'un flux de données transmis sur un réseau de communication synchrone mettant en oeuvre un cadencement définissant un cycle réseau : - depuis un dispositif émetteur recevant des données applicatives d'une application émettrice, et transmettant à un dispositif récepteur, via au moins un canal virtuel dudit réseau affecté à ladite application émettrice, des conteneurs de données comprenant lesdites données applicatives ainsi que des données de bourrage dites symboles de synchronisation ; - ledit dispositif récepteur transmettant à une application réceptrice les données applicatives contenues dans lesdits conteneurs de données ; Ce procédé est remarquable en ce que le dispositif récepteur effectue les étapes suivantes, pour au moins un canal virtuel affecté à ladite application émettrice : - obtention d'un motif récurrent d'utilisation dudit canal ou des canaux virtuel(s), ledit motif étant défini par une période comprenant une séquence d'un nombre déterminé de cycles réseau, avec une indication du ou des cycles réseau de ladite séquence dans lequel ou lesquels un symbole de synchronisation est supposé être émis ; - sur détection d'un symbole de perte de données pendant un cycle réseau courant, prédiction de la nature, applicative ou de bourrage, desdites données perdues, en fonction d'un positionnement dudit cycle réseau courant dans ledit motif ; - remplacement dans ledit flux dudit symbole de perte par un symbole de marquage de données applicatives erronées, s'il résulte de ladite prédiction que les données perdues correspondent à des données applicatives, ou par un symbole de synchronisation, s'il résulte de ladite prédiction que les données perdues correspondent à un symbole de synchronisation. Ainsi, le procédé selon l'invention permet de déterminer de manière instantanée la nature des données perdues, ce qui a l'avantage de garder une durée de transaction constante (contrairement au système basé sur des acquittements et retransmission en cas de perte de données). Le synchronisme entre les différents dispositifs récepteurs est ainsi conservé. De façon avantageuse ladite étape de prédiction comprend les étapes suivantes : - lancement sur un début de période du motif identifié, d'un compteur de cycles réseau modulo la période dudit motif ; - prédiction de la nature desdites données perdues, en fonction de la valeur dudit compteur de cycles réseau pour le cycle courant.
Ainsi, le résultat de la prédiction est vérifié. Notamment, cette étape de vérification de la prédiction antérieure est plus avantageuse que de vérifier la continuité des données applicative, les données système étant moins nombreuses. Dans un mode de réalisation particulier de l'invention, le dispositif récepteur effectue les étapes suivantes : - comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte de données remplacés par des symboles de synchronisation ; - réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - si ledit nombre de symboles de synchronisation émis est supérieur audit nombre de symboles de synchronisation reçus, remplacement, dans ledit flux, de données applicatives par un symbole de synchronisation. La correction de prédiction se fait donc en substituant des données applicatives par des symboles de synchronisation dès lors que le nombre de symboles de synchronisation prédit n'est pas suffisant. Cette étape de correction de prédiction permet ainsi de garder la synchronisation de l'ordonnancement des flux isochrones d'une application multi-canal en cas de pertes de donnée par un ou plusieurs noeuds et de diminuer les effets de pertes de données lors de la restitution du flux applicatif émetteur. Dans un autre mode de réalisation particulier de l'invention, le dispositif récepteur effectue les étapes suivantes : - comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte remplacés par des symboles de synchronisation ; - réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - si ledit nombre de symboles de synchronisation émis est inférieur audit nombre de symboles de synchronisation reçus, remplacement d'un symbole de synchronisation par un symbole de marquage de données applicatives erronées. La correction de prédiction se fait donc en substituant des symboles de synchronisation par des données applicatives marquées comme incorrectes dès lors que le nombre de symboles de synchronisation prédit est trop important. Cette étape de correction de prédiction permet ainsi de garder la synchronisation de l'ordonnancement des flux isochrones d'une application multi-canal en cas de pertes de donnée par un ou plusieurs noeuds et de diminuer les effets de pertes de données lors de la restitution du flux applicatif émetteur. Selon une caractéristique avantageuse, chaque symbole de synchronisation comprend une information représentative du nombre de symboles de synchronisation antérieurement présents dans ledit flux. Ainsi, aucune bande passante supplémentaire n'est requise pour la transmission de l'information permettant de vérifier la prédiction faite par le dispositif récepteur, les symboles de synchronisation (données de bourrage) étant adaptés à cet effet. De plus, cela permet dans le cas où le nombre de symboles de synchronisation antérieurement prédit est trop important, et qu'un symbole de synchronisation doit être substitué par un symbole de marquage de données applicatives erronées, que cette opération soit effectuée directement sur le symbole de synchronisation ayant permis de détecter que le nombre de symboles de synchronisation antérieurement prédit est trop important. Ainsi, la correction de synchronisation est réactive. Avantageusement, ladite étape d'obtention d'un motif récurrent comprend une étape d'identification dudit motif par détection d'une séquence de cycles réseau comprenant deux ensembles successifs de cycles réseau, l'un desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un conteneur de données applicatives et l'autre desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un symbole de synchronisation. Ainsi, l'apprentissage de la période d'insertion des symboles de synchronisation par moyenne des périodes observées permet de s'adapter à tout type de flux isochrone, c'est-à-dire à toute fréquence d'échantillonnage des données, notamment audio. Cette phase d'apprentissage permet notamment plus de souplesse en cas de changement de nature du flux isochrone. Le calcul d'une moyenne pour l'apprentissage de la période permet en outre de s'affranchir des problèmes de dérives des horloges réseau et applicatives L'invention concerne également 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 et comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon l'invention, lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne encore 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é selon l'invention. L'invention concerne en outre un dispositif récepteur d'un flux de données transmis sur un réseau de communication synchrone mettant en oeuvre un cadencement définissant un cycle réseau : - depuis un dispositif émetteur recevant des données applicatives d'une application émettrice, et transmettant audit dispositif récepteur, via au moins un canal virtuel dudit réseau affecté à ladite application émettrice, des conteneurs de données comprenant lesdites données applicatives ainsi que des données de bourrage dites symboles de synchronisation ; - ledit dispositif récepteur transmettant à une application réceptrice les données applicatives contenues dans lesdits conteneurs de données ; Ce dispositif récepteur est remarquable en ce qu'il comprend, pour au moins un canal virtuel affecté à ladite application émettrice : - des moyens d'obtention d'un motif récurrent d'utilisation dudit canal ou des canaux virtuel(s), ledit motif étant défini par une période comprenant une séquence d'un nombre déterminé de cycles réseau, avec une indication du ou des cycles réseau de ladite séquence dans lequel ou lesquels un symbole de synchronisation est supposé être émis ; - des moyens de détection d'un symbole de perte de données pendant un cycle réseau courant, prédiction de la nature, applicative ou de bourrage, desdites données perdues, en fonction d'un positionnement dudit cycle réseau courant dans ledit motif ; - des moyens de remplacement dans ledit flux dudit symbole de perte par un symbole de marquage de données applicatives erronées, s'il résulte de ladite prédiction que les données perdues correspondent à des données applicatives, ou par un symbole de synchronisation, s'il résulte de ladite prédiction que les données perdues correspondent à un symbole de synchronisation.
Avantagusement, ce dispositif récepteur comprend : - des moyens de lancement sur un début de période du motif identifié, d'un compteur de cycles réseau modulo la période dudit motif ; - des moyens de prédiction de la nature desdites données perdues, en fonction de la valeur dudit compteur de cycles réseau pour le cycle courant. De manière avantageuse, ce dispositif récepteur comprend également: - des moyens de comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte de données remplacés par des symboles de synchronisation ; - des moyens de réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - des moyens de remplacement, dans ledit flux, de données applicatives par un symbole de synchronisation si ledit nombre de symboles de synchronisation émis est supérieur audit nombre de symboles de synchronisation reçus.
Selon une autre caractéristique avantageuse, ce dispositif récepteur comprend : - des moyens de comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte remplacés par des symboles de synchronisation ; - des moyens de réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - des moyens de remplacement d'un symbole de synchronisation par un symbole de marquage de données applicatives erronées si ledit nombre de symboles de synchronisation émis est inférieur audit nombre de symboles de synchronisation reçus. De manière avantageuse, chaque symbole de synchronisation comprend des moyens de renseignement d'une information représentative du nombre de symboles de synchronisation antérieurement présents dans ledit flux. Egalement, ce dispositif récepteur comprend des moyens d'identification du motif récurrent par détection d'une séquence de cycles réseau comprenant deux ensembles successifs de cycles réseau, l'un desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un conteneur de données applicatives et l'autre desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un symbole de synchronisation. 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 et des dessins annexés, dans lesquels : - la figure 1 illustre un système implémentant un mode de réalisation de l'invention; - la figure 2 illustre schématiquement l'architecture d'un dispositif (émetteur ou récepteur) selon un mode de réalisation de l'invention; - la figure 3 illustre schématiquement la structure des données transitant par les différents modules du dispositif émetteur ou récepteur de la figure 1; - la figure 4 illustre un exemple de succession dans le temps de conteneurs de données et de symboles de synchronisation pour un canal virtuel donné; - La figure 5 illustre schématiquement la structure d'un module de réception Synchro RX du dispositif récepteur de la figure 1; - La figure 6 illustre schématiquement la structure d'un module de transmission Synchro TX du dispositif émetteur de la figure 1; - La figure 7 illustre un organigramme des différentes étapes effectuées par un bloc de contrôle de réception RX Controller du module de réception Synchro RX de la figure 5 ; - La figure 8 illustre un organigramme des différentes étapes effectuées, lors d'une phase dite initiale, par un module de prédiction VC Predictor du module de réception Synchro RX de la figure 5 ; - La figure 9 illustre un organigramme des différentes étapes effectuées, lors d'une phase dite de prédiction, par un module de prédiction VC Predictor du module de réception Synchro RX de la figure 5; - La figure 10 illustre un organigramme des différentes étapes effectuées par un bloc de transmission TX Controller du module de transmission Synchro TX de la figure 6; - La figure 11 illustre un organigramme des différentes étapes effectuées, lors d'une phase dite initiale avec apprentissage, par le module de prédiction VC Predictor du module de réception Synchro RX de la figure 5. 6. DESCRIPTION DÉTAILLÉE La présente invention concerne une technique permettant d'assurer le synchronisme des données par identification, par un dispositif récepteur, du type (ou nature) de données perdues lors du transport d'un flux isochrone à débit constant dont les données sont émises par un dispositif émetteur au moyen de canaux virtuels d'un réseau de communication synchrone selon un ensemble et une séquence prédéterminés de canaux virtuels dudit réseau de communication synchrone. Par la suite, un exemple d'implémentation de l'invention est décrit pour un système audio 8 voies basé sur un système de communication sans fil. La figure 1 illustre un exemple un tel système de communication à 60GHz constitué de 9 noeuds de communication.
Plus particulièrement, le système comprend : - 8 noeuds la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type récepteur audio sans fil (ou WAR pour Wireless Audio Renderer en anglais) dont chacun est équipé de moyens de restitution de canal audio numérique intégrant chacun un haut-parleur (ou speaker en anglais), respectivement lb, 2b, 3b, 4b, 6b, 7b, 8b, 9b et, - un noeud 5a de type décodeur audio sans fil (ou WAD pour Wireless Audio Decoder comprenant un décodeur audio multi voies 5b (ou Surround Sound Decoder en anglais). Par exemple, le décodeur audio multi voies 5b est intégré dans un écran plat et susceptible de transmettre de manière parfaitement synchronisée, via le système de communication à 60GHz, les différents canaux audio associés à la vidéo affichée sur l'écran. Chacun des dispositifs la, 2a, 3a, 4a, 5a, 6a, 7a, 8a, et 9a, intègre un dispositif de communication, encore appelé module de communication synchrone (ou SCM pour Synchronous Communication Module en anglais), respectivement 1, 2, 3, 4, 5, 6, 7, 8, 9.
Particulièrement, chaque dispositif récepteur intègre les différents moyens conformément à l'invention. L'ensemble de la bande passante disponible est découpée 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 (ou VC pour Virtual Channel en anglais) possède un débit constant de 384 Kbps (kilobits par seconde). Une séquence complète comprend ainsi un échantillon de chacun des canaux virtuels disponibles et constitue un cycle complet de traitement de données synchrones (ou SDPC pour Synchronous Data Processing Cycle en anglais) de durée égale à 125 s dans le cas d'une fréquence de traitement de 8KHz des canaux virtuels. Par exemple, un canal audio de résolution 96KHz-24bits utilisera donc 6 canaux virtuels. Pour un système complet 8 voies (classiquement appelé 7.1), un total de 48 canaux virtuels est donc nécessaire. Le débit utile nécessaire est alors de 18,432 mégabits par seconde uniquement pour le transfert de l'information audio. Si à cela s'ajoute 10 canaux virtuels alloués à l'ensemble des noeuds de transmission du système pour le transfert d'informations supplémentaires (contrôle du système, protocole, commande utilisateur,...), un cycle SDPC est alors composé de 58 canaux virtuels, soit un débit utile de 22,272 mégabits par seconde Les canaux virtuels 48 à 57 sont décodés puis traités par tous les noeuds pour l'échange de manière synchrone de données supplémentaires. Ainsi, à chaque module de communication synchrone émetteur, ou dispositif émetteur, se trouve alloué au moins un canal virtuel pour l'émission de ces données supplémentaires à destination de tous les autres dispositifs récepteurs.
Les données audio transportées dans ces canaux virtuels forment ainsi un flux de données synchrones ( synchronous data stream en anglais). Ainsi, tel que décrit précédemment, un canal audio constitue un flux de données synchrones transporté dans 6 canaux virtuels, ce nombre de canaux virtuels état défini par l'échantillonnage de l'application audio émettrice à l'aide de l'horloge du réseau synchrone. Pour des questions de simplicité de mise en oeuvre et de limitation des informations de signalisation, notamment en évitant la transmission d'indication de taille de données, les canaux virtuels ne contiennent des données applicatives que lorsque celles-ci sont en nombre suffisant pour permettre le remplissage complet du canal virtuel. Cependant, le rapport entre l'horloge applicative émettrice et l'horloge réseau n'est pas forcément entier. L'utilisation du dernier canal virtuel affecté à la transmission du flux de données synchrones n'est donc pas forcément systématique pendant un cycle SDPC. Ainsi, de manière cyclique, aucune donnée n'est insérée par l'application émettrice dans ce dernier canal virtuel. Afin de simplifier le transport des canaux virtuels sur le réseau et de maintenir son caractère synchrone, tous les canaux virtuels affectés à la transmission d'un flux de données sont acheminés à chaque cycle SDPC et ce même lorsqu'un canal virtuel est vide, c'est-à-dire lorsque le dispositif émetteur n'a écrit aucune donnée durant le cycle. Un symbole de synchronisation est alors substitué par le module de communication synchrone à chaque canal virtuel vide. Le réseau transporte donc toujours la même séquence de canaux virtuels à chaque cycle SDPC permettant ainsi de s'affranchir de l'utilisation de moyens d'identification des canaux virtuels transportés. Un symbole de synchronisation n'étant pas une donnée générée par l'application émettrice, il ne doit pas être retransmis par un module de communication synchrone récepteur vers l'application réceptrice destinataire du flux de données.
Au niveau des noeuds récepteurs la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type WAR, les flux de données synchrones du canal audio sont re-générées par la lecture des canaux virtuels au rythme de l'horloge du réseau synchrone. Puis les données sont échantillonnées au rythme de l'application réceptrice. Il est donc nécessaire de reproduire exactement le nombre de données envoyées par le noeud émetteur 5a de type WAD afin de maintenir la synchronisation de l'échantillonnage. La présence de symboles de synchronisation dans les données reçues du réseau doit alors être détectée par le dispositif récepteur, ceux-ci servant à assurer le cadencement de la transmission, mais ne devant pas être transmis vers l'application réceptrice destinataire des données du flux de données.
Ainsi, une perte de données détectée par le dispositif récepteur sur le dernier canal virtuel affecté à la transmission d'un flux de données synchrones pendant un cycle SDPC est problématique. En effet, le maintien de la synchronisation de l'échantillonnage nécessite de connaître, pour chaque canal perdu, si la donnée perdue était une donnée applicative réelle ou bien un symbole de synchronisation. Une telle donnée perdue est identifiée par un symbole MISSING tel que décrit dans la suite de la description. La figure 2 illustre un dispositif récepteur ou émetteur selon un mode de réalisation de l'invention. Un tel dispositif fonctionne en émission et en réception et comprend plusieurs modules dont le rôle de chacun est détaillé par la suite.
Ainsi, un dispositif émetteur ou récepteur comprend : - un module 200 de gestion de la présentation des données servant d'interface entre une application émettrice ou réceptrice et le réseau synchrone ; - un module 201 de gestion des cycles SDPC ; - un module de réception 203 Synchro RX ; - un module de transmission 202 Synchro TX ; - un module 204 de gestion de l'accès au réseau ; - une unité centrale 205 CPU ; - une mémoire vive 206 RAM ; - une mémoire morte 207 ROM .
Dans le mode de réalisation de l'invention, une interface applicative 210 émettrice ou réceptrice est une interface audio numérique de type I2S (pour Inter IC Sound en anglais) bien connue de l'homme du métier. Pour une application émettrice, ce module 200 de gestion de la présentation des données échantillonne selon une période d'échantillonnage les différents flux d'une application émettrice dans des stockages différenciés, à l'aide d'une horloge dérivée de l'horloge du réseau synchrone, par exemple une horloge à 8Khz. Cette période (ou cycle) d'échantillonnage est aussi appelée cycle SDPC (pour Synchronous Data Processing Cycle en anglais). Dans l'exemple d'une application émettrice de type audio multi-canal, chaque canal audio représente un flux applicatif distinct.
Le module 200 de gestion de la présentation des données est relié au module 201 de gestion des cycles SDPC au moyen d'une interface 115 permettant l'échantillonnage, au format du réseau synchrone sous jacent, des données applicatives d'une application émettrice. Pour une application réceptrice, ce module 200 de gestion de la présentation des données délivre les données d'un flux applicatif au rythme d'une horloge applicative synchronisée à l'horloge applicative utilisée par le dispositif émetteur. En cas de perte de données notifiée par le module de réception 203 Synchro RX (décrit plus précisément dans la suite de la description), ce module 200 de gestion de la présentation des données applique une méthode de dissimulation d'erreurs ( error concealment en anglais) envers l'application réceptrice.
Le module 200 de gestion de la présentation des données est relié au module 201 de gestion des cycles SDPC au moyen d'une interface 116 permettant l'échantillonnage, au format du réseau synchrone sous jacent, des données applicatives reçues d'une application émettrice par le module 200 de gestion de la présentation des données. Le module 201 de gestion des cycles SDPC gère quant à lui la répartition de la bande passante synchrone du réseau, en émission ou en réception. Par exemple, pour chaque cycle SDPC, dans le mode de réalisation de l'invention, la bande passante est divisée en un certain nombre de canaux virtuels d'une capacité unitaire de 48 bits et d'une fréquence de 8Khz, ce qui donne un débit unitaire de 384Kbps. En émission, un certain nombre de canaux virtuels est alloué en écriture pour un flux applicatif d'une application émettrice. Ce nombre est choisi de sorte que le débit cumulé des canaux virtuels soit le plus proche possible du débit applicatif. Bien entendu, il est nécessaire que le débit réservé ne soit jamais inférieur au débit applicatif. Comme déjà expliqué, le dernier canal virtuel affecté à la transmission d'un flux de données synchrone pendant un cycle SDPC peut ne pas toujours contenir des données applicatives, le débit cumulé du flux de données synchrones étant dans ce cas légèrement supérieur au débit applicatif. Pour indiquer cette absence de données, le module 201 de gestion des cycles SDPC insère, dans ces canaux virtuels vides, des symboles de synchronisation. Cette étape est notamment connue sous le nom d < insertion de données de bourrage .
Il est à noter que ce n'est pas l'application qui assure l'insertion des données de bourrage (ou padding en anglais). L'application reste indépendante du mode de transport utilisé et de la fréquence utilisée. Cela permet notamment d'avoir des réseaux synchrones capables de gérer une multitude d'applications simultanées, ayant des fréquences complètement indépendantes les unes des autres. Il est alors nécessaire que le module 201 de gestion des cycles SDPC du dispositif récepteur correspondant détecte ces symboles de synchronisation afin de fournir à l'application réceptrice (ou consommatrice) uniquement les données fournies par l'application émettrice (ou génératrice), et ainsi maintenir l'indépendance du réseau synchrone vis-à-vis des applications utilisant ses services. En réception, de même manière, un ensemble de canaux virtuels est alloué en lecture pour le flux applicatif. Lorsqu'un canal virtuel contient un symbole de synchronisation, le module 201 de gestion des cycles SDPC n'émet aucune donnée, au travers de la première interface 116, vers le module 200 de gestion de la présentation des données. En ce qui concerne la partie transmission, le module 201 de gestion des cycles SDPC est en outre relié au module de transmission 202 Synchro TX au moyen d'une interface 212. Cette interface 212 permet l'échange de données dont les différents formats sont décrits en relation avec la figure 3. Ce module de transmission 202 Synchro TX est en charge de piloter l'insertion de symboles de synchronisation et l'insertion d'informations supplémentaires dans le symbole de synchronisation, afin que les noeuds récepteurs puissent se synchroniser de nouveau en cas de perte de données et de mauvaise prédiction. En ce qui concerne la partie réception, le module 201 de gestion des cycles SDPC est en outre relié au module de réception 203 Synchro RX au moyen d'une interface 211. Cette interface 211 permet l'échange de données dont les différents formats sont décrits en relation avec la figure 3. Tel que décrit par la suite, ce module de réception 203 Synchro RX gère la détection d'une perte de données indiquée par le module 204 de gestion de l'accès au réseau. Dans le mode de réalisation de l'invention, la détection, par le module 204 de gestion de l'accès au réseau du dispositif récepteur, d'une donnée perdue est matérialisée par un symbole MISSING . Ce symbole MISSING est plus amplement décrit dans la suite de la description. Lorsqu'une perte de donnée pour un flux de données synchrones est indiquée, le module de réception 203 Synchro RX utilise des moyens de prédiction afin d'estimer si la donnée perdue était un symbole de synchronisation ou bien une donnée applicative. Se basant sur cette prédiction, ce module re-génère soit une donnée marquée comme étant incorrecte soit un symbole de synchronisation. Lors de la réception correcte d'un symbole de synchronisation, ce module de réception 203 Synchro RX met alors à jour ses moyens de prédiction pour le flux de données synchrones concerné, notamment grâce aux informations supplémentaires insérées dans le symbole de synchronisation par le module de transmission 202 Synchro TX du noeud émetteur. Lors de la mise à jour des moyens de prédiction, la pertinence des dernières prédictions est vérifiée au moyen d'une information supplémentaire de continuité contenue dans le symbole de synchronisation (de type NULL ). Si des erreurs de prédiction sont détectées, ce module de réception 203 Synchro RX est capable de se synchroniser à nouveau en modifiant le contenu des données délivrées au module 201 de gestion des cycles SDPC. Le module de réception 203 Synchro RX et le module de transmission 202 Synchro TX sont en outre reliés au module 204 de gestion de l'accès au réseau au travers d'interfaces 214 et 213 respectivement. Ces deux interfaces 213 et 214 permettent l'échange de données dont les différents formats sont décrits en relation avec la figure 3. Le module 204 de gestion de l'accès au réseau gère quant à lui la mise en forme des données au format du réseau synchrone. Il gère également l'envoi (dispositif émetteur) et la réception (dispositif récepteur) des données de manière synchrone au travers d'interfaces réseau 217 et 216 respectivement. Une unité centrale 205 CPU (pour Central Processor Unit en anglais) dotée d'une mémoire morte 207 ROM (pour Read Only Memory en anglais) et d'une mémoire vive 206 RAM (pour Random Access Memory en anglais) complètent l'architecture d'un dispositif récepteur ou émetteur.
Au moyen d'interfaces 208, 215 et 216, l'unité centrale 205 CPU initialise les divers registres du module de réception 203 Synchro RX et du module de transmission 202 Synchro TX lors de la mise sous tension du dispositif. Les valeurs par défaut présentent dans la mémoire morte 207 ROM sont chargées dans la mémoire vive 206 RAM puis dans les registres du module de réception 203 Synchro RX et du module 202 Synchro TX . La figure 3 illustre schématiquement les différents formats de données transitant par les différents modules d'un dispositif récepteur ou émetteur. Chaque format de données comprend une partie utile (ou encore payload en anglais) codée sur 48 bits et une information de contrôle codée sur 1 ou 2 bits. Entre le module 201 de gestion des cycles SDPC et le module de transmission 202 Synchro TX transitent, au travers de l'interface 212, des données codées sur 49 bits et dont le bit numéro 49 sert à indiquer la disponibilité des données pour un canal virtuel donné. Une valeur à 1 du bit numéro 49 (format 301) indique des données disponibles. Une valeur à 0 du bit numéro 49 (format 302) indique des données non disponibles. Pour le format 301, la partie utile est codée sur les 48 autres bits (représentée par D sur la figure). Pour le format 302, cette partie est sans signification (représenté par X sur la figure). A noter que les différents canaux virtuels sont balayés séquentiellement durant un cycle SDPC, selon une séquence par ordre croissant des numéros de canal virtuel. Entre le module 201 de gestion des cycles SDPC et le module de réception 203 Synchro RX transitent, au travers de l'interface 211, des données codées sur 50 bits et correspondant à trois formats 303, 304 et 305 de la figure 3. Deux bits de contrôle indiquent la nature des données, à savoir 11 pour un type de données valide (format 303), 00 pour un type de donnée corrompue (format 304) et 01 pour un type de donnée inconnue (format 305). La partie utile du format 303 est codée sur les 48 autres bits (représentée par D sur la figure). Pour les formats 304 et 305, cette partie est sans signification (représenté par X sur la figure). Entre le module 204de gestion de l'accès au réseau et le module de réception 203 Synchro RX transitent, au travers de l'interface 214, des formats de données 306, 307, 308 et 309.
Un format 306 illustre un format de type conteneur de données dont la réception par le module de réception 203 Synchro RX peut impliquer l'écriture d'une donnée valide 303 sur la troisième interface 211. La partie utile de ce format 306 (représentée par D sur la figure) est codée sur 48 bits et le bit de contrôle numéro 49 est à 1.
Deux formats 307 et 308 illustrent respectivement un symbole de synchronisation sans compteur de continuité et un symbole de synchronisation avec compteur de continuité CPT . Ces deux formats de données sont reçus par le module de réception 203 Synchro RX . Une réception d'un format 307 ou 308, par le module de réception 203 Synchro RX , ne déclenche pas d'écriture sur la troisième interface 211. La partie utile de ces deux formats 307 et 308 est codée sur 48 bits et le bit de contrôle numéro 49 bit est égal à 0. Le symbole de synchronisation avec compteur de continuité CPT (format 308) est notamment utilisé pour les canaux virtuels contenant des données d'un flux de données synchrones. La partie utile du format 308 comporte dans ce cas 24 premiers bits à 0 et un champ compteur CPT sur les 24 derniers bits. Le symbole de synchronisation sans compteur de continuité (format 307) possède quant à elle une partie utile codée sur 48 bits et de valeur nulle. Un format 309 illustre un symbole de détection de perte de type MISSING généré par le module 204 de gestion de l'accès au réseau lorsqu'une perte de donnée est détectée. La partie utile du format 309 est égale à 0x555555555555 et le bit de contrôle prend la valeur O. Une réception du format 309 par le module de réception 203 Synchro RX peut impliquer l'écriture d'une donnée corrompue 304 ou d'une donnée inconnue 305 sur la troisième interface 211, ou rien du tout selon les prédictions comme décrit dans la suite de la description. Entre le module 204 de gestion de l'accès au réseau et le module de transmission 202 Synchro TX transitent également, au travers de l'interface 213, les formats de données 306, 307 et 308. La figure 4 donne un exemple de succession dans le temps de formats conteneurs de données et de symbole de synchronisation uniquement pour le dernier canal virtuel affecté à la transmission d'un flux de données synchrones pendant un cycle SDPC. Soit un axe des temps 400 croissant de gauche à droite et divisé en cycles SDPC (ou cycles TDM) 401, 402, 403, 404. A chaque cycle SDPC, un format conteneur de données ou un format symbole de synchronisation est généré pour ce canal virtuel. Ainsi lors d'un premier cycle SDPC 401, un symbole de synchronisation 405, de format 307 ou 308, est généré. Puis dans un second cycle SDPC 401, un conteneur de données 406 de format 306, est généré. Dans cet exemple de la figure 4, la période 410 NULL Period représentative d'une apparition cyclique des symboles de synchronisation est de 5 cycles SDPC et l'intervalle 412 NULL Interval est de deux cycles (soit deux symboles de synchronisation). L'obtention de ces valeurs de la période 410 NULL Period et de l'intervalle 412 NULL Interval par un module de prédiction VC Predictor est décrite plus amplement dans la suite de la description. La valeur de la période 410 NULL Period indique le nombre de cycles SDPC entre deux mêmes séquences commençant par un conteneur de données et se finissant par un symbole de synchronisation. Les flux de données synchrones transportés étant de débit constant, le schéma de transmission défini par la période 410 NULL Period et par l'intervalle 412 NULL Interval est répété pendant toute la durée de la transmission du flux de données synchrones. Une fin (ou un début) de période 410 NULL Period correspond à l'instant entre deux mêmes séquences d'utilisation de canal virtuel commençant par un conteneur de données et se finissant par un symbole de synchronisation.
Il est alors possible de représenter l'intervalle 412 NULL Interval simplement par un identifiant du cycle à l'intérieur de la séquence NULL Period à partir duquel les symboles de synchronisation apparaissent. La figure 5 détaille le module de réception 203 Synchro RX . Le module de réception 203 Synchro RX est constitué d'un bloc de contrôle 502 Rx Controller chargé de recevoir à chaque cycle de communication réseau des conteneurs de données ou des symboles de synchronisation représentatifs de canaux virtuels envoyés par le module 204 de gestion de l'accès au réseau au travers de l'interface 214. A chaque canal virtuel correspond en outre un module de prédiction 503 VC Predictor en charge de faire une prédiction en cas de détection, par le module 204 de gestion de l'accès au réseau, de donnée perdue et en charge de corriger les prédictions précédentes. Ainsi, après réception des données en provenance du module 204 de gestion de l'accès au réseau, le bloc de contrôle 502 RX Controller envoie les conteneurs de données ou symboles de synchronisation au travers d'un ensemble 505 de sous- interfaces 506, chaque sous-interface 506 reliant, pour un canal virtuel donné, le bloc de contrôle 502 RX Controller et le module de prédiction 503 VC Predictor correspondant audit canal virtuel donné. Puis ces données sont traitées par un module de prédiction 503 VC Predictor associé. Le résultat de ce traitement est ensuite retourné au bloc de contrôle 502 RX Controller au travers de l'ensemble 505 d'interfaces 506 puis envoyé au module 201 de gestion des cycles SDPC au travers de l'interface 211. Le détail des différentes opérations effectuées par le bloc de contrôle 502 RX Controller est illustré plus en détail en relation avec la figure 7. Par ailleurs chaque module de prédiction 503 VC Predictor envoie des informations au travers de la sous-interface 506 correspondante. Par exemple, ces informations concernent l'état du module 503 VC Predictor (module prêt ou non) et le type du canal virtuel. Les différents modules de prédiction 503 VC Predictor sont aussi accessibles par l'unité centrale 205 CPU au travers d'un module 508 d'interface de bus et d'un ensemble d'interfaces 507 reliant chaque module de prédiction 503 VC Predictor audit module 508 d'interface de bus. L'unité centrale 205 CPU accède notamment aux modules de prédiction 503 VC Predictor lors de la phase d'initialisation afin de renseigner les valeurs par défaut des registres NULL Period et NULL Interval tel qu'introduits précédemment.
Les modules de prédiction 503 VC Predictor sont aussi reliés au module 201 de gestion des cycles SDPC au travers d'un ensemble d'interfaces 209. Chaque interface 209 permet en outre au module 200 de gestion de la présentation des données d'envoyer des signaux de synchronisation synchro_ok au module de prédiction 503 VC Predictor correspondant. Lorsque le signal synchro_ok est positif, cela signifie qu'une application consomme effectivement le flux de données correspondant au canal virtuel. Si le signal synchro_ok est négatif, cela signifie qu'aucune application (du dispositif récepteur considéré) ne consomme le flux de données correspondant au canal virtuel et que donc la prédiction en cas de perte de données n'est pas nécessaire. La figure 6 illustre schématiquement le module de transmission 202 Synchro TX . Le module de transmission 202 Synchro TX est constitué d'un bloc de contrôle 602 TX Controller chargé de la gestion de l'émission du contenu des canaux virtuels fournis par le module 201 de gestion des cycles SDPC au travers de l'interface 212. Le bloc de contrôle 602 TX Controller gère, entre autres, l'insertion des symboles de synchronisation et la mise en oeuvre des compteurs de continuité CPT des symboles de synchronisation pour chaque canal virtuel (se référer au format 308 de la figure 3). Pour chaque canal virtuel correspond un module 603 VC Parameters . Après réception des données en provenance du module 201 de gestion des cycles SDPC, le bloc de contrôle 602 TX Controller envoie chaque conteneur de données ou symbole de synchronisation vers le module 603 VC Parameters . Cet envoi est réalisé au travers d'un ensemble 605 de sous-interface 606, chaque sous-interface 606 reliant, pour un canal virtuel donné, le bloc de contrôle 602 TX Controller et le module 603 VC Parameters correspondant audit canal virtuel donné.
Chaque canal virtuel est traité en fonction de paramètres initiaux fixés par l'unité centrale 205 CPU au démarrage. Ces paramètres initiaux sont chargés dans le module 603 VC Parameters au travers de l'interface 208. Ces paramètres initiaux renseignent notamment le type du canal virtuel, c'est-à-dire s'il s'agit d'un canal virtuel destiné à la transmission d'un flux de données synchrones ou non, ainsi que sont état (utilisé ou non).
A chaque canal virtuel correspond donc un module 603 VC Parameters directement accessible par l'unité centrale 205 CPU grâce à un module 608 d'interface de bus, chaque module 603 VC Parameters étant relié au module 608 d'interface de bus au moyen d'un ensemble d'interfaces 609.
Chaque module 603 VC Parameters envoie ensuite ces informations vers le bloc de contrôle 602 TX Controller au travers de la sous-interface 606 correspondante. Une fois traités, les conteneurs de données ou les symboles de synchronisation sont transmis au module 204 de gestion de l'accès au réseau par le bloc de contrôle 602 TX Controller au travers de l'interface 213. La figure 7 présente un organigramme des différentes étapes effectuées par le bloc de contrôle 502 RX Controller du module de réception 203 Synchro RX . Dans une première étape 700, le dispositif récepteur est en attente d'un nouveau cycle SDPC (ou cycle TDM).
Dans une étape 701 suivante, un nouveau cycle SDPC est détecté par le dispositif récepteur. Dans une étape 702, une donnée d'un canal virtuel reçu est traitée par le module 204 de gestion de l'accès au réseau. Dans une étape 703, cette donnée est analysée afin de déterminer s'il s'agit d'un symbole (soit d'un symbole de synchronisation, soit d'un symbole de type MISSING ). Cette opération est effectuée par examen du bit numéro 49 du format de donnée reçu (cf figure 3), une valeur à 0 de ce bit indiquant la présence d'un symbole de synchronisation ou d'un symbole de type MISSING . Si la donnée contient un symbole (bit 49 à 0) alors, dans une étape 704, la donnée reçue est analysée afin de déterminer s'il s'agit d'un symbole MISSING tel que décrit en relation avec le format 309 de la figure 3. Si la donnée est un symbole MISSING , dans une étape 711, le type de données convoyées par le canal virtuel est défini à travers l'interface 505 correspondante afin de vérifier s'il est nécessaire de faire une prédiction, les prédictions étant utiles uniquement dans le cas d'un canal virtuel servant à convoyer des données d'un flux de données synchrones.
Si le canal virtuel n'est pas affecté à la transmission d'un flux de données synchrones alors aucune prédiction n'est nécessaire et dans ce cas, dans une étape 713, un symbole d'erreur bad data 304 est envoyé au module 201 de gestion des cycles SDPC.
Si le canal virtuel est affecté à la transmission d'un flux de données synchrones alors une prédiction est nécessaire et dans ce cas, dans une étape 712, la donnée du canal virtuel reçu est envoyée au travers de l'interface 506 correspondante vers le module de prédiction 503 VC Predictor correspondant audit canal virtuel. Il est à noter qu'il est nécessaire d'envoyer la donnée reçue au module de prédiction 503 VC Predictor correspondant même si celui-ci n'est pas encore dans un état module prêt , car son initialisation dépend des données reçues (se référer à la figure 8 dans la suite de la description). Lors d'une étape 714, l'état du module de prédiction 503 VC Predictor est testé à travers l'interface 505.
Si le module de prédiction 503 VC Predictor est prêt (dans l'état module prêt ), alors dans une étape 715, le résultat de la prédiction est en attente de détermination. Dans une étape 717, ce résultat est déterminé puis envoyé au module 201 de gestion des cycles SDPC dans une étape 718.
Dans une étape suivante 719 décrite plus amplement par la suite, un prochain canal virtuel est ensuite analysé. Dans l'étape 714, si le module de prédiction 503 VC Predictor n'est pas prêt (pas dans l'état module prêt ), un symbole de type donnée inconnue unknown data 305 est envoyé par défaut au module 201 de gestion des cycles SDPC dans une étape 716. Puis dans l'étape suivante 719 décrite plus amplement par la suite, un prochain canal virtuel est analysé. Dans l'étape 704, si la donnée ne contient pas un symbole MISSING alors d'une étape 705, le type de canal virtuel VC est vérifié.
Il est à noter que cette étape 705 est également effectuée si la donnée ne contient pas de symboles de synchronisation (étape 703), c'est-à-dire si le bit numéro 49 prend la valeur 1. Si le canal virtuel VC n'est pas affecté à la transmission d'un flux de données synchrones, la donnée n'est pas traitée et envoyée directement au module 201 de gestion des cycles SDPC lors d'une étape 710. Si le canal virtuel VC est affecté à la transmission d'un flux de données synchrones, alors dans une étape 706, la donnée est envoyée au module de prédiction 503 VC Predictor correspondant, afin qu'une éventuelle correction de prédiction soit appliquée. Tel que mentionné précédemment, le canal virtuel est envoyé au module de prédiction 503 VC Predictor même si ce dernier n'est pas encore prêt car son initialisation nécessite la réception de données. Ce point est plus largement décrit dans la suite de la description en relation avec la figure 8. Puis, dans une étape 708, l'état du module de prédiction 503 VC Predictor correspondant est obtenu. Si le module de prédiction 503 VC Predictor n'est pas prêt (pas dans l'état module prêt ), alors la donnée est inchangée et est envoyée au module 201 de gestion des cycles SDPC lors d'une étape 710. Si le module de prédiction 503 VC Predictor est prêt (dans l'état module prêt ), alors le résultat d'une éventuelle correction est en attente de réception dans une étape 709. Puis le résultat (corrigé ou non) est envoyé au module 201 de gestion des cycles SDPC lors d'une étape 721. Puis, dans une étape 719, un prochain canal virtuel est analysé. Dans une étape 720 est vérifié si tous les canaux virtuels ont déjà été traités et si oui, un nouveau cycle SDPC est analysé dans une nouvelle étape 700. Sinon, il reste des canaux virtuels à traiter. L'ensemble des étapes à partir de l'étape 702 sont alors répétées. Les figures 8 et 9 illustrent les opérations effectuées par un module de prédiction 503 VC Predictor . 20 25 30 Tous les modules de prédiction 503 VC Predictor suivent le même algorithme, chacun des modules de prédiction 503 VC Predictor traite un canal virtuel particulier, la correspondance entre un module de prédiction 503 VC Predictor et un numéro de canal virtuel étant définie statiquement.
Un module de prédiction 503 VC Predictor possède deux modes de fonctionnement. Un mode initial décrit en relation avec la figure 8, et un mode de prédiction et de correction décrit en relation avec la figure 9. Pour passer du mode initial (figure 8) au mode de prédiction et de correction (figure 9), le bloc de contrôle 502 RX Controller doit d'une part recevoir un signal synchro_ok du module 200 de présentation des données indiquant qu'une application consomme effectivement les données du flux transporté par le canal virtuel, et d'autre part recevoir le dernier symbole de synchronisation d'une série sans perte de données comme expliqué en détail en relation avec les étapes de l'algorithme de la figure 8. L'algorithme de la figure 8 détaille les différentes étapes effectuées lors de la phase initiale d'un module de prédiction 503 VC Predictor . A la mise sous tension et à chaque fois que le signal 209 synchro_ok est négatif, une étape d'initialisation 800 est exécutée. Au cours de cette étape, un compteur CPT1 de symboles NULL est mis à 0. Ce compteur permet de compter les symboles NULL reçus par le dispositif récepteur.
Puis lors d'une étape 801, le dispositif récepteur se met en attente de début d'un nouveau cycle SDPC. Dans une étape 802 suivante, un nouveau cycle SDPC est détecté. Lors d'une étape 803, le bloc de contrôle 502 RX Controller est en attente de réception de données.
Dans une étape 804, une donnée d'un canal virtuel est reçue par le dispositif récepteur. Dans une étape 805, la donnée est testée afin de déterminer si elle contient un symbole de synchronisation. Si oui, le compteur CPT1 est incrémenté d'une unité et le compteur contenu dans le symbole NULL (CPT du format 308 de la figure 3) est sauvegardé dans un registre Initial NULL Count lors d'une étape 806 puis le bloc de contrôle 502 RX Controller se met en attente d'un nouveau cycle SDPC (étape 801). Si la donnée reçue n'est pas un symbole de synchronisation, alors dans une étape 807, la donnée est testée afin de déterminer s'il s'agit d'un symbole MISSING représentatif de la détection, par le module 204 de gestion de l'accès au réseau, de la perte d'une donnée du flux de données synchrones considéré. Si oui, la procédure à partir de l'étape 800 est répétée, car il faut être sûr d'être arrivé à la fin d'une séquence de symboles de synchronisation afin de sortir de la phase d'initialisation et, par la suite, d'effectuer une prédiction correcte.
Si la donnée n'est pas un symbole MISSING alors il s'agit d'un conteneur de données. Dans ce cas, une étape 808 permet de vérifier si des symboles de synchronisation ont été reçus avant ce conteneur de données. Si tel est le cas, il s'agit d'une fin de séquence de symboles de synchronisation.
En effet, la valeur NULL Period indique la période entre deux mêmes séquences d'utilisation de canal virtuel commençant par un conteneur de données et se finissant par un symbole de synchronisation. Un symbole de synchronisation suivi d'une donnée représente alors une fin de séquence (indiquée 411 sur la figure 4). Si le résultat du test de l'étape 808 est négatif, c'est-à-dire si le compteur CPT1 est égal à zéro, alors la séquence de symboles de synchronisation n'a pas encore commencé. L'étape 801 est alors répétée afin d'attendre et de traiter un nouveau cycle SDPC. Si le résultat du test de l'étape 808 est positif, alors le module de prédiction 503 VC Predictor est prêt et le signale au bloc de contrôle 502 RX Controller au travers de l'ensemble des interfaces 505. Dans une étape 809 suivante, un compteur CPT2 de cycles passe alors à zéro et le compteur CPT1 prend la valeur du registre Initial NULL Count ). Puis la première étape 901 de la phase de prédiction et de correction est activée (figure 9).
L'algorithme de la figure 9 détaille les différentes étapes de cette phase de prédiction et de correction d'un module de prédiction 503 VC Predictor .
Dans une première étape 901, le dispositif récepteur est en attente d'un prochain cycle SDPC. Dans une étape 902, un nouveau cycle SDPC est détecté. Une fois le nouveau cycle SDPC commencé, dans une étape 903, le compteur CPT2 est incrémenté d'une unité, modulo la périodicité des symboles de synchronisation telle que renseignée dans le registre NULL Period suite à la période d'initialisation du module de prédiction 503 VC Predictor (se référer à la figure 11 décrite plus amplement dans la suite de la description). Puis, dans une étape 904, le dispositif récepteur correspondant est en attente de réception d'une donnée. Dans une étape 905, le module VC Pretictor reçoit les données d'un canal virtuel envoyées par le bloc de contrôle 502 RX Controller (se référer aux étapes 706 et 712). Dans une étape 906, la donnée est testée.
Si cette donnée est un symbole MIS SING , c'est-à-dire une donnée détectée, par le module 204 de gestion de l'accès au réseau, comme perdue, une prédiction est nécessaire. Sinon, la donnée est envoyée telle quelle, via le bloc de contrôle 502 RX Controller , vers le module 201 de gestion des cycles SDPC au travers de l'interface 211, à moins qu'une précédente prédiction nécessite d'être corrigée. Si la donnée est un symbole MISSING , lors d'une étape 907, le compteur CPT2 est comparé avec la valeur du registre NULL Interval . La valeur du registre NULL Interval combinée avec la valeur du registre de périodicité des symboles NULL ( NULL Period ) permet d'indiquer à quel cycle durant une période commence la présence de symboles de synchronisation. Une période étant caractérisée par le fait que les symboles de synchronisation sont contigus et placés en fin de période, comme illustré en figure 4. Si la valeur du compteur CPT2 est supérieure à la valeur du registre NULL Interval , alors le symbole MISSING reçu est interprété comme étant représentatif de la perte d'un symbole de synchronisation.
Dans ce cas, dans une étape 908, le compteur CPT1 est incrémenté d'une unité. Puis, dans une étape 909, le résultat de la prédiction est retourné au module de contrôle 502 RX Controller puis envoyé au module 201 de gestion des cycles SDPC. Puis l'ensemble des étapes à partir de l'étape 901 est répété.
Si la valeur du compteur CPT2 est inférieure à la valeur du registre NULL Interval , alors dans une étape 910, le symbole MIS SING reçu est interprété comme étant représentatif d'une donnée erronée, puis le résultat de la prédiction est envoyé au module de contrôle 502 RX Controller puis envoyé au module 201 de gestion des cycles SDPC.
Puis l'ensemble des étapes à partir de l'étape 901 est répété. Si la donnée n'est pas un symbole MISSING (étape 906), une étape 911 permet de déterminer si le symbole reçu est un symbole de synchronisation ou bien une donnée applicative. Si la donnée est un symbole NULL , dans une étape 912, le compteur CPT1 est incrémenté. Ce compteur CPT1 permet de savoir notamment combien de symboles de synchronisation ont été comptabilisés pour ce canal virtuel. Dans un champ du symbole de synchronisation est également mentionné le décompte des NULL du canal virtuel analysé tel qu'indiqué par le noeud source. Ce décompte est renseigné par le compteur CPT du format 308 de la figure 3.
Puis, dans une étape 917, ces deux valeurs de compteur CPT et CPT1 sont comparées afin de détecter une éventuelle erreur de prédiction antérieure. Si le décompte de l'émetteur renseigné par la valeur du compteur CPT est supérieur au décompte en réception (local) des symboles NULL renseigné par la valeur du compteur CPT1, alors le nombre de symboles de synchronisation prédit précédemment est insuffisant. C'est-à-dire qu'un symbole de type MISSING a été précédemment interprété comme substituant une donnée applicative, alors qu'il substituait un symbole de synchronisation de type NULL . Il est alors nécessaire de réaliser une correction par la substitution de conteneurs de données par des symboles de synchronisation (autant de substitutions que de symboles de synchronisation manquants) lors des prochaines réceptions de données. Cette étape consiste à envoyer la donnée inchangée au bloc de contrôle 502 RX Controller lors de l'étape 918. Cette étape est aussi valable pour le cas où les compteurs CPT et CPT1 sont égaux (pas d'erreur de prédiction, donc pas de correction et la donnée reçue est envoyée inchangée au bloc de contrôle 502 RX Controller ). Puis l'ensemble des étapes à partir de l'étape 901 est répété suite à la détection d'un nouveau cycle SPDC. Si le décompte de l'émetteur renseigné par la valeur du compteur CPT est inférieur au décompte en réception (local) des symboles NULL renseigné par la valeur du compteur CPT1, alors le nombre de symboles de synchronisation prédit précédemment est trop important. C'est-à-dire qu'un symbole de type MISSING a été précédemment interprété comme substituant un symbole de synchronisation de type NULL , alors qu'il substituait une donnée applicative. Il est alors nécessaire de réaliser une correction en décrémentant d'une unité le compteur CPT1 (étape 919) puis en substituant ultérieurement un symbole de synchronisation par un symbole de type bad data (étape 919 et 920).
Puis l'ensemble des étapes à partir de l'étape 901 est répété suite à la détection d'un nouveau cycle SPDC. Dans l'étape 911 précédente, si la donnée reçue n'est pas un symbole de synchronisation alors dans ce cas il s'agit d'un conteneur de données. Il est alors nécessaire de soit remettre tel quel le conteneur de données soit lui substituer un symbole de synchronisation afin de corriger une prédiction précédente erronée. Dans ce cas, dans une étape 913, le décompte de l'émetteur renseigné par la valeur du compteur CPT du dernier symbole NULL reçu, est comparé au décompte en réception (local) des symboles NULL renseigné par la valeur du compteur CPT1. Si le décompte de l'émetteur renseigné par la valeur du compteur CPT est supérieur au décompte en réception (local) des symboles NULL renseigné par la valeur du compteur CPT1, alors le compteur CPT1 est incrémenté d'une unité dans une étape 915. Puis un symbole de synchronisation est substitué au conteneur de données dans une étape 916. Le résultat est ensuite transmis au module de contrôle 502 RX Controller .
Puis l'ensemble des étapes à partir de l'étape 901 est répété suite à la détection d'un nouveau cycle SPDC. Si le décompte de l'émetteur renseigné par la valeur du compteur CPT est inférieur au décompte en réception (local) des symboles NULL renseigné par la valeur du compteur CPT1, la correction est effectuée lors des prochaines réceptions de symboles NULL . Puis l'ensemble des étapes à partir de l'étape 901 est répété suite à la détection d'un nouveau cycle SPDC. La figure 10 décrit l'algorithme exécuté par le bloc de transmission 602 TX Controller . Lors d'une étape 1000, le module émetteur est en attente d'un nouveau cycle SDPC Dans une étape 1001, un nouveau cycle SDPC est détecté. A chaque nouveau cycle SDPC, le bloc de transmission 602 TX Controller effectue une lecture des mémoires de type FIFO associées à chaque canal virtuel dans le module 201 de gestion de cycles SDPC au travers de l'interface 212. Dans une étape 1002, la mémoire associée au canal virtuel est testée afin de vérifier s'il y a suffisamment de données (48 bits minimum) pour être envoyées au module 204 de gestion de l'accès au réseau.
Si c'est le cas, dans une étape 1003, les données sont envoyées au module 204 de gestion de l'accès au réseau. S'il n'y a pas assez de données pour former un conteneur de données, alors dans une étape 1004, un symbole de synchronisation de type NULL est créé pour palier au manque de données.
Dans une étape 1005, le module 603 VC Parameters correspondant au canal virtuel courant est interrogé afin de déterminer si ce canal virtuel est affecté à la transmission d'un flux de données synchrones. Si le canal virtuel est affecté à la transmission d'un flux de données synchrones, dans une étape 1006, le compteur CPT de symboles NULL contenu dans le module 603 VC Parameters correspondant est incrémenté d'une unité.
Puis, dans une étape 1007, la valeur de ce compteur CPT est insérée dans le symbole de synchronisation précédemment créé (étape 1004). Puis dans une étape 1008 le symbole de synchronisation est envoyé au module 204 de gestion de l'accès au réseau afin d'être transmis sur le réseau. Si le canal virtuel n'est pas affecté à la transmission d'un flux de données synchrones, dans une étape 1008, le symbole de synchronisation précédemment créé (étape 1004) est envoyé au module 204 de gestion de l'accès au réseau afin d'être transmis sur le réseau. Puis dans une étape 1009, un prochain canal virtuel est sélectionné. Une étape 1010 suivante permet de vérifier si tous les canaux virtuels ont été traités. Si oui, le bloc de contrôle 602 TX Controller du dispositif émetteur se positionne en attente d'un nouveau cycle SDPC (étape 1000) Si non, le nouveau canal virtuel est analysé dans l'étape 1002. La figure 11 donne un exemple d'algorithme d'apprentissage exécuté par le module de prédiction 503 VC Predictor en phase d'initialisation en lieu et place de l'algorithme donné en figure 8. Dans une étape initiale 1100, des valeurs Learn_Period , Learn_Interval , Mean Learn Interval et Mean Learn Period sont mises à O. Ces valeurs servent 20 au calcul des deux paramètres NULL Interval et NULL Period . L'étape 1100 est exécutée au démarrage du système (reset) ou à chaque fois que le signal synchro_ok 209 est négatif ou à chaque fois qu'une donnée est perdue (symbole MISSING ) lors de la phase d'apprentissage. Une étape 1101 suivante consiste à rechercher le premier symbole de 25 synchronisation. Cette étape consiste à rester dans le même état à chaque nouveau cycle SDPC tant que la donnée reçue n'est pas un symbole de synchronisation. A la réception d'un premier symbole de synchronisation, une étape 1102 permet de trouver le début de la période. Le début de la période étant marqué par la réception de la première donnée après une série de symboles de synchronisation. Cette étape se finit 30 donc dès la réception d'une donnée.
10 15 5 15 20 25 30 Il est à noter que la perte de données pendant cette étape (matérialisée par la réception d'un symbole MISSING ) entraîne la réinitialisation de l'algorithme (réinitialisation à l'étape 1100). Cette transition n'est pas représentée sur la figure 11 par soucis de clarté. A partir d'une étape 1103, la succession des données reçues est comptée jusqu'à réception du premier symbole de synchronisation. Le résultat de ce décompte est ensuite enregistré dans la valeur Learn_Interval . De même que lors de l'étape 1102, la réception d'un symbole MISSING entraîne une réinitialisation de l'algorithme. Au premier symbole de synchronisation reçu, dans une étape 1104, les symboles de synchronisation sont comptés jusqu'à réception d'une donnée finissant ainsi une période complète (données et symboles de synchronisation). Ce décompte de symboles de synchronisation, ajouté à la valeur Learn_Interval , renseigne alors la valeur Learn Period . De même que lors de l'étape 1102, la réception d'un symbole MISSING entraîne une réinitialisation de l'algorithme. Lors d'une étape 1105, une moyenne est calculée pour les deux valeurs Learn_Period et Learn_Interval à l'aide des variables de cumul et de moyenne Mean Learn Interval et Mean Learn Period . Lors d'une étape 1106, le nombre d'apprentissage des deux valeurs Learn_Period et Learn_Interval est vérifié pour savoir s'il est suffisant pour avoir une moyenne fiable (par exemple une moyenne sur 10 valeurs). Si le nombre est insuffisant (par exemple inférieur à 10), l'algorithme boucle sur l'étape 1102 pour l'apprentissage de valeurs supplémentaires. Sinon, dans une étape 1107, le module de prédiction 503 VC Predictor est déclaré comme prêt. Les valeurs Mean_Learn_Period et Mean_Learn_Interval sont chargées dans les paramètres NULL Interval et NULL Period du module de prédiction 503 VC Predictor . Le compteur CPT2 de cycles est alors initialisé à la valeur O. Ensuite, la phase de prédiction de la figure 9 est enclenchée.
Claims (14)
- REVENDICATIONS1. Procédé de synchronisation d'un flux de données transmis sur un réseau de communication synchrone mettant en oeuvre un cadencement définissant un cycle réseau : - depuis un dispositif émetteur recevant des données applicatives d'une application émettrice, et transmettant à un dispositif récepteur, via au moins un canal virtuel dudit réseau affecté à ladite application émettrice, des conteneurs de données comprenant lesdites données applicatives ainsi que des données de bourrage dites symboles de synchronisation ; - ledit dispositif récepteur transmettant à une application réceptrice les données applicatives contenues dans lesdits conteneurs de données ; ledit procédé étant caractérisé en ce que le dispositif récepteur effectue les étapes suivantes, pour au moins un canal virtuel affecté à ladite application émettrice : - obtention d'un motif récurrent d'utilisation dudit canal ou des canaux virtuel(s), ledit motif étant défini par une période comprenant une séquence d'un nombre déterminé de cycles réseau, avec une indication du ou des cycles réseau de ladite séquence dans lequel ou lesquels un symbole de synchronisation est supposé être émis ; - sur détection d'un symbole de perte de données pendant un cycle réseau courant, prédiction de la nature, applicative ou de bourrage, desdites données perdues, en fonction d'un positionnement dudit cycle réseau courant dans ledit motif ; - remplacement dans ledit flux dudit symbole de perte par un symbole de marquage de données applicatives erronées, s'il résulte de ladite prédiction que les données perdues correspondent à des données applicatives, ou par un symbole de synchronisation, s'il résulte de ladite prédiction que les données perdues correspondent à un symbole de synchronisation.
- 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de prédiction comprend les étapes suivantes : - lancement sur un début de période du motif identifié, d'un compteur de cycles réseau modulo la période dudit motif ; - prédiction de la nature desdites données perdues, en fonction de la valeur dudit compteur de cycles réseau pour le cycle courant.
- 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que le dispositif récepteur effectue les étapes suivantes : - comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte de données remplacés par des symboles de synchronisation ; - réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - si ledit nombre de symboles de synchronisation émis est supérieur audit nombre de symboles de synchronisation reçus, remplacement, dans ledit flux, de données applicatives par un symbole de synchronisation.
- 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le dispositif récepteur effectue les étapes suivantes : - comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte remplacés par des symboles de synchronisation ; - réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - si ledit nombre de symboles de synchronisation émis est inférieur audit nombre de symboles de synchronisation reçus, remplacement d'un symbole de synchronisation par un symbole de marquage de données applicatives erronées.
- 5. Procédé selon la revendication 3, caractérisé en ce que chaque symbole de synchronisation comprend une information représentative du nombre de symboles de synchronisation antérieurement présents dans ledit flux.
- 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite étape d'obtention d'un motif récurrent comprend une étape d'identification dudit motif par détection d'une séquence de cycles réseau comprenant deux ensembles successifs de cycles réseau, l'un desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un conteneur de données applicatives et l'autre desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un symbole de synchronisation.
- 7. 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 programmepour la mise en oeuvre du procédé selon au moins une des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur.
- 8. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour 5 mettre en oeuvre le procédé selon au moins une des revendications 1 à 6.
- 9. Dispositif récepteur d'un flux de données transmis sur un réseau de communication synchrone mettant en oeuvre un cadencement définissant un cycle réseau : - depuis un dispositif émetteur recevant des données applicatives d'une application 10 émettrice, et transmettant audit dispositif récepteur, via au moins un canal virtuel dudit réseau affecté à ladite application émettrice, des conteneurs de données comprenant lesdites données applicatives ainsi que des données de bourrage dites symboles de synchronisation ; - ledit dispositif récepteur transmettant à une application réceptrice les données 15 applicatives contenues dans lesdits conteneurs de données ; ledit dispositif récepteur étant caractérisé en ce qu'il comprend, pour au moins un canal virtuel affecté à ladite application émettrice : - des moyens d'obtention d'un motif récurrent d'utilisation dudit canal ou des canaux virtuel(s), ledit motif étant défini par une période comprenant une séquence d'un 20 nombre déterminé de cycles réseau, avec une indication du ou des cycles réseau de ladite séquence dans lequel ou lesquels un symbole de synchronisation est supposé être émis ; - des moyens de prédiction, activés sur détection d'un symbole de perte de données pendant un cycle réseau courant, permettant une prédiction de la nature, applicative 25 ou de bourrage, desdites données perdues, en fonction d'un positionnement dudit cycle réseau courant dans ledit motif ; - des moyens de remplacement dans ledit flux dudit symbole de perte par un symbole de marquage de données applicatives erronées, s'il résulte de ladite prédiction que les données perdues correspondent à des données applicatives, ou par un symbole de 30 synchronisation, s'il résulte de ladite prédiction que les données perdues correspondent à un symbole de synchronisation.
- 10. Dispositif récepteur selon la revendion 9, caractérisé en ce qu'il comprend : - des moyens de lancement sur un début de période du motif identifié, d'un compteur de cycles réseau modulo la période dudit motif ; - des moyens de prédiction de la nature desdites données perdues, en fonction de la valeur dudit compteur de cycles réseau pour le cycle courant.
- 11. Dispositif récepteur selon l'une quelconque des revendications 9 et 10, caractérisé en ce qu'il comprend : - des moyens de comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte de données remplacés par des symboles de synchronisation ; - des moyens de réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - des moyens de remplacement, dans ledit flux, de données applicatives par un symbole de synchronisation si ledit nombre de symboles de synchronisation émis est supérieur audit nombre de symboles de synchronisation reçus.
- 12. Dispositif récepteur selon l'une quelconque des revendications 9 à 11, caractérisé en ce que'il comprend : - des moyens de comptage d'un nombre de symboles de synchronisation reçus, y inclus les symboles de perte remplacés par des symboles de synchronisation ; - des moyens de réception d'une information du dispositif émetteur indiquant un nombre de symboles de synchronisation émis ; - des moyens de remplacement d'un symbole de synchronisation par un symbole de marquage de données applicatives erronées si ledit nombre de symboles de synchronisation émis est inférieur audit nombre de symboles de synchronisation reçus.
- 13. Dispositif récepteur selon la revendication 11, caractérisé en ce que chaque symbole de synchronisation comprend des moyens de renseignement d'une information représentative du nombre de symboles de synchronisation antérieurement présents dans ledit flux.
- 14. Dispositif récepteur selon l'une quelconque des revendications 9 à 13, caractérisé en ce qu'il comprend des moyens d'identification du motif récurrent pardétection d'une séquence de cycles réseau comprenant deux ensembles successifs de cycles réseau, l'un desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un conteneur de données applicatives et l'autre desdits ensembles comprenant au moins un cycle réseau dans lequel est émis un symbole de synchronisation.5
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0853057A FR2931021A1 (fr) | 2008-05-09 | 2008-05-09 | Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. |
US12/437,454 US8289947B2 (en) | 2008-05-09 | 2009-05-07 | Method for synchronizing a data stream transmitted on a communications network, corresponding computer-readable storage medium and receiver device |
EP09159708.8A EP2117145B1 (fr) | 2008-05-09 | 2009-05-07 | Procédé de synchronisation d'un flux de données transmis sur un réseau de communications, produit de programme informatique correspondant, moyen de stockage et dispositif récepteur |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR0853057A FR2931021A1 (fr) | 2008-05-09 | 2008-05-09 | Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. |
Publications (1)
Publication Number | Publication Date |
---|---|
FR2931021A1 true FR2931021A1 (fr) | 2009-11-13 |
Family
ID=40282250
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
FR0853057A Withdrawn FR2931021A1 (fr) | 2008-05-09 | 2008-05-09 | Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. |
Country Status (3)
Country | Link |
---|---|
US (1) | US8289947B2 (fr) |
EP (1) | EP2117145B1 (fr) |
FR (1) | FR2931021A1 (fr) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8438131B2 (en) * | 2009-11-06 | 2013-05-07 | Altus365, Inc. | Synchronization of media resources in a media archive |
US8385372B2 (en) * | 2010-01-21 | 2013-02-26 | Intel Mobile Communications GmbH | Time-based maintenance via a packet-oriented digital interface in radio-frequency transmitting and receiving assemblies |
US8699617B2 (en) * | 2011-03-28 | 2014-04-15 | Infineon Technologies Ag | Transmitter, receiver, method for transmitting and method for receiving |
CN112291076A (zh) * | 2019-07-25 | 2021-01-29 | 华为技术有限公司 | 丢包定位方法、装置及系统、计算机存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0704999A2 (fr) * | 1994-09-30 | 1996-04-03 | Thomson Consumer Electronics, Inc. | Dispositif pour détecter une composante de synchronisation dans le récepteur d'un système de transmission par satellite |
WO2004114676A2 (fr) * | 2003-06-18 | 2004-12-29 | Thomson Licensing S.A. | Procedes et appareils pour traiter des paquets nuls dans un recepteur de supports numeriques |
US20060200725A1 (en) * | 1995-09-29 | 2006-09-07 | Kabushiki Kaisha Toshiba | Coding apparatus and decoding apparatus for transmission/storage of information |
WO2008003588A1 (fr) * | 2006-07-03 | 2008-01-10 | Thomson Licensing | procédé de transmission de données et dispositif pour le réaliser |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2250897A (en) | 1990-12-04 | 1992-06-17 | Ibm | Error recovery in data communication systems. |
US5896388A (en) | 1995-02-13 | 1999-04-20 | Ncr Corporation | Method and apparatus using GPS to reshape isochronous data at the receiving ends of an ATM network |
FR2782867A1 (fr) | 1998-08-31 | 2000-03-03 | Canon Europa Nv | Dispositif et procede de communication a distance et systemes les utilisant |
US6658027B1 (en) | 1999-08-16 | 2003-12-02 | Nortel Networks Limited | Jitter buffer management |
FR2926424A1 (fr) | 2008-01-10 | 2009-07-17 | Canon Kk | Procede d'acces a un medium dans un reseau de communication synchrone par un noeud emetteur, produit programme d'ordinateur, moyen de stockage et noeud emetteur. |
-
2008
- 2008-05-09 FR FR0853057A patent/FR2931021A1/fr not_active Withdrawn
-
2009
- 2009-05-07 EP EP09159708.8A patent/EP2117145B1/fr active Active
- 2009-05-07 US US12/437,454 patent/US8289947B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0704999A2 (fr) * | 1994-09-30 | 1996-04-03 | Thomson Consumer Electronics, Inc. | Dispositif pour détecter une composante de synchronisation dans le récepteur d'un système de transmission par satellite |
US20060200725A1 (en) * | 1995-09-29 | 2006-09-07 | Kabushiki Kaisha Toshiba | Coding apparatus and decoding apparatus for transmission/storage of information |
WO2004114676A2 (fr) * | 2003-06-18 | 2004-12-29 | Thomson Licensing S.A. | Procedes et appareils pour traiter des paquets nuls dans un recepteur de supports numeriques |
WO2008003588A1 (fr) * | 2006-07-03 | 2008-01-10 | Thomson Licensing | procédé de transmission de données et dispositif pour le réaliser |
Non-Patent Citations (1)
Title |
---|
BOB MOSES ET AL: "Audio Distribution and Control using the IEEE 1394 Serial Bus", PROCEEDINGS OF THE INTERNATIONAL AES CONFERENCE, XX, XX, 1 January 1900 (1900-01-01), pages Complete, XP007904127 * |
Also Published As
Publication number | Publication date |
---|---|
EP2117145B1 (fr) | 2019-07-31 |
US8289947B2 (en) | 2012-10-16 |
US20090279530A1 (en) | 2009-11-12 |
EP2117145A2 (fr) | 2009-11-11 |
EP2117145A3 (fr) | 2010-05-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
FR2922066A1 (fr) | Procede de gestion de la bande passante dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants | |
FR2915338A1 (fr) | Procede d'emission et de reception de contenus de donnees dans un reseau de communication, produit programme d'ordinateur, moyen de stockage et dispositifs correspondants | |
EP0487428A1 (fr) | Dispositif pour la transmission d'informations synchrones par un réseau asynchrone, notamment un réseau ATM | |
FR2926424A1 (fr) | Procede d'acces a un medium dans un reseau de communication synchrone par un noeud emetteur, produit programme d'ordinateur, moyen de stockage et noeud emetteur. | |
FR2929063A1 (fr) | Procede et dispositif d'allocation de chemins de transmission de donnees dans un reseau de communication synchrone, produit programme d'ordinateur et moyen de stockage correspondants | |
FR2931021A1 (fr) | Procede de synchronisation d'un flux de donnees transmis sur un reseau de communication synchrone, produit programme d'ordinateur, moyen de stockage et dispositif recepteur correspondants. | |
FR2837038A1 (fr) | Procede et systeme d'extraction de signal d'horloge permettant une synchronisation des horloges sur un reseau de transmission par paquets | |
EP0505281B1 (fr) | Synchronisation de stations terminales dans un réseau arborescent à l'alternat et multidébit | |
FR2466921A1 (fr) | Appareil d'affectation et de selection de parties de canaux de transmission de donnees | |
EP0756394A2 (fr) | Procédé et dispositif de synchronisation d'horloges d'encodeurs et décodeurs numériques | |
FR2926937A1 (fr) | Procedes de synchronisation d'horloges applicatives dans un reseau de communication synchrone, dispositifs d'emission et de reception, produit programme d'ordinateur et moyen de stockage correspondants. | |
FR2935493A1 (fr) | Procede et dispositif de suivi d'antenne. | |
EP2206331A1 (fr) | Reconfiguration de dispositifs de terminaison de reseau | |
FR2918832A1 (fr) | Procedes de transmission de donnees par des noeuds relais dans un reseau de communication synchrone, procede de reception, produit programme d'ordinateur, moyen de stockage et noeuds correspondants. | |
EP0717575B1 (fr) | Système de radio-communication avec station radio deportée | |
EP2507947B1 (fr) | Dispositif et procédé de distribution de données sur une pluralité de liens physiques | |
FR2940873A1 (fr) | Procede de synchronisation d'une transmission de trames de donnees applicatives, dispositifs d'emission et de reception, produit programme d'ordinateur et moyen de stockage correspondants | |
FR2847749A1 (fr) | Procede et dispositif de transmission de donnees d'informations dans un systeme de bus | |
FR2717978A1 (fr) | Procédé de restitution d'une séquence, notamment animée, d'images successivement reçues d'une source distante, sous forme numérisée, et appareil correspondant. | |
FR2693864A1 (fr) | Procédé et dispositif de synchronisation d'un décodeur connecté à un réseau de transmission asynchrone, notamment de type ATM. | |
EP1245099B1 (fr) | Dispositif de reception de paquets | |
FR2793624A1 (fr) | Procede et dispositif de controle de la synchronisation entre deux noeuds d'un reseau | |
FR2897228A1 (fr) | Methode de transmission d'informations temporelles a latence fixe | |
EP0787388A1 (fr) | Procede et systeme de synchronisation d'un reseau de telecommunication en onde commune | |
FR2940874A1 (fr) | Procede de synchronisation d'une transmission de trames de donnees applicatives, dispositifs d'emission et de reception, produit programme d'ordinateur et moyen de stockage correspondants |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ST | Notification of lapse |
Effective date: 20100129 |