Une plate-forme d`expérimentation multiprocesseur pour les

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écommunica-
tions 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 req-
uises, 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 principale-
ment 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 plate-
forme d’expérimentation ouverte, sur laquelle ils peu-
vent modifier l’ensemble de la chaîne de réception, de
l’émission des signaux Iet 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 nom-
breuses et variées. En effet, le nombre de normes ex-
istantes 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 con-
traintes de modularité. En effet, la plate-forme étant
destinée à un but éducatif et de recherche, il est néces-
saire 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 Communi-
cants 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
CIME
P28

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
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 2.4.26 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é.
Fig. 1. Architecture : interfaces
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 macro-
blocs, 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 persis-
tance 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 Pro-
tocol), et sert en fait à offrir aux couches supérieures
une API indépendante des techniques de transmission
CIME
P28

utilisées.
III. PARTIES LOGICIELLES
A. Retour sur le CSMA/CA
Comme défini dans l’architecture, les parties logi-
cielles 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 Ac-
cess/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 tech-
nologie 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 recom-
pilé 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
CIME
P28

Fig. 4. Automate du CSMA/CA
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 con-
traintes 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éim-
plémenté, permettant une expérimentation simplifiée.
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.
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
CIME
P28

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 802.11b, 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 ar-
chitecture 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 modi-
fications à 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
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.
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 802.11b (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 pro-
grammables : 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 analogique-
numé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 802.11b (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.
CIME
P28