FR2942685A1

FR2942685A1 - Procede de gestion d'acces a un reseau de communication pendant un intervalle de temps partage, produit programme d'ordinateur, moyen de stockage et noeud decisionnaire correspondants.

Info

Publication number: FR2942685A1
Application number: FR0951274A
Authority: FR
Inventors: Pierre Visa; Herve Merlet
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2009-02-27
Filing date: 2009-02-27
Publication date: 2010-09-03
Anticipated expiration: 2029-02-27
Also published as: FR2942685B1

Abstract

Il est proposé un procédé permettant de contrôler l'accès à un intervalle de temps partagé par plusieurs noeuds d'un réseau de communication, de manière à ce qu'un seul et unique noeud accède à cet intervalle de temps. Plus précisément, ce procédé consiste à utiliser des noeuds possédant un intervalle de temps réservé pour relayer au moins une requête d'accès émise par un noeud requérrant. Ainsi, ce procédé permet de contrôler l'accès à un intervalle de temps partagé par plusieurs noeuds d'un réseau de communication, de manière à ce qu'un seul et unique noeud accède à cet intervalle de temps dans chaque cycle réseau.

Description

Procédé de gestion d'accès à un réseau de communication pendant un intervalle de temps partagé, produit programme d'ordinateur, moyen de stockage et noeud décisionnaire correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communications. Plus précisément, l'invention concerne un procédé permettant de contrôler l'accès à un intervalle de temps partagé et ce tout en évitant les cas de collision dans lesquels au moins deux noeuds émettent simultanément dans le même intervalle de temps partagé, notamment lorsqu'il existe des masquages. 2. ARRIÈRE-PLAN TECHNOLOGIQUE 2.1 Contexte et problème On s'attache plus particulièrement dans la suite de ce document à décrire la problématique existant dans le contexte d'un système de diffusion d'un contenu audiovisuel à canaux multiples, à laquelle ont été confrontés les inventeurs de la présente demande de brevet. Les systèmes de transmissions de données sans fil sont aujourd'hui de plus en plus nombreux. Ils répondent au besoin croissant des utilisateurs pour des systèmes assurant un très haut débit de transmission tout en offrant haute qualité de service et facilité d'utilisation.

Grâce à une largeur de bande étendue, les systèmes de transmission radio à 60GHz sont particulièrement bien adaptés pour une transmission de données très hauts débits. Une des caractéristiques physiques de la bande millimétrique est le fort taux d'atténuation conjugué au faible taux de réflexion sur les obstacles que l'on peut rencontrer dans un environnement domestique. Ces propriétés rendent cette technologie radio bien adaptée pour le déploiement d'un réseau local sans fil de type PAN (pour Personal Area Network en anglais) dans un rayon d'opération limité. Un PAN sans fil 60GHz sera donc un moyen privilégié pour assurer, par exemple, la connectivité entre les différents éléments d'un home cinema ou d'un système de visioconférence. Ce type d'application requiert 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 (ou surround sound system en anglais), comprenant par exemple jusqu'à 8 hauts parleurs. En effet dans ce cas précis, un émetteur (comprenant aussi un décodeur audio) va transmettre de manière parfaitement synchrone différents canaux audio issus d'une seule source à un sous 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. De plus, dans le cas d'un système home cinema avec un écran plat fixé au mur, il est avantageux pour l'utilisateur de pouvoir connecter sans fil l'écran à la source vidéo. Pour assurer la synchronisation des applications, il est avantageux de s'appuyer sur un système synchrone qui garantie une latence fixe de transmission. C'est pourquoi le mode d'accès au medium préféré est de type TDMA (pour Time Division Multiple Access en anglais), avec un intervalle de temps cyclique et prédéfini pour chaque noeud émetteur du réseau. Le cycle TDMA est appelé super-trame ou encore SDTC (pour Synchronous Data Transmission Cycle en anglais). Un cycle SDTC est divisé en un nombre prédéfini d'intervalles de temps et chaque intervalle correspond à un intervalle de temps réservé à un unique noeud du réseau. L'affectation d'un intervalle de temps à un noeud du réseau dépend de son rôle par rapport aux applications ainsi que de l'environnement extérieur. Si le noeud est connecté à une source audio, il n'aura sans doute besoin que d'un seul intervalle de temps, mais un noeud connecté à une source vidéo en aura besoin de plusieurs. A l'inverse, un noeud uniquement connecté à une enceinte n'aura besoin de transmettre que des données de contrôle, par exemple un message d'acquittement suite à la réception d'une commande pour augmenter le volume du son. Ce type de noeud aura besoin d'un intervalle de temps mais il sera faiblement utilisé. Enfin, certains noeuds auront besoin d'un ou de plusieurs intervalle de temps car ils auront un rôle de répéteur. En effet, afin de pallier aux éventuels masquages, ponctuels ou permanents, dus aux obstacles entre les noeuds du réseau, il est nécessaire de faire répéter les données plusieurs fois par différents noeuds. Ce jeu de répétitions créé un réseau maillé (ou mesh network en anglais), qui permet d'éviter la perte de données. La contrepartie de cette technique est d'augmenter la latence du réseau car plusieurs cycles SDTC seront en général nécessaires pour effectuer toutes les répétitions, mais un inconvénient majeur est aussi de diminuer la bande passante utile disponible.

On se rend compte qu'il est nécessaire d'avoir une répartition et une utilisation de façon judicieuse des intervalles de temps affectés aux noeuds du réseau. Il faut s'assurer que chaque noeud reçoit au moins une fois les données émises par les autres noeuds tout en garantissant une bande passante suffisante pour les applications. Cette étape d'allocation (ou d'affectation) des intervalles de temps s'effectue, par exemple à l'initialisation du système, après que chaque chemin de transmission radio ait été testé, et que chaque noeud ait indiqué ses besoins en bande passante. Cet ensemble, constitué d'au moins un intervalle de temps, est appelé PTS (ou Predefined Time Slot(s) en anglais).

Plutôt que de réserver au moins un intervalle de temps à tous les noeuds du réseau, il apparaît intéressant de ne le faire que pour les noeuds ayant un rôle stratégique : les noeuds connectés à une source de données et les noeuds utilisés comme répéteurs. Pour les autres noeuds du réseau n'ayant pas de données synchrones et peu de données asynchrones à transmettre, il n'est pas optimal de leur allouer un intervalle de temps prédéfini à chaque cycle SDTC. Pour gagner en bande passante, il est alors réservé pour tous ces noeuds un nombre limité, voire un seul, intervalle de temps avec accès partagé, formant un ensemble dit STS (pour Shared Time Slot(s) en anglais). L'arbitrage pour l'accès à l'intervalle de temps partagé STS se fait au moyen d'un (court) intervalle de temps de collision, encore appelé CTS (pour Collision Time Slot en anglais). Le mode préféré de mise en oeuvre consiste à diviser la super-trame en trois phases : une phase PTS supportant le transport de données synchrones, une phase STS ne supportant que le transport de données asynchrones qui est partagée entre les noeuds du réseau (et pourrait être limité par exemple aux noeuds ne disposant pas d'intervalle de temps pour émettre leurs données dans la phase PTS), et une phase CTS qui comprend un intervalle de temps pour envoyer des requêtes d'accès à un intervalle de temps de la phase STS. La technique d'arbitrage par intervalle de temps de collision CTS est largement utilisée dans les réseaux sans fil. Chaque noeud voulant utiliser un prochain intervalle de temps avec accès partagé STS émet une requête pendant l'intervalle de temps de collision CTS correspondant. La requête contenant l'identifiant du noeud et un indicateur de priorité, un seul noeud sera finalement autorisé à émettre dans l'intervalle de temps partagé. Si plusieurs noeuds émettent leur requête au même moment, il y a collision entre les requêtes d'accès et les signaux radio sont inexploitables. Pour diminuer la probabilité de collision, les noeuds commencent à émettre chacun au bout d'un temps pris aléatoirement. Cependant cela ne suffit pas à éviter tous les cas de collision. En effet, une requête peut être complètement bruitée car une ou plusieurs autres requêtes d'accès sont émises simultanément. Par ailleurs deux noeuds qui émettent leur requête de façon bien distincte, mais qui sont trop éloignés l'un de l'autre ou masqués l'un par rapport à l'autre, n'auront pas détecté d'autre requête que celle que chacun aura lui-même émis. Dans tous les cas, il y a toujours une incertitude quant à la décision d'utiliser l'intervalle de temps partagé, et donc il y a toujours risque de collision dans l'intervalle de temps partagé. 2.2 Limites de l'état de la technique Pour réduire ce risque de collisions, de nombreux protocoles ont été décrits comme le protocole CSMA/CA (pour Carrier Sense Multiple Access with Collision Avoidance en anglais) utilisé par la norme IEEE 802.11. Le protocole CSMA/CA utilise un mécanisme d'évitement de collision basé sur un principe d'accusé de réception réciproque entre l'émetteur et le récepteur. En premier lieu, le noeud voulant émettre écoute le réseau. Si le réseau est encombré, la transmission est différée. Dans le cas contraire, si le médium est libre pendant un temps donné appelé DIFS (pour Distributed Inter Frame Space en anglais), alors le noeud peut émettre. Il transmet d'abord un message appelé RTS (pour Ready To Send ou Request To Send en anglais) signifiant prêt à émettre , contenant des informations sur le volume des données qu'il souhaite émettre ainsi que la vitesse de transmission enivsagée. Le récepteur, généralement un point d'accès, répond par un message appelé CTS (pour Clear To Send en anglais) signifiant que le medium est libre, puis le noeud commence l'émission des données. Après réception de toutes les données, le récepteur envoie un accusé de réception ACK (pour acknowledge en anglais). Après détection d'un message RTS ou d'un message CTS, tous les noeuds du réseau autres que l'émetteur du message patientent alors pendant le temps qu'ils considèrent être celui nécessaire à la transmission du volume d'information à émettre à la vitesse annoncée. Cette technique reste néanmoins inefficace pour garantir qu'aucune collision ne se produise dans l'intervalle de temps partagé. En effet si un noeud A émet une requête pour un noeud B et qu'un noeud C émet une requête pour un noeud D alors que le couple (A, B) est temporairement masqué du couple (C, D), alors A et C vont tenter d'utiliser simultanément l'intervalle de temps partagé. Si le masquage entre (A, B) et (C, D) est maintenu, cela ne pose pas de problème, mais si le masquage disparaît (par exemple une personne se déplaçait dans cette zone géographique), alors les données transmises pendant l'intervalle de temps partagé seront inexploitables. Une amélioration de ce protocole appelé FPRP (pour Five-Phase Reservation Protocol en anglais) est proposée par C. Zhu et M. S. Corson ("A Five-Phase Reservation Protocol (FPRP) for Mobile Ad Hoc Networks," Proc. IEEE INFOCOM '98). Le protocole décrit un mécanisme de réservation d'un intervalle de temps dans un système de transmission TDMA avec une faible probabilité de collision. La réservation d'un intervalle de temps est propagée jusqu'aux noeuds situés à deux sauts (ou hop en anglais) du noeud émetteur de la réservation. Deux noeuds séparés par un saut signifie qu'il faut introduire un noeud intermédiaire relais pour que ces deux noeuds puissent communiquer entre eux. Avec ce protocole, l'intervalle de temps de collision CTS est divisé en cinq phases, et chaque phase correspond à l'émission d'un message protocolaire. Cependant, cette technique possède l'inconvénient d'allonger de façon importante la durée de l'intervalle de temps de collision CTS, ce qui diminue d'autant la bande passante utile disponible.

Une autre méthode d'arbitrage est présentée dans un document de brevet US 6,594,247. Un noeud spécifique, dit noeud maître, est chargé de détecter les collisions éventuelles pendant l'intervalle de temps de collision CTS. Si une collision intervient, le maître le signale en demandant à certains noeuds du réseau de communiquer les requêtes d'accès qu'ils ont vu pendant l'intervalle de temps de collision CTS. Le noeud maître détermine alors le noeud vainqueur de la compétition et lui donne l'autorisation d'émettre.

Cependant, cette technique n'est pas fiable car elle suppose que le noeud maître est visible par tous les autres noeuds du réseau. En cas de masquage, il est possible que le noeud maître n'ait pas vu toutes les requêtes d'accès et donc ne détecte pas de collision. De plus, il est possible que la décision d'autorisation d'accès accordé à un noeud donné par le noeud maître ne soit pas reçue par l'ensemble des noeuds du réseau de communication. Au vu de l'art antérieur, il apparaît ainsi clairement un besoin pour une technique d'arbitrage qui soit à la fois simple, peu consommatrice en bande passante et fiable malgré le caractère aléatoire des masquages dans un système de communications sans fil. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier les différents inconvénients de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif de la présente invention est de fournir une technique permettant de contrôler l'accès à un intervalle de temps partagé par plusieurs noeuds d'un réseau de communications (par exemple de type TDMA), de manière à ce qu'un seul et unique noeud accède à cet intervalle de temps. La présente invention permet notamment d'éviter tous les cas de collision dans lesquels au moins deux noeuds émettent simultanément dans le même intervalle de temps partagé. Un tel résultat doit être obtenu quel que soit l'état des chemins de communications du réseau. En particulier dans le cas d'un réseau sans fil, la présente invention permet de s'affranchir des phénomènes de masquages, permanents ou temporaires, qui empêchent la communication directe entre des noeuds du réseau.

Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant l'optimisation de l'usage de la bande passante disponible sur le medium. En effet dans un système de type TDMA par exemple, lorsqu'un intervalle de temps est réservé à un noeud, il ne pourra en aucun cas être utilisé par un autre noeud du réseau même si cet intervalle de temps est faiblement utilisé. Il est donc intéressant de pouvoir limiter le nombre de noeuds avec intervalle de temps réservé, et de réserver aux autres noeuds un intervalle de temps avec accès partagé. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion d'accès à un réseau de communication pendant un intervalle de temps partagé, un intervalle de temps de collision permettant d'émettre une requête d'accès à l'intervalle de temps partagé, un ensemble prédéterminé d'au moins un noeud disposant chacun d'au moins un intervalle de temps pré-affecté pour accéder audit réseau, Ce procédé est remarquable en ce qu'un noeud décisionnaire effectue des étapes consistant à : - recevoir, pendant l'ensemble d'intervalle de temps pré-affecté, une information indiquant, pour chaque noeud dudit ensemble prédéterminé, si ledit noeud a ou non détecté au moins une requête d'accès à l'intervalle de temps partagé; - déterminer, parmi la ou les requêtes dont une indication de réception positive a été reçue, une requête d'accès prioritaire en fonction d'au moins un critère de sélection prédéterminé ; et en ce que l'accès audit intervalle de temps partagé étant autorisé au noeud ayant émis ladite requête d'accès prioritaire pendant l'intervalle de temps de collision. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive d'un procédé consistant à utiliser des noeuds possédant un intervalle de temps pré-affecté pour détecter si au moins une requête d'accès à l'intervalle de temps partagé a été émise par un noeud requérrant. Ainsi, ce procédé permet de contrôler l'accès à un intervalle de temps partagé par plusieurs noeuds d'un réseau de communication, de manière à ce qu'un seul et unique noeud accède à cet intervalle de temps dans chaque cycle réseau. La présente invention permet, notamment d'éviter des cas de collision dans lesquels au moins deux noeuds accèdent simultanément au réseau pendant un même intervalle de temps partagé. En particulier dans le cas d'un réseau sans fil, la présente invention permet de s'affranchir des phénomènes de masquages, permanents ou temporaires, qui empêchent la communication directe entre des noeuds du réseau, au moment de l'émission des requêtes d'accès (c'est-à-dire pendant l'intervalle de collision). Egalement, la bande passante disponible est optimisée. En effet dans un système réseau (de type TDMA par exemple), lorsqu'un intervalle de temps est pré-affecté à un noeud, il ne pourra en aucun cas être utilisé par un autre noeud du réseau même si cet intervalle de temps est faiblement utilisé. Il est donc intéressant de pouvoir limiter le nombre de noeuds avec intervalle de temps pré-affecté, et de réserver aux autres noeuds un intervalle de temps avec accès partagé. Avantageusement, chaque noeud dudit ensemble prédéterminé relaie chaque requête d'accès à l'intervalle de temps partagé que ledit noeud a détecté pendant ledit intervalle de temps de collision. Ainsi, on optimise la probabilité que le noeud décisionnaire reçoive ladite au moins une requête d'accès puisqu'une indication de la ou les requêtes peut être reçue soit de manière classique en utilisant l'intervalle de collision, soit selon l'invention en utilisant au moins un intervalle de temps pré-affecté d'au moins un noeud dudit ensemble prédéterminé. De manière avantageuse, si le réseau ne comprend qu'un unique dit noeud décisionnaire, ladite étape consistant à déterminer la requête d'accès prioritaire est effectuée aussi parmi des requêtes d'accès reçues pendant l'intervalle de temps de collision par ledit noeud décisionnaire. Ainsi, le noeud décisionnaire prend une décision concernant l'accès à l'intervalle de temps partagé suivant une liste de requêtes qu'il a lui-même détectées pendant l'intervalle de collision, liste qu'il peut modifier en fonction des indications de détection de requêtes reçues des noeuds dudit ensemble prédéterminée. Ainsi, on augmente la fiabilité du processus de décision. Le noeud décisionnaire pouvant prendre une décision intermédiaire à partir des requêtes qu'il a détectées pendant l'intervalle de collision, le processus de prise de décision s'en trouve accéléré. De façon avantageuse, lorsqu'un noeud dudit ensemble prédéterminé détecte plusieurs requêtes d'accès à l'intervalle de temps partagé émises pendant ledit intervalle de temps de collision, ledit noeud dudit ensemble prédéterminé effectue une étape consistant à classifier, dans une liste, lesdites requêtes d'accès détectées en fonction dudit critère de sélection prédéterminé, et en ce que qu'il transmet pendant son intervalle de temps pré-affecté une information relative à une requête prioritaire, parmi lesdites requêtes d'accès détectées, selon le critère de sélection prédéterminé.

Ainsi, on accélère le processus de prise de décision et on diminue la consommation de bande passante relative à la transmission des indications de requêtes détectées pendant l'intervalle de collision. Une forme de réalisation particulière selon l'invention prévoit que chaque noeud dudit ensemble prédéterminé relaie, pendant son intervalle de temps pré-affecté, des informations d'indication de réception de requête d'accès à l'intervalle de temps partagé détectée par au moins un autre noeud dudit ensemble prédéterminé pendant l'intervalle de temps de collision. Ainsi, on renforce l'assurance que les indications de requêtes soient reçues par le noeud décisionnaire, lorsqu'au moins un noeud dudit ensemble prédéterminé est masqué du noeud décisionnaire. De façon avantageuse, un noeud requérant étant un noeud émettant un requête d'accès à l'intervalle de temps partagé, si chaque noeud requérant est un dit noeud décisionnaire, ledit noeud décisionnaire effectue des étapes consistant à : - émettre une requête d'accès, pendant ledit intervalle de temps de collision ; - émettre des données sur ledit réseau pendant ledit intervalle de temps partagé, si ladite requête d'accès prioritaire est identique à la requête d'accès transmise par ledit noeud requérant donné. Ainsi, dans cette première forme de réalisation, la présente invention peut être mise en oeuvre de manière distribuée dans les noeuds requérants.

Selon une caractéristique intéressante d'un mode de réalisation particulier de l'invention, si ledit noeud décisionnaire n'est pas un noeud requérant, ledit noeud décisionnaire effectue une étape consistant à émettre, à destination du noeud requérant ayant préalablement émis ladite requête d'accès prioritaire, une information autorisant ledit noeud requérant à accéder audit réseau pendant ledit intervalle de temps partagé.

Ainsi, dans cette seconde forme de réalisation, la présente invention peut être mise en oeuvre de manière centralisée dans un noeud autre qu'un noeud requérant. Selon une autre caractéristique intéressante d'un mode de réalisation particulier de l'invention, le nombre de cycles de transmission séparant un cycle de transmission dans lequel à été émise une requête d'accès et un cycle de transmission dans lequel se trouve l'intervalle de temps partagé associé à la requête, est fixe et prédéterminé. Ainsi, il est possible de mettre en place des mécanismes de répétition, par un premier noeud, de données préalablement émises par un second noeud. Un compromis doit être trouvé entre latence depuis requête jusqu'à accès audit intervalle de temps partagé et garantie de prise en compte par le noeud décisionnaire de l'ensemble des requêtes (ce qui limite en outre les collisions pendant l'intervalle de temps partagé liées à une prise de décision divergente dans un environnement distribué, comme mentionné ci-dessus). Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur. Ce produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur.

Dans un autre mode de réalisation, l'invention concerne un moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation).

Dans un autre mode de réalisation, l'invention concerne un noeud décisionnaire pour la gestion d'accès d'au moins un noeud à un réseau de communication pendant un intervalle de temps partagé, un intervalle de temps de collision permettant d'émettre une requête d'accès à l'intervalle de temps partagé, un ensemble prédéterminé d'au moins un noeud disposant chacun d'au moins un intervalle de temps pré-affecté pour accéder audit réseau. Ce noeud décisionnaire est remarquable en ce qu'il comprend : - des moyens de réception, pendant l'ensemble d'intervalle de temps pré-affecté, une information indiquant, pour chaque noeud dudit ensemble prédéterminé, si ledit noeud a ou non détecté au moins une requête d'accès à l'intervalle de temps partagé ; - des moyens de détermination, parmi la ou les requêtes dont une indication de réception positive a été reçue, une requête d'accès prioritaire en fonction d'au moins un critère de sélection prédéterminé ; - des moyens d'autoriser l'accès audit intervalle de temps partagé pour le noeud ayant émis ladite requête d'accès prioritaire pendant l'intervalle de temps de collision. Avantageusement, chaque noeud dudit ensemble prédéterminé comprend des moyens de relais de chaque requête d'accès à l'intervalle de temps partagé transmise pendant ledit intervalle de temps de collision. Selon une caractéristique avantageuse d'un mode de réalisation particulier de l'invention, si le réseau ne comprend qu'un unique dit noeud décisionnaire, chaque noeud décisionnaire comprend des moyens adaptés pour que la requête d'accès prioritaire soit aussi déterminée parmi les requêtes d'accès reçues pendant l'intervalle de temps de collision.

Avantageusement, chaque noeud dudit ensemble prédéterminé comprend des moyens de détection d'informations d'indication de réception de requête d'accès à l'intervalle de temps partagé détectée par un noeud dudit ensemble prédéterminé pendant l'intervalle de temps de collision et relayées par un autre noeud dudit ensemble prédéterminé pendant son intervalle de temps pré-affecté. Avantageusement, un noeud requérant étant un noeud émettant une requête d'accès à l'intervalle de temps partagé, si chaque noeud requérant est un dit noeud décisionnaire, ledit noeud décisionnaire comprend en outre : - des premiers moyens d'émission d'une requête d'accès, pendant ledit intervalle de temps de collision; - des seconds moyens d'émission des données sur ledit réseau pendant ledit intervalle de temps partagé, si ladite requête d'accès prioritaire est identique à la requête d'accès transmise par ledit noeud requérant donné. En outre, si ledit noeud décisionnaire n'est pas un noeud requérant, ledit noeud décisionnaire comprend des troisièmes moyens d'émission, à destination du noeud requérant ayant préalablement émis ladite requête d'accès prioritaire, d'une information autorisant ledit noeud requérant à accéder audit réseau pendant ledit intervalle de temps partagé. 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 particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 illustre schématiquement, selon un mode de réalisation particulier de l'invention, un système de communication 60GHz constitué de 9 noeuds de communication ; - la figure 2 illustre schématiquement la structure des paquets radio découpés en blocs de données radio RDB, selon un mode de réalisation particulier de l'invention ; - la figure 3 illustre schématiquement une matrice de répartition de la bande passante synchrone initialisée au démarrage du système, selon un mode de réalisation particulier de l'invention ; - la figure 4 illustre schématiquement une architecture d'un module de communication synchrone, selon un mode de réalisation particulier de l'invention ; - - - - 6. la figure 5 illustre schématiquement les données stockées pour la mise en oeuvre de la présente invention, selon un mode de réalisation particulier de l'invention ; la figure 6 illustre schématiquement le fonctionnement d'un module de communication selon un mode de réalisation particulier de l'invention ; la figure 7 illustre schématiquement un organigramme du fonctionnement du bloc 95 d'émission de paquet radio selon un mode de réalisation particulier de l'invention ; la figure 8 illustre schématiquement un organigramme du fonctionnement du bloc 94 de réception de paquet radio selon un mode de réalisation particulier de l'invention. DESCRIPTION DÉTAILLÉE On présente en relation avec la figure 1 un système de communication 60GHz constitué de 9 noeuds de communication implémentant la présente invention selon un mode de réalisation particulier.

Prenons l'exemple d'un système de communication 60GHz constitué de 9 noeuds de communication selon l'invention, un tel système est représenté schématiquement sur la figure 1. Plus particulièrement, le système comprend 8 noeuds la, 2a, 3a, 4a, 6a, 7a, 8a, et 9a de type WAR (pour Wireless Audio Renderer en anglais ou récepteur audio sans fil en français) dont chacun est équipé de moyens de restitution de canal audio numérique (ou Digital Audio Channel Amplifier en anglais), respectivement lb, 2b, 3b, 4b, 6b, 7b, 8b, et 9b qui intègre un haut-parleur (ou speaker en anglais), et, un noeud 5a de type WAD (pour Wireless Audio Decoder en anglais ou décodeur audio sans fil en français), comprenant un décodeur audio multi voies (ou Surround sound decoder en anglais), respectivement 5b, par exemple intégré dans un écran plat et susceptible de transmettre via le système de communication 60GHz, de manière parfaitement synchronisée, les différents canaux audio associés à la vidéo affichée sur l'écran.

Chacun des noeuds la, 2a, 3a, 4a, 5a, 6a, 7a, 8a, et 9a, intègre un module de communication synchrone, SCM, (pour Synchronous Communication Module en anglais), qui intègre les différents moyens conformément à la présente invention. L'ensemble de la bande passante disponible délivrée par le système est découpé en canaux virtuels synchrones. Le débit utile est caractérisé par la fréquence de traitement des canaux virtuels, par exemple 8KHz, ainsi que par la taille des échantillons, par exemple 48 bits. Ainsi, un canal virtuel VC (pour Virtual Channel en anglais) possède un débit constant de 384 Kbps (kilobits par seconde). La séquence complète comprenant un échantillon de chacun des canaux virtuels disponibles constitue un cycle complet de traitement de données synchrone, SDPC (pour Synchronous Data Processing Cycle en anglais) dont la durée est égale à 1251Lts dans le cas d'une fréquence de traitement de 8KHz des canaux virtuels. Un canal audio de résolution 96KHz-24bits utilisera donc 6 canaux virtuels soit par exemple pour un système complet 8 voies (classiquement appelé 7.1), un total de 48 canaux virtuels, donc un débit utile nécessaire de 18,432 Mbps (mégabits par seconde) uniquement pour le transfert de l'information audio. De plus, pour le transfert d'informations supplémentaires (contrôle du système, protocole, commande utilisateur,...) des canaux virtuels sont réservés aux noeuds de transmission du système, ce qui fait qu'un cycle SDPC est ici composé de 54 canaux virtuels, soit un débit utile de 20.352 Mbps. Ainsi parmi les canaux virtuels 0 à 47 transmis par le module de communication synchrone 5 SCM#O du noeud 5a: - les canaux virtuels 0 à 5 sont décodés puis traités par le module de communication synchrone 9 SCM#1 du noeud 9a, et correspondant au haut parleur avant-central (ou Front-Center Speaker en anglais); - les canaux virtuels 6 à 11 sont décodés puis traités par le module de communication synchrone 4 SCM#2 du noeud 4a, et correspondant au haut parleur avant-gauche (pour Front-Left Speaker en anglais) ; - les canaux virtuels 12 à 17 sont décodés puis traités par le module de communication synchrone 7 SCM#3 du noeud 7a, et correspondant au haut parleur avant-droit (ou Front-Right Speaker en anglais) ; - les canaux virtuels 18 à 23 sont décodés puis traités par le module de communication synchrone 3 SCM#4 du noeud 3a, et correspondant au haut parleur latéral-gauche (ou Side-Left Speaker en anglais) ; - les canaux virtuels 24 à 29 sont décodés puis traités par le module de communication synchrone 8 SCM#5 du noeud 8a, et correspondant au haut parleur latéral-droit (ou Side-Right Speaker en anglais) ; - les canaux virtuels 30 à 35 sont décodés puis traités par le module de communication synchrone 2 SCM#6 du noeud 2a, et correspondant au haut parleur arrière-gauche (pour Rear-Left Speaker en anglais) ; - les canaux virtuels 36 à 41 sont décodés puis traités par le module de communication synchrone 1 SCM#7 du noeud la, et correspondant au haut parleur arrière-droit (ou Rear-Right Speaker en anglais) ; - les canaux virtuels 42 à 47 sont décodés puis traités par le module de communication synchrone 6 SCM#8 du noeud 6a, et correspondant au caisson de graves (ou Subwoofer en anglais). Les canaux virtuels 48 à 53 sont décodés puis traités par tous les noeuds pour l'échange de données supplémentaires de manière synchrone. Ils portent le nom de canaux virtuels de contrôle. Ainsi les noeuds impliqués dans la transmission de données synchrones ont au moins un canal virtuel de contrôle réservé pour l'émission de données supplémentaires à destination de tous les autres noeuds du système, par exemple : - pour le noeud SCM#O, les canaux virtuels 48 et 49 ; - pour le noeud SCM#2, le canal virtuel 50 ; - pour le noeud SCM#3, le canal virtuel 51 ; - pour le noeud SCM#4, le canal virtuel 52 ; - pour le noeud SCM#5, le canal virtuel 53.

Une séquence de traitement d'un conteneur de canal virtuel VC Chunk (pour Virtual Channel Chunk en anglais), constitué de l'ensemble des échantillons d'un même canal virtuel (pour Virtual Channel S amples en anglais), doit être effectuée pendant un cycle SDTC. Donc la séquence de transmission de ce même conteneur VC Chunk doit être effectuée pendant la durée du cycle SDTC suivant. En conséquence la durée d'un cycle SDTC est un multiple de la durée d'un cycle SDPC, et est ainsi appelé STPR (pour Synchronous Transmission to Processing Ratio en anglais ou rapport de cycle de transmission synchrone sur cycle de traitement synchrone en français). Ce rapport entier définit ainsi la taille de la séquence de transmission d'un canal virtuel, de manière commune quels que soient les canaux virtuels. Dans le mode de réalisation particulier de la présente invention, STPR = 8. Une séquence de transmission d'un conteneur de canal virtuel, VC Chunk, est donc constituée de 48 octets utiles (la taille des échantillons de 48 bits multipliée par le STPR. La taille totale d'un conteneur VC Chunk est néanmoins de 49 octets car, aux 48 octets utiles, il est nécessaire de rajouter un octet d'en tête indiquant la validité des données transportées dans chacun des 8 canaux virtuels. En effet, si l'application n'a pas fournie de données lors de l'écriture d'un canal virtuel, celui-ci sera écrit avec un symbole nul (par exemple 0x000000000000) et dans l'octet d'en tête du conteneur VC Chunk, le bit correspondant au VC nul prend la valeur `0'. Si un VC contient une donnée valide, son bit dans l'en tête du conteneur VC Chunk prend la valeur `1'. La figure 2 illustre schématiquement la structure des paquets radio découpés en blocs de données radio RDB. Un cycle SDTC est divisé en trois phases : - une phase PTS (pour Predefined Time Slots en anglais) assurant le transport de données synchrones avec répétition pour éviter les pertes dues aux masquages ; - une phase STS (pour Shared Time Slot en anglais) qui correspond dans le mode de réalisation particulier décrit ici à un seul intervalle de temps partagé entre les noeuds du réseau ; et - une phase CTS (pour Collision Time Slot en anglais) qui correspond à un intervalle de temps pour envoyer des requêtes d'accès à l'intervalle de temps partagé STS. Les durées sont données à titre d'exemple et ne sont pas limitatives.

Au sein d'un cycle SDTC, chaque noeud impliqué dans la transmission de données synchrones envoie au moins un paquet radio. Dans un mode préféré de réalisation de l'invention, 6 paquets radio sont émis selon une séquence prédéfinie : - les 2 premiers paquets (10, 11) d'un cycle SDTC sont émis par le noeud 5 de type WAD, SCM#O ; et - les 4 paquets suivants (12, 13, 14, 15) sont émis par des noeuds de type WAR, par exemple selon un ordre prédéfini : SCM#2, SCM#3, SCM#5, SCM#4. Les modules SCM#1, SCM#6, SCM#7, et SCM#8 n'ont pas d'intervalle de temps prédéfini. Ils doivent alors utiliser l'intervalle de temps partagé STS pour émettre un paquet radio 16. La transmission d'une requête pour la réservation d'un intervalle de temps partagé est réalisée pendant l'intervalle de temps de collision CTS 17. En ce qui concerne le traitement des données, pendant un même cycle SDTC, chaque module de communication synchrone doit traiter 8 (dans le cas où STPR = 8) cycles SDPC 1054 à 1754, ayant chacun une durée égale à 1251Lts. Pendant chaque cycle SDPC, le module de communication synchrone SCM assure le traitement des 54 échantillons des canaux virtuels et dont seuls certains sont représentés sur la figure 2. Entre autres, les échantillons 1000, 1030, 1031, 1053 seront traités pendant le cycle SDPC 1054, l'échantillon 1100, pendant le cycle SDPC 1154 et les échantillons 1700, 1730, 1753 pendant le cycle SDPC 1754. Un paquet radio est constitué d'abord d'un préambule 54, puis d'un champ en- tête 50, dit RPH (pour Radio Packet Header en anglais) et enfin d'un champ de données utiles 55, dit RPP (pour Radio Packet Payload en anglais). Le préambule 54 permet au récepteur de se synchroniser et de repérer le début du paquet.

Le champ en tête 50 inclus au moins le numéro de l'intervalle de temps dans lequel est transmis le paquet radio, et l'identifiant du noeud qui émet ce paquet. Le module SCM#O est arbitrairement désigné comme le noeud maître qui impose le cadencement des cycles SDTC. Les modules SCM des autres noeuds, dits noeuds esclaves, doivent reproduire localement un cadencement des cycles SDTC en phase avec le noeud maître. Pour ce faire, un noeud esclave utilise la détection d'un début de réception de paquet radio, ainsi que le numéro de l'intervalle de temps de l'en tête du paquet pour se situer dans le cycle SDTC. Grâce à ces informations, un noeud esclave asservi son cadencement local des cycles SDTC sur celui du maître.

Par ailleurs, le champ RPP 55 est découpé en un ensemble de blocs de données radio RDB 20 à 49 (pour Radio Data Block en anglais) d'une longueur de 58 octets après ajout d'un code correcteur d'erreur (par exemple 8 octets de redondance sont ajoutés au conteneur VC Chunk). Un bloc RDB peut contenir des données propres au noeud émetteur, ou des données à répéter issues d'autres noeuds du réseau.

Pour tous les paquets radio, le champ RPP contient 29 blocs RDB. Ainsi, dans notre exemple, et conformément au champ 112 de la matrice de répartition de la bande passante synchrone illustrée figure 3, le noeud SCM#O émet un paquet radio 11, constitué d'un champ RPP 55, qui contient notamment le bloc de données radio RDB 26, contenant 8 échantillons du VC#30 générés par ce noeud SCM#O au cours du cycle SDTC précédent et transmis pour la première fois au cours du cycle courant. Pour prendre un autre exemple, toujours dans ce même paquet radio 11, on trouve le bloc de données radio RDB 48, correspondant à la retransmission des 8 échantillons du VC#53 transmis au cours du cycle SDTC précédent par le noeud SCM#5, conformément au champ 119 de la matrice de répartition de la bande passante synchrone illustrée figure 3. La figure 3 illustre schématiquement la matrice de répartition de la bande passante synchrone initialisée au démarrage du système par le processeur CPU 87 de la figure 4 (plus amplement décrite par la suite). Cette matrice représente le contenu de chaque paquet radio transmis dans la phase PTS du cycle SDTC. Un cycle complet de transmission synchrone de données est découpé en 174 blocs de données radio RDB correspondant à la transmission de six paquets radio par cycle SDTC, chaque paquet radio comprenant 29 blocs RDB. Les lignes 100, 110, 120, 130, 140, 150 de la matrice décrivent chacune le contenu des champs RDB des 6 paquets radio émis respectivement par les modules SCM#O (qui est le seul à émettre deux paquets consécutifs et qui est le noeud maître), SCM#2, SCM#3, SCM#4, SCM#5. 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 radio. Pour une représentation simplifiée, les champs plus larges, comme par exemple le champ 101, décrivent 6 éléments de la matrice, alors que les autres, comme par exemple le champ 105, ne décrivent qu'un seul élément par souci de simplification de la figure 3.

Ainsi, le champ 101 contient les éléments représentatifs de 6 blocs RDB(0, j) pour j variant de 0 à 5. Le champ 105 lui contient un seul élément, qui est représentatif du bloc RDB(0, 24). La matrice de répartition de capacité du canal décrit la signification des différents champs RDB(i,j), (i<5 ; j<28), au cours d'un cycle SDTC.

Pour 54 de ces blocs de données radio RDB, l'information utile transportée contient un conteneur VC Chunk nouvellement transmis (présent pour la première fois). Il s'agit des champs 101 à 105, 111 à 115, ainsi que des champs 125, 135, 145, 155. Pour les 120 autres de ces blocs de données radio RDB, l'information utile transportée contient un conteneur VC Chunk préalablement reçu puis retransmis (c'est-à-dire relayé), qui est soit issu du même cycle SDTC(n), soit issu d'un ou plusieurs cycles SDTC(n-m) précédents. Dans notre mode de réalisation particulier de l'invention, la retransmission est limitée au cycle précédent uniquement (m=1). Ainsi, les champs 141 à 144, 151 à 154, 136, 137, 146 à 148, 156 à 159, sont représentatifs de 57 blocs RDB retransmis pendant le même cycle SDTC(n) que celui de leur première transmission. Les champs restants, représentatifs des 63 blocs RDB restants, identifient des blocs RDB retransmis (ou relayés), dont la première émission a été effectuée lors du cycle précédent SDTC(n-1). Dans un mode réalisation particulier de l'invention, il est imposé que chaque bloc RDB soit transmis jusqu'à 6 fois avec un minimum de 3 fois, ce qui caractérise en partie la répartition des blocs RDB au sein de la matrice de capacité du canal. Les données audio qui correspondent aux champs 101 à 104 et 111 à 114 seront transmises 3 fois. Les données supplémentaires de contrôle qui correspondent aux champs 105, 115, 125, 135, 145, 155, seront transmises 5 fois. Pour chaque élément de la matrice de répartition de la bande passante synchrone, on trouve au minimum les informations suivantes : - un champ VCB (pour Virtual Channel Bank en anglais) indique un numéro de bande synchrone à laquelle est associé le canal virtuel du conteneur VC Chunk. C'est un identifiant commun aux canaux virtuels VC affectés à la transmission d'un même contenu. Dans l'exemple décrit, il y a une bande VCB par voie audio, c'est-à-dire 8 bandes VCB au total. Une bande VCB est donc composée de 6 canaux virtuels VC. Tous les canaux virtuels VC appartenant à une même bande VCB indiqueront une même valeur prédéfinie pour ce champ VCB. Ce champ est optionnel et par exemple à une valeur indéfinie pour les canaux virtuels VC 48 à 53 destinés au transport de données supplémentaires (de contrôle). - un champ VC indique le numéro de canal virtuel du conteneur VC Chunk ; - un champ Rx indique si le noeud est destinataire du canal virtuel (valeur = ` 1') ou non (valeur = `0') ; - un champ STDC indique le cycle au cours duquel le conteneur VC Chunk a été transmis pour la première fois, un champ STDC d'un cycle courant prenant la valeur `0' ou un champ STDC d'un cycle précédent prenant la valeur `1' ; -un champ Repeat indique s'il s'agit d'un bloc RDB à répéter (valeur = `1') ou non (valeur = '0 . Par exemple, pour l'élément de la matrice correspondant au 61ème bloc RDB du premier paquet radio émis dans un cycle SDTC : RDB(1 ;6)= { VCB =6 ; VC=30 ; Rx=INDEFINI; SDTC=O ; Repeat = 0 ; }. Sur la figure, les champs Rx , SDTC et Repeat ne sont pas représentés. Le choix des noeuds répéteurs n'est pas effectué de façon anodine, il dépend de la topologie du réseau. De par leur position géographique, les modules SCM#2, SCM#3, SCM#4, SCM#5 sont bien placés pour répéter les données audio transmises par le module SCM#0. Grâce aux répétitions, tous les noeuds du réseau reçoivent plusieurs copies d'une même donnée par différents chemins radio. Les différentes copies sont alors comparées pour localiser les erreurs, et le décodeur associé au code correcteur d'erreur est appliqué pour corriger les erreurs. Tel qu'illustré sur les figures 2 et 3, la latence de transmission est fixe et identique pour tous les canaux virtuels. Dans le mode de réalisation particulier de l'invention, la latence pour un VC est exactement de trois cycles SDTC. Il s'agit de la latence entre l'écriture dans le noeud émetteur d'un échantillon de 48 bits dans le cycle SDPC k du cycle SDTC n, et la lecture dans le noeud récepteur de ce même échantillon dans le cycle SDPC k du cycle SDTC n+3.

La figure 4 illustre schématiquement une architecture d'un module de communication synchrone Le module de communication synchrone est constitué d'un processeur CPU 87 (pour Central Processing Unit en anglais) à qui sont associés un bloc de mémoire d'exécution RAM 86 (pour Random Access Memory en anglais) et un bloc de mémoire non volatile ROM 85 (pour Read Only Memory en anglais). Le processeur CPU 87 communique avec le module de communication 84 au travers du bloc 93 (noté CPU IF qui gère notamment les signaux d'interruptions à destination du processeur, ainsi que les échanges de données entre les différents blocs du dispositif de communication 84 et le processeur CPU 87.

Ainsi à l'initialisation du système, le processeur CPU 87 effectue le transfert des informations de configuration, notamment la matrice de répartition de la bande passante synchrone, depuis la mémoire 85 vers le bloc d'interface 93. Eventuellement un choix de configuration peut être effectué parmi plusieurs configurations, toutes stockées en ROM 86, en fonction d'information utilisateur l'environnement du système et sur l'application. Après démarrage du système, les processeurs CPU des différents noeuds du réseau sont à même de s'échanger des messages protocolaires par l'intermédiaire de canaux virtuels de contrôle. Le processeur CPU 87 a également en charge le contrôle du module d'interface radio 99 (noté RF IF ) en définissant notamment l'opération à effectuer (émission, réception) et la configuration des antennes pour chaque intervalle de temps du cycle SDTC. Enfin, le processeur CPU 87 fourni au bloc 95 les données à émettre dans le cas d'une requête d'accès dans l'intervalle de temps de collision CTS et les données à émettre dans le cas d'un paquet radio dans l'intervalle de temps partagé STS. De même le processeur CPU 87 récupère du bloc 94 les requêtes d'accès reçues dans l'intervalle de temps de collision CTS et les paquets radio reçus dans l'intervalle de temps partagé STS. Le module de communication 84 assure le transfert des données synchrones entre le bloc d'interface radio 99 à 60GHz et le bloc d'interface synchrone 98 (not é Audio IF ) vers/depuis le module de traitement des canaux audio 82, qui se trouve être soit un moyen de restitution de canal audio numérique (ou Digital Audio Channel Amplifier en anglais), soit un décodeur audio multi voies (ou Surround sound decoder en anglais). Au sein du dispositif 84 se trouve, du côté traitement des données synchrones, le bloc 89 d'écriture et le bloc 88 de lecture des conteneurs VC Chunks. Le bloc d'écriture 89 est chargé de construire les conteneurs VC Chunks à partir des canaux virtuels VC écrits à chaque cycle SDPC tel que décrit en relation avec la figure 2. Dans le module SCM#0, les échantillons des canaux virtuels audio 0 à 47 ainsi que le canal virtuel de contrôle 48 sont fournis par le bloc d'interface 98. Les échantillons du canal virtuel de contrôle 49 sont fournis par le processeur CPU 87 par l'intermédiaire du bloc d'interface 93. Dans le module SCM#2, le bloc 89 ne traitera que les échantillons du canal virtuel 50 fournis par le processeur CPU 87. A l'inverse, le bloc de lecture 88 est chargé d'extraire les canaux virtuels des conteneurs VC Chunks reçus et de les restituer, pour chaque cycle SDPC, soit au bloc d'interface 98, soit au processeur CPU 87 par l'intermédiaire du bloc d'interface 93. Ainsi, par exemple, dans le module SCM#2, les échantillons des canaux virtuels audio 6 à 11 ainsi que le canal virtuel de contrôle 48 sont transmis au bloc d'interface radio 98. Les échantillons des canaux virtuels de contrôle 49, 51, 52, 53 sont fournis au processeur CPU 87 par l'intermédiaire du bloc d'interface 93.

Pendant un cycle SDTC, le dispositif 84 doit effectuer la lecture et l'écriture de la totalité des échantillons correspondant aux canaux virtuels qu'il doit traiter pendant 8 cycles SDPC consécutifs (ceci dans le cas où STPR = 8). Au sein du dispositif 84 se trouve, du côté transmission des données synchrones, le bloc 95 d'émission et le bloc 94 de réception de paquets radio. Le bloc 95 intègre notamment les fonctions de modulation, par exemple de type OFDM, et d'insertion de préambule indiquant le début d'émission d'un paquet radio. Ainsi le bloc 94 réalise les fonctions inverses de celles implémentées dans le bloc 95, notamment de démodulation, et de détection du préambule indiquant le début de réception d'un paquet radio.

Le bloc 92 est chargé du codage des conteneurs VC Chunks pour créer les blocs de données radio RDB à transmettre. Après codage, les blocs RDB sont stockés dans une mémoire tampon d'émission (ou buffer en anglais) synchrone située dans le bloc 95. Le bloc 91 est chargé du décodage des blocs de données radio RDB reçus. Après décodage, les conteneurs VC Chunks sont stockés dans une mémoire tampon située dans le bloc 88. Le bloc 91 de retransmission des blocs de données radio RDB, récupère certains des blocs RDB reçus par le bloc 94, et les stocke avant retransmission par le bloc 95.

Le bloc de synchronisation 97 contrôle l'enchaînement régulier des cycles SDTC. Le signal de début de cycle SDTC est fourni à tous les blocs du noeud, notamment au processeur CPU 87 par l'intermédiaire du bloc d'interface 93. Le bloc de synchronisation 97 pilote le bloc de synchronisation 96 qui lui contrôle l'enchaînement régulier des cycles SDPC, pour un transfert parfaitement synchrone des échantillons, pour chaque canal virtuel, entre les blocs 88 et 89 et le bloc 98. Le bloc de synchronisation 97 défini également le début chaque intervalle de temps d'un cycle SDTC. Le signal marquant le début d'un intervalle de temps ou le début d'un d'intervalle de temps de collision CTS est fourni au bloc 95 d'émission de paquet radio, au bloc 94 de réception de paquet radio, et au bloc d'interface radio 98. La figure 5 illustre schématiquement les données stockées dans la RAM 86 et gérées par le processeur CPU 87 pour la mise en oeuvre de la présente invention. Dans le mode de réalisation particulier de l'invention, la latence fixe entre l'envoi d'une requête d'accès à un intervalle de temps partagé et l'accès effectif à cet intervalle de temps est de 5 super-trames (c'est-à-dire 5 cycles SDTC). Une requête d'accès transmise dans le cycle SDTC n, est suivie de l'opération d'écriture des canaux de contrôle dans le cycle n+l, puis de la transmission (et répétitions) des canaux de contrôle dans les cycles n+2 et n+3, puis de la lecture des canaux de contrôle dans le cycle n+4, et enfin de la détermination du noeud vainqueur dans le cycle n+5. Ainsi, la mémoire RAM 86 possède six zones mémoires 500, 501, 502, 503, 504, 505 contenant le même type d'information mais pour des cycles SDTC distincts (autant que de cycles SDTC nécessaires pour effectuer l'arbitrage à durée constante pour l'accès à l'intervalle de temps partagé STS d'un cycle donné). Le processeur CPU 87 gère un compteur évoluant de 0 à 5, qui est incrémenté à chaque début de cycle SDTC et qui indique (modulo 5) le numéro de table correspondant au cycle SDTC courant. Si ce compteur est égal à 3, cela signifie que les informations pour le cycle SDTC courant (noté n ) se trouvent dans la table 3 (élément 503) et sont donc stockées en RAM 86 à partir de l'adresse de base de la table 3 (élément 503). En conséquence la table 4 (élément 504) contient les informations pour le cycle SDTC n+l suivant le cycle courant n, la table 5 (élément 505) contient les informations pour le cycle SDTC n+2, la table 0 (élément 500) contient les informations pour le cycle SDTC n+3, la table 1 (élément 501) contient les informations pour le cycle SDTC n+4, la table 2 (élément 502) contient les informations pour le cycle SDTC n+5. Cette gestion de la mémoire permet donc de gérer en permanence l'accès à l'intervalle de temps partagé pour 5 super-trames consécutives (ou cycles SDTC consécutifs). Chaque zone mémoire correspond à une table qui contient trois champs. Sur la figure 5 sont uniquement représentés les champs repères 520 à 522 pour la table 502.

Le champ état paquet 520 indique si un paquet asynchrone est à transmettre dans l'intervalle de temps partagé STS du cycle SDTC correspondant à cette table. Ce champ contient également l'identifiant du paquet à transmettre. Les paquets asynchrones à transmettre sont stockés dans une file d'attente non représentée. Le champ état réception requêtes 521 donne la liste des noeuds utilisant la phase PTS, pour lesquels ont été reçues des requêtes d'accès issues de noeuds requérants émettant une requête d'accès pour l'intervalle de temps partagé STS correspondant à cette table. Dans la suite de la description, ces requêtes d'accès issues de noeuds requérants et relayées durant la phase PTS sont appelées confirmations de requêtes d'accès ou bien encore requêtes d'accès relayées. Le champ état réception requêtes 521 est un vecteur où chaque bit correspond à un noeud du réseau. Un bit avec la valeur `1' signifie que le noeud correspondant est un noeud auquel a été affecté un intervalle de temps dans la phase PTS et que les confirmations de requêtes d'accès venant de ce noeud n'ont pas été reçues. Pour avoir le droit d'utiliser un intervalle de temps partagé STS, il est nécessaire que ce champ soit nul, c'est à dire qu'il est nécessaire de connaître toutes les confirmations de requêtes d'accès de tous les noeuds utilisant la phase PTS. A l'initialisation de la table, les bits correspondant aux noeuds avec intervalle de temps dans la phase PTS ont la valeur `l'.

Dans un mode de réalisation en variante de l'invention, il n'est pas nécessaire d'obtenir les confirmations de requêtes d'accès de tous les noeuds utilisant la phase PTS. Un ensemble de noeuds prédéterminé peut être prédéfini et être un sous-ensemble des noeuds utilisant la phase PTS. Par exemple, cet ensemble de noeuds peut être prédéfini en fonction de leur situation géographique au sein du réseau de communication. En effet, au sein d'un réseau de communication sans-fil tel que le réseau de la figure 1 mettant en oeuvre une application de type home cinema , certains noeuds peuvent avoir des positions privilégiées dans le réseau de communication. Par exemple, le noeud de communication attaché au haut-parleur restituant la voie centrale et ceux attachés aux haut-parleurs restituant les voies latérales, permettent, malgré la présence d'au moins un utilisateur de l'application de type home cinema de relayer (dans le cadre d'une utilisation normale de l'application) un message à l'ensemble des noeuds du réseau, et ce grâce à l'utilisation d'antenne quasi-omnidirectionnelle (c'est-à-dire à large spectre angulaire de rayonnement, par exemple entre 90° et 180°). Le champ liste des requêtes 522 permet de stocker les confirmations de requêtes d'accès au fur et à mesure de leur réception. Le processeur CPU 87 aura en charge le tri de ces requêtes d'accès pour déterminer le noeud prioritaire qui aura l'autorisation d'utiliser l'intervalle de temps partagé STS correspondant à cette table.

Ce tri est effectué suite à la réception des confirmations de requêtes d'accès. Cependant, pour un noeud ayant reçu les requêtes d'accès pendant l'intervalle de temps de collision CTS concerné, un classement (ou pré-classement) des requêtes reçues peut alors être effectué à l'issu de cet intervalle de temps de collision CTS. Cela permet d'accélérer le processus de prise de décision au moment où arrive l'intervalle de temps partagé STS. Il reste cependant dans ce cas, afin de confirmer ou adapter le classement obtenu, d'attendre la réception des confirmations de requêtes d'accès de tous les noeuds utilisant la phase PTS. Pour qu'un noeud ayant émis une requête d'accès pendant un intervalle de collision CTS puisse utiliser l'intervalle de temps partagé STS concerné, il faut que son propre identifiant de noeud soit déclaré comme prioritaire à l'issu de ce processus de tri. La figure 6 illustre schématiquement le fonctionnement d'un module de communication SCM selon un mode de réalisation particulier de l'invention.

Après démarrage du système et initialisation des différents blocs décrits en relation avec la figure 4, le processeur CPU 87 se met en position d'attente de synchronisation du noeud dans une étape 600. Pour le module SCM#O du noeud maître, l'état synchronisé est immédiat et permanent. Pour les autres noeuds (noeuds esclaves), il est nécessaire d'attendre la réception de premiers paquets radio issus de la phase PTS du (ou des) prochain(s) cycle(s) SDTC. Le basculement dans l'état de synchronisation est indiqué par le contrôleur de cycle SDTC 97 dans une étape 601. Puis dans une tape 602 suivante, le processeur CPU 87 se met en attente d'un des quatre événements suivants : - un signal de désynchronisation ou ; - un signal de début d'un nouveau cycle SDTC ou ; - un signal de réception d'une ou plusieurs requêtes d'accès à l'intervalle de temps partagé STS ou ; - un signal de réception d'un ou plusieurs messages par l'intermédiaire de canaux virtuels de contrôle.

Dans le cas de désynchronisation (étape 610) indiquée par le contrôleur de cycle SDTC 97, le processeur CPU 87 effectue alors, dans une étape 611, une lecture des tables 500 à 505 afin de repérer les paquets asynchrones en cours de traitement. Ces paquets sont purgés de la file d'attente et l'application génératrice des paquets est informée de l'échec de transmission. Ensuite, le processeur CPU 87 réinitialise les tables 500 à 505, réinitialise le compteur pointant sur la table représentative du cycle SDTC courant (noté n ), puis retourne à l'étape 600 d'attente de synchronisation. Un noeud esclave est déclaré désynchronisé si ce dernier n'a plus reçu de paquets radio issus de la phase PTS pendant un nombre prédéfini de cycles SDTC consécutifs.

Dans le cas de début de cycle SDTC (étape 620) indiqué par le contrôleur de cycle SDTC 97, le processeur CPU 87 incrémente, dans une étape 621, le compteur pointant sur la table représentative du cycle SDTC courant (noté n ). Dans une étape suivante 622, le processeur CPU 87 effectue d'abord les traitements consécutifs à l'opération réalisée à l'intervalle de temps partagé STS précédent (donc dans le cycle SDTC n-1). Pour cela, le processeur CPU 87 lit le champ état paquet de la table représentative du cycle SDTC n+5 (qui pointait auparavant sur le cycle SDTC courant). Si un paquet asynchrone était à transmettre, le processeur CPU 87 lit un registre interne au bloc d'émission paquet radio 95 pour connaître le résultat de la transmission. Ce résultat est transmis à l'application génératrice du paquet, et si la transmission a échoué l'application pourra demander ultérieurement une retransmission. S'il n'y avait pas de paquet asynchrone à transmettre, le processeur CPU 87 lit un registre interne au bloc de réception paquet radio 94 pour savoir si un paquet a été reçu. Si c'est le cas, le paquet est récupéré par lecture de la mémoire tampon (ou buffer en anglais) de réception asynchrone du bloc 94, et le paquet est transmis à l'application. Une fois ces opérations effectuées, le processeur CPU 87 peut réinitialiser la table représentative du cycle SDTC n+5 qui est donc libre.

Puis une étape 623 est exécutée. Cette étape 623 correspond à une analyse de la file d'attente où sont stockés les paquets asynchrones à transmettre. Si un nouveau paquet est à traiter, il est nécessaire d'envoyer une requête d'accès dans l'intervalle de collision CTS du cycle SDTC courant. Pour cela, dans une étape 624, le processeur CPU 87 construit le message de requête qui comprend l'identifiant local du noeud (un octet) et une information de priorité (un octet) suivant un critère choisi. Par exemple, l'information de priorité pourra être une valeur représentative d'un taux d'accès par le noeud considéré à l'intervalle de temps partagé STS (un noeud qui a rarement eu accès à l'intervalle de temps partagé STS aura une priorité forte). D'autres critères de priorité sont possibles. On peut par exemple utiliser un nombre généré (pseudo-)aléatoirement et effectuer un classement des requêtes d'accès selon le nombre aléatoire qu'elles contiennent. De plus cette information de priorité est dispensable lorsque l'on utilise un critère de priorité basé sur un classement des requêtes d'accès selon l'identifiant local (unique dans le réseau) du noeud. Aux données utiles de la requête d'accès sont ajoutées des octets de redondance pour permettre la détection d'erreurs de transmission. De plus, le processeur CPU 87 calcule un délai pseudo aléatoire qui correspond au délai à attendre après le début de l'intervalle de temps de collision CTS avant transmission de la requête d'accès. Ce temps d'attente permet de limiter les cas de collision où plusieurs requêtes d'accès sont transmises au même moment par différents noeuds. Une fois la requête d'accès construite, elle est écrite dans la mémoire tampon de transmission de requête d'accès du bloc d'émission radio 95, le délai avant transmission est écrit dans un registre interne. Le processeur CPU 87 configure également le module d'interface radio 99 pour l'intervalle de temps de collision CTS à venir en indiquant que le mode émission sera utilisé. Pour finir cette étape, le processeur CPU 87 met à jour le champ état paquet de la table associée au cycle SDTC n+5. Puis une étape 625 est exécutée (cette étape est plus amplement décrite par la suite). Si aucun nouveau paquet n'est à traiter, l'étape 625 est directement exécutée. Dans l'étape 625, le processeur CPU 87 s'attache à la détermination du noeud autorisé à accéder à l'intervalle de temps partagé STS dans le cycle SDTC courant (noté n ). Pour cela, il effectue une lecture du champ liste des requêtes de la table associée au cycle SDTC n. Si des confirmations de requêtes d'accès ont été reçues, les requêtes d'accès sont triées par ordre de priorité selon le critère choisi, et l'identifiant du noeud prioritaire est mémorisé.

Puis une étape 626 permet de vérifier si l'accès à l'intervalle de temps partagé est autorisé. Si l'identifiant du noeud prioritaire déterminé à l'étape 625 n'est pas l'identifiant local, l'accès n'est pas autorisé. Dans ce cas, dans une étape 628, est lu le champ état paquet de la table associée au cycle SDTC n, pour savoir si un paquet asynchrone était à transmettre. Si aucun paquet asynchrone n'était à transmettre (étape 628), une étape 630 est directement exécutée.

Si un paquet asynchrone était à transmettre (étape 628) alors, dans une étape 629, le processeur CPU 87 purge le paquet de la file d'attente, informe l'application génératrice du paquet de l'échec de la transmission, et met à jour le champ état paquet de la table en indiquant qu'aucun paquet n'est à transmettre. Si l'identifiant du noeud prioritaire déterminé à l'étape 625 correspond à l'identifiant local, l'accès à l'intervalle de temps partagé STS est possible (étape 626). Avant d'autoriser l'accès, le processeur CPU 87 doit cependant lire le champ état réception requêtes de la table associée au cycle SDTC n. Si ce champ n'est pas nul, les informations de contrôles de tous les noeuds n'ont pas été reçues. L'accès à l'intervalle de temps partagé STS est alors refusé et l'étape 628 précédemment décrite est directement exécutée. Cette vérification est nécessaire car si tous les éléments ne sont pas connus, il y a toujours un risque de sélectionner de façon erronée un noeud prioritaire. Il existe alors toujours potentiellement un risque de collision dans l'intervalle de temps partagé STS. Si le champ état réception requêtes est bien nul, l'accès à l'intervalle de temps partagé STS du cycle SDTC courant est autorisé (étape 626). Le processeur CPU 87 peut alors procéder, dans une étape 627, au transfert du paquet dans la mémoire tampon (ou buffer en anglais) de transmission asynchrone du bloc d'émission paquet radio 95. Dans une étape 630 suivante, le processeur CPU 87 configure le module d'interface radio 99 pour l'intervalle de temps partagé STS à venir. Par exemple, il indique le mode (émission ou d'une réception) et la configuration de l'antenne en tenant compte des résultats des étapes 625 à 629. Puis dans une étape 631, le processeur CPU 87 prépare l'envoi des confirmations de requêtes d'accès reçues dans l'intevalle de collision CTS du cycle SDTC précédent (c'est-à-dire n-1). Cela n'est évidemment valable que pour un noeud auquel a été affecté un intervalle de temps dans la phase PTS. Le processeur CPU 87 lit le champ liste des requêtes de la table associée au cycle SDTC n+4. Ce champ a été renseigné au cycle SDTC précédent selon la description des étapes 640 et 641 plus amplement décrites dans la suite de la description. Si ce champ n'est pas vide, le processeur CPU 87 écrit un message de contrôle dans la mémoire tampon ( buffer en anglais) de transmission de contrôle du bloc 89 d'écriture de conteneur VC Chunk. Ce message est constitué : - d'un champ en tête avec un octet pour indiquer le contenu du message et un octet pour indiquer la taille (en octets) du message ; - d'un champ de données qui correspond au contenu liste des requêtes de la table. La taille du champ de données dépend du nombre de requêtes d'accès mémorisées, mais la taille du message doit rester inférieure à la taille d'un conteneur VC Chunk afin de garantir une latence fixe de transmission pour tout le champ de données. Quatre modules (SCM#1, SCM#6, SCM#7, et SCM#8) sont susceptibles d'envoyer des requêtes d'accès, en se plaçant dans un mode de réalisation particulier de l'invention où les noeuds pouvant accéder à l'intervalle de temps partagé sont ceux auxquels n'a pas été affecté d'intervalle de temps de la phase PTS. La taille maximale de ce type de message de contrôle sera donc de 10 octets. La capacité d'un conteneur VC Chunk étant de 48 octets utiles, il restera 38 octets libres pour transporter d'autres informations dans le conteneur VC Chunk de contrôle. Après l'étape 631 le processeur CPU 87 a terminé les traitements déclenchés par le début d'un nouveau cycle SDTC. Il se positionne alors de nouveau en attente (étape 602). Soit maintenant le cas de traitements faisant suite à la réception de requête d'accès, dans une étape 640, par le bloc 94 de réception de paquet radio. Cet événement se produit a la fin de l'intervalle de temps de collision CTS si des requêtes d'accès ont été détectées par le bloc 94. Dans une étape suivante 641, le processeur CPU 87 va alors lire la mémoire tampon de réception de requêtes d'accès du bloc 94 et stocker, dans la table correspondant au cycle SDTC n+5 parmi les tables 500 à 505, les requêtes d'accès lues. Il se positionne alors de nouveau en attente (étape 602). Chronologiquement, l'opération effectuée lors de l'étape 641 se produit bien après les opérations des étapes 622 à 624. Les requêtes d'accès nouvellement enregistrées sont écrites dans un canal virtuel VC de contrôle au cycle SDTC suivant (c'est-à-dire n+1). Le bloc RDB (Radio Data Block) correspondant est transmis sur le medium pendant les cycles SDTC n+2 et n+3. Ces requêtes d'accès sont ensuite reçues par tous les noeuds du réseau au cycle SDTC n+4. Elles font parties des informations traitées par tous les noeuds du réseau pour déterminer le noeud autorisé à accéder à l'intervalle de temps partagé STS du cycle SDTC n+5.

Lorsque le processeur CPU 87 reçoit le signal de réception de message(s) de contrôle à l'étape 650, il va éventuellement pouvoir compléter la liste de requêtes d'accès confirmées pour l'accès à l'intervalle de temps partagé STS du prochain cycle SDTC. Ces informations contenues dans les canaux de contrôle ont été construites trois cycles SDTC plus tôt, de la façon décrite à l'étape 631. Puis ces informations ont été transmises sur le médium pendant deux cycles SDTC selon la matrice de répartition de la figure 5. C'est le bloc 88 de lecture de conteneur VC Chunk qui signale la réception de message(s) de contrôle au processeur CPU 87 par l'intermédiaire du bloc d'interface 93. Par exemple, au niveau du module SCM#2, les messages de contrôle peuvent être reçus par les quatre conteneurs VC Chunk contenant respectivement les canaux virtuels 49 (du SCM#O), 51 (du SCM#3), 52 (du SCM#4), 53 (du SCM#5). Dans le bloc 88, quatre mémoires tampon de réception de messages sont réservées : une pour les messages du module SCM#O, une pour les messages du module SCM#3, une pour les messages du module SCM#4 et une autre pour les messages du module SCM#5.

A chaque cycle SDPC, le bloc 88 extrait de chaque conteneur VC Chunk reçu les données du canal virtuel associé au cycle SDPC courant. Par exemple, si un noeud reçoit le conteneur VC Chunk #2, celui-ci contient 16 canaux virtuels VC : le canal virtuel VC#2 du cycle SDPC#O, le canal virtuel VC#2 du cycle SDPC#1, etc jusqu'au canal virtuel VC#2 du cycle SDPC#15. Quand début un nouveau cycle SDPC, par exemple le cinquième de la super trame (cycle SDPC#4), c'est le cinquième canal virtuel VC qui est extrait du conteneur VC Chunk. Lorsque le bloc 88 lit le contenu d'un canal virtuel, si ce canal virtuel VC ne contient pas de donnée valide, le bloc 88 passe au traitement du canal virtuel VC suivant sans rien faire. Si le canal virtuel VC contient une donnée de 48 bits valide, cette donnée est écrite dans la mémoire tampon de réception correspondante. Par conséquent, si le canal virtuel 51 contient une donnée valide, celle-ci est écrite dans la mémoire tampon de réception de messages associée au module SCM#3. A l'étape 650, le bloc 88 de lecture des conteneurs VC Chunk a terminé de lire tous les canaux virtuels pour les 8 cycles SDPC qui composent un cycle SDTC. Chronologiquement, il s'agit là de la fin du cycle SDTC. Dans une étape suivante 651, le processeur CPU 87 effectue la lecture du contenu de chaque mémoire tampon de réception de messages. Chaque message est dépilé et l'en tête analysée dans une étape 652.

Pour la mise en oeuvre d'un mode de réalisation particulier de l'invention, seuls les messages de type confirmation de requêtes sont exploités. Lorsque ce type de message est détecté (étape 652), alors dans une étape 653, le champ de données de chaque message est écrit dans la table 500 à 505 associée au cycle SDTC n+l.

Si une confirmation de requêtes d'accès avait déjà été inscrite précédemment dans la table, elle n'est pas écrite en doublon. Egalement à cette étape, le processeur CPU 87 met à jour le champ état réception requêtes de la table (le bit correspondant au noeud ayant émis un message de type confirmation de requêtes prend la valeur '0'). Le processeur CPU 87 effectue ensuite de nouveau l'étape 602.

Dans cet algorithme, il est à noter que les tables associées aux cycles SDTC n+2 et n+3 ne font l'objet d'aucun traitement. En effet, pendant ces deux cycles SDTC, les données des canaux de contrôle sont transmises sur le medium pendant la phase PTS selon la matrice de répartition décrite à la figure 5.

L'organigramme de la figure 7 illustre schématiquement le fonctionnement du bloc 95 d'émission de paquet radio. Dans une étape 700, le bloc 95 est en attente d'un début de nouvel intervalle de temps, que ce soit le début d'un intervalle de temps de la phase PTS, le début de l'intervalle de collision CTS, ou le début de l'intervalle de temps partagé STS. Cet événement est indiqué par le contrôleur de cycle SDTC 97 dans une étape suivante 701. Dans une étape 702, le bloc 95 vérifie s'il s'agit du début de l'intervalle de collision CTS. Si c'est le cas, le bloc 95 vérifie, dans une étape 703, si une requête d'accès à transmettre est présente dans sa mémoire tampon de transmission de requête d'accès. Si une requête d'accès à transmettre est présente, le bloc 95 lit le registre accessible par le processeur CPU 87 indiquant le délai à attendre avant transmission. Après attente de ce délai dans une étape 704, le bloc 95 procède, dans une étape 705, à l'émission de la requête d'accès, puis retourne en position d'attente d'un nouvel intervalle de temps (étape 700). Si dans l'étape 702, il ne s'agissait pas d'un début de l'intervalle de collision CTS, le bloc 95 vérifie alors, dans une étape 706, s'il s'agit du début de l'intervalle de temps partagé STS. Si c'est le cas, le bloc 95 vérifie, dans une étape 707, si un paquet à transmettre est présent dans sa mémoire tampon de transmission de paquet asynchrone. Si un paquet à transmettre est présent dans sa mémoire tampon de transmission de paquet asynchrone, le bloc 95 procède, dans une étape 708, à l'émission du paquet asynchrone.

En fin d'émission, le bloc 95 renseigne un registre interne accessible par le processeur CPU 87 en indiquant le résultat positif de la transmission. Le bloc 95 retourne ensuite en position d'attente d'un nouvel intervalle de temps (étape 700). Si le test de l'étape 706 est négatif, il s'agit d'un début d'un intervalle de temps de la phase PTS. Le bloc 95 connaissant la séquence TDMA (c'est-à-dire la séquence d'accès au medium selon les affectations des intervalles de temps de la phase PTS aux noeuds du réseau), il est en mesure de déterminer, dans une étape 709, s'il s'agit d'un intervalle de temps réservé au noeud auquel il appartient.

S'il ne s'agit pas d'un intervalle de temps réservé au noeud auquel il appartient, le bloc 95 retourne directement en position d'attente d'un nouvel intervalle de temps (étape 700). S'il s'agit d'un intervalle de temps réservé au noeud auquel il appartient, le bloc 95 procède, dans une étape 710, à l'émission du paquet synchrone dont le champ entête est construit par le bloc 95 et dont le champ de données a été fourni par les blocs 92 et 91. Le champ de données inclut le canal de contrôle du noeud émetteur et éventuellement la répétition de canaux de contrôles émis par d'autres noeuds. Le bloc 95 peut retourner ensuite en position d'attente d'un nouvel intervalle de temps (étape 700).

L'organigramme de la figure 8 illustre schématiquement le fonctionnement du bloc 94 de réception de paquet radio. Dans une étape 800, le bloc 94 est en attente d'un début de nouvel intervalle de temps, que ce soit le début d'un intervalle de temps de la phase PTS, le début de l'intervalle de collision CTS, ou le début de l'intervalle de temps partagé STS. Cet événement est indiqué par le contrôleur de cycle SDTC 97 dans une étape 801. Dans une étape 802, le bloc 94 vérifie s'il s'agit du début de l'intervalle de collision CTS. S'il s'agit du début de l'intervalle de collision CTS, le bloc 94 essaye de détecter un préambule radio, dans une étape 804, jusqu'à expiration de l'intervalle de collision CTS. Pendant l'intervalle de collision CTS, le module d'interface radio 99 est en position de réception sauf si une transmission de requête d'accès a été demandée par le processeur CPU 87. Si aucun préambule n'est détecté à l'étape 804, une étape 806 est directement exécutée. Cette étape 806 consiste à vérifier, par le bloc 94, s'il s'agit de la fin de l'intervalle de collision CTS. Si un préambule est détecté à l'étape 804, le paquet, qui contient a priori une requête d'accès, est mémorisé dans une étape 805. Dans une étape 806, le bloc 94 vérifie s'il s'agit de la fin de l'intervalle de collision CTS. Si le test est négatif lors de l'étape 806, le bloc 94 essaye de détecter d'autres réceptions de paquet. A la fin de l'intervalle de collision CTS, dans une étape 807, le bloc 94 vérifie pour chaque paquet reçu qu'il n'y a pas eu d'erreurs de transmission et mémorise les requêtes d'accès valides dans sa mémoire tampo, de réception de requêtes d'accès. A la fin de cette étape, le bloc 94 envoie un signal d'interruption au processeur CPU 87 pour signaler la réception de requêtes d'accès valides. Le bloc 94 retourne ensuite en position d'attente d'un nouvel intervalle de temps. Si à l'étape 802 il ne s'agit pas du début de l'intervalle de collision CTS, le bloc 94 vérifie alors, dans une étape 808, s'il s'agit du début de intervalle de temps partagé STS. Si c'est le cas, le bloc 94 essaie de détecter un préambule radio, dans une étape 809, jusqu'à expiration d'un délai prédéfini. Pendant l'intervalle de temps partagé STS, le module d'interface radio 99 est en position de réception sauf si une transmission de paquet asynchrone a été demandée par le processeur CPU 87.

Si dans l'étape 809 aucun préambule n'est détecté au bout d'un délai prédéfini, il y a trois possibilités : - aucun noeud n'a de paquet asynchrone à transmettre ou bien ; - le noeud local (auquel le bloc 94 appartient) est l'émetteur du paquet asynchrone ou bien ; un autre noeud émet un paquet asynchrone mais un masquage ou l'éloignement empêche la réception de ce paquet. Une étape 810 permet de vérifier si un délai prédéterminé est atteint. Si ce n'est pas le cas, l'étape 809 est de nouveau exécutée.

Si c'est le cas, le bloc 94 retourne directement en position d'attente d'un nouvel intervalle de temps (étape 800). Si dans l'étape 809 un préambule est détecté, le paquet asynchrone est réceptionné et stocké dans la mémoire tampon de réception de messages asynchrones dans une étape 811.

En fin de réception, le bloc 94 renseigne un registre interne accessible par le processeur CPU 87 en indiquant qu'un paquet (ou lessage) asynchrone a été reçu. Le bloc 94 peut ensuite retourner en position d'attente d'un nouvel intervalle de temps (étape 800). Si le test de l'étape 808 est négatif, il s'agit d'un début d'intervalle de temps de la phase PTS. Dans une étape 812, le bloc 94 essaie alors de détecter un préambule radio jusqu'à expiration d'un délai prédéfini. Pendant chaque intervalle de temps de la phase PTS, le module d'interface radio 99 est en position de réception sauf si une transmission de paquet synchrone est prévue (c'est-à-dire si l'intervalle de temps est affecté au noeud auquel le bloc 94 appartient). Si aucun préambule n'est détecté au bout d'un délai prédéfini lors de l'étape 812, il y a deux possibilités : - soit le noeud local (auquel le bloc 94 appartient) est l'émetteur du paquet synchrone; - soit un autre noeud émet un paquet synchrone mais un masquage ou l'éloignement empêche la réception de ce paquet. Une étape 813 permet de vérifier si un délai prédéterminé est atteint. Si ce n'est pas le cas, l'étape 812 est de nouveau exécutée.

Si c'est le cas, le bloc 94 retourne directement en position d'attente d'un nouvel intervalle de temps (étape 800). Si lors de l'étape 812 un préambule est bien détecté, le paquet synchrone est réceptionné dans une étape 814. Le champ d'entête du paquet est transmis au contrôleur de cycle SDTC 97 qui gère la synchronisation et le champ de données est transmis au bloc de décodage 90. Le champ de données inclut des canaux virtuels de contrôle émis par d'autres noeuds selon la matrice de répartition de la figure 5. Le bloc 94 peut ensuite retourner en position d'attente d'un nouvel intervalle de temps.

La description des figures 6 à 8 ci-dessus réfère à un mode de réalisation particulier de l'invention pour lequel chaque noeud requérant est capable de prendre la décision d'accéder ou non à l'intervalle de temps partagé STS en fonction des requêtes (ou indications de requêtes) relayées par les noeuds disposant d'(au moins) un intervalle de temps pré-affecté dans la phase PTS. Il est aussi possible dans ce mode de réalisation, qu'un noeud non requérant puisse déterminer quel noeud requérant a obtenu l'autorisation d'accès à l'intervalle de temps partagé. Cette information peut alors permettre à ce noeud, de paramétrer son antenne de réception de manière à capter, pendant l'intervalle de temps partagé STS, les signaux émis par le noeud requérant ayant obtenu l'autorisation d'accès à l'intervalle de temps partagé STS.

Un mode de réalisation en variante utilise un noeud décisionnaire, qui valide les autorisations d'accès au réseau pendant l'intervalle de temps partagé, à partir des requêtes émises pendant l'intervalle de collision CTS. Le principe général repose dans ce cas lui aussi sur la transmission, par des noeuds disposant d'intervalles de temps pré-affectés pendant la phase PTS, des requêtes (ou indications de ces requêtes) qui on été détectées par ces noeuds pendant la phase PTS. Comme dans le cas d'un environnement de mise en oeuvre distribuée, les noeuds disposant d'intervalles de temps pré-affectés pendant la phase PTS peuvent (ou pas) retransmettre, selon un schéma de répétition défini par la matrice de répartition de la bande passante synchrone (voir figure 3), les requêtes (ou indications de ces requêtes) qui ont été détectées par d'autres noeuds disposant d'intervalles de temps pré-affectés pendant la phase PTS. Il suffit alors au noeud décisionnaire de transmettre le résultat de la décision concernant l'accès à l'intervalle de temps partagé STS au moins au noeud requérant dont la requête a été sélectionnée comme prioritaire. Pour se faire, le noeud décisionnaire peut par exemple disposer d'un intervalle de temps pré-affecté pendant la phase PTS. Cette décision peut éventuellement être elle aussi relayée par des noeuds disposant d'intervalles de temps pré-affectés pendant la phase PTS. On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en oeuvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas où l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur.

Claims

REVENDICATIONS1. Procédé de gestion d'accès à un réseau de communication pendant un intervalle de temps partagé (STS), un intervalle de temps de collision (CTS) permettant d'émettre 5 une requête d'accès à l'intervalle de temps partagé (STS), un ensemble prédéterminé d'au moins un noeud disposant chacun d'au moins un intervalle de temps pré-affecté (PTS) pour accéder audit réseau, caractérisé en ce qu'un noeud décisionnaire effectue des étapes consistant à : - recevoir (640), pendant l'ensemble d'intervalle de temps (PTS) pré-affecté, une information indiquant, pour chaque noeud dudit ensemble prédéterminé, si ledit noeud a ou non détecté au moins une requête d'accès à l'intervalle de temps partagé (STS) ; - déterminer (625), parmi la ou les requêtes dont une indication de réception positive a été reçue, une requête d'accès prioritaire en fonction d'au moins un critère de sélection prédéterminé ; et en ce que l'accès audit intervalle de temps partagé (STS) est autorisé au noeud ayant émis ladite requête d'accès prioritaire pendant l'intervalle de temps de collision (CTS).
2. Procédé selon la revendication 1, caractérisé en ce que chaque noeud dudit ensemble prédéterminé relaie chaque requête d'accès à l'intervalle de temps partagé 20 (STS) que ledit noeud a détecté pendant ledit intervalle de temps de collision.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que, si le réseau ne comprend qu'un unique dit noeud décisionnaire, ladite étape (625) consistant à déterminer la requête d'accès prioritaire est effectuée aussi parmi des requêtes d'accès reçues pendant l'intervalle de temps de collision par ledit noeud 25 décisionnaire.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que lorsqu'un noeud dudit ensemble prédéterminé détecte plusieurs requêtes d'accès à l'intervalle de temps partagé (STS) émises pendant ledit intervalle de temps de collision, ledit noeud dudit ensemble prédéterminé effectue une étape consistant à 30 classifier, dans une liste, lesdites requêtes d'accès détectées en fonction dudit critère de sélection prédéterminé, et en ce que qu'il transmet pendant son intervalle de temps (PTS) pré-affecté une information relative à une requête prioritaire déterminée, parmi lesdites requêtes d'accès détectées, selon le critère de sélection prédéterminé.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que 35 chaque noeud dudit ensemble prédéterminé relaie, pendant son intervalle de temps 10 15(PTS) pré-affecté, des informations d'indication de réception de requête d'accès à l'intervalle de temps partagé (STS) détectée par au moins un autre noeud dudit ensemble prédéterminé pendant l'intervalle de temps de collision (CTS).
6. Procédé selon l'une quelconque des revendications 1 à 5, un noeud requérant étant un noeud émettant un requête d'accès à l'intervalle de temps partagé (STS), caractérisé en ce que, si chaque noeud requérant est un dit noeud décisionnaire, ledit noeud décisionnaire effectue des étapes consistant à : - émettre une requête d'accès, pendant ledit intervalle de temps de collision (CTS) ; - émettre des données sur ledit réseau pendant ledit intervalle de temps partagé, si ladite requête d'accès prioritaire est identique à la requête d'accès transmise par ledit noeud requérant donné.
7. Procédé selon l'une quelconque des revendications 1 à 5, un noeud requérant étant un noeud émettant un requête d'accès à l'intervalle de temps partagé (STS), caractérisé en ce que, si ledit noeud décisionnaire n'est pas un noeud requérant, ledit noeud décisionnaire effectue une étape consistant à émettre, à destination du noeud requérant ayant préalablement émis ladite requête d'accès prioritaire, une information autorisant ledit noeud requérant à accéder audit réseau pendant ledit intervalle de temps partagé (STS).
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que le nombre de cycles de transmission séparant un cycle de transmission dans lequel à été émise une requête d'accès et un cycle de transmission dans lequel se trouve l'intervalle de temps partagé (STS) associé à la requête, est fixe et prédéterminé.
9. 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é selon au moins une des revendications 1 à 8, lorsque ledit programme est exécuté sur un ordinateur.
10. Moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 8.
11. Noeud décisionnaire pour la gestion d'accès d'au moins un noeud à un réseau de communication pendant un intervalle de temps partagé (STS), un intervalle de temps decollision (CTS) permettant d'émettre une requête d'accès à l'intervalle de temps partagé (STS), un ensemble prédéterminé d'au moins un noeud disposant chacun d'au moins un intervalle de temps pré-affecté (PTS) pour accéder audit réseau, caractérisé en ce que ledit noeud décisionnaire comprend : - des moyens de réception, pendant l'ensemble d'intervalle de temps (PTS) pré-affecté, d'une information indiquant, pour chaque noeud dudit ensemble prédéterminé, si ledit noeud a ou non détecté au moins une requête d'accès à l'intervalle de temps partagé (STS) ; - des moyens de détermination, parmi la ou les requêtes dont une indication de réception positive a été reçue, une requête d'accès prioritaire en fonction d'au moins un critère de sélection prédéterminé ; - des moyens d'accorder l'accès audit intervalle de temps partagé (STS) pour le noeud ayant émis ladite requête d'accès prioritaire pendant l'intervalle de temps de collision (CTS).
12. Noeud décisionnaire selon la revendication 11, caractérisé en ce que chaque noeud dudit ensemble prédéterminé comprend des moyens de relais de chaque requête d'accès à l'intervalle de temps partagé (STS) transmise pendant ledit intervalle de temps de collision.
13. Noeud décisionnaire selon l'une quelconque des revendications 11 à 12, caractérisé en ce qu'il comprend des moyens de réception pour recevoir, pendant ledit intervalle de collision, au moins une requête d'accès à l'intervalle de temps partagé, et en ce que, si le réseau ne comprend qu'un unique dit noeud décisionnaire, la requête d'accès prioritaire est déterminée aussi parmi les requêtes d'accès reçues pendant l'intervalle de temps de collision.
14. Noeud décisionnaire selon l'une quelconque des revendications 11 à 13, caractérisé en ce que chaque noeud dudit ensemble prédéterminé comprend des moyens de détection d'informations d'indication de réception de requête d'accès à l'intervalle de temps partagé (STS) détectée par un noeud dudit ensemble prédéterminé pendant l'intervalle de temps de collision (CTS) et relayées par un autre noeud dudit ensemble prédéterminé pendant son intervalle de temps (PTS) pré-affecté.
15. Noeud décisionnaire selon l'une quelconque des revendications 11 à 14, un noeud requérant étant un noeud émettant une requête d'accès à l'intervalle de temps partagé (STS), caractérisé en ce que, si chaque noeud requérant est un dit noeud décisionnaire, ledit noeud décisionnaire comprend en outre :- des premiers moyens d'émission d'une requête d'accès, pendant ledit intervalle de temps de collision (CTS) ; - des seconds moyens d'émission des données sur ledit réseau pendant ledit intervalle de temps partagé, si ladite requête d'accès prioritaire est identique à la requête d'accès transmise par ledit noeud requérant donné.
16. Noeud décisionnaire selon l'une quelconque des revendications 11 à 14, un noeud requérant étant un noeud émettant un requête d'accès à l'intervalle de temps partagé (STS), caractérisé en ce que, si ledit noeud décisionnaire n'est pas un noeud requérant, ledit noeud décisionnaire comprend des troisièmes moyens d'émission, à destination du noeud requérant ayant préalablement émis ladite requête d'accès prioritaire, d'une information autorisant ledit noeud requérant à accéder audit réseau pendant ledit intervalle de temps partagé (STS).15