Download - Simulation d'une plateforme Radio Logicielle Reconfigurable HDCRAM et implémentation sur USRP
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