FR2919773A1 - Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants - Google Patents

Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants Download PDF

Info

Publication number
FR2919773A1
FR2919773A1 FR0756816A FR0756816A FR2919773A1 FR 2919773 A1 FR2919773 A1 FR 2919773A1 FR 0756816 A FR0756816 A FR 0756816A FR 0756816 A FR0756816 A FR 0756816A FR 2919773 A1 FR2919773 A1 FR 2919773A1
Authority
FR
France
Prior art keywords
data
symbols
block
decoding
rdb
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
Application number
FR0756816A
Other languages
English (en)
Inventor
Laurent Frouin
Bars Philippe Le
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0756816A priority Critical patent/FR2919773A1/fr
Priority to US12/180,632 priority patent/US8176392B2/en
Priority to EP08161298.8A priority patent/EP2020763B1/fr
Publication of FR2919773A1 publication Critical patent/FR2919773A1/fr
Priority to US13/443,824 priority patent/US8397137B2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045Arrangements at the receiver end
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/05Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
    • H03M13/13Linear codes
    • H03M13/15Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes
    • H03M13/151Cyclic codes, i.e. cyclic shifts of codewords produce other codewords, e.g. codes defined by a generator polynomial, Bose-Chaudhuri-Hocquenghem [BCH] codes using error location or error correction polynomials
    • H03M13/154Error and erasure correction, e.g. by using the error and erasure locator or Forney polynomial
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/29Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes
    • H03M13/2933Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using a block and a convolutional code
    • H03M13/2936Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes combining two or more codes or code structures, e.g. product codes, generalised product codes, concatenated codes, inner and outer codes using a block and a convolutional code comprising an outer Reed-Solomon code and an inner convolutional code
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/37Decoding methods or techniques, not specific to the particular type of coding provided for in groups H03M13/03 - H03M13/35
    • H03M13/45Soft decoding, i.e. using symbol reliability information
    • H03M13/451Soft decoding, i.e. using symbol reliability information using a set of candidate code words, e.g. ordered statistics decoding [OSD]
    • H03M13/453Soft decoding, i.e. using symbol reliability information using a set of candidate code words, e.g. ordered statistics decoding [OSD] wherein the candidate code words are obtained by an algebraic decoder, e.g. Chase decoding
    • H03M13/455Soft decoding, i.e. using symbol reliability information using a set of candidate code words, e.g. ordered statistics decoding [OSD] wherein the candidate code words are obtained by an algebraic decoder, e.g. Chase decoding using a set of erasure patterns or successive erasure decoding, e.g. generalized minimum distance [GMD] decoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/004Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056Systems characterized by the type of code used
    • H04L1/0057Block codes
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/03Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
    • H03M13/23Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using convolutional codes, e.g. unit memory codes
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M13/00Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
    • H03M13/61Aspects and characteristics of methods and arrangements for error correction or error detection, not provided for otherwise
    • H03M13/618Shortening and extension of codes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0097Relays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04RLOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R2420/00Details of connection covered by H04R, not provided for in its groups
    • H04R2420/07Applications of wireless loudspeakers or wireless microphones
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04SSTEREOPHONIC SYSTEMS 
    • H04S3/00Systems employing more than two channels, e.g. quadraphonic
    • H04S3/008Systems employing more than two channels, e.g. quadraphonic in which the audio signals are in digital form, i.e. employing more than two discrete digital channels

Landscapes

  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de décodage d'un ensemble de symboles à décoder, plusieurs blocs de données représentatifs dudit ensemble de symboles étant reçus par un noeud récepteur d'un réseau de communication. Les blocs de données sont codés au moyen d'un code correcteur d'erreur permettant un décodage par effacement. Le noeud récepteur effectue les étapes suivantes : première sélection d'au moins un des blocs de données ; détermination de premiers effacements ; vérification si les premiers effacements sont en nombre inférieur à un seuil donné. En cas de détermination positive, le noeud récepteur effectue un premier décodage (235) par effacement dudit ensemble de symboles à décoder, sinon il effectue une seconde sélection d'au moins un des blocs de données, une seconde détermination de seconds effacements, et un second décodage (237) par effacement dudit ensemble de symboles à décoder à partir des seconds effacements.

Description

Procédé de décodage de blocs de données de contenus, produit programme
d'ordinateur, moyen de stockage et dispositif de décodage correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des transmissions de contenus de données dans un réseau de communication. L'invention concerne notamment la transmission de contenus de données dans un réseau de communication domestique sans-fil synchrone comprenant une pluralité de noeuds récepteurs et plus particulièrement la transmission de contenus dans un système de transmission radio à 60 GHz. 2. Solutions de l'art antérieur Les systèmes de transmission radio à 60 GHz sont particulièrement bien adaptés pour la transmission de données à très haut débit sur courtes distances. Par exemple, un tel système de transmission est bien adapté à la connectivité entre les différents éléments d'un home cinema (ou cinéma à domicile en français).
En effet, pour ce cas d'utilisation, la portée de la transmission est limitée à une dizaine de mètres, mais les débits mis en jeux sont très élevés, parfois au-delà du gigabit par seconde, de part la nature (aussi bien audio que vidéo) et la haute résolution de l'information transmise. De tels systèmes de transmission requièrent un synchronisme parfait entre le ou les émetteurs et les récepteurs, notamment dans le cas d'un système de diffusion d'un contenu audio à canaux multiples, comprenant jusqu'à dix (ou plus) hauts parleurs, et connu sous le nom anglais de surround Sound system . En effet, dans ce cas précis, un émetteur (comprenant aussi un décodeur audio) transmet de manière parfaitement synchrone différents canaux audio issus d'une seule source à un ensemble de récepteurs, comprenant chacun un haut parleur, l'ensemble de ces récepteurs devant restituer globalement le son de manière parfaitement synchronisée afin d'apporter au son un effet de spatialisation. Étant donné le comportement aléatoire du canal de transmission de tels systèmes de transmission (notamment très sensibles aux masquages causés, par exemple, par un individu traversant le champ de transmission), il est nécessaire d'effectuer de multiples transmissions des données afin de garantir la bonne réception de ces données au-delà d'un taux d'erreur résiduelle prédéfini. Des techniques de correction d'erreurs sont classiquement mises en oeuvre dans les systèmes de traitement de données numériques des différents dispositifs (émetteurs et/ou récepteurs) des systèmes dc transmission pour optimiser l'utilisation du canal de transmission (c'est-à-dire pour obtenir une capacité de transport maximum du canal de transmission), mais également pour augmenter la fiabilité des données reçues. Par exemple, des premières techniques classiques de correction d'erreurs sont des techniques de type MIMO (pour en anglais Multiple-Input Multiple- Output ) qui reposent sur la diversité spatiale. En particulier, ces techniques de correction d'erreurs de type MIMO utilisent les transmissions et les réceptions multiples de mêmes symboles de données pour améliorer l'estimation dc ces symboles de données lors de la réception. Les techniques de type MIMO s'appuient sur une bonne connaissance a priori des caractéristiques du canal de transmission malgré son comportement aléatoire variant au cours du temps, la corrélation entre les symboles de données transmis plusieurs fois et ceux reçus plusieurs fois reposant sur cette connaissance a priori du canal de transmission. Par conséquent, un inconvénient de ces premières techniques de correction d'erreurs MIMO est qu'elles ne sont pas adaptées pour rester efficaces lors de l'occurrence d'une modification imprévue (modification en dehors du cadre des caractéristiques du canal de transmission définies a priori) des conditions de transmission (par exemple l'apparition d'un obstacle sur le chemin de transmission occasionnant un masquage sur le chemin de transmission) dans le réseau de communication. D'autre part, un autre inconvénient de ces premières techniques est qu'elles reposent sur la réduction du taux d'erreur sur les symboles de données reçues plutôt que la correction des erreurs au sein de ces mêmes symboles. Des secondes techniques de correction d'erreurs de l'art antérieur analysent la qualité d'un signal reçu (par exemple au travers de la mesure du rapport signal sur bruit ( SNR ou Signal Noise Ratio en anglais)) pour sélectionner la donnée reçue ayant la meilleure qualité de réception avant d'en effectuer le décodage. De nouveau, un inconvénient de ces secondes techniques de correction d'erreur repose sur le fait qu'elles ne permettent pas de poursuivre un processus de correction d'erreurs efficace lorsqu'une dégradation imprévue (du fait, par exemple, de l'apparition d'un obstacle sur le chemin de transmission occasionnant un masquage sur le chemin de transmission) des conditions de transmission du réseau se produit. 3. Objectifs de l'invention L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir, dans le cadre de la diffusion d'un contenu de données dans un réseau de communication comprenant plusieurs noeuds récepteurs du contenu, une technique de correction d'erreurs qui reste efficace lors de l'occurrence de dégradations imprévues des conditions de transmission du réseau. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique de correction d'erreur qui permette d'obtenir une correction d'erreur qui soit faiblement consommatrice en termes de ressources et d'énergie. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique de correction d'erreur qui permette d'optimiser le rendement du canal de transmission du réseau de communication. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique de correction d'erreur qui permette de maitriser le temps de traitement des données, indépendamment d'une variation imprévue des conditions de transmission du réseau de communication. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de mettre en oeuvre une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4. Exposé de l'invention Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de décodage d'un ensemble de symboles, dit ensemble de symboles à décoder, extraits d'un contenu de données, plusieurs blocs de données représentatifs dudit ensemble de symboles à décoder étant reçus par un noeud récepteur d'un réseau de communication comprenant une pluralité de noeuds, dans le cadre de la diffusion, au sein du réseau, du contenu de données par un noeud émetteur vers au moins ledit noeud récepteur, lesdits blocs de données étant codés au moyen d'un code correcteur d'erreur permettant un décodage par effacement. Selon un tel procédé, le noeud récepteur effectue les étapes suivantes : - première sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) lors de la première sélection étant associé(s) à un premier niveau de priorité ; - première détermination d'effacements, dits premiers effacements, à partir du ou des bloc(s) de données sélectionné(s) lors de la première sélection ; -vérification si les premiers effacements sont en nombre inférieur à un seuil donné, le seuil donné étant fonction du code correcteur d'erreur ; -dans le cas d'une vérification positive, premier décodage par effacement dudit ensemble de symboles à décoder, à partir des premiers effacements ; - sinon, le noeud récepteur effectue les étapes suivantes : - seconde sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) lors de la seconde sélection étant associé(s) à un second niveau de priorité ; - seconde détermination d'effacements, dits seconds effacements, à partir des blocs de données sélectionné(s) lors des première et seconde sélections et, - second décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements. Le principe général de l'invention consiste à mettre en oeuvre, dans le cadre de la diffusion d'un contenu dans un réseau de communication préalablement codé au moyen d'un code correcteur d'erreur permettant un décodage par effacement, une première détermination d'effacements à partir de blocs de données correspondant à un même ensemble de symboles, les blocs de données étant sélectionnés selon un premier niveau de priorité, et, dans le cas d'un nombre d'effacements déterminés inférieur à un seuil donné, décodage de l'ensemble de symboles à partir des effacements déterminés. Dans le cas contraire, une seconde détermination d'effacements est mise en oeuvre à partir de blocs de données correspondant au même ensemble de symboles, les blocs de données étant sélectionnés selon un second niveau de priorité. Ainsi, le décodage par effacement de blocs de données adresse simultanément la correction des erreurs liées d'une part à la fiabilité du canal de transmission et d'autre part aux variations imprévues des conditions de transmission (par exemple de type masquage).
Ainsi, lorsque les conditions de diffusion du contenu sur le réseau de communication sont idéales (par exemple absence de masquage), l'invention permet de déclencher une première détermination d'effacements à partir d'un ensemble de blocs de données qui est supposé faire rapidement aboutir le décodage complet afin de retrouver l'ensemble de symboles initialement émis.
Ainsi, dans ce cas, la correction des erreurs est essentiellement accomplie au travers d'un décodage, effectué à partir d'une première détermination d'effacements, simple et peu coûteux en termes de ressources et d'énergie. Cela permet de minimiser le temps de traitement, donc la consommation de ressources et d'énergie du noeud récepteur.
Dans le cas d'un nombre d'effacements déterminés supérieur au seuil donné, le second décodage est alors effectué à partir d'une seconde détermination d'effacements effectuée sur la base des blocs de données sélectionnées lors de la seconde sélection. Cette seconde détermination d'effacements, plus coûteuse, permet toutefois de pallier au défaut de la première détermination d'effacements dans le cas de variations des conditions de transmission (par exemple un masquage), et ainsi parvenir tout de même au décodage de l'ensemble de symboles extraits du contenu. On pourra par la suite dénommer décodage de premier niveau (ou décodage incrémentai) le décodage par effacement effectué à partir des effacements obtenus suite à la première détermination d'effacements et dénommer décodage de second niveau (ou décodage final) le décodage par effacement effectué à partir des effacements obtenus suite à la seconde détermination d'effacements. Avantageusement, la seconde détermination d'effacements est mise en oeuvre après obtention, par le noeud récepteur, d'une information, dite information de déclenchement, indiquant que les blocs de données représentatifs de l'ensemble de symboles à décoder ont tous été transmis dans le réseau de communication. Ainsi, la seconde détermination d'effacements n'est effectuée que lorsque l'ensemble des blocs de données pouvant constituer la seconde sélection de blocs de données permettant le décodage de l'ensemble de symboles extraits du contenu ont été transmis (et reçus par le noeud récepteur si aucun masquage n'a eu lieu) dans le réseau de communication. De façon avantageuse, l'information de déclenchement est obtenue à partir d'une information représentative d'une séquence de transmission dans le réseau de communication de blocs de données lors d'un cycle de cadencement du réseau de communication, chacun desdits blocs de données étant représentatif d'un ensemble de symboles extraits d'un contenu de données diffusé dans le réseau de communication. Ainsi, à partir d'une représentation de la séquence de transmission dans le réseau de communication de blocs de données lors d'un cycle de cadencement du réseau de communication, chacun des blocs de données étant représentatif d'un ensemble de symboles extraits d'un contenu de données diffusé dans le réseau de communication, il est possible de déterminer à quel instant l'intégralité des blocs de données représentatifs d'un même ensemble de symboles extraits d'un contenu a été transmise dans le réseau de communication. Selon une caractéristique avantageuse, la séquence de transmission définit, pour chaque ensemble de symboles extraits d'un contenu, au moins quatre blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu. Ainsi, cela permet, avec une forte probabilité, la réussite du décodage de l'ensemble de symboles extraits d'un contenu, dans le cadre du décodage par comparaison deux à deux des blocs de données sélectionnés, alors qu'un masquage est apparu pendant la transmission des blocs de données de la première sélection. Avantageusement, pour un ensemble de symboles extraits d'un contenu, les trois premiers, dans la séquence de transmission, blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu sont associés au premier niveau de priorité et tous les blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu sont associés au second niveau de priorité. Ainsi, il est possible de faire une première détermination d'effacements à partir de 3 blocs de données représentatifs d'un même ensemble de symboles extraits d'un contenu, en effectuant par exemple une comparaison des symboles 2 à 2, et de faire une seconde détermination d'effacements à partir des 4 blocs de données dans le cas où le nombre d'effacements déterminés par la première détermination d'effacements est supérieur au seuil donné. Ainsi, cela permet, avec une forte probabilité, que la première détermination d'effacements suffise à la réussite du décodage en l'absence de masquage pendant la transmission des blocs de données de la première sélection. De façon avantageuse, le procédé comprend au préalable une étape de détermination de la séquence de transmission des blocs de données en fonction d'une topologie du réseau de communication. Par exemple, cette topologie, illustrée par un graphe de réception, tient compte d'au moins un obstacle à une communication entre deux noeuds dans le réseau de communication, ce qui permet d'avoir une matrice de répartition de la bande passante synchrone décrivant des retransmissions de blocs de données, pour des noeuds récepteurs, évitant les masquages permanents. Selon une caractéristique préférentielle, chaque bloc de données étant composé d'une pluralité de symboles de taille identique déterminée, le premier décodage étant effectué à partir de plusieurs blocs de données sélectionnés lors de la première sélection, l'étape de première détermination des effacements comprend une sous étape de comparaison des données des symboles de blocs de données deux à deux, les symboles comparés ayant une position identique dans chacun desdits blocs de données.
Ainsi, préférentiellement, on réalise, dans le cadre de la détermination des effacements, une comparaison deux par deux des symboles des blocs de données sélectionnés et un effacement est déterminé à une position lorsque les symboles de cette même position dans les blocs de données sélectionnés diffèrent tous deux à deux. Avantageusement, le code correcteur d'erreur est un code de type Recd Solomon ayant un nombre de symboles de parité, et le seuil donné est égal au nombre de symboles de parité dudit code correcteur d'erreur.
Ainsi, le décodage par effacement utilise conjointement les multiples transmissions d'un bloc de données et l'information de redondance de type Reed Solomon associée à cc bloc de données (telle que présentée en relation avec la figure 2 ci-après décrite), ce qui permet de réduire le nombre de symboles représentatifs de cette information de redondance, sans affecter la capacité de décodage. On améliore ainsi le rendement du code, et donc l'utilisation dc la bande passante synchrone, pour autoriser par exemple, jusqu'à deux blocs de données supplémentaires par ligne d'une matrice de répartition de la bande passante synchrone (telle qu'illustrée ci-après en relation avec la figure 5). De façon avantageuse, un noeud, dit noeud relais, parmi la pluralité de noeuds du réseau de communication, étant en charge dc retransmettre au moins un bloc de données reçu et représentatif de l'ensemble de symboles à décoder, le procédé comprend en outre une étape de détection d'au moins un bloc de données de bourrage, ledit bloc de données de bourrage étant transmis par le noeud relais dans le réseau à la place d'au moins un desdits bloc de données manquant, un bloc de données étant manquant s'il n'a pas été reçu par le noeud relais, et le bloc de données de bourrage est exclu des première et seconde sélections. Ainsi, dans ce cas, le ou les bloc(s) de données de bourrage est(sont) purgé(s) par le noeud récepteur. Cela permet d'exclure de la sélection, effectuée par les premiers et seconds moyens de sélection, des blocs de données dc bourrage. Selon une caractéristique avantageuse, l'étape de second décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements est interrompue suite à la détection d'au moins un événement prédéterminé. Ainsi, des ressources de traitement sont préservées dans le cas où la poursuite du décodage s'avère non nécessaire, les données à décoder ne pouvant 5 plus être exploitées. Selon une caractéristique avantageuse, lors d'un cycle de cadencemcnt du réseau de communication, les noeuds du réseau accèdent au réseau selon un ordonnancement prédéterminé, et l'évènement prédéterminé est une fin de cycle de cadencement du réseau de 10 communication. Ainsi, l'interruption du décodage effectué à partir des seconds effacements permet de conserver un synchronisme parfait, d'un contenu diffusé dans le réseau par un noeud émetteur, afin que les noeuds récepteurs restituent le contenu de manière synchronisée. Ainsi, si le contenu est un contenu sonore, des effets de 15 spatialisation peuvent être mis en oeuvre lors de la restitution du contenu. Selon une caractéristique préférentielle, l'ensemble de symboles à décoder correspond à une agrégation d'échantillons générés par une application, génératrice du contenu, pendant un cycle de cadencement du réseau. Ainsi, le procédé de décodage s'effectue à la même cadence que celle à 20 laquelle l'application génératrice du contenu génère les échantillons, ensemble de symboles, extraits du contenu et objets du décodage. 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, comprenant des 25 instructions de code de programme pour la mise en oeuvre du procédé de décodage tel que décrit précédemment. L'invention concerne aussi un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de 30 décodage tel que décrit précédemment. L'invention concerne également un noeud récepteur permettant de décoder un ensemble de symboles, dit ensemble de symboles à décoder, extraits d'un contenu de données, plusieurs blocs de données représentatifs dudit enscmblc de symboles à décoder étant reçus par ledit noeud récepteur, dans le cadre de la diffusion, au sein d'un réseau de communication comprenant une pluralité de noeuds, du contenu de données par un noeud émetteur vers au moins ledit noeud récepteur, lesdits blocs de données étant codés au moyen d'un code correcteur d'erreur permettant un décodage par effacement. Selon l'invention, un tel noeud récepteur comprend : - des premiers moyens de sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) par les premiers moyens de sélection étant associé(s) à un premier niveau de priorité ; - des premiers moyens de détermination d'effacements, dits premiers moyens d'effacements, à partir du ou des bloc(s) de données sélectionné(s) par lesdits premiers moyens de sélection ; - des moyens de vérification si les premiers effacements sont en nombre inférieur à un seuil donné, le seuil donné étant fonction du code correcteur d'erreur ; - des premiers moyens de décodage par effacement dudit ensemble de symboles à décoder, à partir des premiers effacements, lesdits premiers moyens de décodage étant activés si lesdits premiers effacements sont en nombre inférieur audit seuil donné ; - des seconds moyens de sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) par les seconds moyens de sélection étant associé(s) à un second niveau de priorité ; - des seconds moyens de détermination d'effacements, dits seconds effacements, à partir des blocs de données sélectionné(s) par les premiers et seconds moyens de sélection ; et - des seconds moyens de décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements ; lesdits seconds moyens de sélection, lesdits seconds moyens de détermination d'effacements, et lesdits seconds moyens de détermination d'effacements étant activés si lesdits premiers effacements ne sont pas en nombre inférieur audit seuil donné.
Avantageusement, le noeud récepteur comprend des moyens d'obtention d'une information, dite information de déclenchement, indiquant que les blocs de données représentatifs de l'ensemble de symboles à décoder ont tous été transmis dans le réseau de communication, lesdits seconds moyens de détermination d'effacements étant activés par ladite information de déclenchement. De façon avantageuse, l'information de déclenchement est obtenue à partir d'une information représentative d'une séquence de transmission dans le réseau de communication de blocs de données lors d'un cycle de cadencement du réseau de communication, chacun desdits blocs de données étant représentatif d'un ensemble de symboles extraits d'un contenu de données diffusé dans le réseau de communication. Selon une caractéristique avantageuse, la séquence de transmission définit, pour chaque ensemble de symboles extraits d'un contenu, au moins quatre blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu.
Avantageusement, le noeud récepteur comprend : - des moyens d'association des trois premiers, dans la séquence de transmission, blocs de données représentatifs d'un ensemble de symboles extraits d'un contenu au premier niveau de priorité ; - des moyens d'association de tous les blocs de données représentatifs d'un ensemble de symboles extraits d'un contenu au second niveau de priorité. De façon avantageuse, le noeud récepteur comprend des moyens de détermination de la séquence de transmission des blocs de données en fonction d'une topologie du réseau de communication. Selon une caractéristique préférentielle, chaque bloc de données étant composé d'une pluralité de symboles de taille identique déterminée, lesdits premiers moyens de détermination des effacements comprennent des moyens de comparaison des données des symboles de blocs de données deux à deux, les symboles comparés ayant une position identique dans chacun desdits blocs de données.
Avantageusement, le code correcteur d'erreur est un code de type Reed Solomon ayant un nombre de symboles de parité, et le seuil donné est égal au nombre de symboles de parité dudit code correcteur d'erreur. De façon avantageuse, un noeud, dit noeud relais, parmi la pluralité de noeuds du réseau de communication, étant en charge de retransmettre au moins un bloc de données reçu et représentatif de l'ensemble de symboles à décoder, le noeud récepteur comprend : - des moyens de détection d'au moins un bloc de données de bourrage, ledit bloc de données de bourrage étant transmis par le noeud relais dans le réseau à la place d'au moins un desdits bloc de données manquant, un bloc de données étant manquant s'il n'a pas été reçu par le noeud relais ; - des moyens d'exclusion dudit bloc de données de bourrage afin qu'il ne soit pas utilisé par lesdits premier et second moyens de sélection. Selon une caractéristique avantageuse, le noeud récepteur comprend: des moyens de détection d'au moins un événement prédéterminé ; - des moyens d'interruption desdits seconds moyens de décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements, lesdits moyens d'interruption étant activés par la détection d'au moins un événement prédéterminé. Selon une caractéristique avantageuse, le noeud récepteur comprend des 20 moyens d'accès au réseau selon un ordonnancement prédéterminé lors d'un cycle de cadencement du réseau de communication; et l'évènement prédéterminé est une fin de cycle de cadencement du réseau de communication. Selon une caractéristique préférentielle, l'ensemble de symboles à décoder 25 correspond à une agrégation d'échantillons générés par une application, génératrice du contenu, pendant un cycle de cadencement du réseau. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation 30 particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente un schéma d'un réseau de communication dans lequel peut être mis en ouvre un procédé de décodage selon un mode de réalisation particulier conforme à l'invention ; - la figure 2 illustre l'organisation en blocs de données des paquets radio transmis dans un cycle de transmission synchrone de données SDTC, selon le mode de réalisation particulier conforme à l'invention ; - la figure 3 présente un exemple d'architecture détaillée d'un module de communication synchrone SCM générique d'un noeud WAR ou WAD du réseau de communication selon le mode de réalisation particulier de l'invention - la figure 4 présente un exemple de fonctionnement du bloc de décodage de données radio RDB synchrones selon le mode de réalisation particulier conforme à l'invention ; - la figure 5 présente un exemple de matrice de répartition de la bande passante synchrone lors de l'initialisation du réseau de communication de la figure 1 selon le mode de réalisation particulier de l'invention ; - les figures 6A à 6D illustrent des exemples de graphe de réception a priori des modules de communication synchrone des noeuds du réseau de communication selon le mode de réalisation particulier conforme à l'invention - la figure 7 présente les étapes principales d'un algorithme d'initialisation et de gestion de la table de réception d'un module de communication synchrone, mis en oeuvre au sein du module d'interface CPU présenté en relation avec la figure 3 selon le mode de réalisation particulier conforme à l'invention - la figure 8 présente les étapes principales d'un algorithme de décodage d'un bloc de données mis en oeuvre par le module de décodage d'un module de communication synchrone lors de la réception d'un paquet radio selon le mode de réalisation particulier de l'invention ; - la figure 9 illustre les étapes principales de l'algorithme de décodage incrémentai (ou de premier niveau) mis en oeuvre par le module de décodage d'un module de communication synchrone selon le mode de réalisation particulier de l'invention ; la figure 10 détaille les étapes principalesde l'algorithme de décodage final (ou de second niveau) mis en oeuvre par le module de décodage d'un module de communication synchrone selon le mode de réalisation particulier de l'invention ; - la figure I l présente les étapes principales d'un algorithme de détection de bloc RDB nul (encore désigne par missing en anglais) selon un mode de réalisation particulier de l'invention. 6. Description d'un mode de réalisation de l'invention Selon une application particulière du procédé de décodage selon un mode de réalisation particulier de l'invention, on se place dans la suite dans le cadre d'un réseau de communication 100 qui est un réseau home cinema de type 7.1 tel qu'illustré par la figure 1. Bien entendu, l'invention s'applique également dans le cadre d'un réseau home cinema de type 5.1 ou même dans tout autre réseau de communication.
Par exemple, le réseau home cinema 100 comprend : - un noeud WAD (pour Wircless Audio Decoder en anglais, ou Décodeur audio sans fil en français) référencé 5a qui est par exemple un téléviseur à écran plat. Le noeud WAD 5a comprend un décodeur audio mufti voies ( Surround sound decoder en anglais) référencé 5b. Le décodeur 5b est susceptible de diffuser les différents canaux audio associés au contenu audio/vidéo affiché sur l'écran plat de manière parfaitement synchronisée dans le réseau de communication 100. Préférentiellement, le noeud WAD 5a comprend également un terminal source audio-vidéo (par exemple un lecteur DVD non illustré) ; - huit noeuds WAR (pour en anglais Wircless Audio Renderer , ou Récepteur audio sans fil en français) référencés 1 a, 2a, 3a, 4a, 6a, 7a, 8a, et 9a. Chacun des noeuds WAR est équipé de moyens de restitution de canal audio numérique ( Digital Audio Channel Amplifier en anglais) qui sont référencés respectivement lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b. Ces moyens de restitution intègrent notamment un haut-parleur ( speaker en anglais).
Par ailleurs, chacun des noeuds WAD et WAR intègre un module de communication synchrone ci-après désigné par module SCM (pour en anglais Synchronous Communication Module ) qui sera décrit plus en détail dans la suite de la description en relation avec la figure 4.
Dans le cadre du réseau home cinema 100, les noeuds WAR et le noeud WAD communiquent grâce à un réseau maillé sans fil à 60GHz. La fonction d'un noeud WAR est donc de réaliser une interface entre le haut-parleur auquel il est associé et le noeud WAD 5a dans le réseau maillé sans fil.
Chacun des noeuds WAR et noeud WAD 5a est alimenté grâce à une prise de courant (non illustrée). Chacun des noeuds comprend une ou plusieurs antennes afin de mettre en oeuvre des communications sans fil à 60G1-1z. Cette antenne est préférentiellement une antenne électromagnétique commandée élcetroniquement. Avantageusement, chacun des noeuds WAD et WAR est capable d'émettre et de recevoir des données. Ainsi, dans le cadre du réseau 100 de la figure 1, on peut réaliser des communications de type N vers N (N=8), c'est-à-dire multipoint vers multipoint, depuis chacun des noeuds WAD Sa, WAR 1 b, 2b, 3b, 4b, 6b, 7b, 8b, et 9b vers chacun des noeuds WAD 5a, WAR 1 b, 2b, 3b, 4b, 6b, 7b, 8b, et 9b. On se place dans la suite dans le cas particulier de la diffusion, dans le réseau de communication 100, d'un contenu de données c0 (à partir duquel sont réalisés des blocs de données) par le noeud WAD Sa, qui est également appelé noeud émetteur, vers les noeuds WAR lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b, également appelés noeuds récepteurs. Dans le cadre de cette diffusion, le procédé de décodage de blocs de données de contenus selon l'invention (décrit de manière plus détaillée en relation avec les figures 4 à 11) est mis en oeuvre sous la forme d'un logiciel et/ou d'une pluralité de sous logiciels (comprenant une pluralité d'algorithmes décrits ci-après) qui est (sont) exécuté(s) dans plusieurs machines du réseau 100, par exemple dans chacun des noeuds WAR.
Tel qu'illustré ci-après, en relation avec la figure 2, selon le mode de réalisation particulier conforme à l'invention, la bande passante disponible sur le canal de transmission associé au réseau de communication 100 est découpée en plusieurs canaux virtuels (en anglais Virtual Channel ou VC) synchrones correspondant à des intervalles temporels, un ensemble de canaux virtuels étant affecté à la transmission du contenu cO. La fréquence de traitement des canaux virtuels (par exemple 8KHz) ainsi que la taille des échantillons de données transmis (par exemple 48 bits) caractérise le débit utile de chaque canal virtuel. Ainsi, un canal virtuel a par exemple un débit constant de 384 Kbps (kilobits par seconde). La séquence complète comprenant un échantillon de chacun des canaux virtuels disponibles sur le réseau constitue un cycle complet de traitement synchrone de données ou cycle SDPC (pour en anglais Synchronous Data Processing Cycle ). La durée d'un cycle SDPC est égale à 125 s dans le cas d'une fréquence de traitement des canaux virtuels de 8KHz. Par exemple, un canal de transmission audio ayant la résolution 96KHz-24bits utilise 6 canaux virtuels, ce qui, dans le cadre du réseau home cinema 7.1 100 à 8 voies du mode de réalisation particulier de l'invention, représente un total de 48 canaux virtuels. Ainsi, le débit utile du canal audio du réseau 100 est de 18,432 Mbps (mégabit par seconde) uniquement pour le transfert de l'information audio. Par ailleurs, dix canaux virtuels sont également alloués à l'ensemble des noeuds WAR et WAD du réseau, ces canaux virtuels étant réservés au transfert d'informations supplémentaires (information de contrôle, information protocolaire, commande utilisateur, ...). En conséquence, selon le mode de réalisation particulier de l'invention, le canal de transmission audio est composé de 58 canaux virtuels ce qui représente un débit utile de 22,272 Mbps. Ainsi, parmi les canaux virtuels VCO à VC47 alloués à l'ensemble des noeuds du système et utilisés par le module de communication SCM#0 du noeud WAD 5a pour transmettre le contenu de données cO, on précise que : - les données transférées par les canaux virtuels VCO à VC5 sont décodées puis traitées par le module de communication synchrone SCM#I du noeud WAR 9a, et correspondent aux données destinées au haut parleur avant-central (ou en anglais Front-Center Speaker ) ; - les données transférées par les canaux virtuels VC6 à VC1 1 sont décodées puis traitées par le module de communication synchrone SCM#2 du noeud WAR 4a, et correspondent aux données destinées au haut parleur avant-gauche (ou en anglais Front-Loft Speaker ) - les données transférées par les canaux virtuels VC12 à VCI7 sont décodées puis traitées par le module de communication synchrone SCM#3 du noeud WAR 7a, et correspondent aux données destinées au haut parleur avant-droit (ou en anglais FrontRight Speaker ) ; - les données transférées par les canaux virtuels VC 18 à VC23 sont décodées puis traitées par le module de communication synchrone SCM#4 du noeud WAR 3a, et correspondent au haut parleur latéral-gauche (ou en anglais Side-Left Speaker ) ; - les données transférées par les canaux virtuels VC24 à VC29 sont décodées puis traitées par le module de communication synchrone SCM#5 du noeud 8a, et correspondent aux données destinées au haut parleur latéral-droit (ou en anglais Side-Right Speaker ) ; - les données transférées par les canaux virtuels VC30 à VC35 sont décodées puis traitées par le module de communication synchrone SCM#6 du noeud 2a, et correspondent aux données destinées au haut parleur arrière-gauche (ou en anglais Rear-Left Speaker ) ; - les données transférées par les canaux virtuels VC36 à VC41 sont décodées puis traitées par le module de communication synchrone SCM#7 du noeud 1 a, et correspondent aux données destinées au haut parleur arrière-droit (ou en anglais Rear-Right Speaker ) ; - les données transférées par les canaux virtuels VC42 à VC47 sont décodées puis traitées par le module de communication synchrone SCM#8 du noeud 6a, et correspondent aux données destinées au caisson de graves (ou en anglais Subwoofer ). En outre, les canaux virtuels VC48 à VC57 sont utilisés par les noeuds du 30 réseau 100 pour échanger des données supplémentaires. Ainsi, au moins un canal virtuel dédié à l'émission de ces données supplémentaires à destination des autres noeuds du réseau 100 est alloué à chaque noeud (WAR ou WAD) du réseau de communication 100. On alloue par exemple : - les canaux virtuels VC48 et VC49 au noeud WAD 5a ; - le canal virtuel VC50 au noeud WAR 9a ; -le canal virtuel VC51 au noeud WAR 4a - le canal virtuel VC52 au noeud WAR 7a - le canal virtuel VC53 au noeud WAR 3a - le canal virtuel VC54 au noeud WAR 8a ; - le canal virtuel VC55 au noeud WAR 2a - le canal virtuel VC56 au noeud WAR la ; et - le canal virtuel VC57 au noeud WAR 6a. Un conteneur de canal virtuel, encore appelé conteneur VC Chunk (pour en anglais Virtual Channel Chunk ), est constitué de l'ensemble des échantillons d'un même canal virtuel (en anglais Virtual Channel Samples ) transmis sur un ensemble de cycles SDPC. La construction d'un conteneur VC Chunk donné est effectuée pendant un cycle complet de transmission synchrone de données ou cycle SDTC (pour en anglais Synchronous Data Transmission Cycle ) et la transmission du conteneur VC Chunk considéré est quant à elle effectuée pendant la durée du cycle SDTC suivant.
En conséquence, la durée d'un cycle SDTC est un multiple de la durée d'un cycle SDPC et on appelle rapport STPR (pour Synchronous Transmission to Processing Ratio ) le rapport de la durée du cycle SDTC de transmission synchrone sur la durée du cycle SDPC de traitement synchrone. Le rapport STPR définit ainsi le nombre d'échantillons d'un même canal virtuel transmis dans un même VC Chunk. Selon le mode de réalisation particulier de l'invention, le rapport STPR est égal à 16. Ainsi, la taille d'un conteneur VC Chunk est de 96 octets correspondants à la taille d'un échantillon (c'est-à-dire 48 bits) multipliée par la valeur du rapport STPR (ici égale à 16).
Au cours d'un cycle SDTC, chaque noeud (WAS ou WAD) envoie au moins un paquet radio. Selon le mode de réalisation particulier conforme à l'invention, au cours d'un cycle SDTC, dix paquets radio de durée identique sont émis sur le réseau selon une séquence de transmission prédéfinie. Ainsi, les deux premiers paquets radio du cycle SDTC sont émis par le module de communication synchrone SCM#0 du noeud WAD 5a, et les huit paquets radio suivants sont émis par chacun des modules de communication synchrone des noeuds WAR, par exemple, selon l'ordre prédéfini suivant : [SCM#1, SCM#2, SCM#3, SCM#4, SCM#5, SCM#6, SCM#7 et SCM#8]. On décrit désormais, en relation avec la figure 2, l'organisation en blocs de données des paquets radio transmis dans un cycle de transmission synchrone de données SDTC. Ainsi, pendant un cycle SDTC (par exemple de durée égale à 2ms), dix paquets radio (référencés 10 à 19) sont émis, chacun des paquets étant émis par le module de communication synchrone SCM d'un noeud (WAD ou WAR) du réseau 100.
Selon le mode de réalisation particulier de l'invention, le délai de transmission d'un paquet radio est légèrement inférieur à 200 ms (par exemple 198 ms), ce qui correspond à la transmission de 3384 octets de données utiles (correspondant à un débit moyen de 136,479Mbps). Bien entendu, des variantes du mode de réalisation de l'invention peuvent mettre en oeuvre des valeurs différentes adaptées aux besoins de l'application et de la configuration du réseau souhaités. Au cours d'un cycle SDTC, dans le cas où le rapport STPR est égal à 16, chaque module de communication synchrone des noeuds (WAD et WAR) du réseau traite 16 cycles complets SDPC (référencés 1058 à 2558), chacun des cycles SDPC ayant une durée égale à 1251_ts. Le débit moyen de traitement des données synchrones est ainsi de 22,272Mbps. Au cours de chacun des cycles SDPC, les 58 échantillons des canaux virtuels sont traités. Ainsi, par exemple, les échantillons 1000, 1030, 1031, 1057 sont traités pendant le cycle SDPC 1058, l'échantillon 1100, pendant le cycle SDPC 1 158 et les échantillons 2500, 2530, 2257 pendant le cycle SDPC 2558. Il est à noter que, par soucis de clarté, seuls les échantillons précités sont représentés sur la figure 2.
Un paquet radio comprend : - un champ en-tête 49, noté RPH (pour en anglais Radio Packct I-leader ), comprenant des informations de protocoles nécessaires notamment à la gestion du contrôle d'accès de chaque noeud au canal de transmission ; et - un champ de données utiles 50, noté RPP (pour en anglais Radio Packct Payload ), comprenant notamment un ensemble de blocs de données radio RDB (pour en anglais Radio Data Block ) et 24 octets réservés pour de futures extensions. En particulier, le champ RPP 50 est découpé en blocs de données radio, ci-après appelés blocs RDB (référencés de 20 à 48), par exemple d'une longueur de 114 octets. En conséquence, pour chaque paquet radio, le nombre de blocs RDB par champ RPP est égal à 29. Le format d'un bloc de données radio RDB reste identique quelle que soit la nature d'un conteneur VC Chunk (transmis, estimé pour être retransmis, ou estimé pour être décodé puis traité). Un bloc de données radio RDB comprend : - un champ en-tête 51, noté RDB-H (pour en anglais Radio Data Block Header ) dont la taille est, par exemple, égale à 2 octets ; - un champ de données utiles 52, noté RDB-P (pour en anglais Radio Data Block Payload ) dont la taille est, par exemple, égale à 96 octets ; et - une information de redondance 53 destinée à la correction des erreurs, notée RDB-FEC (pour en anglais Radio Data Block Forward Error Correction ) dont la taille est, par exemple, égale à 16 octets. Ainsi, le champ de données utiles RDB-P 52 correspond à un conteneur VC Chunk. Les données du champ RDB-P 52 sont soit telles que transmises Si le bloc RDB est émis par le module SCM#0 du noeud WAD 5a (noeud émetteur), soit telles qu' estimées pour être retransmises si le bloc RDB est retransmis par un module SCM d'un noeud WAR relais du bloc, ou soit telles qu' estimées pour être décodées et ensuite traitées si le bloc RDB est reçu par un module SCM récepteur et destinataire du bloc. Lc réseau de communication 100 est un réseau sans-fil, et des erreurs peuvent intervenir lors de la transmission des données.
Ainsi, les modules SCM des noeuds WAR relais ou récepteurs n'ont, dans certains cas, qu'une estimation des données utiles du bloc ROB tel qu'il a été initialement transmis par le noeud WAD 5a. Ainsi, selon l'exemple du mode de réalisation de l'invention, et conformément au champ 112 d'une matrice de répartition de la bande passante synchrone ci-après illustrée en relation avec la figure 5, le module de communication synchrone SCM#0 du noeud WAD 5a émet un paquet radio 1 l qui comprend un champ RPP 50. Le champ RPP 50 comprend notamment le bloc de données radio RDB 26, comprenant lui-même 16 échantillons associés au canal virtuel VC#30 et générés par le module SCM#0 du noeud WAD 5a au cours du cycle SDTC précédent et transmis pour la première fois au cours du cycle courant. De même, le même paquet radio 1 l comprend le bloc de données radio RDB 48 associé à la retransmission des 16 échantillons du canal virtuel VC#56 transmis au cours du cycle SDTC précédent par le module de communication 1 5 synchrone SCM#7 du noeud WAR 1 a, conformément au champ 1 19 de la matrice de répartition de la bande passante synchrone ci-après illustrée en relation avec la figure 5. On entend par retransmission de données, la transmission par un noeud du réseau de données qu'il a précédemment reçues d'un autre noeud du réseau. En 20 effet, de manière à assurer une bonne diversité spatiale dans un système de transmission radio à 60 GHz et ainsi assurer qu'un nombre suffisant de copies d'un échantillon de contenu (ou blocs de données représentatifs d'un même échantillon de contenu) parvient au destinataire de l'échantillon de contenu, certains noeuds relaieront (ou retransmettront) les données émises initialement par 25 d'autres noeuds du réseau de communication. Les retransmissions s'effectuent selon la description portée dans la matrice de répartition de la bande passante synchrone, décrite ci-après en relation avec la figure 5. On présente, en relation avec la figure 3, un exemple d'architecture détaillée d'un module de communication synchrone SCM générique d'un noeud 30 WAR ou WAD du réseau de communication 100 selon le mode de réalisation particulier de l'invention. Ainsi, un module de communication synchrone générique d'un noeud WAR ou WAD comprend : - un bloc de mémoire d'exécution RAM 86 (pour en anglais Read Access Memory ) ; - un bloc de mémoire non volatile 85 (pour en anglais Read Only Memory ), dans lequel différentes représentations statiques de matrices de répartition de la bande passante synchrone (ci-après illustrées en relation avec la figure 5) sont par exemple stockées ; - une interface utilisateur 83 ; une unité de traitement 87, encore appelée CPU (pour en anglais Central Processing Unit ). Le bloc de mémoire d'exécution 86 et le bloc de mémoire non volatile 85 sont associés directement au CPU 87. Par ailleurs, le CPU 87 peut traiter des informations de configuration (par exemple la disposition et les dimensions de la pièce dans laquelle est installé le réseau home cinema 100, les zones de passage, ...) afin de choisir la matrice de répartition de la bande passante synchrone la plus appropriée ; - un module de traitement des canaux audio 82 qui peut être soit un moyen de restitution de canal audio numérique ( Digital Audio Channel Amplifier en anglais), soit un décodeur audio multi voies ( Surround Sound Decoder en anglais) ; - un module d'interface radio 60GHz 99 ; - un module d'interface synchrone audio 98 ; - un module de communication 84 qui communique avec le CPU 87. Par ailleurs, le module de communication 84 assure le transfert des données entre le module d'interface radio 60GHz 99 et le module d'interface synchrone audio 98 vers etlou depuis le module de traitement des canaux audio 82. Par ailleurs, selon le mode de réalisation particulier conforme à l'invention, le module de communication 84 du module de communication synchrone SCM générique comprend notamment : - un module d'interface CPU 93 au travers duquel le CPU 87 communique avec le module de communication 84. Le module d'interface CPU 93 gère notamment les interruptions à destination du CPU 87, ainsi que les échanges de données (non représentées afin de ne pas alourdir la figure) entre les différents blocs du module de communication 84 (ci-après détaillés) et le CPU 87. Par ailleurs, lors de l'initialisation du réseau 100, le module d'interface CPU 93 stocke la matrice de répartition de la bande passante synchrone utilisée par le réseau 100. - un bloc de lecture 88 de conteneurs VC Chunks. Le bloc de lecture 88 est chargé de l'extraction, pendant le cycle SDPC de traitement synchrone de données, de chaque échantillon extrait du champ RDB-P 52 d'un bloc radio RDB reçu en fonction du champ RDB-H 51 ; - un bloc d'écriture 89 de conteneurs VC Chunks. Le bloc d'écriture 89 est chargé de construire les champs RDB-P 52 et RDB-H 51 de chaque bloc de données radio RDB associé à un canal virtuel VC, au fur et à mesure de l'écriture de chacun des échantillons du canal virtuel considéré pendant le cycle SDPC de traitement synchrone de données, auquel l'échantillon est associé ; - un bloc d'émission 95 de paquets radio qui comprend une zone de mémoire d'émission de paquets radio. Le bloc d'émission 95 intègre notamment les fonctions de modulation (par exemple de type OFDM) et de codage convolutionnel (par exemple par division polynomiale dans le corps des éléments binaires) ; - un bloc de réception 94 de paquets radio qui comprend une zone de mémoire de réception de paquets radio. Le bloc de réception 94 réalise les fonctions inverses de celles implémentées dans le bloc d'émission 95, notamment les fonctions de démodulation et de décodage de Viterbi ; - un bloc 97 de synchronisation de cycles SDTC. Le bloc 97 de synchronisation de cycles SDTC contrôle l'enchaînement régulier des cycles SDTC par rapport aux paquets radio reçus par le bloc de réception 94 pour garantir un accès parfaitement synchrone au canal de transmission du bloc d'émission 95 pour l'envoi de paquets radio. Ainsi, selon le mode de réalisation particulier de l'invention, le mécanisme de contrôle ainsi mis en oeuvre permet le traitement en émission/réception d'exactement 10 paquets radio pendant un cycle SDTC de transmission synchrone de données ; un bloc 96 de synchronisation de cycles SDPC 96. Le bloc 96 de synchronisation de cycles SDPC contrôle l'enchaînement régulier des cycles SDPC afin d'assurer un transfert parfaitement synchrone des échantillons de chaque canal virtuel entre les blocs de lecture 88 et d'écriture 89 de conteneurs VC Chunks et le module d'interface synchrone audio 98. Le bloc 96 de synchronisation de cycles SDPC est piloté par le bloc 97 de synchronisation de cycles SDTC, le cycle SDPC étant une division du cycle SDTC et alignée sur le cycle SDTC ; - un bloc de codage 92 de bloc de données radio RDB. Le bloc de codage 92 calcule la valeur du champ RDBFEC 53 en fonction de la valeur des champs RDB-P 52 et RDB-H 51 en appliquant un code séparable à distance maximale MDS (pour en anglais Maximal Distance Séparable ) de type Reed Solomon (j,k) avec j = 114 et k = 98 (114 représentant le nombre total de symboles (ou octets) correspondants aux champs RDB-P 52, RDB-I-1 51 et RDB-FEC 53, et 98 représentant le nombre cumulé de symboles correspondants aux champs RDB-P 52 et RDB-H 51). Le code MDS permet la correction d'un nombre (j-k) maximum de symboles effacés (soit 16 selon l'exemple du mode de réalisation particulier de l'invention). Après codage, les blocs RDB sont stockés dans la zone de mémoire d'émission de paquets radio du bloc d'émission 95, selon leur référencement dans la matrice de répartition de la bande passante synchrone stockée dans le module d'interface CPU 93. Il est à noter que la génération des champs RDB-H 51 et RDB-FEC 53 est seulement effectué par le module de communication synchrone SCM à la source du canal virtuel, respectivement par les blocs d'écriture 89 et de codage 92. En effet, un module SCM de communication synchrone d'un noeud WAR relais d'un bloc RDB ne régénère pas les champs RDB-H 51 et RDB-FEC 53 du bloc RDB considéré, et reprend seulement la valeur de ces champs tels que le module SCM de communication synchrone les a reçus ; un bloc de retransmission 91 des blocs de données radio RDB. Le bloc de retransmission 91 extrait certains des blocs RDB stockés dans la zone de mémoire de réception de paquets radio du bloc de réception 94 pour ensuite les stocker dans la zone de mémoire d'émission de paquets radio du bloc d'émission 95 selon leur référencement dans la matrice de répartition de la bande passante synchrone mémorisée dans le module d'interface CPU 93 ; - un bloc de décodage 90 des blocs de données radio RDB. Le bloc de décodage 90 de données radio RDB synchrones est décrit plus amplement ci-après en relation avec la figure 4.
Les blocs de lecture 88 et d'écriture 89 appartiennent à la partie du module de communication 84 dédiée au traitement des données synchrones, et les blocs d'émission 95 et de réception 94 de paquets radio appartiennent à la partie du module de communication 84 dédiée à la transmission des données synchrones. Lors de l'initialisation du réseau home cincma 100, le CPU 87 effectue le transfert d'une matrice de répartition de la bande passante synchrone depuis le bloc de mémoire ROM 85 vers le module d'interface CPU 93 afin qu'elle soit utilisée pour organiser la communication sur le réseau 100. Optionnellcment, la matrice de répartition de la bande passante synchrone utilisée par le réseau 100 peut être choisie parmi plusieurs matrices (toutes stockées dans le bloc de mémoire ROM 85) en fonction d'information utilisateur sur l'application et l'environnement du réseau 100 communiquées via l'interface utilisateur 83. Pendant un cycle SDTC de transmission synchrone de données, le module de communication 84 doit effectuer la lecture et l'écriture de la totalité des échantillons correspondant aux canaux virtuels qu'il doit traiter pendant les 16 cycles SDPC complets de traitement synchrone de données (dans le cas où le rapport STPR est égal 16). Par ailleurs, avant chaque émission de paquets radio par le bloc d'émission 95, le module de communication synchrone SCM générique du réseau 100 réalise 30 simultanément les opérations suivantes : - réception (au moyen du bloc de réception 94) puis sélection d'un nombre prédéfini de bloc de donnée radio RDB (au moyen du bloc de retransmission 91) ; et - détermination de l'ensemble des blocs RDB associés aux conteneurs VC Chunks dont il est la source (au moyen du bloc de codage 92), ainsi que les informations de protocole RDB qui leur sont associées, respectivement RDB-H 51 (au moyen du bloc d'écriture 89) et RDB-FEC 53 (au moyen du bloc de codage 92). Il est à noter que la retransmission des paquets radio est répartie entre les différents modules de communication synchrone SCM appartenant au réseau home cinema 100 en fonction du nombre de blocs RDB disponibles pour chacun des nœuds du réseau, selon les assignations décrites (ou référencements décrits) dans la matrice de répartition de la bande passante synchrone. On décrit, en relation avec la figure 4, un exemple de fonctionnement du bloc de décodage 90 de données radio RDB synchrones selon le mode de réalisation particulier conforme à l'invention.
Tel qu'illustré par la figure 4, le bloc de décodage 90 de données radio RDB synchrones comprend notamment : - un module de décodage 66 des blocs de données radio RDB reçus en fonction de leur référencement dans la matrice de répartition de la bande passante synchrone 70, stockée dans le module d'interface CPU 93 ; - une mémoire tampon (ou buffer en anglais) de décodage 68, encore notée b_SDTC(N), qui stocke les données radio associées au cycle SDTC(N). La mémoire tampon b_SDTC(N) 68 échange des données avec le module de traitement 66 de blocs de données RDB ; - une mémoire tampon (ou buffer en anglais) de décodage 69, encore notée b SDTC(N-1), qui stocke les données radio associées au cycle SDTC(N-1), SDTC(N-1) étant le cycle SDTC précédent le cycle SDTC(N). La mémoire tampon b_SDTC(N- I) 69 échange des données avec le module de traitement 66 de blocs de données RDB. Le module de décodage 66 décode les blocs RDB provenant de la 30 zone de mémoire de réception 71 du bloc de réception 94. La zone de mémoire de réception 71 comprend plusieurs mémoires tampons qui stockent des paquets radio associés au cycle SDTC(N).
Par ailleurs, le module de décodage 66 transmet les conteneurs VC Chunks décodés à une zone de mémoire tampon 67 (encore noté b_SDTC(N-2)) de traitement du bloc de lecture 88 du module de communication 84. La zone de mémoire 67 comprend plusieurs mémoires tampons qui stockent les conteneurs VC Chunks associés au cycle SDTC(N-2), SDTC(N-2) étant le cycle SDTC précédent le cycle SDTC(N-l), et décodés par le module de décodage 66. Lors d'un cycle SDTC, le module de décodage 66 du bloc de décodage 90 effectue : - un premier niveau de décodage par effacements à partir d'une première sélection de blocs de données radio RDB reçus lors du cycle courant SDTC(N) et lors du cycle précédent SDTC(N-l) par le bloc de réception 94 ; et - un second niveau de décodage par effacements, dans lecas où le premier niveau de décodage par effacements échoue, à partir d'une seconde sélection de blocs de données radio RDB reçus lors du cycle courant SDTC(N) et lors du cycle précédent SDTC(N-l) par le bloc de réception 94. Le bloc de lecture 88 traite les blocs de données radio RDB émis (pour la première fois) lors du cycle SDTC(N-2) et finalement décodés par le module de décodage 66 lors du cycle précédent, c'est-à-dire le cycle SDTC (N-1). Le bloc de décodage 90 du module de communication 84 utilise de manière temporaire la mémoire tampon de décodage b_SDTC(N) 68 et la mémoire tampon de décodage b_SDTC(N-1) 69 comprenant l'ensemble des blocs RDB associés à un conteneur VC Chunk donné ainsi que la valeur intermédiaire du conteneur VC Chunk donné en cours de décodage. Lorsque intervient la fin du cycle SDTC(N), le décodage des blocs RDB, mémorisés dans la mémoire tampon b_SDTC(N-1) 69, par le module de décodage 66 est achevé (ou a été interrompu, comme ci-après décrit en relation avec la figure 8). Les données de la mémoire tampon b_SDTC(N-1) 69 remplacent alors celle de la mémoire tampon b_SDTC(N-2). On présente, en relation avec la figure 5, un exemple de matrice de répartition de la bande passante synchrone stockée dans le module d'interface 93 par le CPU 87 lors de l'initialisation du réseau de communication 100, selon le mode de réalisation particulier de l'invention. Selon le mode de réalisation particulier de l'invention, un cycle de transmission synchrone de données SDTC est découpé en 290 blocs de données radio RDB (10 paquets radio étant transmis par cycle SDTC, chaque paquet radio comprenant 29 blocs RDB). Les lignes (référencées 100, 110, 120, 130, 140, 150, 160, 170, 180, 190) de la matrice de répartition de la bande passante synchrone sont chacune représentative du contenu des champs RDB des 10 paquets radio émis respectivement par les modules SCM#0 (qui est le seul à émettre deux paquets consécutifs), SCM#1, SCM#2, SCM#3, SCM#4, SCM#5, SCM#6, SCM#7, SCM#8 lors du cycle SDTC. Chaque ligne de la matrice est donc composée de 29 éléments, chacun représentatif d'un bloc de données radio RDB selon sa position dans le paquet 15 radio transmis parle module SCM associé à la ligne de la matrice. Par soucis de clarté, tel qu'illustré sur la figure 5, certains éléments des lignes de la matrice sont regroupés pour former des champs plus larges (par exemple le champ 101) décrivant ainsi 6 éléments de la matrice, alors que d'autres éléments ne sont pas regroupés (par exemple l'élément 105). Par exemple, le 20 champ 101 contient les éléments qui sont représentatifs des 6 blocs RDB(0, j) pour j variant de 0 à 5. Le champ 105 contient quant à lui un seul élément qui est représentatif du bloc RDB(0, 24). Ainsi, selon le mode de réalisation particulier de l'invention, au cours d'un cycle SDTC(N), les différents champs RDB(i,j) pour 0 5 i < 10 et 0 < 29 de la 25 matrice de répartition ont par exemple la signification suivante : - pour 58 des blocs de données radio RDB transmis lors du cycle SDTC(N), le champ de données utiles RDB-P 52 contient un conteneur VC Chunk transmis pour la première fois sur le réseau 100. Les 58 blocs RDB considérés sont par exemple représentés par les champs 101 à 105, 1 1 1 à 30 115, ainsi que des champs 125, 135, 145, 155, 165, 175, 185, et 195 de la matrice de répartition ; - pour les 232 autres blocs de données radio RDB de la matrice de répartition, le champ de données utiles RDB-P 52 contient un conteneur VC Chunk qui a été soit préalablement reçu (lors d'un précédent cycle SDTC) puis retransmis, soit qui provient du même cycle SDTC(N), soit qui a été transmis lors d'un ou plusieurs cycles SDTC(N-m) précédents.
Dans le mode de réalisation particulier conforme à l'invention, on limite la retransmission au cycle précédent uniquement (c'est-à-dire au cas m=l). Ainsi, les champs de la matrice 131 à 134, 143, 144, 157, 158, 162, 172, 184, 192, 197, 198 et 199 sont par exemple représentatifs de 65 blocs RDB retransmis pendant le même cycle SDTC(N) que celui de leur première transmission. Les champs restants, représentatifs des 167 blocs RDB restants, identifient des blocs RDB retransmis, dont la première émission a été effectuée lors du cycle précédent SDTC(N-I). Dans le mode de réalisation particulier de l'invention, chaque bloc RDB est transmis (émis ou relayé) par les différents noeuds du réseau 100 à au moins quatre (ici cinq) reprises (c'est-à-dire cinq transmissions pour un même conteneur VC Chunk), ce qui caractérise en partie la répartition des blocs RDB au sein de la matrice de répartition de la bande passante synchrone. Le fait que chaque bloc de données RDB correspondant à un même conteneur VC Chunk soit transmis au moins quatre fois permet notamment d'assigner une priorité forte à trois de ces blocs RDB transmis (par exemple les trois premiers transmis) parmi les au moins quatre transmis, et permet ainsi, avec une forte probabilité, que la première détermination d'effacements suffise à la réussite du décodage en l'absence de masquage pendant la transmission des blocs de données de la première sélection (c'est-à-dire les trois premiers dans l'exemple précité). En effet, en procédant à une comparaison 2 à 2 des symboles pour déterminer les effacements, la probabilité d'obtenir un nombre d'effacements inférieur au nombre de symboles de parité du code correcteur d'erreur est forte, en prenant 3 blocs de données RDB reçus correspondant à un même conteneur VC Chunk. On entend par comparaison 2 à 2 la comparaison des données des symboles de blocs de données deux à deux, les symboles comparés ayant une position identique dans chacun desdits blocs de données ; si lors de cette comparaison les symboles diffèrent, le nombre d'effacements liés au décodage du bloc de données est incrémenté d'une unité. Cependant étant donné cette contrainte de (au moins quatre) cinq transmissions par bloc RDB, il existe de multiples représentations statiques de matrices de répartition de la bande passante synchrone. On peut donc avoir plusieurs représentations statiques de cette matrice stockée dans la mémoire ROM 85, et décider, à l'initialisation du réseau home cinema 100 et/ou sur demande de l'utilisateur, d'en choisir une en particulier (par exemple sur la base d'information renseignée par l'utilisateur comme la présence d'obstacles permanents au moyen de l'interface utilisateur 83).
Chaque élément de la matrice de répartition de la bande passante synchrone correspond à un bloc RDB et comprend notamment les informations suivantes : - un champ désigné VCB (pour en anglais Virtual Channel Bank ) indiquant un numéro de bande synchrone. Le champ VCB indique le numéro de bande synchrone à laquelle est associé le canal virtuel VC dont le conteneur VC Chunk est transporté par le bloc RDB considéré. Ce numéro de bande synchrone est un identifiant d'application, c'est-à-dire que c'est un identifiant commun aux canaux virtuels VC utilisés pour transporter les données issues d'un même contenu. Dans l'exemple du mode de réalisation particulier de l'invention, un numéro VCB est attribué par voie audio soit huit numéros VCB au total. Une bande synchrone de canaux virtuels comprend donc six canaux virtuels. Tous les canaux virtuels appartenant à une même bande synchrone VCB indiquent une même valeur prédéfinie pour ce champ VCB. Le champ VCB est optionnel et peut prendre une valeur indéfinie (par exemple pour les canaux virtuels VC 48 à 57 destinés au transport de données synchrones supplémentaires) ; - un champ désigné VC (pour en anglais Virtual Channel ). Le champ VC indique le numéro de canal virtuel dont 1c conteneur VC Chunk est transporté par le bloc RDB considéré ; - un champ désigné Rx qui indique que le noeud du réseau qui reçoit le conteneur VC Chunk associé au canal virtuel est destinataire des données du canal virtuel (dans ce cas Rx = `1'), ou qu'il ne l'est pas (dans ce cas Rx=`0'); - un champ désigné SDTC qui indique le cycle SDTC au cours duquel le conteneur VC Chunk transporté par le bloc RDB considéré a été transmis pour la première fois. Lorsqu'un tel cycle SDTC est le cycle SDTC courant, alors le champ SDTC prend la valeur `0', et lorsqu'un tel cycle SDTC est le cycle SDTC précédent, alors SDTC prend la valeur' 1' ; - un champ désigné retransmis qui indique si le conteneur VC Chunk transporté par le bloc RDB considéré est retransmis ou relayé (dans ce cas retransmis = `l'), ou non (dans ce cas retransmis = `0') ; -un champ désigné rang qui indique le nombre de blocs RDB restant à transmettre et correspondant au même conteneur VC Chunk que celui transporté par le bloc RDB considéré. Par exemple, le champ rang prend la valeur 4 lors de la première transmission (dans le cas où le conteneur VC Chunk est transmis 5 fois). La valeur du champ rang dépend de l'ordre d'apparition dans le temps du block RDB, et non de l'ordre d'apparition du bloc RDB dans la matrice de répartition ; - un champ prio qui indique la priorité de décodage (préférentiellement, pour un conteneur VC Chunk donné, on attribue dans la matrice de répartition des valeurs de priorité de décodage croissante, de 1 à 5, à chacun des blocs RDB correspondant au même conteneur VC Chunk que celui transporté par le bloc RDB considéré, dans l'ordre chronologique de transmission de ces blocs). Plus la priorité est élevée, et plus la valeur du champ prio est faible (la valeur `1' étant attribuée à la priorité la plus forte). Par exemple, l'élément de la matrice correspondant au sixième bloc RDB du premier paquet radio émis dans un cycle SDTC (encore noté RDB(l ; 6)) est caractérisé par : RDB(l ; 6) = { VCB=6 ; VC=30 ; Rx=INDEFINI ; SDTC=O ; retransmis=0 ; rang=4; prio=INDEFINI}.
Il est à noter que les champs Rx, rang et prio ne sont pas représentés sur la figure 5. Lors de l'initialisation du réseau home cinema 100, chaque noeud du
réseau 100 charge dans le module d'interface 93 de son propre module de communication synchrone une même matrice de répartition de la bande passante synchrone. On décrit, en relation avec les figures 6A à 6D, des exemples de graphe de réception a priori des modules de communication synchrone des noeuds du réseau de communication selon le mode de réalisation particulier conforme à l'invention. Pour chaque noeud (WAS ou WAD) du réseau, on peut identifier a priori un nombre prédéfini de meilleurs noeuds émetteurs à partir d'un graphe de réception a priori, en se basant sur une topologie typique propre au réseau de communication 100. Par rapport à une position idéale dans l'espace de chacun des noeuds du réseau home cinema 100, on peut représenter un graphe de réception a priori. Ainsi, la figure 6A (respectivement la figure 6B, la figure 6C, la figure 6D) décrit un exemple de graphe de réception a priori des modules de communication synchrone SCM#1, SCM#6 et SCM#7 (respectivement SCM#0 et SCM#8 pour la figure 6B, SCM#2 et SCM#3 pour la figure 6C, et SCM#4 et SCM#5 pour la figure 6D). Tel qu'illustré par la figure 6A, le module de communication synchrone SCM#1 est supposé recevoir les paquets radio depuis tous les autres modules de communication synchrone SCM#2, SCM#3, SCM#4, SCM#5, SCM#6, SCM#7, SCM#8 et SCM#0. Un graphe de réception a priori est associé à une matrice de répartition de la bande synchrone, et peut-être utilisé pour initialiser la priorité de décodage associée aux éléments de la matrice de répartition qui constituent la table de réception décrite ci-après. La table de réception d'un module de communication synchrone est un sous-ensemble de la matrice de répartition de la bande passante synchrone constitué de l'ensemble des champs représentatifs des blocs RDB dont l'information utile transportée contient des canaux virtuels destinés à ce module de communication synchrone. Lors de l'initialisation du réseau home cinema 100, chaque noeud initialise la liste des différents blocs RDB associés à la transmission et à la retransmission des échantillons de chacun des canaux virtuels qu'il doit décoder. Par ailleurs, lors de cette initialisation du réseau, chaque noeud détermine a priori un ensemble de blocs RDB à décoder prioritairement en fonction, par exemple, du graphe de réception a priori de leur module de communication synchrone SCM. Les autres blocs RDB sont alors éventuellement décodés ultérieurement. D'autre part, pour chaque canal virtuel, les blocs RDB transmis pour la première fois (c'est-à-dire sans retransmission) ainsi que le cycle SDTC associés à leur transmission sont identifiés.
Par exemple, lors de l'initialisation du réseau 100, le module de communication synchrone SCM#6 (à qui sont notamment destinés les échantillons de données des canaux virtuels VC30 à VC35) peut identifier les blocs RDB associés aux champs 112, 132 et 142 comme étant les blocs RDB à décoder prioritairement pour la réception des conteneurs VC Chunks des canaux virtuels VC30 à VC35. On présente, en relation avec la figure 7, les étapes principales d'un algorithme d'initialisation et de gestion de la table de réception d'un module de communication synchrone mise en œuvre au sein du module d'interface CPU 93 selon le mode de réalisation particulier conforme à l'invention.
Optionnellement, dans une étape préalable, on effectue la sélection d'une matrice de répartition de la bande passante synchrone. Ainsi, dans une étape 200, le CPU 87 charge la matrice de répartition sélectionnée dans le module d'interface 93 depuis le bloc de mémoire ROM 85. Dans une étape 201, le module d'interface 93 sélectionne un élément de la matrice de répartition chargée, cet élément étant représentatif d'un bloc RDB, noté RDB(i, j) (i allant de 0 à 9 et j de 0 à 28). Dans une étape 202, on vérifie que le bloc RDB(i, j) de l'élément sélectionné est représentatif d'un conteneur VC Chunk associé à l'un des canaux virtuels destinés au module de communication synchrone.
En cas de vérification positive de l'étape 202 (1c bloc RDB(i, j) est à décoder), la valeur du champ Rx de l'élément sélectionné prend la valeur I (c'est-à-dire Rx = `l') lors d'une étape 203 (étape de marquage des bloc RDB à décoder). Dans une étape 204, on vérifie si le champ prio de l'élément sélectionné de la matrice de répartition est strictement supérieur à 3. En cas de vérification positive de l'étape 204, le champ prio de l'élément sélectionné prend la valeur 2 (c'est-à-dire que prio='2') lors d'une étape 205. En cas de vérification négative de l'étape 204, le champ prio de l'élément sélectionné prend la valeur 1 (c'est-à-dire que prio=' l') lors d'une étape 206. Ainsi, lors des étapes 204 à 206, on affecte de manière systématique des priorités fortes par affectation de la valeur '1' (priorité forte) au champ prio aux trois premiers blocs RDB dans l'ordre chronologique de réception. Bien entendu, il est envisageable de mettre en oeuvre d'autres méthodes d'initialisation des priorités aléatoires ou empiriques (par exemple des méthodes basées sur un graphe de réception théorique, ou sur un graphe de réception mesurée).
Ensuite dans une étape 208, on sélectionne l'élément suivant de la matrice de répartition (en parcourant la matrice de répartition de gauche à droite, c'est-à-dire par incrément de j, et de haut en bas, c'est-à- dire par incrément de i). En cas de vérification négative de l'étape 202 (le bloc RDB(i, j) n'est pas à décoder), la valeur du champ Rx de l'élément sélectionné prend la valeur 0 (c'est- à-dire Rx = `0') lors d'une étape 207 (étape de marquage des bloc RDB à décoder). L'algorithme arrive ensuite dans l'étape 208 précédemment décrite. Dans une étape 209, on vérifie s'il reste des éléments à analyser dans la matrice de répartition. En cas de vérification positive de l'étape 209, on répète les étapes 202 à 208 pour l'élément suivant sélectionné lors de l'étape précédente 208. En cas de vérification négative de l'étape 209, l'algorithme se termine lors d'une étape 210. Tel qu'illustré par la figure 6A, à l'issue de la phase d'initialisation (étapes 200 à 209 de la figure 7), on obtient, pour le module de communication synchrone SCM#6, les éléments de la matrice de répartition représentatifs des bloc RDB associés au conteneur VC Chunk du canal virtuel VC30 suivants : RDB(l ; 6) = {VCB=6 ; VC=30 ; Rx=l ; SDTC=O ; retransmisû0 ; rang=4; prio=2} - RDB(3 ; 6) {VCB=6 ; VC=30 ; Rx=1 ; SDTC=O ; retransmis=1 rang=3; prio=l } - RDB(4 ; 6) = {VCB=6 ; VC=30 ; Rx=l ; SDTC=l ; retransmis=l 5 rang=2; prio=l } - RDB(5 ; 18) = {VCB=6 ; VC=30 ; Rx=1 ; SDTC=l ; retransmis=l rang=1; prio=2 } - RDB(6 ; 18)= {VCB=6 ; VC=30 ; Rx=l ; SDTC=1 ; retransmis=1 rang=0; priaù 1 } . 10 Par ailleurs, tel qu'illustré par la figure 6A, à l'issue de la phase d'initialisation, on obtient, pour le module de communication synchrone SCM#6, les éléments de la matrice de répartition représentatifs des bloc RDB associés au conteneur VC Chunk du canal virtuel VC52 suivants : VC=52 ; Rx=1 ; SDTC=O ; VC=52 ; Rx=1 ; SDTC=l VC=52 ; Rx=1 ; SDTC=1 VC=52 ; Rx=1 ; SDTC=1 VC=52 ; Rx=l ; SDTC=O ; On présente désormais, en relation avec la figure 8, les étapes principales 25 d'un algorithme de décodage d'un conteneur VC Chunk donné auquel est associé plusieurs blocs de données mis en oeuvre par le module de décodage 66 d'un module de communication synchrone lors de la réception d'un paquet radio selon le mode de réalisation particulier de l'invention. Dans une étape 220 (étape d'initialisation), on réserve les trois mémoires 30 tampons ( buffers en anglais), correspondant aux mémoires tampons de décodage b_SDTC(N) 68 et b_SDTC(N-l) 69, et à la mémoire tampon de traitement b_SDTC(N-2) 67. RDB(4 ; 24) = {VCB=INDEFINI ; 15 retransmis=0 ; rang =4 ; prio=l} - RDB(4 ; 25) = {VCB=INDEFINT ; retransmisù 1 ; rang=2 ; prio=l } - RDB(6 ; 27) = {VCB=TNDEFINI ; retransmisù1 ; rangù1 ; prio=1} 20 - RDB(8 ; 27) = {VCB=INDEFINI ; retransmisù1 ; rang=0; prio=2} ; - RDB(9 ; 28) = {VCB=INDEFINI ; retransmis=1 ; rang=3 ; prio=2}.
Dans une étape 221, le module de décodage 66 reçoit un paquet radio, comprenant 28 blocs RDB. Dans une étape 222, le module de décodage 66 analyse un bloc RDB du paquet radio reçu (en commençant par le premier bloc RDB du paquet radio).
Dans une étape 223, on vérifie si le bloc RDB reçu est associé à un conteneur VC Chunk destiné au module de communication synchrone SCM (c'est-à-dire pour lequel Rx=1). En cas de vérification positive de l'étape 223, on vérifie, dans une étape 224, si le bloc RDB est contient une information utile à décoder, c'est-à-dire si ce n'est pas un bloc de bourrage. Cet aspect de l'invention est plus amplement décrit dans la suite de la description en relation avec la figure 1 1. En cas de vérification négative de l'étape 223 et en cas de vérification positive (le bloc est un bloc de bourrage) de l'étape 224, le bloc RDB est supprimé au cours d'une étape 239 (étape de purge).
Suite à l'étape 239, on détermine, dans une étape 240, si un bloc RDB correspondant au conteneur VC Chunk donné a été reçu et pour lequel le champ `rang' est égal à `0'. La vérification de l'étape 240 permet au module de décodage 66 de fonctionner malgré l'absence de réception d'un paquet radio, notamment dans le cas d'une variation imprévisible des conditions de transmission (par exemple un masquage temporaire ou permanent). En cas de vérification négative de l'étape 240 (aucun bloc RDB dont le champ `rang' est égal à n'a été reçu), on met en oeuvre l'étape 242 décrite ultérieurement.
En cas de vérification positive de l'étape 240 (un bloc RDB dont le champ `rang' est égal à a été reçu), on exécute, lors d'une étape 241, un algorithme de décodage final du conteneur VC Chunk pour lequel le bloc RDB dont le champ rang est égal à `0' a été reçu, tel que décrit ci-après en relation avec la figure 10.
En cas de vérification négative de l'étape 224 (le bloc RDB n'est pas un bloc de bourrage), le bloc RDB à décoder est stocké, lors d'une étape 225, dans une des mémoires tampons de décodage qui correspond soit à la mémoire tampon 68 b SDTC(N) soit à la mémoire tampon 69 bSDTC(N-1) selon la valeur de son champ SDTC . Par ailleurs, le stockage tient également compte de la valeur du champ rang du bloc RDB. Dans une étape 226, on vérifie si la priorité de décodage du bloc RDB à décoder est forte, c'est-à-dire si le champ prio est égal à `l' (indiquant qu'il est utilisé lors de la mise en oeuvre de l'algorithme de décodage incrémentai ci-après décrit en relation avec la figure 9). En cas de vérification négative de l'étape 226 (le champ prio n'est pas égal à `1 '), on vérifie, dans une étape 227, si le bloc RDB à décoder a été reçu sans erreur en analysant le champ RDB-FEC 53 associé, en vérifiant que le syndrome du bloc RDB est égal à zéro, sachant que selon l'état de l'art le syndrome correspond au produit du mot code par la transposée de la matrice de parité du code de correction d'erreur utilisé (par exemple de type Reed-Solomon). En cas de vérification positive de l'étape 227 (le bloc RDB à décoder a été reçu sans erreur), un algorithme de décodage incrémental est exécuté lors de l'étape 235, tel que ci-après décrit en relation avec la figure 9. En cas de vérification négative de l'étape 227 (le bloc RDB à décoder a été reçu avec des erreurs), on vérifie, dans une étape 230, si aucun bloc RDB de forte priorité (le champ prio est égal à ` 1') n'a été reçu.
En cas de vérification négative de l'étape 230 (un bloc RDB de forte priorité a été reçu), on met en oeuvre l'étape 242, ultérieurement décrite. En cas de vérification positive de l'étape 230 (défaut de bloc RDB de forte priorité prio=' l'), on vérifie, dans une étape 231, si le bloc RDB à décoder est issu d'une première transmission (encore appelée transmission directe), c'est-à-dire que le champ retransmis est égal à '0'. En cas de vérification positive de l'étape 231 (retransmis='0'), on notifie, au cours de l'étape 233, le CPU 87 au moyen d'un message prio-1 candidat , pour une réassignation ultérieure éventuelle, par le CPU 87, des niveaux de priorité associés aux blocs RDB dans le but d'optimiser la première détermination d'effacements, en optimisant la sélection des blocs RDB utilisés pour la première détermination d'effacements. En cas de vérification négative de l'étape 231 (le bloc RDB à décoder n'est pas issu d'une première transmission), on vérifie, dans une étape 232, si le bloc RDB à décoder bénéficie de bonnes conditions de réception (indicateur de puissance du signal reçu RSSI (pour Received Signal Strength Indicator ) élevé).
En cas de vérification positive de l'étape 232 (indicateur RSSI élevé), l'étape 233 est remise en oeuvre. En cas de vérification négative de l'étape 232 (indicateur RSSI faible), on notifie, au cours de l'étape 234, le CPU 87 au moyen d'un message alarm prion , pour une réassignation ultérieure éventuelle, par le CPU 87, des niveaux de priorité associés aux blocs RDB dans le but d'optimiser la première détermination d'effacements, en optimisant la sélection des blocs RDB utilisés pour la première détermination d'effacements. À la suite des étapes 234 et 235, on vérifie, dans une étape 236, si le champ rang du bloc RDB à décoder est égal à `0' (dernière réception d'un bloc RDB représentatif du conteneur VC Chunk). En cas de vérification positive de l'étape 236 (le champ rang du bloc RDB à décoder est égal à `0'), on exécute un algorithme de décodage final du VC Chunk lors d'une étape 237, tel que décrit ci-après en relation avec la figure 10. Ensuite dans une étape 242, on vérifie si tous les blocs RDB du paquet radio reçu ont été analysés. En cas de vérification négative de l'étape 236 (cc n'est pas la dernière transmission d'un bloc RDB représentatif du conteneur VC Chunk), on met en oeuvre la vérification de l'étape 242. Les vérifications des étapes 236 et 240 permettent de détecter la réception ou la non-réception du dernier bloc RDB représentatif du conteneur VC Chunk. En cas de vérification positive de l'étape 242 (tous les blocs RDB du paquet radio ont été analysés), on vérifie, dans une étape 244, si le cycle SDTC(N) (cycle courant) est terminé. En cas de vérification négative de l'étape 242 (tous les blocs RDB du paquet radio n'ont pas été analysés), on sélectionne, dans une étape 243, le bloc RDB suivant du paquet radio reçu. On répète ensuite les étapes 223 à 242 précédemment décrites.
En cas de vérification négative de l'étape 244 (le cycle SDTC(N) n'est pas achevé), on répète les opérations 221 à 242 précédemment décrites. En cas de vérification positive de l'étape 244 (le cycle SDTC(N) est achevé), on effectue, au cours d'une étape 245, une permutation des données des trois mémoires tampons b_SDTC(N) 68, bSDTC(N-1) 69 et b_SDTC(N-2) 67, en écrasant les données de la mémoire tampon b_SDTC(N-2). La permutation des trois mémoires tampons est réalisée de la manière suivante : - la nouvelle mémoire tampon 68 b_SDTC(N) utilise les ressources de la mémoire tampon b_SDTC(N-2) précédent, après mise à zéro de la valeur de chacune des variables. On a ainsi b_SDTC(N) = b_SDTC(N-2) = 0 ; - la mémoire tampon b_SDTC(N) 68 précédente devient la nouvelle mémoire tampon b_SDTC(N-l). On a ainsi b_SDTC(N-1) = b_SDTC(N) ; la mémoire tampon b_SDTC(N-1) précédente devient la nouvelle mémoire tampon_SDTC(N-2). On a ainsi b_SDTC(N-2) = b_SDTC(N-1).
Lorsque l'étape 245 est achevée, les opérations de traitement du bloc de lecture de conteneurs VC Chunks 88 (stockés dans la mémoire tampon b_SDTC(N-2) 67) préalablement décodés peuvent être mises en oeuvre et l'algorithme revient à l'étape 221. L'algorithme de décodage décrit, en relation avec la figure 8, les opérations mises en oeuvre par le module de décodage 66 du module de communication synchrone pour effectuer la correction des erreurs des différents conteneurs VC Chunks des canaux virtuels qui lui sont destinés. Par ailleurs, l'algorithme de décodage décrit le mécanisme de sélection des blocs RDB au sein du module de décodage 66 au travers des différentes étapes 223, 224, 226, 231 et 232 lors de la réception d'un paquet radio (étape 221). En outre, l'algorithme de décodage décrit plus principalement la relation des opérations de sélection avec l'opération de décodage de premier niveau dit incrémental (détaillée ultérieurement en relation avec la figure 9) de l'étape 235 et les opérations de décodage de second niveau dit final (détaillées ultérieurement en relation avec la figure 10) des étapes 237 et 241. L'algorithme de décodage décrit également la génération d'alarmes (étapes 233, 234 et 238) en fonction des opérations de sélection, par exemple en notifiant le CPU 87 et en sollicitant la génération d'une interruption auprès du module d'interface CPU 93. Les différentes alarmes permettent notamment au CPU 87 de surveiller le bon déroulement des opérations des décodages afin, par exemple, de déclencher un changement de matrice de répartition de la bande passante synchrone. L'algorithme de décodage de la figure 8 décrit enfin la gestion des mémoires tampons de décodage b_SDTC(N), b_SDTC(N-1) et b_SDTC(N-2) (étapes 220, 244 et 245) lors du passage au cycle suivant de transmission synchrone de données.
Ainsi, l'algorithme de décodage de la figure 8 décrit la façon dont le décodage est effectué par le module de décodage 66 pour que des données soient toujours disponibles pour présentation à une application consommatrice à l'issu d'un cycle SDTC. On décrit, en relation avec lafigure 9, les étapes principales de l'algorithme de décodage incrémenta) (ou de premier niveau) mis en oeuvre par le module de décodage 66 d'un module de communication synchrone selon le mode de réalisation particulier de l'invention. Dans une étape 260, le module de décodage 66 attend un bloc RDB correspondant à un conteneur VC Chunk à décoder. Lorsqu'il reçoit un bloc RDB, le module de décodage 66 charge le contexte de décodage associé au bloc RDB reçu. Le contexte de décodage associé au bloc RDB reçu comprend : - un masque d'effacement ; - le nombre d'itérations de décodage ; - l'état d'achèvement du décodage ; - la valeur corrigée du bloc RDB dans le cas où le décodage est achevé ; - l'ensemble des blocs RDB reçus précédemment et représentatifs de cc même bloc RDB à corriger, et pour chacun de ces blocs RDB : o la valeur du bloc RDB, telle qu'elle a été reçue ; o la priorité de cc bloc, extraite de la table de réception ; o un marqueur de prise en compte de cc bloc dans le positionnement des effacements.
Dans une étape 261, on vérifie si le décodage du conteneur VC Chunk correspondant au bloc RDB reçu a déjà été réalisé (décodage achevé). En cas de vérification positive de l'étape 261 (décodage achevé), on revient à l'étape 260 (attente d'un prochain bloc RDB à traiter).
En cas de vérification négative de l'étape 261 (le décodage du conteneur VC Chunk correspondant au bloc de données reçu n'est pas encore achevé), on calcule, dans une étape 262, le syndrome du bloc RDB reçu pour vérifier qu'il a été reçu sans erreur. Ensuite, dans une étape 264, on vérifie si le bloc RDB reçu est le premier 10 bloc RDB reçu associé au conteneur VC Chunk à décoder. En cas de vérification positive de l'étape 264 (premier bloc RDB reçu), on met à jour, dans une étape 265, le nombre d'itérations de décodage avec Itcration decod = ` 1'. En cas de vérification négative de l'étape 264 (le bloc RDB reçu n'est pas 15 le premier), on incrémente, dans une étape 266, le nombre d'itérations de décodage (étape référencée Itcration decod ++). À la suite des étapes de mise à jour du nombre d'itérations de décodage (étapes 265 et 266), on enregistre, dans une étape 267, la valeur corrigée du bloc RDB avec le bloc RDB reçu, ce qui marque l'achèvement de l'algorithme de 20 décodage. En effet, lorsqu'on utilise un code correcteur d'erreur avec une matrice de parité qui assure que les M premiers bits d'un mot encodé sont identiques aux M premiers bits du mot à encoder, la réception sans erreur du bloc RDB permet d'obtenir l'ensemble de symboles extraits du contenu sans avoir recours à une étape de correction par des effacements, ni de décodage proprement dit. 25 L'algorithme revient ensuite à l'étape 260 dans l'attente du prochain bloc RDB à traiter. En cas de vérification négative de l'étape 262 (bloc RDB reçu avec erreurs), on vérifie, dans une étape 268, si le nombre d'itérations de décodage associé au bloc RDB reçu est nul (ce qui correspond à vérifier si le bloc RDB reçu 30 est le premier bloc RDB reçu associé au conteneur VC Chunk à décoder). En cas de vérification positive de l'étape 268 (premier bloc RDB reçu), le nombre d'itérations de décodage prend la valeur 1 (étape référencée
Iteration decod=l) lors d'une étape 269. Puis, dans une étape 270, on initialise le masque d'effacement à 0 (tous les symboles du bloc RDB reçu sont considérés comme effacés) et on marque le bloc RDB comme ayant été pris en compte dans la détermination des effacements.
L'algorithme revient ensuite à l'étape 260 dans l'attente du prochain bloc RDB à traiter. En cas de vérification négative de l'étape 268 (le bloc RDB reçu n'est pas le premier), on incrémente, dans une étape 271, le nombre d'itérations de décodage (Iteration decod ++).
Puis, on procède, dans une étape 272, à la mise à jour du masque d'effacement qui consiste à comparer le bloc RDB reçu avec les blocs RDB ayant déjà été pris en compte dans la détermination des effacements. Plus précisément, aux positions correspondant à des effacements, on compare deux à deux les symboles du nouveau bloc RDB reçu avec les symboles des blocs précédents et on remplace l'effacement par la valeur du symbole lorsqu'au moins deux symboles sont égaux, et cela pour tous les cas de comparaison. On réduit ainsi le nombre des effacements, d'autant plus rapidement que les différences entre les blocs RDB sont faibles. Suite à l'étape 272, on vérifie, dans une étape 273, si le nombre 20 d'effacements (encore noté Eff ) est descendu en dessous du seuil maximum de correction du code Reed Solomon appliqué au bloc RDB (dans l'exemple du mode de réalisation particulier de l'invention, ce seuil est égal à 16). En cas de vérification positive de l'étape 273 (c'est-à-dire Eff < 16), on procède, dans une étape 274, au décodage des effacements selon des méthodes 25 classiques par exemple celles appliquées au code de type Reed-Solomon, puis on répète l'étape 267 avant de se remettre dans l'attente du prochain bloc à traiter (étape 260). L'étape de décodage des effacements d'un code de type Reed-Solomon (en anglais Error-erasure decoding of Reed Solomon code ) peut se faire selon 30 n'importe quelle méthode conventionnelle, comme par exemple celle dont une implémentation est largement décrite dans le brevet US N 5,715,262.
En cas de vérification négative de l'étape 273 (c'est-à-dire Eff> 16), on se remet dans l'attente du prochain bloc à traiter (étape 260). On présente, en relation avec la figure 10, les étapes principales de l'algorithme de décodage final (ou de second niveau) mis en oeuvre par le module de décodage 66 d'un module de communication synchrone selon le mode de réalisation particulier de l'invention. Dans une étape 300, le module de décodage 66 attend un bloc RDB correspondant à un conteneur VC Chunk à décoder. Lorsqu'il reçoit un bloc RDB, le module de décodage 66 charge le contexte de décodage associé au bloc RDB reçu. Le contexte de décodage associé au bloc RDB reçu comprend : - un masque d'effacement ; - le nombre d'itérations de décodage ; - l'état d'achèvement du décodage ; - la valeur corrigée du bloc RDB dans le cas où le décodage est achevé ; - l'ensemble des blocs RDB reçus précédemment représentatif de ce même bloc RDB à corriger, et pour chacun de ces blocs RDB : o la valeur du bloc RDB, telle qu'elle a été reçue ; o la priorité de cc bloc, extraite de la table de réception ; o un marqueur de prise en compte de ce bloc dans le positionnement des effacements. Dans une étape 301, on vérifie si le décodage du conteneur VC Chunk correspondant au bloc RDB reçu a déjà été réalisé (décodage achevé). En cas de vérification positive de l'étape 301 (décodage achevé), on 25 revient à l'étape 300 (attente d'un prochain bloc RDB à traiter). En cas de vérification négative de l'étape 301 (le décodage du conteneur VC Chunk correspondant au bloc de données reçu n'a pas encore été réalisé), on sélectionne, dans une étape 302, un niveau de priorité (noté X) non encore traité. Avantageusement, cette sélection est réalisée par ordre de priorité croissante. 30 Puis dans une étape 303, on vérifie s'il reste un bloc RDB à traiter correspondant à la priorité X sélectionnée (par exemple s'il existe un premier bloc RDB à traiter pour la priorité X sélectionnée dans le cas où aucun bloc RDB pour la priorité sélectionnée n'a été traité). Dans le cas où il ne reste pas de bloc RDB à traiter correspondant à la priorité X sélectionnée, on sélectionne, dans une étape 310, la priorité suivante (étape référencée Prio suivante X ++ ).
Ensuite dans une étape 311, on vérifie si tous les niveaux de priorité ont été traités. En cas de vérification négative de l'étape 311 (tous les niveaux de priorité n'ont pas été traités), on revient à l'étape 303 précédemment décrite. En cas de vérification positive de l'étape 311, on met à jour, dans une 10 étape 312, le champ en-tête du bloc RDB afin d'identifier d'éventuels échantillons erronés (dans ce cas, on parle de correction d'erreur incomplète). Dans le cas particulier où le champ en-tête est lui-même erroné, on tente de le reconstruire par l'analyse du champ de données utiles du bloc RDB. Puis dans une étape 309, on enregistre une information représentative de 15 l'achèvement du décodage. Dans le cas où il reste au moins un bloc RDB à traiter correspondant à la priorité X sélectionnée, on vérifie, dans une étape 314, si le cycle SDTC(N) est achevé, alors que le conteneur VC Chunk en cours de décodage est associé au cycle STDC(N-1) (c'est-à-dire stocké dans la mémoire tampon de décodage 20 b SDTC(N-1) 69). En cas de vérification positive de l'étape 314 (fin du cycle SDTC(N)), le décodage est interrompu et on passe directement à l'étape 312 décrite précédemment. En cas de vérification négative de l'étape 314 (le cycle SDTC(N) n'est pas 25 achevé), on met à jour, dans une étape 304, le masque d'effacements en comparant le bloc RDB mémorisé avec les blocs RDB ayant déjà été pris en compte dans la détermination des effacements, en particulier ceux de la première détermination d'effacements, correspondant au décodage incrémentai. On compare deux à deux les symboles de deux blocs RDB correspondant à des 30 positions effacées, puis on remplace l'effacement par la valeur du symbole lorsque les deux symboles sont égaux. Cette opération est réalisée pour tous les cas de comparaison. Ainsi, on réduit le nombre des effacements, mais de manière a priori plus aléatoire qu'au cours de l'étape 272 tel qu'illustrée par la figure 9. Suite à l'étape 304, on vérifie, dans une étape 305, si le nombre d'effacements (encore noté Eff ) est descendu en dessous du seuil maximum de correction du code Recd Solomon appliqué au bloc RDB (dans l'exemple du mode de réalisation particulier de l'invention, ce seuil est égal à 16). En cas de vérification négative de l'étape 305 (c'est-à-dire Eff > 16), on charge, dans une étape 306, le bloc RDB suivant à traiter, puis on revient à l'étape 303 décrite précédemment. En cas de vérification positive de l'étape (c'est-à-dire Eff < 16), on procède, dans une étape 307, au décodage des effacements par exemple au moyen de la méthode classique précitée (en relation avec l'étape 274), puis on répète l'étape 309 avant de se remettre dans l'attente du prochain bloc à traiter (étape 300). On présente, en relation avec la figure II, les étapes principales d'un 15 algorithme de détection de blocs RDB de bourrage (aussi appelés blocs RDB nuls ) selon le mode de réalisation particulier de l'invention. L'algorithme de détection n'est pas indispensable à la mise en oeuvre de l'invention, mais permet d'améliorer les performances des algorithmes de décodage de premier (incrémentai) et de second niveau (final) en supprimant un 20 traitement inutile lors des opérations de mises à jour des masques d'effacements (étape 272 de la figure 9 et étape 304 de la figure 10). Comme précédemment décrit en relation avec la figure 2, un bloc RDB comprend notamment un champ RDB-H 51 de 16 bits et un champ RDB-P 52 comprenant 16 mots (encore appelés échantillons) de 48 bits représentatifs des 16 25 échantillons consécutifs d'un canal virtuel (le champ RDB-P 52 est aussi appelé conteneur VC Chunk). A chaque bit du champ RDB-H 51 correspond un mot de 48 bits dans le champ RDB-P 52, dans l'ordre de lecture de ces champs, de la gauche vers la droite, tel qu'illustré par la figure 2. 30 Lorsque le bloc de retransmission 91 des blocs de données radio RDB d'un module de communication synchrone n'a pas reçu le bloc RDB à retransmettre, il insère à la place un bloc RDB ayant une séquence particulière, et dont l'ensemble des bits du champ RDB-H 51 est positionné à et l'ensemble des mots du champ RDB-P 52 est positionné à la valeur hexadécimale `0x555555555555' (correspondant à une suite alternée de `0' et de '1' en binaire).
Ainsi, l'objectif de la vérification de l'étape 224 illustrée par l'organigramme de la figure 11 est de détecter la séquence particulière précitée, selon un mécanisme de seuil, pour identifier les blocs RDB non représentatifs d'information utile et dits blocs de bourrage ou blocs nuls .
Dans une étape 330, on charge le premier mot de 48 bits d'un conteneur VC Chunk.
En commençant par le premier mot de 48 bits, on vérifie, dans une étape
331, si le bit du champ RDB-H 51 correspondant est égal à `0'.
En cas de vérification positive de l'étape 331, on vérifie, dans une étape
332, si la valeur du mot de 48 bits considéré est égale à la valeur hexadécimale `0x555555555555'.
En cas de vérification positive de l'étape 332 (la valeur du mot de 48 bits considéré est égale à la valeur hexadécimale `0x555555555555'), on incrémente, dans une étape 333, un compteur noté cnt (l'incrément est référencé cnt ++).
En cas de vérification négative de l'étape 332 (la valeur du mot de 48 bits considéré n'est pas égale à la valeur hexadécimale `0x555555555555'), on passe au mot de 48 bits suivant (étape 334) jusqu'à avoir traité l'ensemble des mots de 48 bits correspondant au conteneur VC Chunk.
Ensuite, dans une étape 335, on vérifie si le mot de 48 bits chargé est le dernier mot du conteneur VC Chunk.
En cas de vérification négative de l'étape 335 (le mot sélectionné n'est pas 25 le dernier), on répète les étapes 331 à 335.
En cas de vérification positive de l'étape 335 (le mot sélectionné est le dernier), on vérifie, dans une étape 336, si le compteur cnt est supérieur à une valeur de seuil prédéfinie (le seuil est par exemple fixé à une valeur prédéfinie de 50% de détection, c'est-à-dire que la valeur du seuil est égale à 8).
30 En cas de vérification négative de l'étape 336 (cnt < seuil), on décide, dans une étape 337, que le bloc RDB représentatif du conteneur VC Chunk est valide (RDB≠O) ce qui termine l'algorithme de détection.
En cas de vérification positive de l'étape 336 (cnt > seuil), on décide, dans une étape 338, que le bloc RDB représentatif du conteneur VC Chunk est nul (RDB=O) ce qui termine l'algorithme de détection.

Claims (26)

REVENDICATIONS
1. Procédé de décodage d'un ensemble de symboles, dit ensemble de symboles à décoder, extraits d'un contenu de données, plusieurs blocs de données (52) représentatifs dudit ensemble de symboles à décoder étant reçus par un noeud récepteur d'un réseau de communication (100) comprenant une pluralité de noeuds (1a, 2a, 3a, 4a, 5a, 6a, 7a, 8a, 9a), dans le cadre de la diffusion, au sein du réseau, du contenu de données par un noeud émetteur vers au moins ledit noeud récepteur, lesdits blocs de données étant codés au moyen d'un code correcteur d'erreur permettant un décodage par effacement, caractérisé en ce que le noeud récepteur effectue les étapes suivantes : - première sélection (201) d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) lors de la première sélection étant associé(s) à un premier niveau de priorité ; - première détermination d'effacements, dits premiers effacements, à partir du ou des bloc(s) de données sélectionné(s) lors de la première sélection ; -vérification (273, 305) si les premiers effacements sont en nombre inférieur à un seuil donné, le seuil donné étant fonction du code correcteur d'erreur ; - dans le cas d'une vérification positive, premier décodage (235) par effacement dudit ensemble de symboles à décoder, à partir des premiers effacements ; - sinon, le noeud récepteur effectue les étapes suivantes : - seconde sélection (302) d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) lors de la seconde sélection étant associé(s) à un second niveau de priorité ; - seconde détermination d'effacements, dits seconds effacements, à partir des blocs de données sélectionné(s) lors des première et seconde sélections et, - second décodage (237) par effacement dudit ensemble de symboles à décoder à partir des seconds effacements.
2. Procédé de décodage selon la revendication 1, caractérisé en ce que la seconde détermination d'effacements est mise en oeuvre après obtention, par le 30noeud récepteur, d'une information, dite information de déclenchement, indiquant que les blocs de données représentatifs de l'ensemble de symboles à décoder ont tous été transmis dans le réseau de communication.
3. Procédé de décodage selon la revendication 2, caractérisé en ce que l'information de déclenchement est obtenue à partir d'une information représentative d'une séquence de transmission dans le réseau de communication de blocs de données lors d'un cycle de cadencement du réseau de communication, chacun desdits blocs de données étant représentatif d'un ensemble de symboles extraits d'un contenu de données diffusé dans le réseau de communication.
4. Procédé de décodage selon la revendication 3, caractérisé en ce que la séquence de transmission définit, pour chaque ensemble de symboles extraits d'un contenu, au moins quatre blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu.
5. Procédé de décodage selon la revendication 4, caractérisé en ce que, pour un ensemble de symboles extraits d'un contenu, les trois premiers, dans la séquence de transmission, blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu sont associés au premier niveau de priorité et en ce que tous les blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu sont associés au second niveau de priorité.
6. Procédé de décodage selon l'une quelconque des revendications 3 à 5, caractérisé en ce qu'il comprend au préalable une étape de détermination de la séquence de transmission des blocs de données en fonction d'une topologie du réseau de communication.
7. Procédé de décodage selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, chaque bloc de données étant composé d'une pluralité de symboles de taille identique déterminée, le premier décodage étant effectué à partir de plusieurs blocs de données sélectionnés lors de la première sélection, l'étape de première détermination des effacements comprend une sous étape de comparaison des données des symboles de blocs de données deux à deux, les symboles comparés ayant une position identique dans chacun desdits blocs de données.
8. Procédé de décodage selon l'une quelconque des revendications 1 à 7,caractérisé en ce que le code correcteur d'erreur est un code de type Reed Solomon ayant un nombre de symboles de parité, et en ce que le seuil donné est égal au nombre de symboles de parité dudit code correcteur d'erreur.
9. Procédé de décodage selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, un noeud, dit noeud relais, parmi la pluralité de noeuds du réseau de communication, étant en charge de retransmettre au moins un bloc de données reçu et représentatif de l'ensemble de symboles à décoder, le procédé comprend en outre une étape de détection (224) d'au moins un bloc de données de bourrage, ledit bloc de données de bourrage étant transmis par le noeud relais dans le réseau à la place d'au moins un desdits bloc de données manquant, un bloc de données étant manquant s'il n'a pas été reçu par le noeud relais, et en ce que le bloc de données de bourrage est exclu des première et seconde sélections.
10. Procédé de décodage selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape de second décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements est interrompue suite à la détection d'au moins un événement prédéterminé (244).
11. Procédé de décodage selon la revendication 10, caractérisé en ce que, lors d'un cycle de cadencement du réseau de communication, les noeuds du réseau accèdent au réseau selon un ordonnancement prédéterminé et en ce que l'évènement prédéterminé (244) est une fin de cycle de cadencement du réseau de communication.
12. Procédé de décodage selon la revendication 11, caractérisé en ce que l'ensemble de symboles à décoder correspond à une agrégation d'échantillons générés par une application, génératrice du contenu, pendant un cycle de cadencement du réseau.
13. Produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de décodage selon l'une au moins des revendications 1 à 12.
14. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par leditordinateur pour mettre en oeuvre le procédé de décodage selon l'une au moins des revendications 1 à 12.
15. Noeud récepteur permettant de décoder un ensemble de symboles, dit ensemble de symboles à décoder, extraits d'un contenu de données, plusieurs blocs de données représentatifs dudit ensemble de symboles à décoder étant reçus par ledit noeud récepteur, dans le cadre de la diffusion, au sein d'un réseau de communication comprenant une pluralité de noeuds, du contenu de données par un noeud émetteur vers au moins ledit noeud récepteur, lesdits blocs de données étant codés au moyen d'un code correcteur d'erreur permettant un décodage par effacement, caractérisé en ce qu'il comprend : - des premiers moyens de sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) par les premiers moyens de sélection étant associé(s) à un premier niveau de priorité ; - des premiers moyens de détermination d'effacements, dits premiers moyens d'effacements, à partir du ou des bloc(s) de données sélectionné(s) par lesdits premiers moyens de sélection ; - des moyens de vérification si les premiers effacements sont en nombre inférieur à un seuil donné, le seuil donné étant fonction du code correcteur 20 d'erreur ; - des premiers moyens de décodage par effacement dudit ensemble de symboles à décoder, à partir des premiers effacements, lesdits premiers moyens de décodage étant activés si lesdits premiers effacements sont en nombre inférieur audit seuil donné ; 25 - des seconds moyens de sélection d'au moins un desdits blocs de données, le ou les bloc(s) sélectionné(s) par les seconds moyens de sélection étant associé(s) à un second niveau de priorité ; - des seconds moyens de détermination d'effacements, dits seconds effacements, à partir des blocs de données sélectionné(s) par les premiers 30 et seconds moyens de sélection ; et - des seconds moyens de décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements ;lesdits seconds moyens de sélection, lesdits seconds moyens de détermination d'effacements, et lesdits seconds moyens de détermination d'effacements étant activés si lesdits premiers effacements ne sont pas en nombre inférieur audit seuil donné.
16. Noeud récepteur selon la revendication 15, caractérisé en ce qu'il comprend des moyens d'obtention d'une information, dite information de déclenchement, indiquant que les blocs de données représentatifs de l'ensemble de symboles à décoder ont tous été transmis dans le réseau de communication, lesdits seconds moyens de détermination d'effacements étant activés par ladite information de déclenchement.
17. Noeud récepteur selon la revendication 16, caractérisé en ce que l'information de déclenchement est obtenue à partir d'une information représentative d'une séquence de transmission dans le réseau de communication de blocs de données lors d'un cycle de cadencement du réseau de communication, chacun desdits blocs de données étant représentatif d'un ensemble de symboles extraits d'un contenu de données diffusé dans le réseau de communication.
18. Noeud récepteur selon la revendication 17, caractérisé en ce que la séquence de transmission définit, pour chaque ensemble de symboles extraits d'un contenu, au moins quatre blocs de données représentatifs dudit ensemble de symboles extraits d'un contenu.
19. Noeud récepteur selon la revendication 18, caractérisé en ce qu'il comprend : des moyens d'association des trois premiers, dans la séquence de transmission, blocs de données représentatifs d'un ensemble de symboles extraits d'un contenu au premier niveau de priorité ; - des moyens d'association de tous les blocs de données représentatifs d'un ensemble de symboles extraits d'un contenu au second niveau de priorité.
20. Noeud récepteur selon l'une quelconque des revendications 17 à 19, caractérisé en ce qu'il comprend des moyens de détermination de la séquence de transmission des blocs de données en fonction d'une topologie du réseau de communication.
21. Noeud récepteur selon l'une quelconque des revendications 15 à 20, caractérisé en ce, chaque bloc de données étant composé d'une pluralité de symboles de taille identique déterminée, lesdits premiers moyens de détermination des effacements comprennent des moyens de comparaison des données des symboles de blocs de données deux à deux, les symboles comparés ayant une position identique dans chacun desdits blocs de données.
22. Noeud récepteur selon l'une quelconque des revendications 15 à 21, caractérisé en ce que le code correcteur d'erreur est un code de type Reed Solomon ayant un nombre de symboles de parité, et en ce que le seuil donné est égal au nombre de symboles de parité dudit code correcteur d'erreur.
23. Noeud récepteur selon l'une quelconque des revendications 15 à 22, caractérisé en que, un noeud, dit noeud relais, parmi la pluralité de noeuds du réseau de communication, étant en charge de retransmettre au moins un bloc de données reçu et représentatif de l'ensemble de symboles à décoder, le noeud récepteur comprend : - des moyens de détection d'au moins un bloc de données de bourrage, ledit bloc de données de bourrage étant transmis par le noeud relais dans le réseau à la place d'au moins un desdits bloc de données manquant, un bloc de données étant manquant s'il n'a pas été reçu par le noeud relais ; - des moyens d'exclusion dudit bloc de données de bourrage afin qu'il ne soit pas utilisé par lesdits premier et second moyens de sélection.
24. Noeud récepteur selon l'une quelconque des revendications 15 à 23, caractérisé en ce qu'il comprend: - des moyens de détection d'au moins un événement prédéterminé, - des moyens d'interruption desdits seconds moyens de décodage par effacement dudit ensemble de symboles à décoder à partir des seconds effacements, lesdits moyens d'interruption étant activés par la détection d'au moins un événement prédéterminé.
25. Noeud récepteur selon la revendication 24, caractérisé en ce qu'il comprend 30 des moyens d'accès au réseau selon un ordonnancement prédéterminé lors d'un cycle de cadencement du réseau de communication;et en ce que l'évènement prédéterminé est une fin de cycle de cadencement du réseau de communication.
26. Noeud récepteur selon la revendication 25, caractérisé en ce que l'ensemble de symboles à décoder correspond à une agrégation d'échantillons générés par une 5 application, génératrice du contenu, pendant un cycle de cadencement du réseau.
FR0756816A 2007-07-30 2007-07-30 Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants Withdrawn FR2919773A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR0756816A FR2919773A1 (fr) 2007-07-30 2007-07-30 Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants
US12/180,632 US8176392B2 (en) 2007-07-30 2008-07-28 Method of decoding content data blocks, corresponding computer program product and decoding device
EP08161298.8A EP2020763B1 (fr) 2007-07-30 2008-07-28 Procédé de décodage de blocs de données de contenu, produit de programme informatique correspondant et dispositif de décodage
US13/443,824 US8397137B2 (en) 2007-07-30 2012-04-10 Method of decoding content data blocks, corresponding computer program product and decoding device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0756816A FR2919773A1 (fr) 2007-07-30 2007-07-30 Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants

Publications (1)

Publication Number Publication Date
FR2919773A1 true FR2919773A1 (fr) 2009-02-06

Family

ID=39345475

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0756816A Withdrawn FR2919773A1 (fr) 2007-07-30 2007-07-30 Procede de decodage de blocs de donnees de contenus, produit programme d'ordinateur, moyen de stockage et dispositif de decodage correspondants

Country Status (3)

Country Link
US (2) US8176392B2 (fr)
EP (1) EP2020763B1 (fr)
FR (1) FR2919773A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7916665B2 (en) * 2008-03-18 2011-03-29 Canon Kabushiki Kaisha Method and device for building of a network coding scheme for data transmission, corresponding computer program product and storage means
FR2942579B1 (fr) * 2009-02-23 2017-11-17 Canon Kk Procedes de transmission et reception de copies d'un paquet vers un noeud destination pour decodage par erreur/ effacement, produit programme d'ordinateur, moyen de stockage et noeuds correspondants.
EP2285112A1 (fr) * 2009-08-07 2011-02-16 Canon Kabushiki Kaisha Procédé pour l'envoi de données compressées représentant une image numérique et dispositif correspondant
US8751832B2 (en) * 2013-09-27 2014-06-10 James A Cashin Secure system and method for audio processing

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993006671A1 (fr) * 1991-09-20 1993-04-01 Motorola, Inc. Correction d'erreurs etendue d'un message de donnees emis
WO1993018589A1 (fr) * 1992-03-13 1993-09-16 Digital Equipment Corporation Recuperation de donnees apres une defaillance de correction d'erreur
US5715262A (en) * 1995-07-12 1998-02-03 Lsi Logic Corporation Errors and erasures correcting reed-solomon decoder
WO2000076272A1 (fr) * 1998-12-03 2000-12-14 Audiologic, Incorporated Systeme numerique de haut-parleurs sans fil
US20060153155A1 (en) * 2004-12-22 2006-07-13 Phillip Jacobsen Multi-channel digital wireless audio system
US20070030986A1 (en) * 2005-08-04 2007-02-08 Mcarthur Kelly M System and methods for aligning capture and playback clocks in a wireless digital audio distribution system

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5365525A (en) * 1992-11-27 1994-11-15 Motorola, Inc. Method for reducing bandwidth of a wireline communication path
US5696774A (en) * 1994-12-01 1997-12-09 Mitsubishi Denki Kabushiki Kaisha Digital signal recording device, digital signal playback device, and digital signal decoding device therefor
FR2805102A1 (fr) 2000-02-16 2001-08-17 Canon Kk Procedes et dispositifs d'emission et de reception d'information, et systemes les mettant en oeuvre
FR2807237A1 (fr) 2000-04-04 2001-10-05 Canon Kk Procede et dispositif d'evaluation du bruit associe aux turbocodes, et systemes les mettant en oeuvre
US6877125B2 (en) 2000-09-18 2005-04-05 Canon Kabushiki Kaisha Devices and methods for estimating a series of symbols
EP1293978A1 (fr) * 2001-09-10 2003-03-19 STMicroelectronics S.r.l. Procédé et dispositif pour codage et décodage, par exemple pour lecteurs de disques
US7003712B2 (en) * 2001-11-29 2006-02-21 Emin Martinian Apparatus and method for adaptive, multimode decoding
FR2849514A1 (fr) 2002-12-26 2004-07-02 Canon Kk Code de geometrie algebrique adapte aux erreurs en rafale
US7336695B1 (en) * 2003-03-10 2008-02-26 Hendershot James R m-ary variable shift keying communications system
FR2858141A1 (fr) 2003-07-21 2005-01-28 Canon Kk Codage d'informations par codes de reed-solomon raccourcis
FR2860360B1 (fr) 2003-09-29 2005-12-09 Canon Kk Dispositif de codage /decodage utilisant un codeur/decodeur de reed-solomon
FR2863794B1 (fr) 2003-12-16 2006-03-03 Canon Kk Procedes et dispositifs de localisation d'erreurs pour les codes de geometrie algebrique
FR2865083B1 (fr) 2004-01-13 2006-04-07 Canon Kk Decodage pour code de geometrie algebrique associe a un produit fibre.
FR2866998B1 (fr) 2004-02-27 2006-05-19 Canon Kk Decodage et correction d'erreurs pour codes de geometrie algebrique
FR2867925B1 (fr) 2004-03-22 2006-05-19 Canon Kk Codage de canal adapte aux erreurs rafale
FR2873518B1 (fr) 2004-07-22 2008-12-19 Canon Kk Procede de codage et de decodage d'une sequence de mots, signal, codeur, decodeur, programmes d'ordinateur et moyens de stockage correspondants
FR2873532B1 (fr) 2004-07-22 2006-09-22 Canon Kk Procede de codage et de decodage d'une sequence d'elements, signal, codeur, decodeur, programmes d'ordinateur et moyens de stockage correspondants
FR2880218B1 (fr) 2004-12-23 2007-02-16 Canon Kk Procede de decodage pour codes de geometrie algebrique et dispositif associe
US20090106624A1 (en) * 2005-09-01 2009-04-23 Hiroaki Kondo Error correction method
FR2922699A1 (fr) 2007-10-18 2009-04-24 Canon Kk Decodage iteratif dans un reseau maille, procede et systeme correspondants

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1993006671A1 (fr) * 1991-09-20 1993-04-01 Motorola, Inc. Correction d'erreurs etendue d'un message de donnees emis
WO1993018589A1 (fr) * 1992-03-13 1993-09-16 Digital Equipment Corporation Recuperation de donnees apres une defaillance de correction d'erreur
US5715262A (en) * 1995-07-12 1998-02-03 Lsi Logic Corporation Errors and erasures correcting reed-solomon decoder
WO2000076272A1 (fr) * 1998-12-03 2000-12-14 Audiologic, Incorporated Systeme numerique de haut-parleurs sans fil
US20060153155A1 (en) * 2004-12-22 2006-07-13 Phillip Jacobsen Multi-channel digital wireless audio system
US20070030986A1 (en) * 2005-08-04 2007-02-08 Mcarthur Kelly M System and methods for aligning capture and playback clocks in a wireless digital audio distribution system

Also Published As

Publication number Publication date
US20120260143A1 (en) 2012-10-11
US8176392B2 (en) 2012-05-08
EP2020763B1 (fr) 2014-03-05
EP2020763A1 (fr) 2009-02-04
US8397137B2 (en) 2013-03-12
US20090037789A1 (en) 2009-02-05

Similar Documents

Publication Publication Date Title
FR2929063A1 (fr) Procede et dispositif d&#39;allocation de chemins de transmission de donnees dans un reseau de communication synchrone, produit programme d&#39;ordinateur et moyen de stockage correspondants
EP3756295B1 (fr) Procédé et système omamrc de transmission avec adaptation lente de lien sous contrainte d&#39;un bler
FR2905209A1 (fr) Procede et dispositif de decodage de blocs encodes avec un code ldpc
EP3639427B1 (fr) Procédé et système omamrc de transmission avec adaptation lente de lien
EP3476071B1 (fr) Transmission dynamique et selectif d&#39;un signal numerique pour un systeme avec relais full-duplex et une voie de retour limitee
EP3387773A1 (fr) Procede, dispositif de relayage et destinataire avec retour dans un systeme omamrc
FR2919773A1 (fr) Procede de decodage de blocs de donnees de contenus, produit programme d&#39;ordinateur, moyen de stockage et dispositif de decodage correspondants
WO2021229183A1 (fr) Procédé et système omamrc de transmission avec variation du nombre d&#39;utilisations du canal
FR2948246A1 (fr) Procede et dispositif d&#39;allocation de bande passante liberee dans un reseau de communication, produit programme d&#39;ordinateur et moyen de stockage correspondants
FR2935493A1 (fr) Procede et dispositif de suivi d&#39;antenne.
FR2918832A1 (fr) Procedes de transmission de donnees par des noeuds relais dans un reseau de communication synchrone, procede de reception, produit programme d&#39;ordinateur, moyen de stockage et noeuds correspondants.
EP4173167A1 (fr) Procédé et système omamrc avec transmission fdm
CN105007142B (zh) 确认从通信设备成功接收的消息的方法和通信设备
FR2921777A1 (fr) Procede d&#39;acquittement hierarchique de donnees, produit programme d&#39;ordinateur, moyen de stockage et noeud correspondants.
EP2436134A2 (fr) Procédé de transmission de données depuis une infrastructure d&#39;un réseau de radiocommunication vers des équipements utilisateur, et équipements pour la mise en uvre du procédé
WO2024002886A1 (fr) Procédé de transmission et système omamrc avec une stratégie de sélection lors de retransmissions tenant compte du débit des sources et d&#39;un ou plusieurs échanges de contrôle
FR2922390A1 (fr) Procede de modification d&#39;un paquet code, procede de transmission, procede de reception, produit programme d&#39;ordinateur, dispositif de modification, noeud intermediaire et noeud destinataire correspondants
WO2024002899A1 (fr) Procédé de transmission et système omamrc avec une stratégie de sélection lors de retransmissions tenant compte du débit des sources et d&#39;un unique échange de contrôle
FR2943195A1 (fr) Procede de transmission de donnees avec mecanismes de retransmission et synchronisation en cas de perte, dispositif emetteur, produit programme d&#39;ordinateur et moyen de stockage correspondants
WO2024133311A1 (fr) Procédé de communication et système omamrc avec une sélection lors de retransmissions tenant compte du débit des sources et d&#39;un unique échange de csi
FR2926426A1 (fr) Procede de transmission de donnees par un noeud emetteur dans un cycle de transmission de donnees d&#39;un reseau de communication synchrone, produit programme d&#39;ordinateur, moyen de stockage et noeud emetteur.
FR2935580A1 (fr) Procedes de reintroduction d&#39;un noeud dans un reseau de communication, produit programme d&#39;ordinateur, moyen de stockage et noeuds correspondants.
WO2024079309A1 (fr) Procédé de retransmission coopérative dans un système omamrc avec allocation de ressources et sélections des sources à aider conjointes
FR2934736A1 (fr) Procede et dispositif de transmission dans un reseau maille a codage reseau, procede et dispositif de reception, signal, produits programme d&#39;ordinateur et moyens de stockage correspondants
FR2954659A1 (fr) Procede de determination d&#39;une sequence de nœuds, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20090331