Recherche dans les collections de brevets nationales et internationales
Une partie du contenu de cette demande n'est pas disponible pour le moment.
Si cette situation persiste, contactez-nous auObservations et contact
1. (FR2864870) METHODE DE TRANSMISSION DE DONNEES IEEE 1394 SUR UNE LIAISON SANS FIL ET APPAREIL IMPLEMENTANT LA METHODE
Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique
Méthode de transmission de données IEEE 1394 sur une liaison sans fil et appareil implémentant la méthode
La présente invention concerne le domaine de l’interconnexion de bus de données série IEEE 1394 par des liaisons sans fil.
Le bus IEEE 1394 défini dans le document 'IEEE Std 1394-1995 High Performance Bus, 1996-08-30’ décrit un bus série pour transmission numérique permettant la connexion d’appareils aussi appelés ‘nœuds’.
HiperLAN/2 est une norme produite par l’ETSI (European Télécommunications Standards Institute) dans le cadre de son projet BRAN (Broadband Radio Access Network). Elle définit un protocole de communication entre appareils sur un réseau sans fil.
La famille de norme 802.11 définit une norme de communication sur un réseau sans fil normalisé dans le document ANSI/IEEE std 802.11- 1999.
Lorsque l’on veut interconnecter plusieurs bus IEEE 1394 par un pont constitué d’un réseau sans fil, on doit porter le protocole IEEE 1394 sur la norme utilisée par le réseau sans fil. Dans cette optique, HiperLAN/2 spécifie, dans le document « Broadband Radio Access Networks (BRAN) ; HIPERLAN Type 2 ;Packet based convergence layer ; Part 3 : IEEE 1394 Service Spécifie Convergence Sublayer», une couche de convergence appelée IEEE 1394 SSCS (Service Spécifie Convergence Sublayer) qui permet le transport des paquets de données IEEE 1394 dans des paquets HiperLAN/2. Par contre une telle couche de convergence n’est pas standardisée dans le cas de réseaux sans fil fonctionnant selon la norme 802.11, malgré une tentative abandonnée par la « 1394 Trade Association ».
Lorsque l’on veut interconnecter plusieurs bus IEEE 1394 par un réseau sans fil 802.11, il est donc nécessaire de développer une couche de convergence permettant le transport des paquets de données IEEE 1394 dans des paquets 802.11. L’objet de l’invention est de définir une méthode de transport du trafic IEEE 1394 sur un réseau 802.11 en s’appuyant sur la couche de convergence normalisée pour les réseaux HiperLAN/2, IEEE 1394 SSCS. Les services de la couche de convergence vont être utilisés pour obtenir les paquets, appelés SAR PDU (Segmentation and Re-assembly Packet Data Unit) dans la norme, bruts ou empaquetés dans un paquet LCH (Long CHannel) au format utilisé par la DLC (Data Link Control) d’Hiperlan/2. Ensuite ce sont ces paquets qui vont être assemblés dans une trame 802.11 et envoyés sur le réseau 802.11. L’appareil récepteur fonctionnant à l’inverse, récupérant dans la trame 802.11, les SAR PDU ou les LCH et utilisant un module IEEE 1394 SSCS pour reconstruire le paquet IEEE 1394 d’origine.
Cette méthode est particulièrement avantageuse lorsqu’elle est utilisée dans un appareil disposant d’un circuit d’interface entre le réseau IEEE 1394 et le réseau sans fil qui dispose d’un module IEEE 1394 SSCS matériel. L'invention concerne un méthode de transmission de données sur une liaison sans fil comportant l’insertion des données dans des paquets selon un format correspondant à au moins certaines couches d’un premier protocole de transmission de données sur un réseau sans fil, ainsi que l’utilisation de ces paquets pour former une trame conforme à un second protocole de transmission de données sur un réseau sans fil, différent du premier protocole, et la transmission sur le réseau sans fil selon le second protocole.
Selon un mode particulier de réalisation de l’invention les données initiales sont formatées selon un protocole d’un bus câblé.
Selon un mode particulier de réalisation de l’invention le bus câblé 5 est un bus IEEE 1394, le premier protocole de transmission de données sur un réseau sans fil est HiperLAN/2 et le second protocole de transmission de données sur un réseau sans fil est un protocole de la famille 802.11.
Selon un mode particulier de réalisation de l’invention les paquets 10 utilisés sont générés par un module IEEE 1394 SSCS.
Selon un mode particulier de réalisation de l’invention les trames, générées à partir des paquets selon un format intermédiaire défini par la ou lesdites couches du premier protocole de transmission de données sur un 15 réseau sans fil, lesdites trames étant conformes au second protocole de transmission de données sur un réseau sans fil, sont distinguées d’autres trames par un identificateur spécifique dans la trame.
Selon un mode particulier de réalisation de l’invention les trames, 20 générées à partir des paquets selon un format intermédiaire défini par la ou lesdites couches du premier protocole de transmission de données sur un réseau sans fil et conformes au second protocole de transmission de données sur un réseau sans fil, sont distinguées d’autres trames par l’utilisation d’adresses MAC spécifiques identifiant leur origine et leur 25 destination. L’invention concerne également un appareil de transmission de données, contenant des moyens permettant de recevoir des trames selon le protocole formatées selon un bus câblé, des moyens de connexion à un 30 réseau sans fils, un module de traitement des trames formatées selon un bus câblé pour insérer les données reçues sur le bus câblé dans une trame selon un format défini par un premier protocole de transmission de données sur un réseau sans fil, caractérisé en ce que l’appareil contient des moyens de génération de trames de transmission conformes à un second protocole de transmission de données sur un réseau sans fil à partir desdits paquets dans lesquels ont été insérées des données reçues à partir du bus câblé, 5 lesdits paquets étant formatés selon au moins certaines couches du premier protocole.
Selon un mode particulier de réalisation de l’invention, l’appareil comporte, pour ce qui est du second protocole, uniquement les couches 10 nécessaires à l’encapsulation et la transmission de paquets générés à l’aide desdites couches du premier protocole. L'invention sera mieux comprise, et d’autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la 15 description faisant référence aux dessins annexés parmi lesquels :
La figure 1 représente l’architecture matérielle du circuit utilisé dans l’exemple de réalisation de l’invention.
La figure 2 représente l’architecture logicielle du circuit utilisé dans l’exemple de réalisation de l’invention. 20 La figure 3 représente l’architecture logicielle de la couche de convergence IEEE 1394 SSCS.
La figure 4 représente le format d’un paquet selon la norme 802.11.
La figure 5 représente le format d’un paquet SAR-PDU tel que 25 construit par le module SAR de la couche de convergence IEEE 1394 SSCS.
La figure 6 représente le même paquet inclus dans un paquet LCH tel qu’utilisé par la DLC Hiperlan/2.
La figure 7 est un diagramme représentant les étapes de la 30 méthode selon l’invention. L’exemple de réalisation de l’invention qui va être décrit maintenant se place dans le cadre de l’utilisation d’un circuit d’interfaçage entre un réseau sans fil et un bus câblé. Mais l’invention peut être mise en œuvre en utilisant d’autres circuits. Certains modules utilisés peuvent être implémentés en matériel dans un circuit ou en logiciel.
La figure 1 représente l’architecture du circuit. Ce circuit comprend un processeur central généraliste 13, par exemple de la famille PowerPC (PPC) connecté sur son bus 14. Sur ce même bus est connectée une interface réseau Ethernet 12. Le bus 14 est connecté par un pont 16 à un second bus ARM-AMBA 15. Sur ce second bus sont connectés diverses unités dont, entre autres, une interface USB 11, une interface audio/vidéo (A/V) 10, une unité de calcul de code selon l’algorithme Reed/Salomon (R/S) 9, une interface réseau 8 selon la norme IEEE 1394. Le circuit est également connecté à un émetteur-récepteur RF 2 permettant la transmission par onde radio dans la gamme des 5 GHz. Cet émetteur-récepteur 2 est piloté par un contrôleur physique 3. Il existe deux modules capables d’utiliser ce contrôleur physique 3, d’une part un module 4 implémentant la couche MAC de la norme 802.11a et permettant donc l’envoi et la réception de paquets de données selon cette norme au niveau MAC, et d’autre part un module 5 implémentant la couche DLC (Data Link Control) de la norme HiperLAN/2 permettant l’envoi et la réception de paquets selon cette norme via l'émetteur-récepteur 2. Un équipement doté de ce circuit est donc à même de se connecter à des réseaux sans fil selon la norme 802.11a et la norme HiperLAN/2. Ces deux modules 4 et 5 utilisent une mémoire DLC 6. Un module matériel 7 implémente la couche de convergence IEEE 1394 SSCS ainsi que la partie commune chargée du traitement des trames IEEE 1394 constituée par la couche CPCS (Common Part Convergence Sublayer) et la couche de segmentation et de ré assemblage SAR (Segmantation And Reassembly) telle que définie dans la figure 3. La couche IEEE 1394 SSCS est chargée de la transformation des trames IEEE 1394 en un format commun de paquets de taille variable, tandis que la partie commune va prendre ces paquets et y ajouter des octets de complémentation et les transmettre à la couche de segmentation et de ré assemblage qui va les découper en paquets de taille fixe. Ces paquets de taille fixe seront transmis à la DLC de HiperLAN/2. Cette partie commune est définie dans le document ETSI TS 101 493-1.
La figure 2 détaille l’architecture logicielle portée sur le circuit. Ce circuit dispose d’un certain nombre de modules logiciels pilotant le matériel (driver), un module pour le bus IEEE 1394 référencé 54, un module pour HiperLAN/2 référencé 52, un module pour le 802.11 référencé 49, un module pour Ethernet référencé 47, un module pour l’USB référencé 46. Au dessus de ces pilotes, se trouvent un certain nombre de couches MAC, la couche MAC d’HiperLAN/2 référencé 51 contenant la DLC, la couche MAC 802.11 référencé 48. Le circuit dispose encore de couches de convergence permettant le transport de certains protocoles au dessus d’HiperLAN/2 comme l’Ethernet SSCS référencé 50 et le IEEE 1394 SSCS référencé 21. Le module référencé 55, Pont transparent IEEE 1394, gère la transparence du pont HiperLAN/2 pour la couche IEEE 1394. C’est à dire que plusieurs bus IEEE 1394 connectés via un réseau HiperLAN/2 vont pouvoir apparaître au niveau de la couche IEEE 1394 comme un unique bus IEEE 1394 virtuel contenant tous les nœuds des différents bus IEEE 1394 interconnectés. Le module référencé 44 établit un pont entre ethernet et la couche de contrôle de lien logique LLC (Logical Link Control) au dessus de la couche MAC de 802.11. Au dessus se trouvent les modules classiques TCP/IP 43 et une pile HTTP 42. Les applications de haut niveau 40 ont accès à ces modules à travers une API (Application Program Interface) 56 et des couches de configuration 41.
La figure 3 détaille l’architecture logicielle de la couche de convergence IEEE 1394 SSCS référencée 21. Elle offre aux couches hautes référencées 20, un service IEEE 1394 au dessus d’un réseau HiperLAN/2. Pour ce faire, elle se compose d’une partie spécifique au service IEEE 1394 référencée 22, contenant des couches de convergences pour différents services comme ethernet ou, en ce qui nous concerne ici, IEEE 1394 référencées 23. Ces différentes couches de convergence spécifiques s’appuient sur une partie commune à tous les services référencée 24 5 composée d’un module CPCS référencé 25 et d’un module SAR référencé 26. Un paquet de données, ici 1394, sera donc traité d’abord par le module 1394 SSCS spécifique au standard 1394 pour être ensuite traité par la partie commune qui va produire des paquets de données dits SAR-PDU (Packet Data Unit) aptes à être traités par les couches inférieures HiperLAN/2 10 référencées 27 composées de la DLC 28 (Data Link Control) et de la couche physique référencée 29 d’HiperLAN/2.
La figure 4 représente le format général d’un paquet MAC 802.11 généré selon l’invention. La signification des différents champs de l’entête 15 peut être trouvée dans le document ANSI/IEEE Std 802.11, 1999 Edition. Suivant l’entête, on trouve la place utile du paquet 37, suivi d’un champ de contrôle 38. Le paquet utile est généré par généralement 4 paquets LCH ayant la structure décrite figure 5 et 6. 20 La figure 5 représente la structure d’un SAR-PDU tel qu’il est généré par la SAR. C’est un paquet de 49,5 octets contenant une partie de données utiles de 48 octets précédée d’un octet et demi d’entête. Ce paquet est ensuite utilisé par la DLC d’HiperLAN/2 qui l’encapsule dans un paquet LCH comme illustré par la figure 6. Ce LCH est de 54 octets. Dans le circuit 25 considéré, le module 1394 SSCS produit directement ces LCH prêts à être utilisés par la DLC. L’encapsulation se fait par l’adjonction d’un type identifiant le type du paquet, un numéro de séquence ainsi qu’un CRC assurant l’intégrité du paquet. 30 Dans un mode de fonctionnement classique du circuit, le trafic 1394 asynchrone peut être transféré sur un réseau sans fil via le protocole HiperLan/2 de la manière suivante. Les paquets 1394 arrivent sur l’interface 8. Ces paquets sont pris en charge par le module 1394 SSCS logiciel implémenté sur le processeur généraliste 13. Ce module génère à partir de ce paquet 1394 des LCH qui sont rangés dans la mémoire 6 pour accès par les DLC. Ces LCH sont ensuite pris en charge par la DLC HiperLAN/2 5 pour être envoyés sur l’interface physique sans fil 3. Le trafic 1394 isochrone quant à lui suivra le même chemin à la différence qu’il va être traité par le module 1394 SSCS matériel 7. Mais de la même façon, ce module va générer des paquets LCH de 54 octets qui vont être disposés dans la mémoire DLC 6. Ces paquets LCH seront ensuite pris en charge de la même manière par la DLC 5 pour être envoyés via le réseau sans fil.
Dans le cadre de l’invention, ce même trafic 1394 asynchrone peut être transféré sur un réseau sans fil via le protocole 802.11 au lieu d’HiperLAN/2 . Les paquets 1394 arrivent sur l'interface 1394. Ils sont pris en charge par le module 1394 SSCS logiciel implémenté sur le processeur 13. Comme précédemment, ce module génère des paquets LCH dans la mémoire 6. Ces paquets LCH contiennent les « SAR-PDU » dont la structure connue en soi est représentée figure 5 plus un champ de type appelé « LCHPDUtype », un numéro de séquence et un CRC comme on peut le voir sur la figure 6. Mais ici, contrairement au cas précédent, ce n’est pas la DLC d’HiperLAN/2, mais un programme spécifique, appelé 1394CL, qui va prendre en charge ces paquets LCH et qui va créer dans la mémoire DLC 6 une trame 802.11 telle que celle représentée à la figure 4. Ce programme spécifique est implémenté sur le contrôleur 4 de la DLC 802.11. C’est donc une tâche supplémentaire qui tourne sur le micro-controlleur en plus de sa tâche habituelle dévolue à la DLC 802.11a. Mais il peut également être exécuté par le processeur central PPC. Cette trame va pouvoir être envoyée par la DLC 802.11 sur le réseau sans fil. La trame 802.11 peut contenir plusieurs paquets LCH, quoique dans le cas du trafic asynchrone, nous n’allons pas généralement attendre d’avoir plusieurs paquets LCH et nous allons envoyer chaque paquet LCH dès que possible, voire individuellement. Dans le cas du trafic isochrone détaillé plus loin ce ne sera plus le cas.
Le trafic isochrone 1394, quant à lui, est transféré sur le réseau sans fil selon la norme HiperLAN/2 comme suit. Les trames isochrone 1394 arrivent, comme les trames asynchrones, sur l’interface 1394 8. Mais contrairement au trafic asynchrone, pris en charge par le module 1394 SSCS logiciel sur le PPC, le trafic isochrone est pris en charge par un module 1394 SSCS matériel figure 1 n° 7. C’est donc ce module matériel qui va construire les « SAR-PDU » et les LCH les contenant dans la mémoire des DLC 6. Ici aussi ces paquets LCH seront ensuite pris en charge par la DLC HiperLAN/2 figure 1 n° 5 qui va les envoyer sur la réseau sans fil via la couche physique figure 1 n° 3.
Lorsque l’on va vouloir envoyer ce trafic 1394 isochrone sur le réseau sans fil selon le protocole 802.11 selon l’exemple de réalisation de l’invention, la DLC HiperLAN/2 va être désactivée et, comme dans le cas du trafic 1394 asynchrone, le programme spécifique va construire une trame 802.11 constituée de paquets LCH. De préférence la trame va être constituée de 4 paquets LCH de 54 octets soit 216 ce qui correspond à un message FEC. En effet le module implémentant la correction d’erreurs de transmission (FEC pour « Forward Error Correction » en anglais) travaille sur des blocs de 216 octets.
Une variante d’implémentation de l’exemple de réalisation de l’invention consiste à utiliser directement les paquets « SAR-PDU » dans la trame 802.11 sans l’habillage sous forme de LCH. En effet, l’implémentation décrite utilise les LCH, car le module 1394 SSCS utilisé dans le circuit produit directement ce type de paquet, bien que le passage du paquet « SAR-PDU » au paquet LCH soit, en toute logique, une opération dévolue à la DLC HiperLAN/2 et non au module 1394 SSCS tel que défini dans la norme. L’essentiel étant de réutiliser le travail de découpage de la trame 1394 faite par le module 1394 SSCS, le format exact du paquet issu de ce module et que l’on utilise dans la trame 802.11a n’influe pas sur le fonctionnement de la méthode.
Le problème de l’identification de ces paquets 802.11a comme transportant des trames 1394 et devant donc, sur le récepteur, être transmis à ce module 1394CL peut se résoudre de plusieurs manières. Une première méthode consiste à ajouter dans la trame 802.11a un paquet LLC/SNAP. Ce type de paquet est décrit dans la RFC 802.2 et permet de décrire le type de données et la nature des couches de transport ainsi que des informations sur le constructeur. C’est un paquet de 8 octets que l’on place en début du paquet 802.11a qui se compose alors d’un entête de 24 octets, de 4 octets de graine de clé publique, des 8 octets du paquet LLC/SNAP, des données utiles, les paquets LCH dans notre cas, de 4 octets de code d’intégrité et de 4 octets de CRC.
Une autre manière d’identifier les paquets transportant du trafic 1394 sur 802.11a est de créer une adresse MAC spécifique à ce trafic au niveau du driver 802.11a. Une seconde adresse MAC peut être créée par une station dans un réseau 802.11a en répétant les phases d’authentification et d’association telles qu’elles sont prévues dans la norme avec une nouvelle adresse MAC. Ensuite, il faut programmer le matériel pour filtrer ces deux adresses MAC et non pas seulement la première de façon à être reconnu comme destinataire des paquets destinés à ces deux adresses MAC. Cette adresse MAC peut être une adresse de diffusion simple (« unicast » en anglais) ou multiple (« multicast » en anglais). L’avantage d’une adresse de diffusion multiple est la possibilité offerte à des stations IEEE 1394 de s’enregistrer auprès d’une adresse MAC commune associée à un lien isochrone. Les adresses MAC de diffusion multiple sont créées par une convention de plus haut niveau. Par exemple, un ensemble d’adresses MAC de diffusion multiple peut être créé par défaut à l’initialisation pour le trafic 1394. Dans ce cas il est possible de se passer du paquet LLC/SNAP.
Cette méthode offre l’avantage d’isoler le trafic 1394 du reste du trafic par l’utilisation d'adresses MAC spécifiques, tandis que celle utilisant le paquet LLC/SNAP permet à un équipement non compatible d’identifier un type de paquet inconnu et de l’ignorer. Le driver 802.11a, dans ce cas va lire l’adresse MAC de destination de la trame, reconnaître l’adresse dédiée au trafic 1394 sur 802.11a et passer la trame au module 1394CL.
Au niveau du driver 802.11a, le trafic 1394 est traité de la même manière que le trafic Ethernet envoyé par le module « data delivery » 48. Si rien n’est fait pour différencier les trafics, il se peut que le trafic Ethernet vienne perturber l’envoi des trames 1394. Il est possible de résoudre ce problème par une gestion statistique du trafic en envoyant une trame Ethernet pour 5 trames 1394 par exemple.
Il apparaîtra à l’homme du métier que l’invention, bien que décrite dans le cadre de l’utilisation du circuit considéré, n’est pas limitée à l’utilisation de ce circuit mais peut s’utiliser dans tout système comportant sensiblement les mêmes modules. Il est également évident que l’implémentation, tant logicielle que matérielle, de ces modules n’influe pas sur le fonctionnement de l’invention. Cette invention peut également se généraliser à d’autre protocoles que le 802.11a, tels que les autres protocoles de la famille 802.11, mais aussi à des protocoles d’autres familles. Il apparaîtra encore à l’homme du métier que les paquets élémentaires que l’on regroupe dans une trame selon le protocole utilisé sur le réseau sans fil, peuvent être modifiés dans le détail par rapport à la solution exposée ici.