Simulation d'une plateforme Radio Logicielle Reconfigurable HDCRAM et implémentation sur USRP Matthieu PASTORE Vincent LE FLOCH Pierre LE BERRE Boying ZHU Mercredi 24 Mars 2010

Introduction Modèle HDCRAM de Loïg Godard Modélisation du système complet émetteur/récepteur Simulateur SystemC USRP

Méta-modèle HDCRAM GNU Radio Programme SystemC Simulation d'une plateforme Radio Logicielle Reconfigurable HDCRAM et implémentation sur USRP Méta-modèle HDCRAM GNU Radio Programme SystemC

1) Méta-modèle HDCRAM

Radio Cognitive Définition Possibilité pour une chaine de transmission radio de modifier elle-même ses paramètres ou sa structure en fonction de son environnement dans le but de communiquer le plus efficacement possible ( QoS)

Radio Cognitive Caractéristique Système pouvant utiliser les capacités de la Radio Logicielle Basée sur l’information donnée par des capteurs qui caractérisent le signal reçu Réglage des éléments de la chaine de transmission en fonction des informations données par les capteurs

Cycle Cognitif Observe Learn Decide Reconfiguration Collecter des information des métriques Learn Évaluer et analyser les information des métriques Decide Choisir la meilleure configuration Reconfiguration

Modèle HDCRAM Les composantes L’opérateur Entités de gestion cognitive (CRM) Entités de gestion de reconfiguration (ReM) L’opérateur Bloc de fonctionnement qui permet de réaliser une partie de traitement global du standard de communication

Choix de HDCRAM Gestion hiérarchique Gestion distribuée Centraliser les reconfiguration d’un ensemble de ressources Gestion distribuée Chaque opérateur est contrôlé par un unité de gestion Séparation des chemins de données et de reconfiguration

Architecture HDCRAM Architecture vertical HDCRAM (1) Les entités de gestion cognitive (CRM) Architecture vertical HDCRAM (2) Les entités de gestion de reconfiguration (ReM) Architecture horizontal HDCRAM (3) Association entre CRM et ReM

Architecture vertical HDCRAM (1) Une approche (bottom/up):La remontée de métrique L3_CRMU Collecter les métriques à partir de l’opérateur L2_CRMU Comme une interface entre L1 et L3 L1_CRM (unique) Possède une interface avec le monde extérieur

Architecture vertical HDCRAM (2) Une approche (Top/down): L’envoi d’ordre de reconfiguration L1_ReM (unique) Superviseur général de reconfiguration L2_ReMU Comme une interface entre L1 et L3 L3_ReMU S’occuper d’un unique opérateur

Architecture horizontal HDCRAM une approche transversale: l’envoi d’ordre de reconfiguration L’ordre de reconfiguration est interprétée par l’unité ReMU associée

Architecture global HDCRAM

Création des blocs (1/2) ReMs : OK, création hiérarchisée, successive CrMs ? Analogie ReMs : pas possible Par L3_ReM : hiérarchie ? Par L2_ReM : pas de lien ?

Création des blocs (2/2) Choix : Manque de recul sur la solution : L3_CrM : architectures FPGAs dynamiquement reconfigurables (L2_ReM : gestionnaire de reconfiguration) L2_CrM : analogie au L3_CrM Manque de recul sur la solution : Peu de connaissance des architectures dynamiquement reconfigurable Autres cibles ? Problèmes connexions (créations statiques ? )

Synchronisation émetteur-récepteur (1/2)

Synchronisation émetteur-récepteur (2/2) Protocole tramé : Paramètres du signal (modulation, codage,…) => DVB, SCCC Timestamp : le récepteur envoie le timestamp sur lequel se reconfigurer => Wifi Délai de reconfiguration en « dur » Estimation du délai ? Perte de données

2) GNU Radio

Principe de fonctionnement Passage des données de SystemC à travers un vrai canal de transmission 2 entités différentes Entité 1 (Emetteur) Absorption des données venant de SystemC Envoie des données sur une antenne Entité 2 (Récepteur) Réception des données Envoie des donnée vers SystemC

Entité GNU Radio 2 Composantes Composante logicielle GNU Radio et GRC Composante matérielle URSP

Universal Software Radio Peripheral

Convertisseurs A/N et N/A Résolution : 12 bits Fréquence d’échantillonnage : 64 MHz Convertisseurs N/A Résolution : 14 bits Fréquence d’échantillonnage : 128 MHz

FPGA

Carte fille Carte RFX2400 Emission et Réception De 2.3 GHz à 2.9 GHz Transposition IQ en fréquence Intermédiaire

GNU Radio Composante logicielle Contrôle de l’URSP Traitement de signal Librairie de blocs de traitement du signal Codée en C++ Assemblage des blocs et création de graphes En Python

GNU Radio Companion Interface graphique pour le développement Génération de code Python Bloc représenté graphiquement Entrée(s) / Sortie(s) Paramètres

Emetteur

Performance de transmission Emission CNA : 128 MHz fixe Interpolation matérielle (DUC) : 256 Cadencement : 128 / 256 = 500 k ech/s Interpolation logicielle : 40 Cadencement : 500 / 20 = 12,5 k ech/s Débit maximal que le programme SystemC est capable de fournir

Récepteur

Ambigüité de phase Boucle accroche de phase : ambigüité de π /2 (QPSK), π (QPSK) : Non déterministe Non mesurable Constant tant que la boucle de phase reste « accrochée » (plusieurs positions stables) Première solution : corrélation sur un header, on essaye toutes les possibilités Overhead sur le signal Grande complexité de calcul (initialisation seulement) Autre : précodage différentiel : Baisse du SNR

Ambigüité de phase : précodage différentiel décodage Modulation BPSK : OK Ordres supérieurs : Approche mathématique : pas de résultats 8psk « by Vincent »… Approche par analogie : travail sur l’alphabet numérique

Accroche de phase Synchronisations symbole (M&M) + phase (costas) Problème : dimensionner les chaines (paramètres asservissement) « Boites noires » sous GRC Exploration du bloc « ConstellationSink » Permet d’obtenir la structure et les paramètres Problème : structure pas « normale »

Accroche de phase : « problème du filtre adapté » (1/2) Bonne constellation Signal binaire incorrect (corrélation) en QPSK, correct en BPSK L’analyse des symboles fait apparaitre un mauvais « brassage » : 1 3 1 3 3 1 2 4 4 2 2 4 2 3 1

Accroche de phase : « problème du filtre adapté » (2/2) Explication supposée : Filtre adapté Interpolation Structure récepteur non idéale « tracking » du signal par l’asservissement de phase sur les chemins intermédiaires…

3) Programme SystemC

3) Programme SystemC Fonctionnement du programme Blocs : classe dérivant de sc_module. Liens entre les blocs : sc_port Méthodes de classe : sc_thread Démarrage : sc_start

3) Programme SystemC Scenario : émetteur Scenario : récepteur modèle HDCRAM (niveaux L1, L2 et L3) Chaine de traitement (source, codeur différenciel, mapper (QPSK ou BPSK) et sink). Scenario : récepteur Chaine de traitement (source, demapper (QPSK ou BPSK) , décodeur différenciel, et sink).

3) Programme SystemC deux blocs (en émission et en réception) permettant d’envoyer des ordres de reconfiguration par UDP et ethernet de l’émetteur au récepteur. Le bloc Image_Sink récupère une information sur le bruit du signal et la transmet au L3_CrM_SNR_Sensor.

3) Programme SystemC

3) Programme SystemC

3) Programme SystemC Principe de fonctionnement : émetteur Source : programme de lecture d’image au format BMP Sink envoie les symboles I et Q vers les blocs GNU radio par TCP. Principe de fonctionnement : récepteur Source reçoit les symboles I et Q par TCP des blocs GNU radio. sink reçoit l’image et l’affiche à l’aide des bibliothèques OpenCV.

3) Programme SystemC Envoi d’une image envoyée ligne par ligne avec un entête de 64bits entre elles et ce même entête deux fois après la dernière ligne. corrélation du signal reçu avec la séquence de 64bits qu’il possède en mémoire. Si corr < 50, on affiche les pixels

3) Programme SystemC

3) Programme SystemC Modélisation des niveaux L1, L2 et L3

3) Programme SystemC

3) Programme SystemC

3) Programme SystemC Opérateurs reconfigurables : Mapper/Demapper bloc mapper directement crée par le L3 blocs mapperBPSK et mapperQPSK crées par le mapper. changement de mapping : variable publique ready_to_reconfigure du mapper)

3) Programme SystemC Image_Sink capte une information sur le bruit et la transmet au L3_CrM_SNR_Sensor Créé par le bloc L2_ReM Valeur de corrélation lors de la détection de l’entête.

Refonte du MétaModèle : objectifs Capitalisation de code Intégration de nouvelles fonctionnalités Permettre utilisation directe du MétaModèle Construction aisée de la chaine de traitement

Refonte du MétaModèle : diagramme de classes

Refonte du MetaModèle : le framework Design Pattern Singleton Enregistrement des operateurs data_flow « SOURCE32 « CHAN_INT32 « MAPPER« CHAN_INT16 « FILTER « CHAN_INT16 « SINK16 ;

4) Difficultés rencontrées