Systmes RFDI

Simulation d'une plateforme Radio Logicielle Reconfigurable HDCRAM et implmentation sur USRPMatthieu PASTOREVincent LE FLOCHPierre LE BERREBoying ZHU

Mercredi 24 Mars 2010IntroductionModle HDCRAM de Log GodardModlisation du systme complet metteur/rcepteurSimulateur SystemCUSRP

Simulation d'une plateforme Radio Logicielle Reconfigurable HDCRAM et implmentation sur USRPMta-modle HDCRAMGNU RadioProgramme SystemC

1) Mta-modle HDCRAMRadio CognitiveDfinitionPossibilit pour une chaine de transmission radio de modifier elle-mme ses paramtres ou sa structure en fonction de son environnement dans le but de communiquer le plus efficacement possible ( QoS)

5Radio CognitiveCaractristiqueSystme pouvant utiliser les capacits de la Radio LogicielleBase sur linformation donne par des capteurs qui caractrisent le signal reuRglage des lments de la chaine de transmission en fonction des informations donnes par les capteurs

6Cycle CognitifObserve Collecter des information des mtriquesLearn valuer et analyser les information des mtriquesDecide Choisir la meilleure configurationReconfiguration

7Modle HDCRAMLes composantesEntits de gestion cognitive (CRM)Entits de gestion de reconfiguration (ReM)LoprateurBloc de fonctionnement qui permet de raliser une partie de traitement global du standard de communication

8Choix de HDCRAMGestion hirarchiqueCentraliser les reconfiguration dun ensemble de ressourcesGestion distribueChaque oprateur est contrl par un unit de gestionSparation des chemins de donnes et de reconfiguration9Architecture HDCRAMArchitecture vertical HDCRAM (1)Les entits de gestion cognitive (CRM)Architecture vertical HDCRAM (2)Les entits de gestion de reconfiguration (ReM)Architecture horizontal HDCRAM (3)Association entre CRM et ReM10Architecture vertical HDCRAM (1)Une approche (bottom/up):La remonte de mtriqueL3_CRMUCollecter les mtriques partir de loprateurL2_CRMUComme une interface entre L1 et L3L1_CRM (unique)Possde une interface avec le monde extrieur

11

Architecture vertical HDCRAM (2)Une approche (Top/down): Lenvoi dordre de reconfigurationL1_ReM (unique)Superviseur gnral de reconfigurationL2_ReMUComme une interface entre L1 et L3L3_ReMUSoccuper dun unique oprateur12

Architecture horizontal HDCRAMune approche transversale: lenvoi dordre de reconfigurationLordre de reconfiguration est interprte par lunit ReMU associe13

Architecture global HDCRAM

14Cration des blocs (1/2)ReMs : OK, cration hirarchise, successiveCrMs ?Analogie ReMs : pas possiblePar L3_ReM : hirarchie ?Par L2_ReM : pas de lien ?

15

Choix :L3_CrM : architectures FPGAs dynamiquement reconfigurables (L2_ReM : gestionnaire de reconfiguration)L2_CrM : analogie au L3_CrMManque de recul sur la solution :Peu de connaissance des architectures dynamiquement reconfigurableAutres cibles ?Problmes connexions (crations statiques ? )

16Cration des blocs (2/2)

Synchronisation metteur-rcepteur (1/2)17

Protocole tram :Paramtres du signal (modulation, codage,) => DVB, SCCCTimestamp : le rcepteur envoie le timestamp sur lequel se reconfigurer => WifiDlai de reconfiguration en durEstimation du dlai ?Perte de donnes18Synchronisation metteur-rcepteur (2/2)2) GNU RadioPrincipe de fonctionnementPassage des donnes de SystemC travers un vrai canal de transmission2 entits diffrentesEntit 1 (Emetteur)Absorption des donnes venant de SystemCEnvoie des donnes sur une antenneEntit 2 (Rcepteur)Rception des donnesEnvoie des donne vers SystemC20Entit GNU Radio2 Composantes

Composante logicielleGNU Radio et GRC

Composante matrielleURSP21Universal Software Radio Peripheral22

Convertisseurs A/N et N/AConvertisseurs A/N Rsolution : 12 bitsFrquence dchantillonnage : 64 MHz

Convertisseurs N/ARsolution : 14 bitsFrquence dchantillonnage : 128 MHz

23FPGA24

Carte filleCarte RFX2400

Emission et RceptionDe 2.3 GHz 2.9 GHzTransposition IQ en frquence Intermdiaire

25

GNU RadioComposante logicielleContrle de lURSPTraitement de signal

Librairie de blocs de traitement du signalCode en C++Assemblage des blocs et cration de graphesEn Python26GNU Radio CompanionInterface graphique pour le dveloppementGnration de code Python

Bloc reprsent graphiquementEntre(s) / Sortie(s)Paramtres27Emetteur28

Performance de transmissionEmissionCNA : 128 MHzfixeInterpolation matrielle (DUC) : 256Cadencement : 128 / 256 = 500 k ech/sInterpolation logicielle : 40Cadencement : 500 / 20 = 12,5 k ech/s

Dbit maximal que le programme SystemC est capable de fournir29Rcepteur30

Ambigit de phaseBoucle accroche de phase : ambigit de /2 (QPSK), (QPSK) :Non dterministeNon mesurableConstant tant que la boucle de phase reste accroche (plusieurs positions stables)Premire solution : corrlation sur un header, on essaye toutes les possibilitsOverhead sur le signalGrande complexit de calcul (initialisation seulement)Autre : prcodage diffrentiel :Baisse du SNR31Ambigit de phase : prcodage diffrentielModulation BPSK : OKOrdres suprieurs :Approche mathmatique : pas de rsultats8psk by VincentApproche par analogie : travail sur lalphabet numrique32

prcodagedcodage

Accroche de phaseSynchronisations symbole (M&M) + phase (costas)Problme : dimensionner les chaines (paramtres asservissement)Boites noires sous GRCExploration du bloc ConstellationSinkPermet dobtenir la structure et les paramtres Problme : structure pas normale

33

Accroche de phase : problme du filtre adapt (1/2)Bonne constellationSignal binaire incorrect (corrlation) en QPSK, correct en BPSKLanalyse des symboles fait apparaitre un mauvais brassage : 1 3 1 3 3 1 2 4 4 2 2 4 2 3 134

Accroche de phase : problme du filtre adapt (2/2)Explication suppose :Filtre adaptInterpolationStructure rcepteur non idaletracking du signal par lasservissement de phase sur les chemins intermdiaires35

3) Programme SystemC3) Programme SystemCFonctionnement du programmeBlocs : classe drivant de sc_module.Liens entre les blocs : sc_portMthodes de classe : sc_threadDmarrage : sc_start

373) Programme SystemCScenario : metteurmodle HDCRAM (niveaux L1, L2 et L3) Chaine de traitement (source, codeur diffrenciel, mapper (QPSK ou BPSK) et sink).Scenario : rcepteur modle HDCRAM (niveaux L1, L2 et L3) Chaine de traitement (source, demapper (QPSK ou BPSK) , dcodeur diffrenciel, et sink).383) Programme SystemCdeux blocs (en mission et en rception) permettant denvoyer des ordres de reconfiguration par UDP et ethernet de lmetteur au rcepteur.Le bloc Image_Sink rcupre une information sur le bruit du signal et la transmet au L3_CrM_SNR_Sensor.

393) Programme SystemC

403) Programme SystemC41

3) Programme SystemCPrincipe de fonctionnement : metteurSource : programme de lecture dimage au format BMPSink envoie les symboles I et Q vers les blocs GNU radio par TCP.Principe de fonctionnement : rcepteurSource reoit les symboles I et Q par TCP des blocs GNU radio.sink reoit limage et laffiche laide des bibliothques OpenCV.

423) Programme SystemCEnvoi dune imageenvoye ligne par ligne avec un entte de 64bits entre elles et ce mme entte deux fois aprs la dernire ligne.corrlation du signal reu avec la squence de 64bits quil possde en mmoire.Si corr < 50, on affiche les pixels

433) Programme SystemC

443) Programme SystemCModlisation des niveaux L1, L2 et L3453) Programme SystemC

463) Programme SystemC47

3) Programme SystemCOprateurs reconfigurables : Mapper/Demapperbloc mapper directement cre par le L3blocs mapperBPSK et mapperQPSK cres par le mapper.changement de mapping : variable publique ready_to_reconfigure du mapper)

483) Programme SystemCImage_Sinkcapte une information sur le bruit et la transmet au L3_CrM_SNR_SensorCr par le bloc L2_ReMValeur de corrlation lors de la dtection de lentte.

49

Refonte du MtaModle : objectifsCapitalisation de codeIntgration de nouvelles fonctionnalitsPermettre utilisation directe du MtaModleConstruction aise de la chaine de traitement50Refonte du MtaModle : diagramme de classes51

Refonte du MetaModle : le frameworkDesign Pattern SingletonEnregistrement des operateursdata_flow SOURCE32 CHAN_INT32 MAPPER CHAN_INT16 FILTER CHAN_INT16 SINK16 ;52

4) Difficults rencontres