Soutenance mémoire
Les communications sans fil continuent de se développer et leur utilisation augmente sans cesse, la téléphonie cellulaire et les radios des services d’urgence font partie de ces énormes systèmes de réseaux sans fil, mais il reste toujours des zones rurales ou éloignées qui sont caractérisées par de faibles densités d’utilisation avec des zones où il n’y a aucune couverture de communication.
Le déploiement des réseaux cellulaires dans les zones lointaines où il y a une faible densité de population coûte très cher par rapport au nombre d’utilisateurs, la grande partie de ce coût étant lié à la complexité des infrastructures requises et à la disponibilité de source d’énergie à proximité. Ces conditions engendrent la nécessité de simplifier l’infrastructure et en même temps justifie la possibilité de diminuer le cout d’énergie par l’utilisation des sources renouvelables comme l’énergie solaire au lieu d’utiliser des générateurs alimentés au diesel.
Radio définie par logiciel (SDR)
La radio définie par logiciel (Software Defined Radio- SDR) est une technique permet d’obtenir le signal radio le plus proche possible des besoins du système et de fournir ce message à l’antenne pour qu’il soit transmis par la voie hertzienne. Il convertit donc les problèmes de matérielle radio en problèmes de logiciels.
La partie matérielle fait l ‘interface entre la bande de base et la partie RF. La forme d’onde d’un signal transmis est entièrement générée par le logiciel, ainsi que le signal reçu qui est entièrement traité et démodulé par les algorithmes logiciels. En SDR, la puissance de traitement nécessaire pour le traitement du signal provient d’un système qui contient des composants tels que des processeurs à usage général (GPP), des processeurs de signaux numériques (DSP), des FPGA (Field Programmable Gate Arrays) ou des ASIC (Application Specifie Integrated Circuits) et plusieurs autres possibilités.
Environnements SDR
L’implantation d’une radio logicielle est actuellement réalisable sur de nombreuses plateformes de développement. Nous présentons ici plusieurs environnements de radio logicielle, avec chacun leurs spécificités.
SCA (Software Communications Architecture)
L’architecture ouverte SCA est parrainée par le Bureau du programme interarmées (Joint Program Office JPO) du Département de la Défense des États-Unis (DoD) dans le cadre du programme de système mixte de radio tactique (Joint Tactical Radio System- JTRS). La SCA est une architecture relativement complexe destinée à apporter un soutien aux applications sécurisées de traitement du signal et exécutée en matériels hétérogènes et distribués.
En outre, plusieurs solutions sont aujourd’hui disponibles et elles offrent un soutien pour les systèmes utilisant cette architecture, dont certains sont disponibles publiquement, comme OSSIE Virginia Tech ou Communications Research Center (SCARI)], fournissant ainsi au concepteur un large éventail de possibilités et un soutien croissant de base. La SCA est une architecture de gestion des composants et elle fournit l’infrastructure requise pour créer, installer, gérer et désinstaller les formes d’ondes, ainsi que la capacité de contrôler et gérer le matériel et d’interagir avec des services externes à travers un ensemble d’interfaces compatibles et des structures.
Il y a cependant certaines limites claires à ce qu’il est possible de faire avec une architecture SCA. Par exemple, la CSA ne prévoit pas un tel soutien en temps réel, mais seulement des garanties de temps de latence maximal et une gestion des communications. En outre, la SCA ne précise pas la manière dont les composantes doivent être mises en œuvre, si ce matériel devra soutenir ce type de fonctionnalité, ou de toute stratégie de déploiement autre que l’utilisateur ou un développeur peut vouloir suivre. La SCA fournit un ensemble de règles de base pour la gestion du logiciel sur un système, en laissant un grand nombre des décisions de conception au développeur. Une telle approche offre une plus grande probabilité que le développeur sera en mesure de répondre aux besoins inhérents du système.
La SCA est basée sur une technologie sous-jacente pour être en mesure de remplir deux objectifs fondamentaux, à savoir, la portabilité du code et la réutilisation. Afin de maintenir une interface cohérente, la SCA utilise le Common Object Request Broker Architecture (CORBA) dans le cadre de son middleware. CORBA est un logiciel qui permet à un développeur d’effectuer des appels de procédure distante (RPC) sur des objets comme s’ils résidaient dans l’espace mémoire local.
Ces dernières années, les implémentations de CORBA sont apparues sur DSP et FPGA, mais, traditionnellement, CORBA a été écrit pour GPP (General Purpose Processor). En outre, les appels systèmes sont effectués grâce à un système d’exploitation (OS), nécessitant un système d’exploitation de mise en œuvre sur la plate-forme. Dans le cas de la SCA, l’OS de choix est un POSIX PSI-52 OS -conforme, mais CORBA ne se limite pas à un tel OS. Son accent GPP-centrique conduit à un flux de l’SCA, Tel qu’illustré sur cette figure, le système d’exploitation est le centre de la mise en œuvre de SCA, ce qui implique, mais ne nécessite pas, l’utilisation d’un GPP. Différentes pièces de la SCA sont liées à cette structure par CORBA et Interface Definition Language (IDL). IDL est la langue utilisée par CORBA pour décrire les interfaces des composants, et il fait partie intégrante de CORBA.
Les différentes pièces du système sont attachées ensemble en utilisant IDL (Interface Definition Language) , c’est que CO RBA permet l’indépendance des services aux implémentations; il peut donc y avoir plus d’un processeur à la base. Au-delà de cette contrainte de l’architecture, les pièces réelles qui constituent le fonctionnement du système SCA, à savoir la SCA et les logiciels existants, le matériel de traitement incompatible avec CORBA, la sécurité, la gestion logicielle et le système de fichiers intégrés.
La SCA est divisée en quatre parties : le cadre (Framework), les profils, les API (Application programming interface) et les formes d’ondes. Le cadre est en outre divisé en trois parties : les composants de base, le contrôle de cadre et les services . La SCA fait suite à une composante basée conception (design), donc la totalité de l’infrastructure tourne autour de l’objectif de la création, l’installation, la gestion et la désinstallation des composants qui constituent une forme d’onde particulière.
Communications Research Center’ s (SCARI)
La SCA se définit comme Wl ensemble de normes soumtses à de nombreuses interprétations qw peuvent aisément limiter l’interopérabilité entre différentes implémentations .Ainsi, il est devenu nécessaire de développer ooe implémentation de référence (RI) et de définir le comportement, de ces normes et co di fier les aspects techniques. Le CRC (Commooications Research Center) a fait appel ooe première fois au SDRF (Software Developernent Research Fooodalion) pour développer ooe implémentation de référence (RI) de la SCA et d’en faire une source ouverte (open source) disponible sur son site Web. L’objectif de cette RI était de :
➤ Réduire le niveau d’ambiguïté des documents de spécification de la SCA
➤ Accroître le potentiel pour l’interopérabilité en permettant aux développeurs de personnaliser l’RI plutôt que de réécrire complètement l’architecture
➤ Améliorer la compréhension de l’architecture à travers Wl exemple
➤ Accélérer l’émergence de SDR par la disponibilité d’une mise en oeuvre
➤ Réduire les coûts et les temps d’accès au marché de la SDR
CONCLUSION
Dans ce projet, nous avons traité le problème de l’interopérabilité entre différents modes radios de sécurité publique, en profitant des avantages de la radio logicielle SDR et nous avons utilisé le matériel USRP avec la plateforme logicielle GNU Radio.
|
Table des matières
CHAPITRE I INTRODUCTION
1.1 Travaux précédents
1.2 Contenu du mémoire
CHAPITRE II LA PLATEFORrvΠSDR
2.1 Radio définie par logiciel (SDR)
2.2 Environnements SDR
2.2.1SCA (Software Communications Architecture)
2.2.2Communications Research Center’s (SCARI)
2.2.3OS SIE: SCA-Based Open Source Software D efmed Radio
2.3GNU Radio
2.3.1GNU Radio Companion (GRC)
2.4 l\1atériel
2.4.1Universal Software Radio Peripheral (USRP)
2.4.2USB 2.0 Controller
2.4.3ADC (Convertisseur analogique numérique)
2.4.4DAC (Convertisseur numérique-analogique)
2.4.5PGA (Amplificateur à gain programmable)
2.4.6 Cartes Filles
CHAPITRE III APPROClffi PROPOSÉE
3.1 Introduction
3.2 Gestion du spectre
3.2.1Normes
3.2.2Interface utilisateur
3.2.3Sécurité de Communications
3.2.4Services des données
3.2.5Interopérabilitéoo
3.3 Caractéristiques d’une station de base SDR
3.3.1Multi-Bandes
3.3.2Multi-Canaux
3.3.3Multi-Modes
3.3.4Multi-Débits
3.3.5Multi-Bandes Passantes
3.4 Implémentation des plusieurs modes
3.4.1 Récepteur radio FM
3.4.2 Répéteur FRS
3.4.3Répéteur PMR
3.4.4Récepteur Apco25
3.4.4.1Phases de P25
3.4.4.2Fonctionnement de P25
3.4.4.3Implémentation de P25
3.5 Adaptation de l’OpenBTS au système multi-modes
3.5.1 Architecture du système GSM
3.5.2 System d’authentification utilisé
3.5.3 Configuration de serveur Asterisk
3.5.4 Déploiement de station de base OpenBTS
3.5.4.1 Chaîne RF
CHAPITRE IV TRANSFORMATION DES MODES AVEC SIGNALISATION
4.1 Introduction
4.2 Transformation dans la couche physique
4.2.1 Passerelle radio FM-> FRS
4.2.2 Passerelle FRS-PMR
4.3 Transformation dans la couche application
4.3.1 Méthode de connexion GNU radio-Asterisk
4.3.2 Étapes d’implémentations
4.4 Bilan
CHAPITRE V PERFORMANCE DU SYSTÈME PROPOSÉ
5.1 Introduction
5.2 Capacité du système
5.3 Capacité d’OpenBTS
5.4 Latence dans le système
5.5 Limitation de l’USRP
5.6 Limitation de l’OpenBTS
CHAPITRE VI CONCLUSION
Télécharger le rapport complet
