vient et part vient et part

7/28/2019 vient et part vient et part

1/138

THSEPour obtenir le grade de

DOCTEUR DE LUNIVERSIT DE GRENOBLESpcialit : Informatique

Arrt ministriel : 7 aot 2006

Prsente par

Pierre-Henri Horrein

Thse dirige par Frdric Ptrotet encadre par Christine Hennebert

prpare au sein du CEA/LETI et du TIMAet de lcole Doctorale Mathmatiques, Sciences et Techniques delIngnieur, Informatique

Architectures logicielles pour laradio flexible : intgration dunitsde calcul htrognes

Thse soutenue publiquement le 10 janvier 2012,devant le jury compos de :

M. Olivier SentieysProfesseur des Universits, ENSSAT, Prsident

M. Tanguy RissetProfesseur des Universits, INSA Lyon, Rapporteur

M. Christophe MoyProfesseur, Suplec Rennes, Rapporteur

M. Jean-Luc DangerDirecteur dtudes, Tlcom ParisTech, Examinateur

M. Franck RousseauMatre de Confrences, Grenoble INP, Examinateur

M. Frdric PtrotProfesseur des Universits, Grenoble INP, Directeur de thse

Mme Christine HennebertDocteur, CEA, Encadrante

tel00680080,v

ersion1

17Mar2012
http://hal.archives-ouvertes.fr/http://tel.archives-ouvertes.fr/tel-00680080


2/138

tel00680080,v

ersion1

17Mar2012


3/138

RemerciementsLa thse est un travail personnel, mais beaucoup de monde y participe. Jaimerais citer dans

ces remerciements toutes les personnes qui ont rendu ce travail possible. Cependant, elles sontnombreuses, et je demande pardon par avance ceux que je ne pourrai pas citer. Jaimerais toutdabord remercier mes deux rapporteurs, Tanguy Risset et Christophe Moy davoir accept desacquitter de cette tche consommatrice en temps. Leurs remarques judicieuses sur mon travailavant et pendant la soutenance mont forc creuser et largir mon champ de vision. Je remerciegalement les membres du jury, Olivier Sentieys, Franck Rousseau, et Jean-Luc Danger davoirfait le dplacement jusqu Grenoble pour ceux qui ny taient pas, et davoir pris le temps desintresser mon travail.

Jai eu la chance dtre soutenu avant et durant cette thse par mon directeur de thse,Frdric Ptrot. Mme si la thse est un objectif depuis longtemps, il ma montr ce qutaitla recherche et ma remotiv (sans le savoir) lors de mon premier stage avec lui en 2007. Je laiparfois trop sollicit, mais il a toujours rpondu prsent, mme quand le temps lui manquait. Demme, Christine Hennebert ma encadr au CEA durant cette thse, et je len remercie. Elle asu juguler ma tendance papillonner, et ma permis de rester sur des rails plus ou moins droitsmalgr les difficults, et a na pas t vident.

Jai pu mappuyer sur deux laboratoires durant ma thse. Du ct du CEA, lquipe LASP,mon quipe de rsidence devenue ANP au cours de ma thse, ma chaleureusement accueilli dsmon arrive. Certaines personnes ont cependant eu plus dinfluence que dautres. Dimitri Kt-

nas, bien quextrieur lquipe ma offert la possibilit de travailler sur son simulateur et mapermis davancer dans la direction que javais prise lpoque. Xavier Popon ma consacr dutemps pour le support sur la carte Magnet. Dominique Noguet ma soutenu dans mes dmarchesadministratives et ma judicieusement conseill sur les directions prendre tout au long de maprsence au CEA. Manuel Pezzin, par ses conseils, ses avis, et sa bonne humeur ma grandementaid surmonter mes moments de petite forme. Florian Pebay-Peyroula ma accueilli dans sonbureau. Jai beaucoup apprci nos discussions, quelles soient scientifiques ou non, et jesprepouvoir continuer travailler avec lui. Pour nos discussions (pas forcment professionnelles) tardle soir, je remercie galement Roselin. Finalement, une bonne ambiance au travail est primor-diale pour avancer et lquipe Ptit-Dj a fortement contribu cette ambiance. Je remercie doncAlexandre, Yanis, Ccile, Mathilde, Jessie, Philippe, et Stphanie (et Manuel et Florian, une fois

de plus !), ainsi que Claire, arrive aprs le Ptit-Dj. Ces remerciements dpassent bien sr lecadre strictement professionnel.

Mme si dans les faits, je ntais pas rellement dans le laboratoire TIMA, je me suis toujourssenti bienvenu dans lquipe SLS, pour les quelques runions de groupe auxquelles jai particip,ou juste pour un th. Les personnes du groupe que jaimerais remercier individuellement, en plusde mon directeur de thse, sont plus des amis que des collgues. Donc, au TIMA et pas seulement,je remercie tout particulirement Olivier Muller. Son soutien scientifique, son oreille attentive, sesconseils aviss (sans oublier son chat !) mont t dun grand secours. Merci galement de mavoirdonn lopportunit de participer au projet C. Cette exprience, bien qupuisante, aura t bn-fique. Nicolas Fournel et Damien Hedde mont support la maison durant ces dernires annes(et il faut du courage !). Nos soires (nuits/week-ends) Vorbis, nos discussions vidoludiques, nos

randonnes, et finalement les conseils de Nicolas et le paralllisme temporel de la thse de Damienet de la mienne ont t un soutien bienvenu.

Finalement, mme sans aucun lien avec le travail, certaines personnes ont particip au bon

iii

tel00680080,v

ersion1

17Mar2012


4/138

REMERCIEMENTS REMERCIEMENTS

droulement de cette thse. Pour cela, je remercie Catherine, qui ma support et soutenu du-rant toute cette dernire anne de thse, malgr les difficults de sa propre thse. Cline, pourson soutien inconditionnel et les preuves traverses ensemble, sera toujours importante. Merci

finalement Guillaume et Juliette qui restent proches mme sils sont loins, et Sylvain, moinsloin et aussi proche.Et bien entendu, pour mavoir permis den arriver l et mavoir soutenu et entour quels que

soient mes choix, ne les oublions pas : je naurais pas pu y arriver sans le soutien permanent demes parents, de mes frres, et de ma famille. Je nai malheureusement pas la place de tous lesciter, mais je tiens les remercier chaleureusement.

iv

tel00680080,v

ersion1

17Mar2012


5/138

Table des matires1 Introduction 1

2 Problmatique 52.1 Contexte de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Modle rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Chane de communication . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Rseaux flexibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Radio classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Radio reconfigurable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2.1 Vision gnrale . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2.2 Software Radio . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2.3 Software-Defined Radio . . . . . . . . . . . . . . . . . . . . 9

2.2.3 Radio flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Radio cognitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.4.1 Terminal de radio cognitive . . . . . . . . . . . . . . . . . . . 102.2.4.2 Radio opportuniste . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.5 Interactions radio flexible/radio cognitive . . . . . . . . . . . . . . . . . 11

2.2.5.1 Diffrences de terminologie . . . . . . . . . . . . . . . . . . 112.2.5.2 Architecture dun terminal radio . . . . . . . . . . . . . . . . 11

2.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Radio flexible : de multiples possibilits . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Scnarios de reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.1 Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.2 volution des normes . . . . . . . . . . . . . . . . . . . . . . 132.3.1.3 Multimode . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2 De multiples cibles de reconfiguration . . . . . . . . . . . . . . . . . . 132.3.2.1 Cibles logicielles . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2.2 Matriel reconfigurable . . . . . . . . . . . . . . . . . . . . . 142.3.3 Conclusion sur la radio flexible . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Choix de limplantation : volution . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Performance de la radio logicielle . . . . . . . . . . . . . . . . . . . . . 152.4.2 Essor du GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Problmes du GPGPU pour la radio logicielle . . . . . . . . . . . . . . 16

2.5 Environnement de reconfiguration unique . . . . . . . . . . . . . . . . . . . . . 162.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2 Gestion de la reconfigurabilit . . . . . . . . . . . . . . . . . . . . . . . 172.5.3 Intgration de la radio flexible . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.4 Gestion de la reconfiguration . . . . . . . . . . . . . . . . . . . . . . . 182.5.5 Conclusion : besoins dun environnement flexible . . . . . . . . . . . . 19

2.6 Conclusion gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

v

tel00680080,v

ersion1

17Mar2012


6/138

TABLE DES MATIRES TABLE DES MATIRES

3 tat de lart 213.1 Reprsentation dune application radio . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1 Reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1.1 Dfinition gnrale . . . . . . . . . . . . . . . . . . . . . . . 223.1.1.2 Cas de la radio logicielle . . . . . . . . . . . . . . . . . . . . 223.1.2 Reprsentation des applications . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Plateformes de radio logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 Solutions base de processeurs . . . . . . . . . . . . . . . . . . . . . . 233.2.2 Intgration des GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.3 Utilisation de FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.4 Solutions hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.5 Matriel reconfigurable et adaptabilit . . . . . . . . . . . . . . . . . . 25

3.2.5.1 Paramtrisation et oprateurs communs . . . . . . . . . . . . 253.2.5.2 ASIC et SOC . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.6 Conclusion sur les plateformes . . . . . . . . . . . . . . . . . . . . . . 263.3 Environnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.2 Excution htrogne . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.2.1 Acclrateurs matriels . . . . . . . . . . . . . . . . . . . . . 273.3.2.2 Intgration des FPGA . . . . . . . . . . . . . . . . . . . . . . 273.3.2.3 Excution htrogne GPP/DSP . . . . . . . . . . . . . . . . 27

3.3.3 Environnements complets . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3.1 SCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3.2 RMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3.3 GNURadio . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.3.4 P-HAL/Aloe . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.3.5 MVR : Machine Virtuelle Radio . . . . . . . . . . . . . . . . 313.3.3.6 Surfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 Conclusion du chapitre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4 Intgration du GPU dans la radio logicielle 354.1 Introduction : le GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 Origine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.2 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.2.1 Architecture dune plateforme OpenCL . . . . . . . . . . . . 36

4.1.2.2 Format dune application . . . . . . . . . . . . . . . . . . . . 374.1.3 Contraintes et objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Utilisation optimise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.1 Oprations basiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2 Oprations complexes : premire approche . . . . . . . . . . . . . . . . 404.2.3 Proposition : maximisation de lutilisation . . . . . . . . . . . . . . . . 41

4.2.3.1 Paralllisation grain fin . . . . . . . . . . . . . . . . . . . . 414.2.3.2 Paralllisation gros grain . . . . . . . . . . . . . . . . . . . 424.2.3.3 Comparaison . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.1 Efficacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 Latence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.3 Mmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4 Intgration distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

vi

tel00680080,v

ersion1

17Mar2012


7/138


4.4.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.4.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.2.1 Intgration transparente . . . . . . . . . . . . . . . . . . . . . 46

4.4.2.2 Buffer OpenCL . . . . . . . . . . . . . . . . . . . . . . . . . 464.5 Intgration centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5.2 Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5.3 En pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.6 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.1 Synthse des contributions . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.2 Oprations implantes . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.6.2.1 FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6.2.2 Demapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6.2.3 IIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6.3 Protocole dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . 524.6.4 Rsultats des oprations unitaires . . . . . . . . . . . . . . . . . . . . . 53

4.6.4.1 Influence du seuil . . . . . . . . . . . . . . . . . . . . . . . . 534.6.4.2 Influence de la taille des vecteurs . . . . . . . . . . . . . . . . 55

4.6.5 Rsultats pour des applications multitches . . . . . . . . . . . . . . . . 564.7 Perspectives et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.7.1 Discussion : portabilit vers lembarqu . . . . . . . . . . . . . . . . . . 574.7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5 Dfinition dun environnement pour la radio flexible 615.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.1.2.1 Support des units dexcution . . . . . . . . . . . . . . . . . 635.1.2.2 Application, adaptabilit et reconfigurabilit . . . . . . . . . . 63

5.2 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.1 Prsentation gnrale de lenvironnement . . . . . . . . . . . . . . . . . 645.2.2 R-HAL et traducteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2.2.1 Reprsentation et contrle de la plateforme . . . . . . . . . . 655.2.2.2 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2.2.3 Gestion des applications . . . . . . . . . . . . . . . . . . . . 66

5.2.3 Couche protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 Gestion des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.1 Prsentation : flot de dveloppement dune application avec FRK . . . . 675.3.2 Reprsentation dune application . . . . . . . . . . . . . . . . . . . . . 68

5.3.2.1 Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.2.2 Configuration Instance . . . . . . . . . . . . . . . . . . . . . 68

5.3.3 Traduction et implantation de lapplication . . . . . . . . . . . . . . . . 685.3.3.1 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.3.3.2 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 705.3.3.3 Chargement dune application . . . . . . . . . . . . . . . . . 71

5.3.4 Gestion de lexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . 715.3.4.1 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.4.2 Adaptabilit : modification dynamique de la CI . . . . . . . . 725.4 Implantation des cibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.4.1 TaME et extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

vii

tel00680080,v

ersion1

17Mar2012


8/138


5.4.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.4.1.2 Interface : API principale . . . . . . . . . . . . . . . . . . . . 73

5.4.2 Cible logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.4.2.1 Dfinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.4.2.2 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 745.4.2.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 74

5.5 Intgration des coprocesseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.5.1 Dfinition et postulat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.5.2 Reprsentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.5.2.1 Coprocesseur . . . . . . . . . . . . . . . . . . . . . . . . . . 765.5.2.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.5.3 Fonctionnement de la cible coprocesseur . . . . . . . . . . . . . . . . . 775.5.3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.5.3.2 Config Switch . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5.3.3 Ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . 785.5.3.4 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 785.5.3.5 Exemple : le codeur . . . . . . . . . . . . . . . . . . . . . . . 79

5.6 FRK en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.6.1 tat de FRK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.6.2 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.6.2.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.6.2.2 RTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.6.3 Exemple du codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . 815.6.3.1 Prsentation du programme . . . . . . . . . . . . . . . . . . . 815.6.3.2 Excution logicielle . . . . . . . . . . . . . . . . . . . . . . . 82

5.6.3.3 Excution matrielle : une seule application . . . . . . . . . . 835.6.3.4 Excution matrielle : deux applications . . . . . . . . . . . . 845.6.4 Exemple complet : IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 87

5.6.4.1 Prsentation du programme et de la plateforme . . . . . . . . 875.6.4.2 Fonctionnement BPSK . . . . . . . . . . . . . . . . . . . . . 885.6.4.3 Demande dadaptation . . . . . . . . . . . . . . . . . . . . . 88

5.6.5 Quelques chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6 Conclusion 91

A Rsultats complets pour le GPU 95

B Paralllisation dun filtre IIR 99B.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99B.2 Dmonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99B.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

C Prsentation gnrale de linterface de FRK 103C.1 OPM et communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.1.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103C.1.1.1 Opration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103C.1.1.2 Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.1.1.3 CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104C.1.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

C.1.2.1 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

viii

tel00680080,v

ersion1

17Mar2012


9/138


C.1.2.2 Cration de la waveform . . . . . . . . . . . . . . . . . . . . 105C.1.2.3 Traduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

C.2 Interface R-HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

C.2.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106C.2.1.1 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 106C.2.1.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

C.2.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107C.3 TaME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

C.3.1 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108C.3.1.1 Structure dun TaME . . . . . . . . . . . . . . . . . . . . . . 108C.3.1.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108C.3.1.3 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 109

C.3.2 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110C.3.2.1 CI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

C.3.2.2 Oprations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110C.3.2.3 Transferts de donnes . . . . . . . . . . . . . . . . . . . . . . 110C.4 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111C.5 Rsum et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

D Intgration de matriel ddi dans FRK 113D.1 Utilisation de MAGNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

D.1.1 Plateforme MAGNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 113D.1.2 Reprsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

D.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Publications 117

Bibliographie 119

ix

tel00680080,v

ersion1

17Mar2012


10/138


x

tel00680080,v

ersion1

17Mar2012


11/138

Table des figures2.1 Modle OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Exemple de chane de communication type pour un rseau sans fil . . . . . . . . 72.3 Reprsentation dun rcepteur superhtrodyne . . . . . . . . . . . . . . . . . . 82.4 Reprsentation dun rcepteur idal de radio logicielle . . . . . . . . . . . . . . 92.5 Reprsentation dun rcepteur ralisable de SDR . . . . . . . . . . . . . . . . . 102.6 Cycle simplifi dun terminal intelligent [MM99] . . . . . . . . . . . . . . . . . 102.7 Interactions entre radio flexible et radio cognitive . . . . . . . . . . . . . . . . . 122.8 Reprsentation du rapport flexibilit/performance de diffrentes solutions dim-

plantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.9 Architecture de plateforme flexible gnrique . . . . . . . . . . . . . . . . . . . 17

3.1 Reprsentation et reconfiguration hirarchique [DMLP05] . . . . . . . . . . . . 233.2 Architecture de lenvironnement SCA . . . . . . . . . . . . . . . . . . . . . . . 283.3 Architecture gnrale de GNURadio . . . . . . . . . . . . . . . . . . . . . . . . 303.4 Architecture gnrale de P-HAL/Aloe . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Reprsentation dune plateforme OpenCL . . . . . . . . . . . . . . . . . . . . . 374.2 Architecture dune application OpenCL . . . . . . . . . . . . . . . . . . . . . . 384.3 Opration de radio logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4 Opration de radio logicielle sur GPU : approche classique . . . . . . . . . . . . 404.5 Opration de radio logicielle sur GPU : approche propose . . . . . . . . . . . . 424.6 Dbit chantillons en MS/s pour des FFT de 128 points pour diffrents seuils . . 444.7 Implantation distribue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.8 Utilisation de buffers spcifiques pour les GPU . . . . . . . . . . . . . . . . . . 474.9 Implantation centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.10 Protocole dexprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.11 Dbit chantillons en MS/s pour la FFT pour diffrents seuils, taille de vecteur

fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.12 Dbit chantillons en MS/s pour le demapping pour diffrents seuils, taille de

vecteur fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.13 Dbit chantillons en MS/s pour lIIR pour diffrents seuils, taille de vecteur fixe 554.14 Dbit chantillons en MS/s en fonction de N, pour un seuil optimal calcul expri-

mentalement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.15 Rsultats pour une squence doprations, pour un seuil optimal calcul expri-

mentalement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1 Architecture de plateforme flexible gnrique . . . . . . . . . . . . . . . . . . . 625.2 Intgration de Flexible Radio Kernel (FRK) dans une architecture logicielle classique 645.3 Intgration de FRK dans une architecture logicielle classique . . . . . . . . . . . 655.4 Architecture de la PL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5 tapes de chargement dune application FRK . . . . . . . . . . . . . . . . . . . 675.6 Traduction dune opration en utilisant lOPM . . . . . . . . . . . . . . . . . . . 69

5.7 Architecture gnral dun contrleur de cibles . . . . . . . . . . . . . . . . . . . 735.8 Reprsentation dune tche pour la cible logicielle . . . . . . . . . . . . . . . . . 755.9 Codeur convolutif matriel paramtrable . . . . . . . . . . . . . . . . . . . . . . 76

xi

tel00680080,v

ersion1

17Mar2012


12/138

TABLE DES FIGURES TABLE DES FIGURES

5.10 Instance pour le codeur convolutif . . . . . . . . . . . . . . . . . . . . . . . . . 775.11 Implantation de la cible pour le codeur . . . . . . . . . . . . . . . . . . . . . . . 775.12 Automate de slection dune configuration pour le TaME coprocesseur . . . . . . 79

5.13 Plateforme MagNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.14 Application traduite pour une cible logicielle . . . . . . . . . . . . . . . . . . . 835.15 FRK avec deux codeurs, cibles mixtes . . . . . . . . . . . . . . . . . . . . . . . 845.16 FRK avec deux codeurs en matriel . . . . . . . . . . . . . . . . . . . . . . . . 855.17 Reprsentation de ltat du systme . . . . . . . . . . . . . . . . . . . . . . . . 865.18 Application IEEE 802.11 simplifie utilise . . . . . . . . . . . . . . . . . . . . 875.19 Plateforme matrielle pour lapplication IEEE 802.11 . . . . . . . . . . . . . . . 87

A.1 Rsultats complets pour la FFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 95A.2 Rsultats complets pour le demapping . . . . . . . . . . . . . . . . . . . . . . . 96A.3 Rsultats complets pour la IIR . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.1 Diagramme de classe des structures de FRK . . . . . . . . . . . . . . . . . . . . 112

xii

tel00680080,v

ersion1

17Mar2012


13/138

Liste des acronymesAPI Application Programming Interface

ASIC Application Specific Integrated Circuit

ASIP Application Specific Integrated Processor

BSP Board Support Package

CI Configuration Instance

CORBA Common Object Request Broker Architecture

CPU Central Processing Unit

DSP Digital Signal ProcessorDVB Digital Video Broadcasting

FFT Fast Fourier Transform

FIFO First In First Out

FIR Finite Impulse Response

FRK Flexible Radio Kernel

FPGA Field-Programmable Gate Array

GPGPU General Purpose computing on Graphics Processing Unit

GPP General Purpose ProcessorGPU Graphics Processing Unit

GSM Global System for Mobile communications

HAL Harware Abstraction Layer

KPN Kahn Process Network

LDPC Low Density Parity Check

MAC Medium Access Control

NoC Network on Chip

OFDM Orthogonal Frequency Division Multiplexing

OPM Operation to Platform MappingOSI Open Systems Interconnection

OpenCL Open Computing Language

PHY couche PHYsique

PL Protocol Layer

POSIX Portable Operating System Interface for Unix

QAM Quadrature Amplitude Modulation

QPSK Quadrature Phase Shift Keying

R-HAL Radio Hardware Abstraction LayerRTEMS Real-Time Executive for Multiprocessor Systems

RVM Radio Virtual Machine

xiii

tel00680080,v

ersion1

17Mar2012


14/138

LISTE DES ACRONYMES LISTE DES ACRONYMES

SCA Software Communications Architecture

SIMD Single Instruction Multiple Data

TaME TArget Management Element

UMTS Universal Mobile Telecommunication System

WCDMA Wideband Code Division Multiple Access

xiv

tel00680080,v

ersion1

17Mar2012


15/138

Chapitre 1

Introduction

Linformatique daujourdhui est connecte tous les niveaux. Les applications sont de plus enplus externalises, et il devient difficile de trouver des programmes informatiques nutilisantpas les rseaux.

Allant de paire avec les applications, la conception mme des plateformes matrielles intgreles rseaux. Que ce soit les serveurs, les stations de travail, les ordinateurs portables, les tl-phones, . . . La plupart des systmes utilisent aujourdhui plusieurs mthodes daccs aux rseaux.Lvolution des tlphones portables est reprsentative de cette connectivit accrue. Ils permettentde se connecter au rseau tlphonique 1, peuvent utiliser le Bluetooth pour se connecter des p-riphriques ou un ordinateur, et ont galement souvent accs un rseau WiFi. Tous ces rseauxsont des rseaux sans fil, qui utilisent les ondes lectromagntiques comme support. Ils voluentrgulirement, de nouveaux voient le jour, certains ne sutilisent plus.

Contexte : la radio logicielle

Intgrer une norme rseau dans une plateforme matrielle requiert lintgration de plusieurslments :

une antenne adapte londe utilise pour la norme ; un systme de modulation et de dmodulation, qui permet de moduler le signal en bande

de base sur la porteuse lmission, et deffectuer lopration inverse pour la rception. Cesystme est gnralement en partie analogique et en partie numrique ;

une chaine doprations, appele couche PHYsique (PHY), qui transforme lmission lasuite de bits envoyer en un signal en bande de base selon des caractristiques propres lanorme. A la rception, une chaine doprations duale effectue le traitement inverse afin derestituer la squence de bits mise ;

un protocole, appel couche Medium Access Control (MAC), qui dfinit quelle suite de bitssera envoye quel moment sur quel canal. La couche MAC reoit les donnes du rseau etles transfre la couche physique.

Les Application Specific Integrated Circuit(ASIC) sont communment utiliss pour supporterune norme de communication dans un terminal radio. Un terminal radio contient autant de p-riphriques matriels quil y a de rseaux auxquels il est susceptible de se connecter. Lutilisationde priphriques matriels permet actuellement datteindre les performances requises en termesde taille, de consommation et de dbit.

Alors que la multiplication des normes supportes par un simple systme gnre une aug-mentation de la surface de silicium requis par les ASIC, que de nouvelles normes arrivent sur lemarch rgulirement, que toutes ces normes sont sujettes de nombreuses volutions et mises jour, la notion de flexibilit sinvite dans la rflexion concernant la conception des futurs sys-tmes communicants. On ne veut pas seulement implanter des rseaux de manire performante,et en limitant la consommation dnergie. On veut pouvoir faire voluer ces rseaux, et les im-planter de manire intelligente. Cette flexibilit peut sappuyer sur diffrents types de circuits :

1. ce qui reste tout de mme leur fonction premire

1

tel00680080,v

ersion1

17Mar2012


16/138

CHAPITRE 1. INTRODUCTION

logiciel sur processeurs (gnralistes ou non), matriel paramtrable, Field-Programmable GateArray (FPGA), . . .

La notion de flexibilit recouvre plusieurs aspects. Elle permet de grer la coexistence, voire

la coopration entre units de calcul htrognes. Mais, au-del de cette possibilit offerte auxfuturs systmes, elle permet aussi doffrir aux systmes une forme dintelligence dans leurs capac-its dadaptation leur environnement. Ces capacits dadaptation peuvent servir pour diffrentsobjectifs :

changer les paramtres intrinsques dun codeur pour sadapter aux dfaillances du canal etrduire les erreurs ;

changer de norme en fonction de la distance lmetteur, du dbit requis ; teindre des lments qui ne servent pas et les r-allumer ds que ncessaire ; utiliser une puce unique pour excuter diffrentes normes, potentiellement en concurrence

(multimode).Cette liste nest pas exhaustive.

Si lutilisateur peut souhaiter mettre jour certaines caractristiques de son systme en fonc-tion de ses besoins, il ne veut pas que sa communication soit coupe parce que le codeur changede paramtres ou que le systme a dtect quil peut communiquer avec une norme plus conomeen nergie. La capacit du systme sadapter doit donc tre intgre tout en conservant la qualitdu service offerte lutilisateur. La notion de flexibilit prend lallure dun dfi pour les systmes venir.

Problmatique gnrale et contributions

La flexibilit ultime en informatique reste le logiciel. Cependant, la radio logicielle reste ex-primentale, utilisable uniquement avec des processeurs puissants, des plateformes ddies, ou

des normes requrant peu de calculs. On peut galement se demander si cest vraiment un objectif atteindre. La recherche ne seffectue plus rellement au niveau de la radio logicielle mais dudveloppement des processeurs, puisquon peut difficilement rduire le nombre minimal dopra-tions requises pour une norme. En attendant lmergence de processeurs suffisament puissants quinarriveront peut tre pas, dautres solutions peuvent tre utilises qui permettent dj une certaineflexibilit. Elles se basent sur lutilisation dunits de calcul htrognes. On peut par exempleenvisager lutilisation de processeurs spcialiss, que ce soit des Application Specific IntegratedProcessor(ASIP) ou des Digital Signal Processor(DSP). Nous tudions dans cette thse une unitassez rcente pour ce type de calculs, le Graphics Processing Unit(GPU). Ces units proposentune puissance de calcul norme (de lordre du TFlop/s pour les plus puissants !), mais sont basessur une architecture complique exploiter. Nous verrons comment on peut en bnficier.

Mais des units matrielles sont galement utilisables. Ces units sont conues pour raliserune opration donne, mais sont paramtrables pour pouvoir modifier leur fonctionnement. Cer-tains coprocesseurs Fast Fourier Transform (FFT), par exemple, peuvent calculer des transformespour diffrents nombres de points. On peut aussi dfinir des encodeurs ou des dcodeurs canal pro-grammables. De plus en plus darchitectures matrielles voient le jour qui permettent une certaineflexiblit. Ces architectures sont htrognes, cest--dire quelles utilisent des units diffrentes.Elles ne permettent pas de tout faire, mais sont tout de mmes capables de balayer des ensemblesassez large de possibilits, en utilisant le plus possible les acclrateurs, et en compensant en logi-ciel les lments non ralisables en matriel. Le problme des plateformes htrognes rsidentdans la difficult les utiliser. Une plateforme logicielle est dans un sens simple programmer,mme si le systme qui permet de la contrler est complexe. On fournit du code, et quelle que soit

la plateforme qui lexcutera, on pourra conserver le mme code. Les possibilits de plateformeshtrognes sont beaucoup plus nombreuses, parce quon peut mettre les acclrateurs que lonveut, pour les oprations que lon veut. Il y a une infinit de possibilits. Nous nous intressons

2

tel00680080,v

ersion1

17Mar2012


17/138


ces plateformes htrognes dans cette thse, en proposant un environnement capable dabstrairenimporte quelle unit, et en proposant une mthode originale de gestion des units matriellesparamtrables.

Plan de la thse

Cette thse est ordonne en 6 chapitres. Le premier chapitre est cette introduction.Le chapitre 2 prsente la problmatique de la radio flexible et de cette thse en gnral et les

points particuliers sur lesquels portent nos travaux.Le chapitre 3 est ddi ltat de lart. Nous prsentons plusieurs travaux raliss dans le do-

maine de la radio flexible, qui ont aliment notre rflexion. Nous nous attardons sur les plateformesradio htrognes tudies par dautres quipes de recherche.

Le chapitre 4 est consacr lutilisation du GPGPU pour la radio flexible. La conception duneapplication radio base de GPU et son intgration dans une chaine de communication logicielle

sont tudies thoriquement. Des exprimentations sont menes et les rsultats sont prsents etanalyss.

Le chapitre 5 dtaille un nouvel environnement de radio flexible ralis pendant cette thse.Lenvironnement et ses enjeux sont prsents avant daborder des aspects prcis comme la gestiondes units dexcution htrognes, lintgration dunits matrielles ou limpact du contrle surles applications. Des cas pratiques dutilisation de lenvironnement sont ensuite proposs.

Finalement, les conclusions gnrales de cette thse sont donnes dans le dernier chapitre.Celui-ci souvre sur des perspectives de complments, damliorations ou dvolution des travauxeffectus, et du domaine en gnral.

Quatre chapitres dannexe sont galement joints. Lannexe A contient les rsultats numriquescomplets pour lutilisation du GPU dans la radio flexible.

On donne la dmonstration dans lannexe B de la correction dune implantation parallle dunfiltre rcursif.

Lannexe C prsente de manire plus dtaille linterface de lenvironnement dfini dans lechapitre 5.

Finalement, lannexe D donne des dtails dimplantation de FRK pour lutilisation avec dumatriel ddi.

3

tel00680080,v

ersion1

17Mar2012


18/138


4

tel00680080,v

ersion1

17Mar2012


19/138

Chapitre 2

Problmatique

Dans ce chapitre, nous abordons diffrents problmes lis la radio flexible. Comme nousavons pu le voir dans lintroduction, la notion de flexibilit est prendre en compte lors dela conception dun terminal radio. Cette flexibilit nest cependant pas exempte dinconvnients,en particulier au niveau de lintgration. Nous donnons ici une dfinition plus prcise de la radioflexible, et nous discutons ensuite les axes adresss dans ces travaux de thse.

2.1 Contexte de la thse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Modle rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Chane de communication . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Rseaux flexibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Radio classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Radio reconfigurable . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 Radio flexible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4 Radio cognitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.5 Interactions radio flexible/radio cognitive . . . . . . . . . . . . . . . . 112.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Radio flexible : de multiples possibilits . . . . . . . . . . . . . . . . . . . . 122.3.1 Scnarios de reconfiguration . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.2 De multiples cibles de reconfiguration . . . . . . . . . . . . . . . . . 132.3.3 Conclusion sur la radio flexible . . . . . . . . . . . . . . . . . . . . . 15

2.4 Choix de limplantation : volution . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Performance de la radio logicielle . . . . . . . . . . . . . . . . . . . . 152.4.2 Essor du GPGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3 Problmes du GPGPU pour la radio logicielle . . . . . . . . . . . . . 16

2.5 Environnement de reconfiguration unique . . . . . . . . . . . . . . . . . . 162.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2 Gestion de la reconfigurabilit . . . . . . . . . . . . . . . . . . . . . . 172.5.3 Intgration de la radio flexible . . . . . . . . . . . . . . . . . . . . . . 182.5.4 Gestion de la reconfiguration . . . . . . . . . . . . . . . . . . . . . . 182.5.5 Conclusion : besoins dun environnement flexible . . . . . . . . . . . 19

2.6 Conclusion gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5

tel00680080,v

ersion1

17Mar2012


20/138

2.1. CONTEXTE DE LA THSE CHAPITRE 2. PROBLMATIQUE

2.1 Contexte de la thse : les rseaux sans fil

Les travaux raliss durant cette thse se situent la frontire entre les rseaux et larchitecture

des systmes. Afin de pouvoir prsenter la problmatique que nous adressons, il convient de dfinircorrectement larchitecture gnrale dun terminal radio.

2.1.1 Modle rseau

Tout dabord, les normes rseaux actuelles sont divises selon un modle en couche, le modleOpen Systems Interconnection (OSI).

Le modle OSI, prsent dans la figure 2.1, est un modle bas sur 7 couches distinctes, cha-cune des couches tant spcifie pour remplir un objectif bien prcis. Dans un terminal rseau,chacun de ces niveaux est capable de dialoguer avec son quivalent dans un autre terminal. Unniveau donn reoit des requtes de la couche directement au dessus, et met des requtes vers la

couche directement en dessous.

Figure 2.1 Modle OSI

On sintresse principalement aux deux premires couches du rseau, la couche physique (ap-pele PHY), et la couche de liaison de donnes (data link layer). La premire couche est en con-tact direct avec le medium utilis pour la transmission des donnes. Dans le cadre de la radio, cemedium est le domaine des ondes lectromagntiques.

La seconde couche est conue pour permettre le transfert entre deux terminaux du rseau.Elle se divise en deux sous-couches, la couche Medium Access Control (MAC), qui permet degrer effectivement laccs au milieu, surtout dans le cas daccs multiples, et la couche Logical

Link Controller(LLC), qui gre normalement le contrle derreur en plus dautres attributions. Onregroupera par abus de langage sous la mme appellation "MAC" lensemble des lments de lacouche 2.

2.1.2 Chane de communication

La partie physique dun rseau est gnralement reprsente comme une chane de communi-cation, permettant de transposer linformation du domaine numrique au domaine analogique enutilisant des techniques de modulation. Cette chane de communication correspond ce que nousappellerons dans ce mmoire une application radio. Une chane type extrmement simplifie estprsente dans la figure 2.2.

La chane de communication est donc idalement reprsente sous la forme dun graphe.Chaque nud reprsente une tche et les artes qui relient les nuds reprsentent les commu-nications (donnes) entre les tches. Ce graphe peut-tre assimil un pipeline. On peut utiliser

6

tel00680080,v

ersion1

17Mar2012


21/138

CHAPITRE 2. PROBLMATIQUE 2.2. RSEAUX FLEXIBLES

Figure 2.2 Exemple de chane de communication type pour un rseau sans fil

le modle de programmation Synchronous Data Flow pour reprsenter cette application, les ratiosentre les entres consommes et les sorties produites pour chaque tche tant connus.

2.2 Vers des rseaux de plus en plus flexible

La flexibilit devient une notion incontournable des rseaux sans fil [Tut02]. Le terme deflexibilit est utilis, dans ce contexte, pour caractriser un lment du rseau qui nest pas figdans un mode de fonctionnement. Cet lment peut tre le rseau lui-mme, ou bien un terminalrseau, ou encore un lment de ce terminal. Depuis la formalisation de la radio logicielle en1992 [Mit92], la notion de flexibilit dans la radio a pris de lampleur et est maintenant devenueun des principaux domaines de recherche associs aux liaisons sans fil.

Cependant, cette notion de flexibilit est floue. Une multitude de termes se rapportent plusou moins la radio flexible, il est par consquent difficile den donner une dfinition prcise.Nous recensons dans cette partie les termes les plus utiliss, afin de clarifier la rflexion autourdes travaux raliss dans le cadre de cette thse. Nous employons la terminologie utilise dans

[DZD+05].

2.2.1 Radio classique

On dfinit un terminal radio comme un appareil capable dmettre et de recevoir des don-nes modules sur des ondes lectromagntiques du domaine radio-frquentiel (RF). On dfinitune chane de communication radio comme la squence dactions effectuer pour transmettre ourecevoir les donnes. La chane de transmission prend donc en entre un flux de donnes trans-mettre, et fournit en sortie une onde lectromagntique. La chane de rception prend en entrelonde lectromagntique, et fournit en sortie un flux de donnes, qui correspond aux donnestransmises par lmetteur.

Les domaines frquentiels et dimplantation pour un rcepteur superhtrodyne usuel sontprsents en figure 2.3. Le domaine RF est la sortie directe de lantenne. Le rcepteur effectuecouramment un filtrage et une amplification, qui sont plus simplement raliss en analogique.Les rcepteurs superhtrodynes utilisent une frquence intermdiaire (FI), qui sobtient enmlangeant le signal RF un signal issu dun oscillateur local. Ce signal intermdiaire est gale-ment filtr, puis dmodul afin dobtenir le signal en bande de base (BB). Ces oprations sontcouramment ralises en analogique galement. Le signal bande de base est ensuite chantillonn,afin de raliser les oprations suivantes en numriques (synchronisation, demapping, dsentrelace-ment, correction derreur, ...).

Dans une implantation traditionnelle dune chane de communication, tous les lments dela chane sont implants laide de matriel ddi sur ASIC. Cette solution prsente le meilleur

rapport consommation/performance/surface. Elle limite galement la difficult dintgration dansune plateforme complte, puisque les communications ne sont pas la seule fonctionnalit attenduedun systme informatique moderne. Il ny a en effet pas besoin de rajouter de connaissance de la

7

tel00680080,v

ersion1

17Mar2012


22/138

2.2. RSEAUX FLEXIBLES CHAPITRE 2. PROBLMATIQUE

Figure 2.3 Reprsentation dun rcepteur superhtrodyne : implantation et frquences

chane de communication dans le systme, uniquement de grer un priphrique.La multiplication des normes rseaux remet en cause la pertinence de cette approche classique

car la conception de terminaux "multistandards", cest--dire qui supportent plusieurs normes decommunication, imposerait la multiplication dimplantations ddies. Il y a donc une limite rapi-dement atteinte quant au cot de la multiplication des implantations matrielles ddies.

2.2.2 Radio reconfigurable

2.2.2.1 Vision gnrale

Un terminal radio reconfigurable est un terminal qui utilise le mme matriel pour excuterplusieurs chanes de communication diffrentes (les applications radio). On distingue ici deuxproprits :

ladaptabilit [DZD+05][GC97][KH00], qui sapplique plutt la chane de communica-tion, et qui lui permet de sadapter lenvironnement ambiant en faisant varier un ensemblede valeurs connues, comme par exemple le taux de codage ou la constellation de la modu-lation;

la reconfigurabilit [DZD+05][KMR00], qui est une proprit du terminal, et qui dfinitsa capacit modifier en profondeur la structure de lapplication ou des lments qui lacomposent.

Ces deux proprits sont bien sr non exclusives. Lorsquon parle de radio reconfigurable, onsintresse donc des implantations de terminaux radio qui permettent une modification profondede la chane de communication.

2.2.2.2 Software RadioLa radio logicielle ("software radio" en anglais) est une mise en uvre de la radio reconfigu-

rable, dans laquelle les lments qui composent une chane de communication sont implants enlogiciel, et sont donc excuts par des processeurs gnriques [Mit92][Jon05][Tut02].

La radio logicielle reprsente la vision idale de la radio reconfigurable. Lantenne est directe-ment relie un chantillonneur (convertisseur analogique numrique), qui peut fonctionner unefrquence suffisante pour respecter le critre de Shannon-Nyquist, cest--dire

fs 2 fc

avec fc la frquence de londe porteuse, et fs la frquence dchantillonnage. Les modifications de

domaines par rapport la radio classique sont prsents sur la figure 2.4. Il ny a plus de frquenceintermdiaire, toutes les oprations sont ralises directement en numrique, et sur un processeurgnrique (General Purpose Processor(GPP)).

8

tel00680080,v

ersion1

17Mar2012


23/138


Figure 2.4 Reprsentation dun rcepteur idal de radio logicielle

Cependant, dans des systmes radio, on travaille sur des frquences dont lordre de grandeurvarie entre la dizaine de mgahertz (107 Hz), et la dizaine de gigahertz (1010 Hz). Ltat de la

technique sur les chantillonneurs commerciaux permet actuellement datteindre, un prix lev,des frquences de lordre de 3 Gch/s. titre dexemple, les convertisseurs de National Semicon-ductor, sur 8 bits, 3 Gch/s (rfrence : ADC083000CIYB-ND), se vendent aux alentours de 800dollars lunit (en juin 2011). La cible nest donc pas llectronique grand public.

Au-del du problme de lchantillonnage, si on prend la norme WiFi qui opre 2.4 GHz,traiter 4.8 109 chantillons par seconde avec des oprations de traitement du signal complexeest un dfi intressant mais difficile relever avec les capacits de traitement actuelles. Daprsune tude des normes Global System for Mobile communications (GSM) et Universal MobileTelecommunication System (UMTS), [Alh10] estime les besoins en calcul pour le GSM (porteuseautour de 900 MHz) 10 GIPS, et pour lUMTS (mme porteuse) 100 GIPS. On notera que lestudes divergent quant cette complexit. Ainsi, [TR08] estime 100 MIPS le GSM, et 6 GIPS

le Wideband Code Division Multiple Access (WCDMA) (comparable lUMTS).LUMTS nest donc mme pas thoriquement ralisable sur un processeur Intel Xeon actuel,

malgr ses 4 curs et 8 threads potentiels. Raliser une plateforme de radio logicielle requiert laconception dune architecture multiprocesseur intgre trs haute performance. Ceci est ralis-able, mais pose des problmes de cots, de consommation, de surface, et galement de contrlelogiciel.

2.2.2.3 Software-Defined Radio

La radio logicielle est donc un concept, qui est atteignable en utilisant une plateforme ddie,mais qui dans la pratique souffre de problmes de consommation et dencombrement qui limitent

son dveloppement commercial.Afin de pallier ce problme de performance requise, le concept de Software-Defined Radio

[Jon05] (radio logicielle restreinte [Alh10] en franais) fait intervenir un traitement prliminairede londe, afin de rduire la frquence en entre du systme logiciel. La partie logicielle ne sap-plique donc qu un sous-ensemble du terminal radio complet. Il y a galement une gnralisationdu terme logiciel, qui ne dsigne plus simplement lexcution sur un processeur gnralis, maislutilisation dune architecture qui permet la reconfiguration (GPP, DSP, FPGA, ou autres fonc-tions ddies reconfigurables).

On prsente sur la figure 2.5 les domaines correspondants la SDR. La partie RF est grepar une entit matrielle, qui se charge dappliquer les filtres et de slectionner uniquement labande de frquence souhaite. La translation de frquence vers une frquence intermdiaire est

galement effectue par ce front-endRF. Le signal analogique rsultant est ensuite numris, puistransmis au logiciel SDR, qui est donc en charge du traitement numrique du signal. Ce logicielpeut sexcuter sur un FPGA, sur un DSP, ou encore sur un processeur classique.

9

tel00680080,v

ersion1

17Mar2012


24/138

2.2. RSEAUX FLEXIBLES CHAPITRE 2. PROBLMATIQUE

Figure 2.5 Reprsentation dun rcepteur ralisable de SDR

2.2.3 Radio flexible

La radio flexible est un concept distinct de la radio reconfigurable, daprs [DZD+05]. Cestgalement un concept extrmement flou. [DZD+05] dfinit la notion de flexibilit comme un en-semble de proprits qui permettent une implantation volutive de la radio, comme par exemplela reconfigurabilit, ladaptabilit, la modularit, lextensibilit,. . . Daprs [PRR+03], un terminalprsentant une seule de ces caractristiques peut tre considr comme un terminal flexible. Onpeut galement trouver le terme de radio logicielle tendue.

La flexibilit englobe de nombreux domaines. On sintresse principalement ici la flexibi-lit de la couche physique, ainsi qu la mise disposition de cette flexibilit dans les couchessuprieures. Ainsi, un protocole de routage "flexible" sort du domaine abord, alors que la priseen compte dans la couche MAC de la possibilit de changer la modulation, par exemple, en faitpartie.

2.2.4 Radio cognitive

2.2.4.1 Terminal de radio cognitive

Finalement, la dernire notion lie la radio flexible est la radio intelligente (cognitive ra-dio) [MM99][Jon05]. Un terminal de radio cognitive est capable danalyser son environnementet de ragir aux potentiels changements. Dans un monde idal, un terminal de radio intelligenteest un terminal capable de communiquer avec nimporte quelle autre entit, intelligente ou non,en sadaptant aux modes de communications des autres entits. Il est galement capable doprerdans des conditions de transmission difficiles, ou encore de sintgrer dans des "trous" de com-munication dautres entits (radio opportuniste). Il se base sur les capacits de la radio flexible, et

permet doptimiser lutilisation du spectre.

Figure 2.6 Cycle simplifi dun terminal intelligent [MM99]

Un terminal de radio cognitive peut tre dcrit de faon simplifie comme sur la figure 2.6[MM99]. Le terminal surveille en permanence son environnement. Cet environnement peut tre

10

tel00680080,v

ersion1

17Mar2012


25/138


dfini de diffrentes manires, selon lapplication. En fonction du rsultat de cette surveillance,le terminal dcide quelle sera sa configuration, et transmet lunit de reconfiguration les modi-fications effectuer. Tout ce cycle sorganise autour dun apprentissage. La radio cognitive peut

tre utilise dans diffrentes applications. Par exemple, elle peut permettre de crer un terminalradio qui peut se connecter nimporte quelle norme radio porte, afin de communiquer avecnimporte quel terminal. Mais lune des utilisations principales du concept de radio cognitive estactuellement laccs dynamique au spectre radio (Dynamic Spectrum Access, DSA).

2.2.4.2 Radio opportuniste

La radio opportuniste est un effort pour optimiser lutilisation des bandes de frquence, souslicence ou non. Un rseau opportuniste est un rseau secondaire, qui communique en prsencedautres rseaux (le rseau primaire tant le rseau officiel) de manire invisible pour ces autresrseaux.

La radio opportuniste temporelle sattache combler les trous dans une bande de frquencedonne. Le projet Oracle [ora] est un exemple de ce type dapplication. Il vise crer un rseausecondaire permettant lchange dinformations alors quun rseau primaire de type WiFi, utilisantle CSMA/CA, est prsent.

La radio opportuniste frquentielle ou spatiale cherche utiliser les frquences sous licences,mais non utilises dans une zone donne du fait de la rpartition en cellules du rseau. Lexempletypique de cette application est lutilisation des TV White Space (TVWS)[qos][cog]. La diffusionde la tlvision se fait sur des bandes de frquences sous licence. Cependant, afin dviter lesinterfrences, le rseau de diffusion est divis en cellules. Deux metteurs adjacents ne se verrontpas allouer la mme bande de frquence. Il existe donc des trous dans lutilisation du spectrefrquentiel. Le passage au tout numrique pour la tlvision est galement une opportunit pour

cet axe de recherche, avec la libration des bandes de frquence prcdemment utilises par latlvision analogique.

2.2.5 Interactions radio flexible/radio cognitive

2.2.5.1 Diffrences de terminologie

Selon les tudes sur le sujet, on peut trouver diffrentes terminologie pour les diffrents do-maines abords prcdemment. Ainsi, la radio flexible dans notre cas reprsente une implantationflexible dune application radio, alors que dans dautres tudes, elle peut reprsenter le domainegnral de la radio volutive, et donc inclure la radio cognitive. De mme la radio logicielle peutgalement se dcliner en radio logicielle tendue, et inclure ce que nous appelons la radio flexible.

2.2.5.2 Architecture dun terminal radio

Un terminal radio volutif peut donc tre compos de deux lments : la partie cognitive, qui se concentre sur la prise de dcision, et sur la rponse apporter aux

modifications denvironnement ; une implantation flexible, qui excute les applications radio, et offre la possibilit de modi-

fier son fonctionnement.Cette dcoupe en deux couches de limplantation cohabite avec la dcoupe en couche du mo-

dle OSI. On prsente sur la figure 2.7 une architecture conceptuelle dun terminal radio.Le sondage effectu par la radio cognitive correspond en fait un retour dinformation fait

par limplantation de lapplication radio. Cette implantation correspond au domaine de la radioflexible. Toutes les couches du modle OSI peuvent tre concernes. De mme, la phase dactiondu cycle de la radio cognitive correspond finalement une modification de limplantation, elle

11

tel00680080,v

ersion1

17Mar2012


26/138

2.2. RADIO FLEXIBLE CHAPITRE 2. PROBLMATIQUE

Figure 2.7 Interactions entre radio flexible et radio cognitive

correspond donc des ordres donns la partie radio flexible du terminal. On entrevoit dj ici lancessit de faciliter ces ordres et lutilisation de la radio flexible.

2.2.6 Conclusion

Il existe donc plusieurs manires daborder la radio flexible. On approfondira dans cette tudeles notions de reconfigurabilit et dadaptabilit, et plus particulirement leur intgration dans lecontexte de la radio flexible et cognitive.

Lun des avantages majeurs de la radio flexible (et cognitive) rside dans le moment de laprise de dcision. Alors que dans un systme classique, la prise de dcision se fait en amont de laspcification du rseau, dans la radio flexible, cette prise de dcision est distribue, la fois dans le

temps et entre les diffrents acteurs, de la spcification lexcution. Le systme est ainsi capablede changer dynamiquement son fonctionnement pour sadapter son environnement.

Cependant, lajout de la flexibilit un terminal ne se fait pas sans heurts. Un terminal deradio classique est simple en termes dintgration et de contrle. Il prend en entre des donnes transmettre, quelques paramtres pour le contrle, et fonctionne en bote noire. Plus un terminaldevient flexible, plus ce contrle et cette intgration se compliquent.

2.3 Radio flexible : de multiples possibilits

2.3.1 Scnarios de reconfiguration

Dans la radio flexible, la reconfiguration peut suivre diffrents scnarios [KM02][MBGS03]selon lobjectif recherch. Chaque scnario prsente sa propre problmatique.

2.3.1.1 Adaptation

Tout dabord, ladaptabilit permet de modifier le fonctionnement de la radio dans le but deladapter au rseau. Dans un tel scnario, un terminal, ou le rseau lui-mme, intgre des algo-rithmes de prise de dcision qui lui permettent, selon son environnement, de modifier son fonc-tionnement.

La complexit rside dans les critres et les algorithmes permettant de prendre les dcisions

dadaptation. Le champ de la modification est gnralement connu, et la transformation du ter-minal reste limite une gamme de fonctionnement finie et matrise, contrlable par un jeu deparamtres numriques (cf. 2.2.2.1).

12

tel00680080,v

ersion1

17Mar2012


27/138

CHAPITRE 2. PROBLMATIQUE 2.3. RADIO FLEXIBLE

2.3.1.2 volution des normes

Un deuxime scnario possible est le scnario de la mise jour de la radio. La prise de dcisionnest pas intgre la radio, mais est effectue par des acteurs externes au systme. En rgle

gnrale, ces acteurs sont les lments responsables de la maintenance du systme.Il existe de nombreuses illustrations de ce cas de figure. Par exemple, dans le domaine de la

tlphonie, ce scnario peut tre utilis pour toutes les volutions mineures des normes, commepar exemple le passage de lUMTS lHSPA, sans avoir modifier toute linfrastructure (et donc changer les stations de base, lments coteux du rseau). Dans ce cas, la dcision de mise jourest prise par loprateur responsable de linfrastructure faire voluer.

Ce scnario fait appel la notion de reconfigurabilit, mais dans un cadre statique. Dans lecadre dune mise jour, on peut se permettre dteindre temporairement un systme. La dcisionde reconfiguration est externe au systme, et les algorithmes de prise de dcision du systme sontdonc inexistants.

Par contre, le besoin de reconfigurabilit est plus large que pour ladaptation. Dans le cadre deladaptation, seule une partie du systme est modifie, dans le respect de la spcification initialedes lments le constituant. Cela peut tre fait en cours de fonctionnement. Dans le cadre de lamise jour, une nouvelle version des lments, rpondant de nouvelles spcifications, peut trecharge, venant potentiellement modifier lintgralit de la chane de communication.

2.3.1.3 Multimode

Le cas du multimode est le plus complexe et le plus dlicat. Dans un scnario multimode, lareconfiguration a lieu afin de permettre lutilisation de plusieurs rseaux diffrents en utilisant lemme matriel.

Lexemple du smartphone est une bonne illustration du scnario. Ces appareils sont gnrale-ment quips de plusieurs mthodes de connexion sans fil, les plus courantes tant la tlphonie(GSM, GPRS, EDGE, UMTS, HSPA), les rseaux locaux (WiFi) et les rseaux personnels (Blue-tooth). La coexistence de ces diffrents rseaux se fait gnralement par la coexistence de plusieursASIC figs, chacun tant spcifi pour excuter une norme.

Afin dviter cette multiplication des ASIC, il est envisageable de mettre en place un com-posant gnrique, capable dexcuter toutes ces normes, et de se reconfigurer selon les besoins demanire dynamique. Ce scnario fait appel la reconfigurabilit, mais galement des algorithmesde prises de dcision. La reconfiguration est temporellement beaucoup plus contrainte que dansle cas dune volution, et doit tre faite dynamiquement et de faon transparente pour lutilisateur(ou le systme qui utilise les diffrentes chanes de communication).

2.3.2 De multiples cibles de reconfiguration

La reconfigurabilit dune plateforme peut satteindre de diffrentes manires, selon les be-soins lis au scnario envisag. Le problme du choix de la solution est intimement li au com-promis classique performance/flexibilit, comme prsent sur la figure 2.8 [Kha02][MGT01]. Onparle ici de performance nergtique, cest dire du rapport entre la performance (en termes decapacit de calcul) et lnergie dpense pour atteindre cette performance.

2.3.2.1 Cibles logicielles

La cible logicielle est la plus flexible des possibilits, dans ltat actuel des connaissances.

En effet, si on ne considre pas la performance et les difficults pratiques de mise en place dela radio logicielle, un processeur est virtuellement capable dexcuter nimporte quelle opration,tant quon lui fournit le programme qui la dcrit.

13

tel00680080,v

ersion1

17Mar2012


28/138

2.3. RADIO FLEXIBLE CHAPITRE 2. PROBLMATIQUE

Figure 2.8 Reprsentation du rapport flexibilit/performance de diffrentes solutions dimplan-tation

En pratique, il est difficile dignorer les aspects de performances et de consommation. Dans unsystme embarqu, la consommation dun processeur est nettement suprieure celle dun ASIC.Les implantations utilisant des ASIC sont certes figes, mais extrmement performant avec uneconsommation rduite. Les aspects de consommation mis part, la question de la performancepeut tre aborde dun autre point de vue : la sparation entre lapplication elle-mme et lex-cutant de cette application. Dans la radio traditionnelle, le concepteur de lapplication conoit lecircuit qui permettra dimplanter une norme. Dans ce but, il recherche un compromis visant raliser un circuit de petite taille rpondant aux exigences de dbit imposes par lapplication touten tenant compte de la technologie du circuit et de lergonomie finale du produit. Dans la radiologicielle, le concepteur dploie lapplication sur une cible dont la puissance de calcul est limiteet indique par le fondeur du processeur.

Cette limite externe de performance est compense par la mise en place darchitectures basede multiples processeurs htrognes (DSP), qui augmentent dautant la complexit de mise enuvre. En effet, le surcot li la gestion de ces architectures, qui sajoute la complexit dela gestion de la radio logicielle elle-mme (chemins de donnes, contrle, interactions avec lescouches hautes, reconfiguration, ...), rendent ces implantations extrmement lourdes. La com-plexit de la radio logicielle nest pas lie limplantation dalgorithmes de traitement du signalqui sont dj connus, mais lintgration de ces algorithmes et la gestion dynamique de leurexcution. Ceci rejoint des problmatiques darchitecture des systmes intgrs.

2.3.2.2 Matriel reconfigurable

La dfinition dacclrateurs matriels reconfigurables permet de rpondre en partie au prob-lme de performance de la radio logicielle. Cependant, la perte de gnricit lie lutilisation dematriel est sensible.

Afin de dfinir du matriel reconfigurable efficace, cest--dire permettant datteindre des per-formances suffisantes en gardant la place requise sous contrle, il est ncessaire de trouver uncompromis entre gnricit et performance. Alors que les approches logicielles font le choix de lagnricit "absolue", les solutions de matriels reconfigurables se basent sur des lments ayantune fonctionnalit bien dfinie (par exemple, un oprateur FFT), mais qui peuvent modifier leurfonctionnement (par exemple, changer le nombre de points de la FFT).

la diffrence des techniques logicielles (ou apparentes), on dfinit ici du matriel ddi, quirestera en place. Dans les solutions logicielles, on charge une fonction logicielle sur un processeur

gnrique, qui va excuter cette fonction. La reconfiguration est simplement un changement defonction. Dans une solution base de matriel reconfigurable, lexcutant de la fonction, cest dire lacclrateur matriel, est confondu avec la fonction, et la reconfiguration est donc limite

14

tel00680080,v

ersion1

17Mar2012


29/138

CHAPITRE 2. PROBLMATIQUE 2.4. CHOIX DE LIMPLANTATION : VOLUTION

sa gamme dexcution.Ces approches font apparatre de nouveaux problmes, en particulier des problmes de con-

trle du matriel. Il nest pas envisageable, dans un cadre flexible, de supprimer compltement

le logiciel. Linteraction entre le contrle logiciel et le matriel est un point crucial des environ-nements base de matriel reconfigurable. De plus le nombre de possibilits pour rpondre unbesoin donn est tel quil ny a pas duniformisation et quil est ncessaire de fonctionner au caspar cas pour le contrle.

Finalement, il pourrait tre envisageable de mettre en place des solutions mixtes base dematriel reconfigurable et de logiciel. De telles mthodes combinent les avantages du logiciel etdu matriel : tant que lapplication reste dans le cadre du matriel dfini, il est possible dutiliserce matriel. Mais si un besoin ponctuel non gr par le matriel apparat, il est possible dabsorbercet cart en utilisant le logiciel. Ces approches sont cependant difficiles mettre en place, causedes transferts de donnes requis, et de la synchronisation.

2.3.3 Conclusion sur la radio flexible

Les possibilits dutilisation et dimplantation de la radio flexible sont donc trs vastes. Lob-jectif est dobtenir des terminaux capables de sadapter leur environnement. Ceci passe en partiepar la possibilit de reconfigurer le terminal. Les techniques de radio flexible taient pressenties,au dbut des annes 2000, comme les solutions miracles, qui seraient adoptes trs largementdans un dlai de 10 ans [Tut02]. Mme si des progrs ont t faits, ces solutions restent encoremajoritairement exprimentales.

Dans le domaine de la radio reconfigurable, les recherches se concentrent gnralement surla dfinition de composants permettant une reconfiguration et sur des architectures intgrant cescomposants. Le problme rside dans le peu dinteroprabilit entre les diffrentes implantations.

La dcision dutiliser la radio flexible pour une implantation commerciale impose le choix dunesolution. Ce choix est dterminant car le dveloppement qui sera ralis sur cette solution nepourra pas tre utilis pour une autre mthode.

Au del de ce problme du choix de larchitecture reconfigurable, se pose le problme delintgration de cette architecture avec les algorithmes de radio flexible ou cognitive. Il y a unbesoin de faire cooprer les lments qui grent ces algorithmes (gnralement, des lmentslogiciels rattachs la couche MAC), aux lments qui vont effectivement rpercuter les dcisions(la partie reconfigurable). La multiplication des possibilits posent galement un souci dans cecadre, puisque pour chaque mthode de reconfigurabilit, il faut revoir lintgration.

2.4 Choix de limplantation : volutionLa radio logicielle utilise donc des processeurs pour implanter la chane de communication de

la radio. Cependant, cette solution dimplantation se heurte de nombreux problmes, en particu-lier des problmes de performance et de gestion des diffrentes tches.

2.4.1 Performance de la radio logicielle

Les chanes de communication radio sont gnralement implantes en matriel, dans un envi-ronnement non flexible. En effet, elles utilisent un modle de pipeline de tches particulirementadapt une implantation matrielle, et les oprations trs coteuses utilises dans les normes sans

fil rendent loptimisation ncessaire pour atteindre les dbits requis.Alors que la radio logicielle est une solution optimale en termes de flexibilit, la performance

nest pas vraiment au rendez-vous. En effet, le modle pipeline qui est utilis ne se prte pas

15

tel00680080,v

ersion1

17Mar2012


30/138

2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUECHAPITRE 2. PROBLMATIQUE

vraiment aux processeurs, qui ne peuvent excuter quune opration la fois, et qui doivent doncrendre les calculs squentiels.

Ceci dtriore considrablement les performances en terme de dbit atteignable des solutions

de radio logicielle. Lutilisation de plateformes multiprocesseurs est une solution aux problmesdadquation application/architecture, puisque limplantation dun pipeline devient possible, maisne rsout pas les problmes doptimisation.

Les processeurs simple cur ne se trouvent plus que dans les systmes embarqus pourlesquels lnergie consomme est un lment cl du systme. Cette squentialisation du pipelinenest donc que partielle. De plus, la forte progression de la puissance de calcul des processeursactuels permet galement datteindre des dbits intressants. Cependant, dautres solutions peu-vent tre envisages, qui permettraient de librer les processeurs pour son usage de base, tout enoffrant potentiellement un meilleur dbit accessible.

2.4.2 Essor du GPGPU

Le calcul gnral sur processeur graphique (General Purpose computing on Graphics Pro-cessing Unit(GPGPU)) est un domaine de recherche assez rcent, li lvolution des ApplicationProgramming Interface (API) graphiques. Alors que les oprations taient trs cibles au dpart,le besoin en gnricit pour certains calculs est devenu de plus en plus important, ce qui a men une utilisabilit du GPU pour des calculs autres que des calculs purement graphique.

Un GPU est une architecture base dune multitude de curs de calculs dgnrs. Ces curssont uniquement capable dexcuter des oprations, mais pas de grer toutes les tches annexesdun processeur habituel, cest dire la gestion dun programme, les branch, et autres oprationsnon calculatoires.

La gestion de ces oprations annexes est dlgue une entit spare, qui contrle les curs.Cest donc une architecture de type Single Instruction Multiple Data (SIMD) (ou SPMD selon lescas), capable dexcuter une seule instruction ou programme sur une multitude de donnes.

Les GPU tant lorigine ddis au traitement de limage, de nombreuses oprations de typetraitement du signal sont proposes et optimises.

2.4.3 Problmes du GPGPU pour la radio logicielle

Il peut paratre intressant dutiliser le GPU pour augmenter encore le dbit atteignable pardes applications de radio logicielle. Cependant, le problme dadquation application/architectureest encore plus prsent dans ce cas. Alors que la paralllisation des processeurs permet dexcuterplusieurs tages du pipeline en parallle, la paralllisation interne du GPU, de type SIMD, nepermet pas cette amlioration.

Si on prend lexemple de la radio logicielle sur un ordinateur standard, avec deux processeurs 4 curs, cette architecture permet en thorie dexcuter en concurrence 8 tages du pipeline.Afin davoir un intrt en termes de performances pures utiliser un GPU, il faudrait que celui-ciexcute ces 8 tages squentiellement plus rapidement, ce qui implique un gain moyen par tagesuprieur 8, ce qui est trs lev.

Lintgration dapplications de radio logicielle sur un GPU nest donc pas intuitive, et il nestpas garanti quun gain soit observable.

2.5 Environnement de reconfiguration unique

2.5.1 ObjectifsLe dveloppement de la radio cognitive et la multiplication des plateformes cibles pour la radio

logicielle crent de nouveaux besoins. Afin de permettre lexcution efficace de la radio cognitive,

16

tel00680080,v

ersion1

17Mar2012


31/138

CHAPITRE 2. PROBLMATIQUE2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUE

et lutilisation optimale des plateformes, il est ncessaire dintgrer les diffrentes techniques deradio flexible (matriel reconfigurable, logiciel sur GPP, DSP ou GPU, ...) dans un mme envi-ronnement. Il est galement ncessaire de faire collaborer ces solutions avec des algorithmes de

prise de dcision qui permettent de bnficier au mieux de la reconfigurabilit pour le protocole.Cette collaboration pose le problme plus gnral de lintgration des diffrents domaines de laradio flexible.

Lintelligence de la radio flexible est gnralement implante en logiciel, alors quil existediffrentes manires dimplanter la partie oprative. Cette intgration peut ds lors tre envisagecomme un simple programme logiciel, qui utilise les units fonctionnelles matrielles ou logi-cielles en ayant une connaissance complte de ce quils font. Si on prend lexemple du H-ARQ,la partie protocolaire, qui prend la dcision de choisir une certaine configuration du composant,rpercuterait cette dcision directement sur la partie PHY. Cependant, le moindre changementdans la plateforme, que ce soit sur lenvironnement logiciel, ou sur la partie PHY de lH-ARQ,impose dimplanter nouveau le protocole.

Dans cette section, on sintresse aux diffrents problmes rsoudre afin dobtenir un envi-ronnement unifi et efficace pour la radio flexible. On utilise, cette fin, la plateforme reprsentedans la figure 2.9. On y trouve des lments matriels reconfigurables, des lments dexcutionlogicielle (processeurs, spcialiss ou non), des lments de mmorisation, et des entres/sorties(E/S) classiques dun systme de ce type.

Figure 2.9 Architecture de plateforme flexible gnrique

On envisage donc de mettre en place un environnement pour la radio flexible capable de sex-cuter sur cette plateforme gnrique, et de sadapter aux modifications de la plateforme.

2.5.2 Gestion de la reconfigurabilit

La reconfigurabilit est une proprit lie limplantation [KMR00]. Lorsquun systme pos-sde cette proprit, son fonctionnement est susceptible dtre modifi.

Cette proprit de reconfigurabilit sobtient de diffrentes manires, comme voqu en

section 2.2. La multiplication des implantations reconfigurables, quelles soient logicielles oumatrielles ou les deux, est le premier point grer lors de lintgration des diffrents lments dela radio flexible dans un environnement unique.

17

tel00680080,v

ersion1

17Mar2012


32/138

2.5. ENVIRONNEMENT DE RECONFIGURATION UNIQUECHAPITRE 2. PROBLMATIQUE

La mise en place de solutions reconfigurables passe souvent par une phase de slection du typede reconfigurabilit souhait, en fonction des avantages des diffrentes mthodes. Une fois ce typechoisi, on intgre les lments de reconfigurabilit soit au niveau du systme dexploitation (pour

les lments matriels), soit directement au niveau de lapplication (pour les lments logiciels etmatriels).Ce manque dabstraction nuit la flexibilit, car il empche dintgrer des solutions qui pour-

raient tre avantageuses en termes de reconfigurabilit, et limite galement le dveloppement al-gorithmique et protocolaire, puisquil faut chaque fois adapter limplantation de lalgorithme la plateforme que lon utilise. De manire gnrale, la partie protocolaire du rseau na pas be-soin de connatre les dtails du fonctionnement des lments reconfigurables. Que ceux-ci soientlogiciels ou matriels, le seul objectif pour le protocole est dtre capable de signaler le mode defonctionnement qui convient, quel que soit la mthode utilise pour limplanter.

La gestion de la reconfigurabilit au niveau de lenvironnement est donc un point cl dunenvironnement unifi. Cette gestion soulve plusieurs interrogations. Tout dabord, les couches

hautes ont besoin dune abstraction des oprateurs ncessaires la radio, quil convient de dfinir.Ensuite, les mcanismes de rpercussion de modifications depuis la couche haute jusqu llmentpermettant effectivement de raliser lopration ne sont pas immdiats. Finalement, en plus de lagestion de la reconfigurabilit au niveau de la fonctionnalit, il faut aussi se poser la question dela reconfigurabilit des connexions entre les diffrents lments.

2.5.3 Intgration de la radio flexible

Les environnements existant actuellement sont principalement des environnements de recon-figuration spcifiquement conus pour une solution. Cependant, afin de permettre lutilisation de laradio flexible dans les meilleures conditions possibles, il est intressant de se pencher sur loppor-tunit dtendre ces environnements reconfigurables des environnements flexibles, cest--direintgrant les algorithmes de prise de dcision propres la radio flexible (ou par extension la radiocognitive).

Les algorithmes dits "cross-layer" qui tendent augmenter la coopration entre les couchestraditionnelles du rseau, sont mettre sur le mme plan que les algorithmes flexibles. Ils soulventun problme plus large, puisquil peut galement tre ncessaire de modifier le fonctionnement dela couche MAC.

Cette intgration nest donc ni vidente ni immdiate. Il faut, pour la rendre effective, rsoudrele problme de la place des algorithmes propres la radio flexible dans le rseau, cest--dire deleurs interactions avec les couches MAC et PHY, du rseau.

2.5.4 Gestion de la reconfigurationLa reconfiguration se gre diffrents

Documents

vient et part vient et part