Une plate-forme d expérimentation multiprocesseur pour les réseaux sans fil

Transcription

1 Une plate-forme d expérimentation multiprocesseur pour les réseaux sans fil Damien Hedde, Pierre-Henri Horrein, Frédéric Pétrot, Robin Rolland et Franck Rousseau CNRS/Grenoble INP/UJF CIME-Nanotech Parvis Louis Néel, Grenoble RÉSUMÉ Cet article présente le travail effectué dans le cadre de la mise en place d une plate-forme d expérimentation pour les réseaux sans fil se basant sur des cartes FPGA à bas coût. Mots-clés: SDR, radio logicielle, télécommunications sans fil, systèmes embarqués I. INTRODUCTION La mobilité généralisée des personnes et des équipements change totalement la problématique de l accès aux différents réseaux. Cette mobilité est généralement obtenue en utilisant des télécommunications sans fil, que ce soit pour le téléphone ou les réseaux informatiques. L étude et l enseignement pratique de solutions d interconnexions mobiles, efficaces, et peu coûteuses est donc fondamentale. Traditionnellement, les couches du réseau gérant la concurrence des sources de données et la transmission physique étaient, vu les débits et les latences requises, réalisées en matériel. Depuis quelques années, une solution en plein essor, possible seulement grâce à l intégration micro-électronique, consiste à effectuer les traitements numériques, habituellement réalisés en matériel, à l aide de programme s exécutant principalement sur des processeurs de type DSP. Une telle solution a, en particulier, l avantage de très bien s adapter au nombre croissant de standards «sans fil» : il est possible de modifier dynamiquement les opérations effectuées en fonction du standard sans avoir besoin d une plate-forme matérielle par standard, réduisant ainsi les coûts de fabrication. L objectif du projet est de permettre à des étudiants se spécialisant en réseau d avoir accès à une plateforme d expérimentation ouverte, sur laquelle ils peuvent modifier l ensemble de la chaîne de réception, de l émission des signaux I et Q à la réception du paquet dans l application tournant sous Linux. La plate-forme de radio logicielle est en cours de finalisation, et les TPs et projets qui l utiliseront sont en cours de définition. II. CHOIX D ARCHITECTURE A. Objectifs : problèmes à résoudre Les contraintes posées par un tel projet sont nombreuses et variées. En effet, le nombre de normes existantes est impressionnant, et de nouvelles normes sont sans cesse en développement. L objectif du projet est de s abstraire de la norme pour proposer une vue générale adaptable à n importe quel système de communications. D autres contraintes existent, en particulier des contraintes de modularité. En effet, la plate-forme étant destinée à un but éducatif et de recherche, il est nécessaire de pouvoir séparer les différentes parties du réseau à différents grains. En effet, si une manipulation doit mettre en évidence les différences entre deux protocoles d accès au médium, il est inutile et même contraignant de travailler à un grain trop fin. Par contre, pour étudier les performances de telle ou telle technique de modulation, il est nécessaire de pouvoir modifier la modulation sans avoir à redévelopper l intégralité de la chaîne de transmission. B. Matériel disponible Le matériel disponible dans le cadre de ce projet est fourni par la plate-forme OCAE (Objets Communicants et Applications Embarquées) du CIME-Nanotech de Grenoble. Les cartes programmables pour la mise en place du système sont des cartes Digilent XUPV2P intégrant un FPGA Xilinx Virtex2Pro, une barrette de mémoire RAM DDR 512Mo et de la connectique. Le Virtex2Pro est un FPGA de taille moyenne, embarquant 2 PowerPC405 cadencés à 300MHz. Sont également disponibles des processeurs synthétisables MicroBlaze, pouvant être cadencés à un maximum de 150MHz. Ces cartes sont extensibles facilement grâce à de la

2 connectique spécifique. Du matériel ad-hoc a ainsi été mis à disposition et interfacé avec les cartes : des modules Wireless USB CYWUSB6935 de Cypress et des cartes d évaluation du composant Maxim MAX19713 (Front-End radio, permettant en particulier de traiter les signaux IQ du WiFi (802.11b)). La plate-forme dispose également de nombreux appareils de mesures, parmi lesquels des oscilloscopes pour l étude des signaux analogiques générés et reçus, et des analyseurs de spectre pour l étude de l occupation des fréquences. C. Solution : architecture du système Fig. 1. Architecture : interfaces Pour répondre au problème, une architecture matérielle/logicielle à base de blocs logiques semble la mieux adaptée. Deux niveaux de blocs ont été proposés. Tout d abord, des «macro-blocs», correspondant en fait aux différentes couches du modèle Internet qui nous intéresse ici : la couche physique, la couche de liaison de données, et les couches réseaux et applications. Les couches supérieures étant déjà implémentées, il était préférable ici de prendre les solutions les plus standards possible, et il a donc été décidé d utiliser un noyau Linux porté sur la carte XUPV2P. Ce noyau a l avantage d être connu par beaucoup de développeurs, et permet d offrir aux utilisateurs un environnement standard, même si parfois peu familier, pour contrôler la carte. Ce macrobloc n est pas découpé en blocs de grain plus fin. En effet, l objectif n est pas d expérimenter sur les couches hautes. Les couches inférieures, dépendantes de la norme utilisée, sont développées pour répondre à nos besoins. Pour fonctionner et offrir la modularité nécessaire, il a fallu de définir correctement les APIs logicielles et les interfaces matérielles permettant de relier ces différentes couches. On distingue deux macro-blocs. D abord, un macro-bloc liaison de données, plus communément appelé couche MAC. Ce bloc est divisé en 3 sous parties : deux blocs d interface et un bloc de protocole. Ce macro-bloc est défini plus précisément dans la partie traitant du logiciel. Le second macro-bloc correspond à la couche physique. Ce bloc comporte un bloc d interface, développé en logiciel, et une multitude de blocs de traitement, qui, une fois reliés entre eux, permettent d obtenir une chaîne de traitement numérique. Grâce à la définition d une interface matérielle unique, chaque bloc est indépendant, ce qui permet de construire une chaîne par assemblage. Cette couche est détaillée dans la partie décrivant le matériel utilisé. D. Communication interne Une telle architecture en blocs impose des interfaces entre blocs définies précisément, tant au niveau matériel qu au niveau logiciel. Les interfaces de niveau matériel pour les blocs de traitement de la couche physique ont été développés entièrement, et sont présentés dans la partie traitant du matériel dans le système. Les interfaces entre macroblocs, elles, font partie de l architecture. Deux interfaces nous intéressent ici : l interface MAC/Linux et l interface MAC/PHY. Chacune de ces interfaces requière une étude séparée, les besoins n étant pas les mêmes. L interface MAC/PHY, par exemple, a des besoins temps réel que l on ne retrouve pas dans l interface MAC/Linux. Ces besoins temps-réel nous ont poussé vers une interface à base de liens rapides de type FIFO, pour l interface MAC/PHY. Le Linux et la couche MAC ont eux besoin de persistance dans les données, une communication à base de mémoire partagée a été adoptée. Une interface à base de DMA est envisageable, mais plus complexe à implanter. Au niveau logiciel, les APIs sont également différentes, car liées à l architecture matérielle. Ainsi, l interface MAC/Linux utilise des registres/variables partagés, et un système de signalisation par interruption. Par contre, l API MAC/PHY ne peut être implémentée de la même manière, les contraintes temps réel ne supportant pas le surcoût occasionné. Un système de scrutation sur les FIFO et de commandes prédéfinies est donc mis en place. Enfin, une interface logicielle est nécessaire pour le contrôle des blocs matériels de traitement de la couche PHY. Cette «interface», définie dans les normes IEEE, s appellent le PLCP (Physical Layer Convergence Protocol), et sert en fait à offrir aux couches supérieures une API indépendante des techniques de transmission

3 utilisées. A. Retour sur le CSMA/CA III. PARTIES LOGICIELLES Comme défini dans l architecture, les parties logicielles concernent essentiellement les couches hautes, ainsi que la couche de convergence (PLCP). Le plus gros effort de développement a été fait sur la couche MAC et sur l implantation d un protocole d accès au médium appelé CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance). Le CSMA/CA est une évolution du CSMA axée sur les réseaux sans fil. La version filaire, appelée CSMA/CD, ne pouvait pas convenir du fait des caractéristiques du médium utilisé. Le CSMA/CD se base en effet sur la détection des collisions par la mesure de la puissance : si la puissance mesurée est supérieure à la puissance attendue, deux émissions ont eu lieu en même temps. Dans le cas des réseaux sans fils, la forte atténuation de la puissance du signal fait qu un émetteur ne peut mesurer ces différences, le signal qu il émet écrasant complètement les autres signaux. Plutôt que de détecter les collisions, le CSMA/CA a pour objectif de les éviter. Ceci se fait par l intermédiaire de temps d attente «aléatoires». Fig. 2. Fonctionnement du CSMA/CA B. Linux embarqué Pour pouvoir utiliser le système, il est nécessaire d offrir à l utilisateur une interface avec un système d exploitation connu pour pouvoir le contrôler. Plusieurs solutions existent. La plus courante utilise le système comme une carte réseau et se branche sur un PC hôte comme un périphérique, par USB ou PCI. Le Virtex2Pro a l avantage d offrir deux PowerPC405 en matériel à l utilisateur, et un noyau Linux 2.4 avait déjà été porté sur ce processeur avec l architecture Xilinx. Il a donc été décidé d offrir à l utilisateur un système complet, avec la partie réseau et le système d exploitation tournant sur la carte, donnant lieu à la création d un système embarqué Fig. 3. Architecture logicielle du système complet. Selon les besoins, deux variantes de l environnement sont disponibles, différenciées par le type de partition racine. En effet, la solution la plus simple utilise la technologie NFS pour monter une partition racine disponible sur une machine hôte. Cette solution permet d inclure dynamiquement des modifications depuis le PC hôte (la compilation n étant pas possible depuis la carte), et de conserver les modifications. Par contre, l utilisation d une partition NFS nécessite une connexion réseau active avant le lancement réel du système, ce qui peut être bloquant pour certaines manipulations (par exemple, la mise en place d un point d accès WiFi avec un bridge reliant l interface sans fil et l interface Ethernet). Une deuxième solution a donc été implémentée. Cette solution utilise une partition racine chargée en mémoire vive au démarrage. Elle présente certains désavantages, principalement le temps de chargement et la volatilité des modifications. Elle ne permet pas non plus de modifications dynamiques depuis la machine hôte : les modifications doivent être inclues puis le noyau recompilé pour les prendre en charge. Par contre, elle offre des avantages non négligeables en termes de performance, et permet de se passer du réseau au démarrage du système. L environnement standard offert reste cependant le même dans les deux cas (même noyau et mêmes outils). Les outils installés sont les outils de base pour un Linux axé réseau : les outils de configuration ifconfig, iwconfig, arp, traceroute, ping, brctl,... Des commandes plus spécialisées sont disponibles, telles

4 Fig. 4. Automate du CSMA/CA D. MadWiFi L interface logicielle entre la couche MAC et les couches supérieures a déjà été explicitée, mais elle ne suffit pas dans notre cas. Il faut en effet ajouter l interface avec le Linux. Toujours dans un souci de normalisation, le système utilise un driver répandu appelé MadWiFi, développé à la base pour supporter les chipsets WiFi de type Atheros. Ce driver est organisé en plusieurs modules Linux, parmi lesquels un module appelé HAL qui offre une API aux autres modules pour le contrôle du matériel. L implantation de l interface revient donc à implémenter cette HAL en utilisant nos spécifications. L utilisation de MadWiFi permet de se concentrer sur les parties nous intéressant ici. Cependant, le développement dans MadWiFi peut se révéler ardu. que wget ou dhcpcd. Le noyau est compilé avec le support pour la plupart des manipulations fines du réseau, telles que le bridging ou les VLANs, et avec le support de la cryptographie pour le cryptage des données (WEP ou WPA). Un «sniffeur» de réseau est également installé pour capturer et étudier les paquets en transit (tcpdump). C. Couche MAC Le développement de la couche MAC comporte en fait deux parties principales : la partie CSMA/CA décrite plus haut, qui définit le protocole d accès au médium, et la partie «paquet», qui gère la mise en forme des données dans un format défini par la norme. Dans notre système, la partie de gestion des paquets est faite dans le driver MadWiFi (présenté plus bas), ce qui permet de ne s intéresser qu au protocole d accès. Le développement de la couche MAC impose des contraintes de type temps réel fortes. En effet, la notion de priorité est omniprésente, et les contraintes temporelles imposées par les normes forcent à répondre dans des temps très courts à certaines requêtes. Par exemple, dans le cas du WiFi, le temps entre la réception du paquet et l acquittement de ce paquet est de 10μs, avec une marge d erreur de 10%. Le protocole actuellement disponible est de type CSMA/CA, avec quelques modifications sur les temporisations préconisées dans le WiFi. Ce protocole est en fait une machine à état, d un point de vue algorithmique. De nouveaux protocoles peuvent facilement être réimplémentés en utilisant les interfaces disponibles : seul le coeur de l algorithme doit être réimplémenté, permettant une expérimentation simplifiée. E. Test du logiciel : CYWUSB6935 Pour tester ces différentes parties logicielles, il peut être utile d utiliser une couche physique existante. Pour se faire, le module Cypress CYWUSB6935 est d une grande utilité. En effet, il offre, via une interface SPI, un système de transmission complet : il suffit de le configurer au début, puis on écrit dans des registres les octets à envoyer. Un système d interruption permet de connaître l état du système. Dans la configuration utilisée, le module peut atteindre un débit binaire de 16kb/s, soit 2ko/s. Le débit utile obtenu dans la version stable actuelle est de 1,40ko/s, avec comme test un transfert d un fichier de 116ko par FTP. IV. PARTIES MATÉRIELLES A. Architecture de la couche physique La couche physique a pour fonction de transmettre les paquets reçus de la couche MAC sur le médium et vice versa. Elle génère les signaux analogiques pour l émission et les traite dans le cas de la réception. Une grande partie de sa tâche relève du traitement du signal et nécessite donc une importante puissance de calcul pour être effectuée en logiciel. Les ressources permettant d exécuter du logiciel disponibles sur le Virtex2Pro n étant pas suffisamment puissantes, le traitement est effectué en grande partie dans des blocs matériels de calcul développés en VHDL. La couche physique est ainsi constituée d un processeur MicroBlaze, appelé «PLCP», et de deux chaînes de traitement formées de plusieurs blocs de calculs, une pour l émission et l autre pour la réception. Chacune

5 une autre chaîne de traitement. L interface d entrée et de sortie d un bloc est prédéfinie et de cette manière, il suffit d implémenter ces interfaces pour développer un nouveau bloc. Fig. 5. Couche PHY des deux chaînes de traitement est reliée au MicroBlaze et au bloc matériel s interfaçant avec les convertisseurs Numérique-Analogique et Analogique-Numérique, par exemple le composant Maxim 19713, connectés a la carte XUPV2P. Ces chaînes de traitement sont entièrement contrôlées par le MicroBlaze. Chaque bloc de traitement qui nécessite une configuration via des registres est doté d un accès à un bus permettant au MicroBlaze de lire et écrire dans ces registres. De plus, un composant d initialisation connecté sur ce même bus permet de déclencher une ré-initialisation complète d une chaîne de traitement, ce qui est nécessaire avant toute émission ou réception. Une chaîne de traitement ressemble donc à un pipeline, où chaque bloc de calcul est un étage, cela permet d atteindre des débits bien plus important qu en logiciel et nécessaires pour respecter les standards de réseaux sans fil. Pour la norme b, le WiFi, il faut en effet échantillonner les signaux analogiques à au moins 11 MHz. Comme dit précédemment l intérêt d une telle architecture est son efficacité, celle-ci est aussi aisément modifiable même si cela ne peut être fait en modifiant uniquement la partie logicielle. Pour apporter des modifications à la chaîne de traitement, il suffit d ajouter et/ou de supprimer des blocs dans l architecture, de recompiler celle-ci et de la charger dans le Virtex II Pro. Chaque bloc étant basique et parfois configurable par registre, la plupart des blocs peuvent être réutilisés pour réaliser B. Aiguillage des données Une contrainte supplémentaire est introduite par les normes : plusieurs modulations peuvent être utilisées lors d une transmission. Cela correspond par exemple aux différents débits proposés par la norme b (le WiFi) : 1, 2, 5.5 ou 11 Mbits/s. Il est donc nécessaire de pouvoir changer le traitement qu effectue la chaîne et cela en temps réel car il doit être possible de passer d une modulation à une autre à un instant précis. Ce problème est résolu en introduisant des aiguilleurs dans la chaîne de traitement permettant ainsi d orienter les données vers ou depuis un bloc de calcul choisi. Pour pouvoir changer de traitement a un instant donné, un mécanisme d étiquetage est introduit. Chaque donnée de la chaîne se voit affectée un «ID» unique qui est utilisé pour l identifier. Les aiguillages sont programmables : il est possible de leur ordonner de changer l aiguillage des données lorsqu un certain ID est détecté. Ainsi le MicroBlaze peut contrôler quel traitement est effectué en anticipant les changements à faire et en programmant les aiguillages. C. Domaines d horloge Un autre problème est posé par la fréquence d échantillonnage des convertisseurs analogiquenumérique (CAN) et numérique-analogique (CNA). En effet celle-ci dépend de la fréquence des signaux analogiques générés ou traités et fixe aussi la fréquence de l interface avec ces convertisseurs, à savoir un bus parallèle. Les blocs voisins de cet interface sont donc obligatoirement cadencés à cette fréquence tandis que les blocs voisins du MicroBlaze doivent être cadencés à la fréquence de ce dernier. Il est donc nécessaire d ajouter des FIFOs bisynchrones entre certains blocs permettant de séparer les domaines d horloges de la chaîne de traitement. De plus chaque bloc nécessitant une liaison sur le bus du MicroBlaze intègre une interface de synchronisation puisque la fréquence du bus n est pas forcément celle du bloc. D. Implantation du WiFi Le développement de la couche physique a été orienté vers la norme b (norme WiFi), et plus précisément sur les deux premiers débits définis : 1et2Mbits/s. La modulation est divisée en deux parties.

6 Fig. 6. Chaîne de traitement pour l émission La première partie consiste à moduler les données en symboles. Les symboles sont des phases et ils codent 1 ou 2 bits suivant le débit voulu (1 ou 2 Mbits/s). Un symbole vaut 0 où π quand il code 1 bit et il vaut 0, π/2, π ou 3π/2 quand il code 2 bits. La modulation est différentielle, ce qui signifie que la phase d un symbole est relative à celle du symbole précédent et non absolue. La deuxième partie reprend les symboles précédents, et duplique chacun 11 fois suivant la séquence de Barker suivante :1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1. Un1 signifie que le symbole n est pas modifié et un 1 signifie que le symbole est inversé. Une fois la séquence de Barker appliquée, le débit des symboles est de 11 millions de symboles par seconde quel que soit le débit de données initial. Ces symboles sont ensuite transmis à un convertisseur analogique numérique. La figure 6 montre la chaîne de traitement pour l émission. La chaîne de traitement pour la réception est similaire. Le passage vers et depuis les signaux analogiques I et Q se fait grâce au composant MAX19713 qui est connecté via sa carte d évaluation à la carte XUPV2P. Fig. 7. Développement Linux/MAC/PLCP V. EXPÉRIMENTATIONS Les figures 7 et 8 présentent la mise en œuvre du prototype. Sur la figure 7, on peut distinguer l environnement de développement Linux, les deux cartes XUPV2P, les modules RF Cypress, et des trames circulant sur l oscilloscope. C est l environnement qui a été utilisé pour développer la couche MAC en lien avec le Linux d un coté et le PLCP de l autre. La figure 8 montre les deux convertisseurs IQ, connectés en filaire, attaqués par les éléments matériels et logiciels implantant la couche PLCP, avec un symbole après étalement de spectre circulant sur les fils analogiques. La totalité du développement des blocs matériels et logiciels s effectue dans un environnement Linux, y compris la programmation des cartes. VI. CONCLUSION Cet article illustre les possibilités qu offrent les FPGA intégrant des processeurs : il est maintenant possible d intégrer des systèmes complets réalisant des fonctions radio complexes couvrant la totalité de la transmission numérique. Ces systèmes incluent des aspects Fig. 8. Dévelopement PLCP/PHY logiciels, numériques et même analogiques à de faibles coûts, et les rendent ainsi tout à fait utilisables dans le cadre de travaux pratiques ou de projets d intégration matériel/logiciel, de transmission numérique ou de réseau. Néanmoins, il est nécessaire de concevoir dès le départ ces plates-formes en ayant en tête le public visé, afin que l investissement dans des développements aussi complexes et longs puisse effectivement être mis en mis en œuvre par l utilisateur final.