Projet!de!Fin!d’Etudes!: Détectiondesprécipitations!...

1

ç

INSA Strasbourg Spécialité Génie électrique

Option système Mars-‐Septembre 2015

Tuteur : Dr. GARN Heinrich Professeur référent : FLIELLER Damien

Projet de Fin d’Etudes : Détection des précipitations par l’analyse de la qualité du signal du protocole GSM/UMTS.

Clément Faure

P1310087 - TYCO

Projet de Fin Etude : Détection des précipitations par l’analyse de la qualité du signal du protocole GSM/UMTS.

2

Détection des précipitations par l'analyse de la qualité du signal du protocole

GSM/UMTS

Résumé : Aujourd’hui, les données récoltées par les stations météo locales, les satellites et les radars météorologiques sont analysées, croisées et inspectées au travers de modèles mathématiques dédiés à la prédiction dynamique de la météorologie. Ce travail propose d'étudier une méthode novatrice en la matière, basée sur l'analyse de la qualité du signal des protocoles GSM/UMTS en fonction des précipitations. Elle a pour but d'améliorer les prévisions météorologiques locales à court terme (6 à 72 heures), en se reposant sur un réseau déjà existant. Ce travail consiste dans un premier temps à l'élaboration d'un capteur capable de relever les différents paramètres concernant la qualité du signal, puis à l'analyse des mesures réalisées par ce même capteur.

Detection of precipitation based on quality data of cellular phone connections.

Abstract : Nowadays, the data measured by the local meteorological stations, satellites and radars are merged together and analysed through mathematical patterns dedicated to the dynamic prediction of the weather. This work has for aim to analyse an innovative method, based on the analysis of the quality of GSM/UMTS signal depending up on the precipitation. Its goal is the improvement of the nowcast, relying on an existing network. It firstly consists of designing a sensor able to measure the different signal quality parameters, and then analyse the measurements realised by this sensor.


3

1 SOMMAIRE

2 Remerciements ............................................................................................................................................. 6

3 AIT : Austrian Institute of technology ............................................................................................................ 7 3.1 Qui sont-‐ils ? .......................................................................................................................................... 7 3.2 Que font-‐ils ? .......................................................................................................................................... 7

4 détection des précipitations par l’analyse de la qualité du signal radio GSM/UMTS ....................................... 9 4.1 Etat actuel des connaissances et des recherches à ce sujet. .................................................................... 9

4.1.1 Notion de now-‐ et forecasting. ................................................................................................................ 9 4.1.2 Influence des précipitations sur les ondes radio. .................................................................................... 9 4.1.3 Analyse à grande échelle de données du réseau cellulaire. .................................................................. 11

4.2 Description du problème ...................................................................................................................... 11

5 Reseaux cellulaires ...................................................................................................................................... 12 5.1 Un peu d’histoire : de premier réseau mobile à la 3G ........................................................................... 12 5.2 Structure et fonctionnement du système GSM et ses évolutions .......................................................... 13

5.2.1 Structure ................................................................................................................................................ 13 5.2.2 Fonctionnement .................................................................................................................................... 15 5.2.3 Les différent canaux .............................................................................................................................. 17

5.2.3.1 Canaux logiques et canaux physiques ............................................................................................ 17 5.2.3.2 Canaux communs et canaux dédiés ............................................................................................... 17 5.2.3.3 Les canaux de trafic ........................................................................................................................ 17 5.2.3.4 Les canaux de contrôle ................................................................................................................... 18

5.2.3.4.1 BCH : Broadcast Control Channels .......................................................................................... 18 5.2.3.4.2 CCCH : Common Control Channels ......................................................................................... 18 5.2.3.4.3 DCCH : Dedicated Control Channels ....................................................................................... 18

5.2.4 RSSI : Received Signal Strength Information ......................................................................................... 18 5.2.5 Le Speech Frame Structure .................................................................................................................... 19 5.2.6 Comment la voix et les autres informations sont-‐elles codées ? .......................................................... 20 5.2.7 RxLex ...................................................................................................................................................... 21 5.2.8 Rxqual .................................................................................................................................................... 22

5.3 Comment tout cela fonctionne ensemble? ........................................................................................... 22 5.4 UMTS ................................................................................................................................................... 23

5.4.1 Qu’est-‐ce que le power control? ........................................................................................................... 24 5.4.1.1 « Open loop » ................................................................................................................................. 24 5.4.1.2 « Inner loop » ................................................................................................................................. 24 5.4.1.3 « Outer loop » ................................................................................................................................ 24

5.4.2 Autres différences ................................................................................................................................. 24 5.4.2.1 Les canaux ...................................................................................................................................... 24 5.4.2.2 Que devient le RSSI? ...................................................................................................................... 25

5.4.2.2.1 RSSI : Received Signal Strength Informartion : ....................................................................... 26 5.4.2.2.2 RSCP : Received Signal Code Power ........................................................................................ 26 5.4.2.2.3 Ec/No et Ec/Io : Rapport signal/bruit ...................................................................................... 26


4

5.5 Pertinence de tous ces paramètres. ...................................................................................................... 27

6 Concepte de l’installation ............................................................................................................................ 28

7 Nano-‐ordinateur : le Banana Pi .................................................................................................................... 28 7.1 Qu’est-‐ce que c’est ? ............................................................................................................................ 28 7.2 Caractéristiques ................................................................................................................................... 29 7.3 Systèmes d’exploitations compatibles .................................................................................................. 30 7.4 Connexion avec les différents capteurs ................................................................................................ 31

8 Capteur de temperature et d’humidité ........................................................................................................ 32 8.1 Modèle ................................................................................................................................................ 32 8.2 Interprétation des données transmises ................................................................................................ 32

9 MODEM ...................................................................................................................................................... 33 9.1 Huawei E3531 ...................................................................................................................................... 33 9.2 UR5i v2 ................................................................................................................................................. 33 9.3 Gemalto ............................................................................................................................................... 34

10 Carte sim « roaming » ............................................................................................................................... 34

11 Commandes AT ......................................................................................................................................... 34 11.1 Histoire : ............................................................................................................................................ 34 11.2 Fonctionnement et syntaxe ................................................................................................................ 35 11.3 Exemples théoriques d’envoi de commande AT et de sa réponse. ...................................................... 36 11.4 Principales commandes AT utilisées ................................................................................................... 37 11.5 Règles pour utiliser les commandes AT. ............................................................................................. 38

12 Le Script .................................................................................................................................................... 38 12.1 A propos de Python ............................................................................................................................ 38 12.2 Structure générale ............................................................................................................................. 38

12.2.1 Librairies utilisées ................................................................................................................................ 39 12.2.1.1 Serial ............................................................................................................................................ 39 12.2.1.2 Time ............................................................................................................................................. 39 12.2.1.3 Sqlite ............................................................................................................................................ 39 12.2.1.4 Datetime ...................................................................................................................................... 39 12.2.1.5 Subprocess ................................................................................................................................... 39 12.2.1.6 Os ................................................................................................................................................. 39 12.2.1.7 Threading ..................................................................................................................................... 39 12.2.1.8 RPI.GPIO ....................................................................................................................................... 39 12.2.1.9 Paramiko ...................................................................................................................................... 40

12.3 Déroulement du script : schéma blocs ................................................................................................ 41 12.4 Structure des différentes bases de données ....................................................................................... 42 12.5 Autre script python développés et utilisés. ........................................................................................ 43

12.5.1 Crontest.py .......................................................................................................................................... 43 12.5.2 Crontest2.py ........................................................................................................................................ 44

13 Les autres paramètres ou outils utilisés ..................................................................................................... 44 13.1 Périphérique USB ............................................................................................................................... 44


5

13.1.1 Usb Modeswitch .................................................................................................................................. 44 13.1.2 Udev et udev rules .............................................................................................................................. 44

13.2 Transfert des données et contrôle à distance ..................................................................................... 45 13.2.1 Envoie des données par SMS .............................................................................................................. 45 13.2.2 /bin/ScriptCopy ................................................................................................................................... 46 13.2.3 SSH et /etc/network/interfaces .......................................................................................................... 47 13.2.4 SFTP ..................................................................................................................................................... 47

13.3 Stabilité et sécurité ............................................................................................................................ 48 13.3.1 Tee ...................................................................................................................................................... 48 13.3.2 Cron et Crontab ................................................................................................................................... 48

13.4 Cell ID et LAC : bases de données publiques ....................................................................................... 49

14 Résultats et analyses ................................................................................................................................. 50 14.1 Tous premiers résultats ...................................................................................................................... 50 14.2 Premiers résultats avec une carte SIM roaming. ................................................................................. 50 14.3 Analyse d’un mois de mesures ........................................................................................................... 53

15 Critiques et futures améliorations ............................................................................................................. 54 15.1 Critiques et problèmes ....................................................................................................................... 54

15.1.1 Difficultés pour rester connecté à un seul réseau ............................................................................... 54 15.1.2 Erreurs de script non résolues ............................................................................................................. 54 15.1.3 Matériel ............................................................................................................................................... 56 15.1.4 Manque de données ........................................................................................................................... 56

15.2 Futurs travaux et améliorations ......................................................................................................... 57 15.2.1 Stabilité et précision du capteur ......................................................................................................... 57 15.2.2 Ajout de fonctionnalités ...................................................................................................................... 57 15.2.3 Utilisation d’autres types de capteurs ................................................................................................. 58 15.2.4 Etudes d’une possibilité d’implantation des capteurs dans le sud de la France. ................................ 58

16 Conclusion ................................................................................................................................................ 59

17 Bibliographie et sources ............................................................................................................................ 60

18 Lexique et acronymes ................................................................................................................................ 61


6

2 REMERCIEMENTS

Je souhaite en premier lieu remercier l’AIT de m’avoir accueilli, et ainsi, m’avoir permis de réaliser ce projet qui fut très intéressant. Plus précisément, j’aimerai remercier Bernard, Martin et Daniel qui ont passé la majeure partie de leurs déjeuners à m’aider et m’expliquer comment améliorer mon projet. Mes remerciements s’adressent aussi au Professeur Philipp Svoboda, qui m’a apporté son expertise de la technologie GSM/UMTS tout au long de mon PFE. J’aimerais aussi remercier, encore une fois le SRI de l’INSA Strasbourg, qui m’a soutenu dans les démarches qui m a soutenu dans les démarches administratives nécessaires à l obtention de ce PFE, mais surtout qui m’a donné l’opportunité pendant toute ma scolarité de concilier découvertes et études. Plus généralement je remercie l’INSA Strasbourg, pour son ouverture à l’international ce qui m’a permis d’effectuer une partie de mon cursus au Brésil et tous mes stages à l’étranger ,Suisse, Espagne, Autriche, que de rencontres, de découvertes, et d’ouverture ! Enfin j’aimerai remercier toutes les personnes m’ont soutenu et aidé de près ou de loin pendant ce projet de fin d’études, mais aussi pendant toute ma scolarité.


7

3 AIT : AUSTRIAN INSTITUTE OF TECHNOLOGY

3.1 Qui sont-‐ils ?

L’Austrian Institute of Technology est le plus gros institut non universitaire autrichien, et fait partie des spécialistes européens dans la recherche. En partenariat avec les industries, mais aussi les institutions publiques. L’AIT cherche et développe dès aujourd’hui les technologies, méthodes et outils de demain, ouvrant ainsi la porte aux innovations futures. La République d’Autriche possède 50,46% des parts, tandis que la Fédération des industries autrichiennes détient 49,54%. L’AIT compte dans ses rangs plus de 1100 employés dans les domaines de la santé, l’environnement, l’énergie, la mobilité et la sécurité. J’ai passé six mois dans ce dernier, plus précisément dans le secteur des nouvelles technologies appliquées au capteur, dirigé par le DR Heinrich Garn. Ce secteur se concentre sur quatre spécialités : fusion de données, capteur d’imageries, reconnaissance des formes et capteur de traitement du signal. Dans ce secteur sont développées des applications liées à la mobilité, pour des systèmes autonomes, pour la robotique et les applications industrielles. En étroite collaboration avec des médecins, des experts de tous horizons et des partenaires de l'industrie, les différents projets développés entre ses murs vont du diagnostic et la thérapie de maladies psychiques dans la vieillesse jusqu’à l’élaboration d’un coffre-‐fort, en passant par le développement d’une nouvelle méthode de prévisions météorologiques.

3.2 Que font-‐ils ?

FIGURE 1: DOMAINE D'INTERVENTION DE L'AIT


8

AIT a pour but de se placer en tant qu’institut clef dans la recherche que ce soit en Autriche, en Europe ou à l’international. Pour cela, l’AIT se focalise sur dans la recherche appliquée pour permettre l’exploiter le marché des solutions infrastructurelles innovantes, et ainsi combler le fossé entre la recherche et la commercialisation des technologies. Comparé aux universités, l’AIT ne s’arrête pas à la recherche fondamentale, mais couvre l’ensemble du processus de recherche partant de technologies émergentes, passant par toutes les phases de développement et arriver à l’industrialisation d’un produit. L’AIT se veut être le pont entre la recherche fondamentale et l’industrie.


9

4 DETECTION DES PRECIPITATIONS PAR L’ANALYSE DE LA QUALITE DU SIGNAL RADIO GSM/UMTS

4.1 Etat actuel des connaissances et des recherches à ce sujet.

4.1.1 Notion de now-‐ et forecasting.

« Nowcasting » signifie prévision à courts termes (de 0 à 6 heures) des précipitations et orages, alors que « forecasting » décrit les prévisions à moyens termes (6 à 72 heures). Aujourd’hui, les données récoltées par les stations météo locales, les satellites et les radars météorologiques sont analysées, croisées et inspectées au travers de modèles mathématiques dédiés à la prédiction dynamique de la météorologie. Pour cela, la connaissance de l’état exact de l’atmosphère à un instant donné est primordiale, ce qui implique une observation pertinente des paramètres météorologiques. Bien que la précision et la quantité des mesures sur le terrain aient considérablement augmenté ces dernières années, les réseaux actuels de stations météorologiques restent insuffisants pour pouvoir prédire le temps de manière précise à court terme. Ceci peut être en partie réalisé par les radars et les satellites. Les observations actuelles ne sont que des approximations du réel état de l’atmosphère, fréquemment parsemées d’erreurs lorsqu’elles sont étudiées localement. En outre, les stations qui ne sont pas complétement équipées sont incapables de rendre compte du type et de la quantité des nuages et de la mesure des précipitations, particulièrement lorsqu’il s’agit de neige, est très difficile. Enfin, tous les phénomènes n’ayant pas de contacts directs avec les capteurs restent inobservables. Le problème de la fiabilité des stations météorologiques automatiques est devenu de plus en plus importants ces vingt dernières années car les sociétés (publiques ou privées) impliquées dans la prévision météorologique, ont considérablement baissé le nombre de relevés 24 heures sur 24 réalisés par des intervenants, principalement pour des raisons de coût. Un grand nombre de stations sont devenues automatisées, ce qui a eu pour conséquence de réduire le nombre et la qualité des observations météorologiques. Dans le but d’évaluer le temps à n’importe quel moment, d’autres paramètres doivent être pris en compte. Pour cela, il serait possible d’équiper toutes les stations météorologiques de capteurs spéciaux et de caméras pour observer le ciel, mais cela augmenterait considérablement le coût d’une telle station. Il est donc peut être plus judicieux d’utiliser (ou de détourner) un moyen d’observation déjà mis en place : le réseau cellulaire.

4.1.2 Influence des précipitations sur les ondes radio.

La relation entre l’atténuation des ondes radio et l’humidité dans l’air peut être mise en équation sous cette forme là :

𝐴 = 𝑎×𝑅!


10

Où A est l’atténuation en dB/km R est le taux de précipitation en mm/h a et b deux constantes principalement dépendantes de la fréquence L’influence des précipitations sur la transmission a été étudiée sur des fréquences comprises entre 15 et 23 GHz. La vapeur ayant une fréquence de résonance de 22GHz, l’humidité est donc responsable de nombreuses interférences pour des ondes ayant une fréquence proche de 22GHz. Cependant, les fréquences comprises entre 1 à 10GHz sont aussi affectées par ce phénomène.

De nos jours, les logiciels de simulation des systèmes radio ne prennent pas en considération l’influence du temps, car son influence est bien moins importante qu’un autre phénomène appelé le « multipath propagation » qui peut être observé quand une onde radio atteint une antenne en passant par plusieurs chemins (ce qui a peut engendrer des interférences constructives ou destructives, problèmes de différences de phases. Bien que l’influence des phénomènes météorologiques sur le GSM (Global System for Mobile Connections) et UMTS (Universal Mobile Telecomunication System) a été étudiée, aucun travail n’a permis à ce jour de tirer des conclusions sur les variations locales des précipitations en observant la qualité du signal de ce type de réseau. Les systèmes de communication W-‐CDMA, comme l’UMTS possèdent un contrôle de puissance : la station de base communique avec le mobile, et lui envoie des informations : ce dernier règle la puissance transmise à un niveau suffisant, appelée Qualité de Service, pour maintenir la communication, ce qui réduit la puissance transmise à l’UE (User Equipment, terme normalisé de téléphone mobile).

FIGURE 2: ATTENUATION MOYENNE DES ONDES MOYENNE ELECTROMAGNETIQUE DE FREQUENCES F AU COURS D'UNE PRECIPITATION ALPHA


11

4.1.3 Analyse à grande échelle de données du réseau cellulaire.

L’étude à grande échelle de données a déjà été réalisée dans de nombreux projets tels que le « OpenSignal Initiative ». Aujourd’hui, la mesure à grande échelle avec les téléphones portables est cantonnée aux paramètres mesurables en direct, comme la température par exemple. Dans notre cas, nous sommes intéressés par la qualité du signal téléphonique. Ce paramètre varie grandement dans le temps (à cause des propriétés particulières d’un réseau sans fil ou de ce que fait l’utilisateur). Et ces variations sont encore plus importantes dans un réseau sans fil. Par conséquent, les mesures de performance à grande échelle sont normalement réservées aux réseaux filaires. Cependant, le projet actuel ne nous permet pas d’utiliser ce type de réseau. La philosophie du « big data », qui consiste à dire que « plus il y a de données, plus les résultats seront précis », n’est vraie seulement si toutes ces données peuvent être comparées avec des observations très précises. Un des côtés innovants de ce projet, sera de nettoyer ces données à partir d’informations qui ne peuvent pas être mesurées sur place, mais qui seront des moyennes dans le temps et l’espace. Au travers de méthodes mathématiques, il faudra extraire des données fiables parmi la quantité importante de mesures.

4.2 Description du problème

Un grand nombre de secteurs (tels que le tourisme, les évènements en plein air, l’agriculture, la construction ou le transport) reposent sur des prévisions à court terme précises et locales. En prenant l’exemple particulier des transports, les conséquences d’un changement brusque de conditions météorologiques peuvent être dramatiques. Les systèmes de prévisions météorologiques connus à ce jour ne sont pas capables de détecter ces changements qui sont très limités dans le temps et l’espace, bien que la résolution globale des prévisions s’améliore de jour en jour. Le problème est que des phénomènes tels que le brouillard, les averses ou les orages sont souvent difficiles à simuler, ce qui rend les modèles inadaptés aux prévisions détaillées. De plus, les stations météorologiques ne transmettent leurs données qu’une fois toutes les 5 minutes, et aucune d’entre-‐elles n’est capable de détecter le brouillard. En augmentant le nombre de données en temps réel, il serait alors possible d’améliorer les prévisions à court et à long terme de régions propices à ce type de changements météorologiques. Ce projet a pour but d’explorer différentes méthodes permettant de recueillir ce genre de données, à partir de sources déjà existantes, c’est à dire sans avoir à construire une nouvelle infrastructure. L’analyse de la qualité du signal radio du réseau cellulaire au travers de méthodes mathématiques et statistiques pourrait remplir ces objectifs.


12

5 RESEAUX CELLULAIRES

5.1 Un peu d’histoire : de premier réseau mobile à la 3G

L’étude des ondes électromagnétiques comme un moyen de communication a commencé au cours du XIX siècle, mais ce n’est que dans les années 1940 que le premier système de communication mobile est apparu: le « car-‐phone », autrement dit la voiture munie d’un téléphone. Bien que révolutionnaire, ces systèmes étaient très limités (qualité, mobilité réduite, etc.). En plus de cela, leur dimension, leur poids et leur prix ont limité leur diffusion sur le marché. Résultat moins de un million de personnes utilisait ce système au début des années quatre-‐vingt. L’apparition du système cellulaire, appelé 1G vers la fin des années soixante-‐dix a été un bond de géant dans la télécommunication mobile. Ajouté à cela l’apparition des semi-‐conducteurs et des microprocesseurs qui a rendu les systèmes plus petits, légers et sophistiqués entrainant une utilisation accessible pour le plus grand nombre. Cette évolution a permis d’approcher les vingt millions d’utilisateurs au début des années quatre-‐vingt-‐dix. Cependant, cette première génération de systèmes cellulaires transmettait seulement des informations analogiques. La seconde génération (2G) de système de communication mobile fut dirigée par le besoin d’améliorer la qualité, la capacité et la couverture du réseau. Les avances technologiques des différents domaines utilisés par la télécommunication mobile ont conduit à l’utilisation d’un système digital. Et bien que la communication vocale restait le type de communication le plus utilisé, les utilisateurs se tournaient de plus en plus vers les fax, SMS ou la transmission de données. Cette nouvelle génération de télécommunication utilise les normes telles que GSM, Digital AMPS (D-‐AMPS), Code Division Multiple Access (CDMA) et Personal Digital Communication (PDC) que nous détaillerons un peu plus loin. La 1G et 2G sont utilisées dans le monde entier, mais différents standards sont employés pour certaines applications spécifiques (paging ou réseau privé par exemple), ou dans certains pays et la plupart sont incompatibles. Cependant la norme GSM est utilisée par plus de 55% des téléphones dans le monde, présente dans cent quarante pays et sur quatre réseaux téléphoniques. Une première standardisation de la norme GSM900 a été développée en 1990 par l’Institut Européen des Normes de Télécommunication (the European Telecommunications Standards Institute, ETSI), comprenant toutes les définitions nécessaires au bon fonctionnement du réseau GSM. Malgré cela la norme ne réalisait que des services basiques, c’est pour cela que la norme fut améliorée en 1995, pour offrir une plus grande variété de services et d’applications. Et c’est en 1996, que l’ETSI a incorporé les nouvelles possibilités de la 3G: réseau intelligent (IN: Intelligent Network), Customized Application for Mobile Enhanced Logic (CAMEL)… Finalement une dernière optimisation des standards GSM, appelé UTMS, a été développée et utilisée pour la première fois à des fins commerciales le vingt-‐cinq septembre deux mille deux en Autriche. Enfin, une nouvelle optimisation de la télécommunication est apparue au cours des dernières années, la 4G. Deux principaux standards ont été développés le LTE (Long Term Evolution) and the WiMAX (Worldwide Ineroperability for Microwave Access) permettant le très haut débit mobile. Actuellement une cinquième génération est en cours de développement qui devrait être disponible courant 2020.


13

FIGURE 3: NORMES 1G, 2G ET 3G

5.2 Structure et fonctionnement du système GSM et ses évolutions

5.2.1 Structure

Le système GSM (Global System for Mobile telecommunication) comprend les standards des sous-‐systèmes et une structure basée sur les normalisations du CCIT (Comité Consultatif International télégraphique) et du CCIR (Comité Consultatif International des Radiocommunications). Le GSM permet une mobilité des terminaux de communication (téléphones), grâce à la SIM (Subscriber Identity Modul) qui porte un numéro désignant l’utilisateur du téléphone. Le réseau GSM est basé sur un ensemble de cellules (réseau cellulaire). Le concept de communication cellulaire est basé sur la réutilisation des différentes fréquences d’un spectre. C’est à dire que la communication va être réalisée sur un ensemble de N fréquences qui ne se chevauchent pas, et qui vont être attribuées tour à tour aux différents utilisateurs de réseaux cellulaires. La représentation hexagonale des différentes mailles du réseau est une


14

idéalisation théorique qui permet de symboliser au mieux le cercle d’émission des différentes antennes omnidirectionnelles. Cela pour créer un ensemble de cellules sans intervalle ou chevauchement. Le nombre N de fréquences dépend de différents paramètres locaux : l’environnement dans un premier temps, va déterminer la propagation des ondes dans l’air et les interférences, et donc influencer l’écart entre les différents canaux du réseau. Dans un second temps, la densité du trafic des communications va déterminer la surface couverte par une cellule : plus la demande de communication est importante, plus la taille de la cellule va être petite. Mais plus les cellules sont petites, plus le nombre d’équipements est important ce qui augmente considérablement le coût. La première interface (après le téléphone cellulaire lui-‐même) avec laquelle l’utilisateur est en contact s’appelle le sous-‐système de station de base (BSS : Base Station Subsystem) : c’est là que se trouve les émetteurs/récepteurs et l’équipement de commutation de canal. Plus les cellules sont petites et moins la réutilisation des différentes fréquences est importante, plus l’utilisation du spectre sera efficace. Comme le système digital utilisé par le GSM est moins sensible aux interférences qu’un signal analogique (utilisé par la 1G, l’ancien système cellulaire), il permet une meilleure utilisation du spectre de fréquence. Généralement, le système digital est composé d’antennes monodirectionnelles avec un angle d’émission de 120°.

L’infrastructure classique utilisée dans le réseau cellulaire est représentée dans la figure 4. La BSS permet la gestion des ressources des signaux radio, le changement entre les différents canaux et de la coordination du multiplexage temporel (TDM) avec le MSC (Mobile Switching Center). Le MSC agit comme le nerf du réseau, il est chargé du routage du réseau, de l’interconnexion avec les autres réseaux et de la coordination des appels. C’est aussi lui qui va permettre le « Handover », c’est à dire l’ensemble

FIGURE 4: STRUCTURE DU RESEAU GSM


15

des opérations permettant à un téléphone de changer de cellule sans pour autant couper la communication. Chaque MSC est à son tour connecté à un Réseau Téléphonique Commuté Public (PSTN : Public Switched Telephone Network) pour établir la connexion entre les téléphones mobiles et les téléphones fixes, mais aussi l’ensemble du réseau mobile et les autres MSC. Ainsi n’importe quel utilisateur peut communiquer avec le reste des utilisateurs. EDGE est une version plus performante du GSM avec un débit de 384 kbps.

5.2.2 Fonctionnement

Le système GSM utilise deux bandes de fréquence : une fréquence de transmission (TX), appelée aussi fréquence montante, et une fréquence de réception (RX), appelé fréquence descendante, munies de canaux de signalisation permettant la modulation de la puissance en fonction de la distance entre l’antenne et le GSM. Les principales configurations utilisées sont décrites dans le tableau suivant :

Standard

Nombres de porteuses (Numéro

des canaux)

Fréquences d’émission

Fréquences de

réception

Largeur des bandes

Différence entre

l’émission et la transmission

GSM 850 124 (128–251) 824.2–849.2 MHz 869.2–893.8 MHz 0,2MHz 45MHz

GSM 900 124 (0-‐124) 890-‐915 MHz 935-‐960 MHz 0,2 MHz 45MHz

GSM 1800 374 (512–885) 1 710 -‐1 785 MHz 1 805 -‐1 880 MHz 0,2MHz 95 MHz

GSM 1900 299 (512–810) 1,850–1,910 MHz 1,930–1,990 MHz 0,2MHz 80MHz

GSM 450 (le moins commun)

35 (259–293) 450.4–457.6 MHz ou

478.8–486 MHz

460.4–467.6 MHz ou

488.8–496 MHz

0,2MHz 10MHz

Nous allons décrire plus précisément comment fonctionne le GSM 900, qui est le standard le plus utilisé en Europe. Le GSM utilise un multiplexage fréquentiel, c’est à dire qu’il découpe le spectre fréquentiel en plusieurs canaux regroupés en bande. Il existe dans le GSM deux types de bandes : La bande montante (Uplink vers le réseau) comprise entre 890MHz et 915MHz et la bande descendante (Downlink vers le mobile) comprise entre 935MHz et 960MHz sont chacune divisées en 124 porteuses de 200 kHz (appelé écart adjacent). Les deux bandes sont séparées de 20 MHz. On appelle écart duplex, l’écart entre deux fréquences correspondantes au duplexage Uplink-‐Downlink. Dans notre cas il est constant et de 45 MHz. De cette manière, il est possible d’utiliser simultanément les 124 porteuses. Chaque porteuse est identifiée grâce à un nombre n codé sur 10 bits, et désigné par le sigle ARFCN (Absolute Radio Frequency Channel Number). Ainsi pour trouver la fréquence d’une porteuse particulière, il suffit de réaliser ce calcul :

F!"#$%&(n) = 890 + n ∗ 0,2 avec 0 ≤ n ≤ 124 F!"#$%&$'(n) = 935 + n ∗ 0,2 avec 0 ≤ n ≤ 124


16

Chaque porteuse comporte 8 TS, ou Time Slots (créneaux temporaires) : ce sont des intervalles de temps permettant l’accès multiple à répartition dans le temps, c’est à dire de réaliser un multiplexage permettant de transmettre plusieurs signaux sur un même canal. Ainsi, le GSM utilise un multiplexage temporel, lui-‐même utilisé dans un multiplexage fréquentiel. Mais ce type de multiplexage sera décrit plus loin dans la partie 5.2.5. L’ensemble composé de l’infrastructure décrite figure 4 et de ce système de fréquence, permet d’avoir un réseau mobile terrestre public (PLMN : Public Land Mobile Network). Pour pouvoir réaliser la communication, le réseau utilise différentes bases de données. Le registre de localisation nominale (HLR : Home Location Register), qui garde et met à jour la localisation et les informations de l’utilisateur. Le réseau utilise aussi le registre de localisation des visiteurs (VLR : Visitor Location Register), qui est la même chose que le HLR, mais lorsque l’utilisateur est en mouvement. Le registre d’identités des équipements (EIR : Equipment Identity Register), qui est utilisé pour répertorier les identités des équipements et ainsi permettre l’authentification d’utilisateurs non autorisés et leur refuser l’accès au service du réseau. Enfin, le centre d’authentification (AC : Authentification Center), qui fournit les clefs et les algorithmes de sécurité et de cryptage. Le MSC est alors équipé d’un appareil appelé SSP (Service Switching Point) qui va réaliser différentes requêtes auprès de ces bases de données, autorisant l’utilisateur ou non, à utiliser le réseau. L’antenne émet en permanence dans toutes les directions, un signal d’identification qui comprend le numéro de la cellule et le nom de l’opérateur. Un téléphone portable cherche quant à lui en permanence ces signaux d’identification. Lorsqu’il reçoit plusieurs signaux provenant de différentes antennes, il mesure la puissance et la qualité de ces derniers, et choisit l’antenne avec le meilleur signal. Alors, il se manifeste à l’antenne correspondante en lui envoyant à son tour son signal d’identification. L’antenne transmet cette information au PTSN qui gère l’ensemble réseau. Ainsi, le PTSN sait où se trouve l’utilisateur et peut diriger les informations qui lui sont destinées.

FIGURE 5: REPARTITION DES BANDES FREQUENCIELLES DU UPLINK ET DOWNLINK DANS LA TECHNOLOGIE GSM


17

5.2.3 Les différent canaux

5.2.3.1 Canaux logiques et canaux physiques

La technologie GSM possède une grande variété de canaux, qui lui permet de transmettre différentes données. Ils sont classés selon deux types appelés canaux physiques et canaux logiques. Les canaux physiques sont déterminés par les créneaux temporaires, alors que les canaux logiques sont déterminés par les informations portées au moyen des canaux physiques. Pour résumé, plusieurs créneaux sur une fréquence porteuse constituent un canal physique, et ces derniers sont utilisés par différents canaux logiques pour transmettre des informations concernant l’utilisateur ou permettant le bon fonctionnement du réseau.

5.2.3.2 Canaux communs et canaux dédiés

On peut séparer les canaux logiques en deux genres : les canaux communs et les canaux dédiés. Les canaux communs envoient sans restriction les mêmes informations à tous les utilisateurs. Ils sont principalement utilisés pour émettre des informations à l’attention de tous les mobiles se situant sur la zone couverte par le BSS mais aussi lorsque l’on cherche à joindre un autre utilisateur se trouvant sur cette zone (détails voir 5.3). Les canaux communs ne sont que des canaux de contrôle. Les canaux dédiés sont toujours destinés à un seul mobile. Il existe deux catégories de canaux dédiés : canaux de trafic et canaux de contrôle ou de signalisation.

5.2.3.3 Les canaux de trafic

Les canaux de trafic (TCH) sont l’association des canaux permettant la transmission de la voix et des données sur le signal, utilisés lors d’une communication. Il existe trois types de canaux de trafic dans le GSM : -‐ Le canal de trafic « full rate » (vitesse maximale) ayant une vitesse de transmission de 22,8 kbps,

appelé aussi TCH/F, qui dédie un slot par trame (voir 5.2.5.) lors d’une communication entre l’utilisateur et le réseau cellulaire.

-‐ Le canal de trafic « half rate » (50% de la vitesse maximale) ayant une vitesse de transmission de 11,4 kbps, appelé aussi TCH/H, qui dédie un slot toutes les deux trames.

-‐ Le canal de trafic « eighth rate » (un huitième de la vitesse maximale) ayant une vitesse de transmission de 2,85 kbps, appelé aussi TCH/8, qui dédie un slot toutes les 8 trames. Ce canal est uniquement utilisé pour la configuration du système ou l’envoi de messages courts liés au service, limitant ainsi le taux de transmission des données.

Ce sont des canaux bidirectionnels.


18

5.2.3.4 Les canaux de contrôle

5.2.3.4.1 BCH : Broadcast Control Channels Ces canaux sont des canaux point-‐to-‐multipoint, c’est à dire qu’ils sont émis à partir d’une seule source (dans notre cas la BSS), et reçus par plusieurs récepteurs (dans notre cas les stations mobiles). Ils transportent les informations concernant le downlink, et sont principalement responsables de la synchronisation et de la correction en fréquence de la station mobile. Chaque cellule utilise une porteuse spécifique pour le BCH.

5.2.3.4.2 CCCH : Common Control Channels C’est un ensemble de canaux uplink et downlink entre la station mobile et la station de base. Ces canaux sont faits pour transmettre du réseau vers la station mobile et permettre à cette dernière d’y avoir l’accès.

5.2.3.4.3 DCCH : Dedicated Control Channels Cet ensemble de canaux est responsable du « roaming », handovers, cryptage, etc… Au sein des DCCH, on distingue trois canaux différents. Pour plus de détails sur les différents canaux voir en annexe.

5.2.4 RSSI : Received Signal Strength Information

Lorsque que le GSM n’est pas en cours de communication, il a besoin de connaître régulièrement l’intensité du signal que lui transmettent les antennes autour de lui pour garantir la meilleure communication possible avec un autre interlocuteur lors de la future communication. Pour cela, il existe le RSSI, qui est une mesure de la puissance en réception du signal d’un signal radio. Ce n’est pas inhérent au GSM, il peut être utilisé dans toute transmission radio (le WIFI par exemple) et donc être mesuré de manière analogique ou numérique. Dans notre cas il est exprimé en dBm (rapport de puissance en décibels entre la puissance mesurée et un milliwatt), donc dans une échelle logarithmique (valeurs comprises entre 0 et -‐120dBm) et peut s’interpréter de la manière suivante : plus le RSSI est proche de zéro, plus le signal reçu est fort, et plus il est proche de -‐120dBm, plus le signal est de mauvaise qualité. On peut ainsi connaître la qualité de la réception et éventuellement l’ajuster ou changer de cellule radio (si possible sans coupure, ce qui est appelé le HANDOVER). Il permet aussi d’améliorer la géolocalisation dans un réseau mobile. L’image suivante schématise le fonctionnement du RSSI : le signal perçu par le mobile venant de l’antenne de droite sera plus important que celui venant de l’antenne de gauche. Ainsi le mobile va choisir de se connecter à l’antenne de droite. Ce système fonctionne avec plusieurs antennes, cependant en raison de la hauteur des antennes et de l’orientation des émetteurs (vers le bas), il est peu probable qu’un mobile reçoive le signal de plus de 6 antennes différentes. En croisant le RSSI de plusieurs antennes on peut donc facilement déterminer la position de l’utilisateur.


19

5.2.5 Le Speech Frame Structure

Nous avons donc vu que le téléphone mesure la qualité et la puissance du réseau en permanence pour ainsi bénéficier de la communication. Mais lors d’une communication, il doit vérifier plus régulièrement (toutes les 20ms) la qualité du signal. Pour vérifier cela, il utilise deux paramètres : le RXlev et le RXqual. Dans cette partie nous allons décrire comment le message (la voix) est codé et comment sont mesurés le Rxlev et Rxqual, et c’est là que le multiplexage temporel, ou plus précisément le TDMA (Time Division Multiple Access) intervient.

FIGURE 6: QU'EST CE QUE LE RSSI

FIGURE 7: SUPERTRAMES DU GSM


20

Ainsi qu’énoncé un peu plus tôt, chaque porteuse comporte 8 Time Slots : ce sont des intervalles de temps permettant l’accès multiple à répartition dans le temps, c’est à dire de réaliser un multiplexage assurant la transmission de plusieurs signaux sur un même canal. Ainsi la même fréquence porteuse peut être utilisée par plusieurs personnes en même temps. Ces 8 time slots sont numérotés de 0 à 7, et sont répétés continuellement pour former un flux de TDMA où chaque mobile est associé à un numéro. Puis, une multi trame de 26 time slots (appelée 26 multiframe) est formée à partir de 26 time slots du même mobile, et enfin 4 «26 multiframes» forment à leur tour, la SACCH multi trame. Sur le les 26 time slots de la multi trame, 24 sont utilisés pour envoyer la conversation. Deux time slots sont réservés de façon plus spécifique : un time slot appelé A sert à signaliser le début ou la fin d’une série de time slots, et un time slot appelé I contient les informations d’identification de la cellule. Le temps d’un time slots est de 577 μs, et ce sont ces slots qui permettent de transmettre la voix ou la signalisation. Le débit brut de la porteuse est de 271 kbit/s, soit 33,8 kbit/s par slot. Le débit utile est de 24,7 kbit/s par slot.

5.2.6 Comment la voix et les autres informations sont-‐elles codées ?

La voix est découpée en échantillons de 20 ms compressés en 260 bits. Ces bits sont divisés en classes selon leur importance : classe 1a pour les bits très importants, classe 1b pour les bits importants and classe 2 pour les bits pas importants.

CRC est le Cyclic Redundancy Check, c’est à dire le contrôle de redondance cyclique, qui est un outil qui permet de détecter les erreurs de transmissions ou de transfert par ajout. Après avoir été codé, les 456 bits sont découpés en bursts. Ensuite dans le décodeur, les données sont transformées en 260

FIGURE 8: CODAGE DE LA VOIX


21

bits, puis passent dans un décodeur de voix qui transformera les bits en message qui paraitra comme les 20 ms enregistrées plutôt. Pour les données qui ne concernent pas le message sonore envoyé par le téléphone mais d’autres informations le codage est différent. -‐BCCH : Broad Cast Control Channel : comporte un ensemble d’informations sur l’antenne comme son identité, sa configuration ou les différentes options possibles. -‐CCCH : Commun Control Channels : transfère les informations de contrôle entre les téléphones et l’antenne (autorisation de connexion, canal pour la communication…). -‐SDCCH : Stand alone Dedicated Control Channel : Contient les informations sur la configuration des appels, authentification, localisation et les SMS (protocole point-‐to-‐point). -‐FACCH : Fast Associated Control Channel : Transporte les informations concernant les authentifications de l’utilisateur, l’assignation des canaux ou les handovers

5.2.7 RxLex

Le Rxlev, correspond au niveau de champ reçu par le mobile provenant de la BSS. Il est mesuré sur 64 niveaux, de 0 à 63, qui correspondent à la différence entre -‐110 et -‐47 dBm. Il existe deux type de RxLev : RxLev Full qui mesure l’ensemble des bursts (signal radio émis dans une slot) sans exception, et le RxLev Sub qui est la mesure sur les bursts réellement utilisés. Ce dernier est relevé lorsque le téléphone veut économiser de l’énergie, et réalise une transmission discontinue, appelée DTX (Discontinous Transmission). Cela consiste à interrompre l ‘émission lors des silences, réduisant ainsi l’énergie utilisée

FIGURE 9: CODAGE DES AUTRES INFORMATIONS


22

par le téléphone. Les mesures sont faites toutes les 500ms environ. Ce procédé est aussi réalisé au niveau des BSS.

5.2.8 Rxqual

Le Rxqual est l’évaluation de la qualité du signal. Il est mesuré grâce au taux d’erreurs binaires appelé BER (Bit Error Ratio), sur 8 niveaux (3 bits). Une valeur représentative du niveau de chaque niveau de RxQual est utilisée pour moyenner diverses mesures de RxQual. Cette valeur correspond à la moyenne géométrique des bornes de la plage :

𝐵𝐸𝑅 𝑖 = 2 ∗ 2! ∗ 0,1 𝑒𝑛 % i correspondant au niveau de RxQual déterminé ainsi : de 0-‐4 bonne qualité, de 5-‐6 de qualité moyenne et 7 de mauvaise qualité. Cela permet d’établir un tableau d’interprétation comme ceci :

RxQual BER Valeurs représentatives

Interprétation

0 BER=0,2% 0,4% Très bonne qualité 1 0,2%<BER<0,4% 0,28% Bonne qualité 2 0,4%<BER<0,8% 0,57% Bonne qualité 3 0,8%<BER<1,6% 1,13% Qualité médiocre 4 1,6%<BER<3,2% 2,26% Qualité médiocre 5 3,2%<BER<6,4% 4,53% Médiocre 6 6,4%<BER<12,8% 9,05% Mauvaise 7 12,8% 18,10% Très mauvaise

5.3 Comment tout cela fonctionne ensemble?

Une fois que l’utilisateur a allumé son appareil, et rentré son code PIN, la MS va chercher un réseau. Pour cela la BTS envoie le FCCH à intervalles réguliers, pour aider la MS à trouver la fréquence de la bande descendante et à adapter sa fréquence pour la bande montante. Et pour cela, la MS va sélectionner le signal le plus fort. Le SCH va aider la MS à se synchroniser avec le time slot numéro 0 envoyé par la BTS. LE SCH contient le numéro d’identité de la BTS et des informations basiques à propos des opérateurs qui peuvent être comparées avec celles stockées dans la carte SIM. Après cette étape, la MS peut décider si elle a choisi le réseau approprié, et si ce n’est pas le cas, elle recommence la procédure avec le second signal le plus fort, puis le troisième jusqu'à trouver le réseau lui correspondant. Alors que la MS utilise le FCCH pour ajuster sa fréquence et le SCH pour se synchroniser et s’identifier, le BCCH, qui est aussi envoyé par la BTS, fournit des informations supplémentaires sur la cellule sélectionnée. Maintenant, avant de pouvoir recevoir ou réaliser un appel, une mise à jour de sa position et une authentification doivent être réalisées et seulement après cela, la MS sera enregistrée sur le réseau et


23

aura une couverture radio. Et pourra recevoir et réaliser des appels. Pour cela, les Common Control Channels sont nécessaires. Quand un utilisateur appelle, le PCH est diffusé dans la bande descendante par toutes les BSS dans la zone où se trouve la MS, pour que cette dernière, si elle est concernée, réagisse. Pour commencer l’appel, la MS envoie un RACH qui contient son code d’identification et ses requêtes. EN retour, le réseau envoie le AGCH, pour attribuer à la MS les ressources suffisante en lui donnant un SDCCH, qui lui permettra de communiquer. Si l’utilisateur se déplace vers une zone couverte par un autre BTS, la commande handover dont il aura besoin est transmise sur le FACCH. Les données et la voix de l’utilisateur sont transportées sur les canaux de trafique, à la fréquence attribuée par la BTS.

5.4 UMTS

L’UMTS, aussi appelé 3G, est basé sur une technologie plus récente, le W-‐CDMA qui est probablement une des méthodes les plus complexes que l’on connaisse à ce jour dans la télécommunication. Le Code Division Multiple Access est un système où tous les usagers utilisent la même fréquence en même temps. Comment cela est-‐il possible sans qu’il n’y ait aucune interférence ? Cela fonctionne car chaque message est attribué à un code unique. Pour mieux comprendre il suffit de prendre un exemple : imaginez que chaque message soit dans une langue différente et que vous vous placiez dans une salle pour entendre tous les messages en même temps. Le message le plus facile à comprendre sera le message dans le langage que vous parlez. Ainsi, si vous entendez ‘Me chamo Caio’, ‘Ich heisse Hanz’ et ‘Je m’appelle Clément’ en même temps, le message le plus clair sera celui dans votre langue maternelle. Bien sûr cela ne fonctionne que si les messages sont plus ou moins au même volume : si un des messages est bien plus fort que les autres, il sera difficile de les comprendre. C’est pourquoi, dans le système radio CDMA les récepteurs (dans notre exemple les auditeurs) doivent informer à tous les émetteurs (ceux qui parlent), le volume auquel ils reçoivent leur signal, permettant ainsi aux émetteurs d’ajuster la puissance d’émission des messages. Tout cela dans le but de recevoir tous les messages au même volume. Ceci est appelé le ‘power control’. Un autre problème existant pour les récepteurs utilisant la CDMA est appelé le ‘cell breathing’. Imaginez que vous puissiez comprendre quatre langues, la probabilité que vous entendiez, parmi ces quatre langues, votre langue maternelle est assez importante. Maintenant si vous parlez soixante-‐quatre langues, la probabilité que vous puissiez distinguer, parmi toutes ces langues, votre langue maternelle est bien plus mince. C’est pourquoi plus il y a d’émetteurs sur la même fréquence, plus il est difficile pour le récepteur d’écouter. Pour compenser cela, les récepteurs doivent se rapprocher des émetteurs, ce qui n’est pas possible dans le cas des réseaux téléphoniques, mais qui se traduit par un rétrécissement de la zone couverte par l’antenne. Et grâce à tous ses processus, le CDMA peut supporter deux fois plus d’utilisateurs sur le même spectre fréquentiel que la technologie utilisée avant lui, c’est à dire la TDMA ou FDMA. Cependant, l’UMTS utilise un spectre fréquentiel différent de celui utilisé par le GSM : 1885–2025 MHz pour la communication du mobile vers la BSS (uplink) et 2110–2200 MHz pour la communication de la BSS vers le mobile (downlink). Bien que ces bandes hertziennes aient été choisies comme standard certains pays, comme les Etats Unis, ont choisi différentes bandes : -‐ Les bandes 1710–1755 MHz uplink et 2110–2155 MHz downlink pour les Etats Unis, car une partie de

la bande proposée par le standard était déjà utilisée.


24

-‐ Les bandes 850 MHz et/ou 1900 MHz (parfois sans séparer les bandes uplink ou downlink), en Australie, en Nouvelle-‐Zélande ou par certains opérateurs aux Etats Unis.

5.4.1 Qu’est-‐ce que le power control?

Le power contrôle (contrôle en puissance) a cinq objectifs : • Maintenir la qualité en bande descendante et montante en ajustant le power. • Atténuer near far problème en fournissant la puissance minimum nécessaire à chaque

connexion. • Prévenir le fast fading et le shadowing. • Minimiser les interférences. • Augmenter l’autonomie des MS, en diminuant leur consommation.

Pour réaliser cela il existe trois différents types de contrôle en puissance : open loop, inner loop et outer loop. Tous les trois reposent sur des algorithmes différents :

5.4.1.1 « Open loop »

Le power contrôle appelé open loop est chargé de fournir l’énergie initiale suffisante a la MS au début de la connexion. Il suppose que la perte de puissance est la même dans la bande montante que dans la bande descendante. La MS mesure la puissance reçue, puis les pertes sont déterminées en sachant la puissance en Tx de la BSS. Finalement, la MS ajuste sa puissance en Tx en fonction des pertes estimées.

5.4.1.2 « Inner loop »

Ce type de contrôle en puissance est utilisé en bande monte et descendante. La MS transmet un signal initial, ensuite la BSS compare le SIR avec le SIR cible. S’il est plus grand, la BSS diminue la puissance, et s’il est plus petit il augmente la puissance.

5.4.1.3 « Outer loop »

Ce contrôle en puissance mesure le BER ou FER, qui reflètent plus comment l’utilisateur perçoit la qualité de la connexion. Il fait en sorte que le niveau du FER et BER reste à un certain niveau, et ajuste le SIR cible utilisé dans le inner loop.

5.4.2 Autres différences

5.4.2.1 Les canaux

En plus d’utiliser la technologie CDMA, l’UMTS emploie un multiplexage temporel, avec case et créneaux, comme pour le GSM, seulement l’organisation est différente. Les canaux sont divisés en trames de 10 ms, qui sont à leur tour divisées en 15 time-‐slots de 666 microsecondes. Sur la bande descendante, les time-‐slots sont encore divisés pour pouvoir contenir des données utilisateur ou des messages de contrôle. Sur la bande montante, une modulation double canal est utilisée pour transmettre simultanément des données et des messages de contrôle.


25

Les canaux peuvent être classifiés ainsi : • Canaux logiques : qui définissent comment les données vont être transférées. • Canaux de transport : qui définissent, avec les canaux logiques, comment les données

seront transférées. • Canaux physiques : qui portent la puissance des données et régissent les caractéristiques

du signal. Les canaux sont organisés de telle sorte que les canaux logiques sont liés à ce qui est transporté,

tandis que la couche physique des canaux de transport gère comment et quelles caractéristiques le sont. Les canaux communs ont la priorité la plus importante sur la puissance. Leur puissance est fixe.

Les canaux dédiés sont les seconds prioritaires sur la puissance : leur puissance est d’ailleurs contrôlée. Enfin, toute l’énergie restante peut être attribuée à HSDPA.

Pour plus de détails, voir annexes.

5.4.2.2 Que devient le RSSI?

Pour l’UMTS, le canal CPICH est en permanence transmis du Node B vers le MS. Il ne transporte

pas d’information et peut être considéré comme une balise, transmettant continuellement le scrambling code de la cellule. Dans le WCDMA, les cellules sont identifiées grâce à ce code, et c’est ce canal qui est utilisé par le téléphone pour faire toutes les mesures concernant la cellule, le réseau et les handovers. Pour ce dernier, il utilise un paramètre qui n’existe pas dans la technologie GSM, le Ec/Io. Il existe en plus de cela, un autre paramètre mesuré par le MS, le Received Signal Power (RSCP) d’un CPICH en particulier en dBm.

FIGURE 10: RÉPARTITION DE LA PUISSANCE ENTRE LES CANAUX


26

5.4.2.2.1 RSSI : Received Signal Strength Informartion : Dans la technologie UMTS, le RSSI représente la puissance du signal sur l’ensemble de la porteuse de 5MHz, qui inclut toutes les composantes reçues, c’est-‐à-‐dire le signal de l’actuelle cellule avec laquelle il est connecté, mais aussi les cellules voisines sur la même fréquence. En fait, le RSSI représente ce qui (en dBm) du signal brut est reçu par le MS. Le problème de cette mesure est qu’elle comporte beaucoup de bruit.

5.4.2.2.2 RSCP : Received Signal Code Power

C’est le niveau de puissance du canal pilote d’une cellule et il est exprimé en dBm. Il peut être décrit comme l’énergie après traitement, en d’autres termes, l’énergie avec le gain du code. Avec ce paramètre, plusieurs cellules utilisant la même porteuse peuvent être comparées, et le téléphone peut alors réaliser un handover.

5.4.2.2.3 Ec/No et Ec/Io : Rapport signal/bruit C’est l’énergie reçue par puce sur le canal pilote, appelée Ec, divisé par la densité totale de bruit, appelée No. Similaire au rapport signal sur bruit, c’est une simple mesure de la qualité du signal, en opposition avec la puissance brute du signal. Plus le Ec/Io est élevé, plus le signal de la cellule peut être distingué du bruit ambiant. Le Ec/No est exprimé en dB. Cette valeur peut être utilisée pour comparer différentes cellules sur la même porteuse ou réaliser des handover ou des sélections de cellules. On peut l’exprimer de deux manières :

𝐸𝑐𝑁𝑜 = 𝑅𝑆𝐶𝑃 − 𝑅𝑆𝑆𝐼 avec le RSCP et le RSSI en dBm

𝑜𝑢 𝐸𝑐

𝑁𝑜 = 10 log 𝐶𝑃𝐼𝐶𝐻 𝑝𝑜𝑤𝑒𝑟 𝑇𝑜𝑡𝑎𝑙 𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡 𝑝𝑜𝑤𝑒𝑟

FIGURE 11: REPRÉSENTATION DU RSSI, RSCP EC/IO


27

Le Ec/No est calculé dans le récepteur. Le Ec/Io est en fait Ec/(Io+No), avec Io pour les interférences dans la bande passante. Mais pour des raisons pratiques on utilise Ec/Io car les interférences sont bien plus fortes que le bruit.

5.5 Pertinence de tous ces paramètres.

Nous nous sommes questionnés sur quels paramètres parmi ceux décrits plus tôt, pouvions-‐nous analyser pour permettre de mesurer les variations de qualités du signal GSM. Le RxLev et RxQual peuvent être de bons indicateurs de la qualité du signal GSM/UMTS. Le problème principal est qu’il faut que la MS soit en train de communiquer pour pouvoir atteindre ces informations. Ce qui augmenterait significativement les coûts. En plus de cela, ces paramètres ne sont pas directement reliés aux conditions météorologiques. Concernant l’UMTS, ni le RSSI, ni le ECIO ou le RSCP ne représentent physiquement la puissance du signal émis par l’antenne (ceci n’est pas accessible par les appareils standards). Cependant le RSSI est ce qui se rapproche le plus de cela, et est accessible dans la plupart des appareils, grâce aux commandes AT. Par conséquent, nous avons choisi d’étudier l’influence des changements climatiques et en particulier des précipitations sur ces paramètres (RSSI, ECIO et RSCP)


28

6 CONCEPTE DE L’INSTALLATION

7 NANO-‐ORDINATEUR : LE BANANA PI

7.1 Qu’est-‐ce que c’est ?

Le Banana PI est ce qu’on appelle un nano-‐ordinateur : ce sont des ordinateurs dont la taille équivaut plus ou moins celle d’une carte de crédit. C’est une technologie assez récente, mais qui est en plein essor. Banana Pi est d’ailleurs loin d’être la seule option sur le marché : on compte notamment parmi ses concurrents le raspberry pi, l’arduino ou le beagleboard. Ce type d’évolution a été possible grâce à l’architecture RISC (Reducted Instruction Set Computer), qui est un type de microprocesseur caractérisé par un jeu d’instructions simples. Ceci a permis, par leur petite taille, de développer des SoC (System on a Cheap) avec l’ensemble des processeurs et contrôleurs nécessaires sur une surface de 1 ou 2 cm.

FIGURE 12: SCHÉMA DE L'INSTALLATION

FIGURE 13: LE BANANA PI


29

7.2 Caractéristiques

Le Banana Pi supporte différents systèmes d’exploitation tel que Debian, Unbuntu, Android, Fédora… Il possède l’ensemble des caractéristiques suivantes :

• CPU : Cortex-‐A7 dual-‐core 1GHz. • RAM : 1GB DDR3. • ROM : Emplacement pour carte SD et port SATA. • Sortie HDMI, CVBS, sortie LVDS dédiée. • Jack 3,5mm, microphone intégré. • 2 ports USB 2.0, 1 port USB OTG, 1 port mini-‐USB pour l’alimentation • GPI/O 26 broches

FIGURE 14: REPRÉSENTATION DU BANANA PI N°1


30

7.3 Systèmes d’exploitations compatibles

Trouver une un système d’exploitation fonctionnant n’a pas été très facile, non pas parce qu’ils ne sont pas disponibles, mais seulement qu’un grand nombre de fichiers accessibles sur internet sont corrompus, et par conséquent inutilisables. C’est pourquoi nous avons utilisé un des premiers OS fonctionnant que nous avons trouvé : le Bananian Linux. Le Bananian Linux est une image Debian 7 préinstallée et optimisée pour le Banana Pi. Debian 7, aussi appelé wheezy, paru le 4 mai 2013, est un système d’exploitation GNU/Linux qui possède ces différents éléments :

• Linux Kernel 3.2; • X-‐server: X.Org 7.7; • GNOME 3.4; • KDE 4.8.4; • Xfce 4.8; • Libc: eglibc 2.13; • Apt 0.9.7 • Possède des services et applications préinstallés comme des server SSH et NTP.

Cet OS utilise moins de 25 MB de RAM et peut être installé sur une carte SD de 2GB.

FIGURE 15: REPRESENTATION DU BANANA PI N°2


31

7.4 Connexion avec les différents capteurs

FIGURE 16: CONNEXION DU BANANA PI AVEC LE RESTE DU MATÉRIEL


32

8 CAPTEUR DE TEMPERATURE ET D’HUMIDITE

8.1 Modèle

Le capteur de température et d’humidité est le con-‐hytelog-‐usb de chez hygrosens. C’est donc un capteur que l’on branche grâce à un port USB. Il a son propre logiciel d’affichage de données, cependant il était impossible d’exploiter ses (données dans un script et le logiciel n’existait que pour les systèmes d’exploitation Windows. Le capteur peut effectuer des mesures de températures comprises entre -‐40 à 80 °C avec une résolution de 0,01 °C, et des mesures d’un taux d’humidité variant de 0 à 100% rH avec une résolution de 0,01%. Il a une précision de +/-‐ 0,3 K° et de +/-‐ 2% rH à 23°. Il est alimenté à travers le câble USB et nécessite 25mA pour son fonctionnement.

8.2 Interprétation des données transmises

Alors que le capteur est connecté sur un port série de l’ordinateur, il est possible de voir des données arriver par ce dernier. Les données reçues sont envoyées par bloc. Un bloc commence par un symbole “@” et finit avec le symbole “$”. A l’intérieur d’un bloc il y a deux types de données : les données à propos du capteur lui-‐même, dites « informatives » et dont la ligne commence par un “I”, et les données traitant du de la température et de l’humidité, dites de « mesures » dont la ligne commence par un “V”. Après le “I” dans les données « informatives » il est possible de voir:

• 8 Bit (deux caractères ASCII) pour le numéro du canal logique. Le capteur peut transmettre des données au travers de vingt canaux différents, qui sont assignés tour à tour.

• 8 Bit (deux caractères ASCII) pour le numéro d’identification de la cellule. • 8 Bit (deux caractères ASCII) pour le numéro d’identification du matériel. • 48 Bit (douze caractères ASCII) pour le numéro de série du capteur. • 8 Bit (deux caractères ASCII) pour le check-‐sum (CRC). • et “<CR>” comme fin de ligne.

Après le “V” dans les données de « mesures »:

• 8 Bit (deux caractères ASCII) pour le numéro du canal logique. • 2 Byte (quatre caractères ASCII) pour la valeur de la mesure relevée. • 8 Bit (deux caractères ASCII) pour le check-‐sum (CRC). • Et “<CR>” comme fin de ligne.

FIGURE 17: HYTELOGO-‐USB


33

Voici un exemple de bloc que le capteur peut envoyer: @ I01010100B00725030178 V01099EC6 I02020100B00725030148 V02179A73 I035300B5 V03066EE5 I04550065 V040541A8 $ La première ligne et la troisième (peu intéressante dans notre cas) nous donnent l’identité du capteur, le canal utilisé et de nombreuses d’informations sur les caractéristiques du capteur. Lorsqu’une ligne commence par V cela signifie que les données qui suivent sont des mesures. V01 pour la température, V02 pour l’humidité. Ensuite il suffit de traduire les deux bytes suivant en décimal, et de réaliser ces opérations :

𝑇 (𝑡𝑒𝑚𝑝é𝑟𝑎𝑡𝑢𝑟𝑒 𝑒𝑛 °𝐶) = !"#$%& !é!"#$% !"#$%é!""

, donc dans notre cas T= 24,62°C.

𝐻 ℎ𝑢𝑚𝑖𝑑𝑖𝑡é 𝑒𝑛 % = !"#$%& !é!"#$% !"#$%é!""

, donc dans notre cas H=30,21 %.

Il a donc suffit de réaliser un script qui traduisait ces données pour pouvoir les interpréter.

9 MODEM

9.1 Huawei E3531

Ce modem est un simple modem 3G USB sans fil. Très facile à utiliser, il comporte néanmoins un grand nombre de limitation pour faire de la recherche : la documentation technique est impossible à trouver et seulement très peu de commandes AT sont compatibles. Cependant, ce fut suffisant pour un premier développement, et une bonne manière pour comprendre comment fonctionnent les modems. Nous l’avons utilisé jusqu’à la fin, bien qu’il soit limité.

9.2 UR5i v2

Le UR5i v2 est le premier modem industriel utilisé dans ce projet. Dans un premier temps, après avoir lu la documentation, il semblait correspondre parfaitement à nos besoins, car il acceptait différentes commandes AT très utiles (the AT^SMONC, AT^SMOND, AT^MONI and AT^MOND). Mais rapidement, nous nous sommes rendus compte que la dernière version n’était pas compatible avec ces commandes.


34

Cependant nous avons continué à l’utiliser pour envoyer les données à travers le protocole SFTP en utilisant sa connexion internet.

9.3 Gemalto

Le gemalto est un modem que nous avons acquis en cours de projet (mi juin). Il accepte la commande AT^SMONC, et peut donc rendre compte du RSSI, RSCP et Ec/Io de la cellule avec laquelle il est connecté et des six cellules voisines. Cependant faute de temps, il n’a pas été possible d’adapter le script à sa configuration.

10 CARTE SIM « ROAMING »

Les premiers essais de mesures du RSSI ont été réalisés avec une carte SIM dite « normale » de l’opérateur A1. Cela fonctionnait bien, et les commandes AT basiques étaient compatibles. Cependant, comme c’était une carte SIM A1, il n’était pas possible de se connecter à un autre réseau que ceux de A1, ce qui limitait très vite les possibilités de notre programme. C’est pourquoi nous nous avons décidé de travailler avec une carte SIM « roaming ». Roaming signifiant vagabonder en anglais, désigne ici le fait qu’une telle carte SIM peut se connecter à tous les réseaux (cela dépend des contrats entre les opérateurs nationaux et le fournisseur de la carte SIM « roaming »). L’utilisation de ce type de carte SIM nous a ouvert de nouvelles portes dans nos recherches, et nous avons pu nous connecter à un grand nombre de réseaux.

11 COMMANDES AT

Aussi appelées commandes Hayes, les commandes AT constituent un langage permettant de communiquer directement avec un modem. Elles ont d’abord été développées pour le smartmodem 300 (pour 300 bauds) de chez Hayes, puis ont ensuite été élargies à l’ensemble des modems. Ce sont des commandes que l’opérateur peut directement envoyer au modem en mode Command, et qui permettent par exemple de composer un numéro téléphone, de commander le raccordement du modem à la ligne, ou d’obtenir des informations sur l’état de la ligne (ce qui nous intéresse dans notre cas).

11.1 Histoire :

Avant l’apparition du BBS (Bulletin Board System), ou même d’internet, les modems utilisaient le réseau téléphonique avec un modem dont l’adresse était connue à chaque extrémité. Ils pouvaient


35

fonctionner selon deux modes : « originate » (originaire) ou « answer » (réponse). Généralement, l’utilisateur en position originaire devait composer le numéro manuellement. Le modem en attente de l’appel répondait, la communication téléphonique était coupée mais les deux modems restaient connectés. Il fallait ensuite que l’utilisateur coupe manuellement la connexion entre les deux modems. Dans les années quatre-‐vingt, avec l’apparition des modems dits intelligents et l’automatisation des systèmes, il a fallu développer un jeu de commandes pour permettre aux modems de gérer différentes actions sans l’intervention d’un opérateur. C’est ainsi que les commandes Hayes ont vu le jour. Et grâce à la puissance de leur syntaxe et leur relative simplicité d'utilisation, ces commandes sont devenues un standard. Cependant il faut que le modem ait été configuré préalablement, pour pouvoir être piloté au moyen des commandes AT.

11.2 Fonctionnement et syntaxe

En 1981, Hayes Communication a implémenté sa solution dans son smartmodem en réutilisant les broches déjà existantes, mais le modem pouvait fonctionner selon deux modes qu’il pouvait choisir lui-‐même:

• Le mode donnée dans lequel le modem envoie les données au modem commandé. (Un modem en mode data traite toutes les données qu’il reçoit de l’ordinateur, et les envoie sur la ligne téléphonique.

• Le mode commande dans lequel le modem interprète les données reçues comme des commandes, qu’il exécutera. Et c’est dans ce dernier mode qu’il est possible d’exécuter les commandes AT.

Les commandes Hayes comprennent un grand nombre d’actions possibles, allant de la manipulation de ligne téléphonique, jusqu’à la configuration du modem. Cet ensemble de commande a été copié verbatim, par presque tous les fabricants de modem de l’époque. Les commandes AT (AT pour attention), peuvent être divisées en quatre groupes :

1. Les commandes basiques avec une majuscule suivie d’un nombre. Exemple : M1. 2. Les commandes étendues avec un « & » (Esperluette) et une lettre majuscule suivie d’un

nombre. Exemple : &M1. 3. Les commandes exclusives : habituellement avec une barre oblique inversée (« \ ») ou un signe

pourcent (« % »). Ces commandes varient selon les fabricants. 4. Les commandes de registre. Exemple : Sr=n où r est numéro du registre à changer, et n la

nouvelle valeur qui est attribuée. Un registre représente un emplacement spécifique dans la mémoire. Les modems ont très peu de

mémoire. Le quatrième groupe de commandes sert à entrer une valeur dans un registre particulier, qui pourra être utilisée de nouveau par le modem ou la communication plus tard.

Bien que la plupart des commandes est définie par une combinaison lettre-‐chiffre, le zéro reste optionnel (M0=M). Il existe aussi certaines combinaisons spéciales :

• <CR>, retour charriot, est une commande dont la valeur, en décimal ASCII entre 0 et 255, est définie par le paramètre S3. Sa valeur par défaut est 13.

• <LF> Line Feed, ou fin de ligne, est une commande dont la valeur, en décimal ASCII entre 0 et 255, est définie par le paramètre S4. Sa valeur par défaut est 10.


36

• <…> Un mot entre deux chevrons sont des éléments syntaxiques et n’apparaissent pas dans la ligne de commande.

• […] Sont des paramètres optionnels.

Une commande AT contrôle l’interaction entre un terminal utilisateur tel qu’un ordinateur, et un terminal mobile tel qu’un modem. La figure précédente montre cette interaction.

11.3 Exemples théoriques d’envoi de commande AT et de sa réponse.

FIGURE 18:INTÉRACTION ENTRE LE MODEM ET LE TERMINAL UTILISATEUR

FIGURE 19: COMMANDE AT THÉORIQUE


37

Par exemple avec une commande que nous utilisons, en écrivant : AT+HSCQ ? On va recevoir une réponse de la forme : ^HSCQ : « WCDMA », 30, 30, 58

11.4 Principales commandes AT utilisées

AT COMMAND ROLE E3531 Gemalto ER71 v2 AT+COPS=?

Donne la liste des opérateurs et des réseaux disponibles.

Acceptée Acceptée mais syntaxe différente

Acceptée

AT+COPS=1,2,"networkname","netwworktype"

Sélectionne et connecte le modem à un opérateur en particulier.


Acceptée

AT^HCSQ? Demande le RSSI, RSCP et ECIO (les deux derniers seulement si le réseaux est UMTS)


Acceptée mais syntaxe différente

AT+CREG? Demande le LAC et le CELLID de la BSS avec laquelle le modem est connecté.


Acceptée mais syntaxe différente

AT&F Ensemble de commande pour envoyer un SMS.

Acceptée Non testée Non testée AT+CMGF=1 Acceptée Non testée Non testée AT+CSCS="GSM" Acceptée Non testée Non testée AT+CMGS="+phonenumber" Acceptée Non testée Non testée AT^SMONC, AT^SMOND, AT^MONI, AT^MOND.

Ces quatre commandes peuvent donner le RSSI, RSCp et Ec/Io de la cellule avec laquelle la MS est connectée mais aussi des six cellules voisines.

Non acceptée

Acceptée Non acceptée

Il faut garder en tête que les commandes AT ne fonctionnent que si elles ont été implémentées par les fabricants. C’est pourquoi la syntaxe peut différer d’un modem à l’autre (parfois même entre deux versions du même modem). Le meilleur moyen de savoir quelles sont les commandes disponibles et leur syntaxe est de consulter leur documentation.


38

11.5 Règles pour utiliser les commandes AT.

• Chaque commande doit contenir une seule commande AT, et finir avec un retour chariot. • Une commande AT ne peut pas être interrompue, après avoir envoyé la commande, l’utilisateur doit

attendre que le terminal mobile ait répondu avant d’envoyer une autre commande. • Certaines commandes AT renvoient une réponse après un long moment, et dans le but d’éviter des

interférences avec d’autres évènements, il est conseillé de récupérer le résultat de manière asynchrone.

12 LE SCRIPT

12.1 A propos de Python Python est un langage informatique dit de haut niveau. Il a été conçu avec comme buts principaux : facilité de lecture et syntaxe simple afin de réduire sa complexité en comparaison avec d’autre langage comme java ou C++.

12.2 Structure générale

FIGURE 20: STRUCTURE DU SCRIPTE


39

12.2.1 Librairies utilisées Pour faire fonctionner l’ensemble du programme, nous avons du faire appel à différentes bibliothèques python. Dans les paragraphes suivants, nous allons décrire l’ensemble de ces bibliothèques.

12.2.1.1 Serial

Cette bibliothèque donne au programme, l’accès au port série, donc au port usb. Dans notre programme, elle est utilisée pour accéder au con-‐hytelog-‐usb.

12.2.1.2 Time

Time fournit plusieurs fonctions en relation avec le temps, cependant nous l’utilisons principalement pour suspendre le programme pendant ‘s’ secondes grâce à time.sleep(s).

12.2.1.3 Sqlite

Cette bibliothèque permet l’utilisation de base de données dans un programme python. SQLite est une bibliothèque écrite en C fournissant, qui a pour particularité de ne pas reproduire le schéma habituel client-‐serveur, mais d’être directement intégrée au programme. Nous l’utilisons pour l’ensemble de nos bases de données.

12.2.1.4 Datetime

Datetime fournit un ensemble de classes très pratique pour la manipulation des variables concernant les dates et le temps.

12.2.1.5 Subprocess

Cette bibliothèque permet de générer de nouveaux processus, de se connecter à leur « pipe » d’entrée/sortie/erreur et d’obtenir leur code de retour. Notre programme l’utilise principalement lorsqu’il communique avec le terminal.

12.2.1.6 Os

Grâce à Os, le programme peut utiliser des fonctions dépendantes du système d’exploitation. Dans notre cas, nous l’utilisons pour exécuter des commandes dans le « subshell » comme super utilisateur.

12.2.1.7 Threading

Threading construit une interface de processus de haut niveau, par-‐dessus d’autres processus de bas niveau. En quelque sorte cela permet d’exécuter des processus en parallèle, et ainsi éviter de stopper toute l’application en cas de problème.

12.2.1.8 RPI.GPIO

Ce module gère la communication avec les pins du Banana Pi. Dans notre programme il est exclusivement utilisé dans le thread ledIndicator().


40

12.2.1.9 Paramiko

Paramiko est un module qui permet l’utilisation du protocole SSH, fournissant les fonctionnalités client et serveur. Pour plus de détails, voir annexes.


41

12.3 Déroulement du script : schéma blocs

FIGURE 21: SCHÉMA BLOCS DU DÉROULEMENT DU SCRIPT


42

12.4 Structure des différentes bases de données

Structure de la base de données Analysedata :

date temp hydro error LAC cellid networkname networktype rssi rscp ecio antenaid

blob Float Float float int int blob blob int int int blob

Date: date en format UTC format. Temp: température en degrés Celsius. Hydro: humidité relative en pourcent. Error: la fiabilité directe du capteur d’humidité et de température en pourcentage. Lac: Local Area Code. Cellid: Cell-‐id Networkname: Le nom du réseau. Networktype: Le type de réseau: GSM ou WCDMA Rssi: Valeur du rssi. Entre 0 et 96, et 255 signifie valeur inconnue ou indétectable. Rscp: Valeur du rscp. Entre 0 et 96, et 255 signifie valeur inconnue ou indétectable. Ecio: Valeur du ecio Entre 0 et 65, et 255 signifie valeur inconnue ou indétectable. Antenaid : Un code d’identification unique par antenne fait avec le lac, le cell id et le networkname. Exemple :

date temp hydro error LAC cellid networkname networktype rssi rscp ecio antenaid

2015-‐07-‐24T08:18:35.025323+00:00

25 54.91 100 2012 6776040

3 AT "WCDMA" 51 39 41 201267760403 AT

A propos des valeurs du RSSI, RSCP et Ec/Io : Les valeurs se trouvant dans la base de données ne sont pas les valeurs réelles en dBm des différents paramètres. Voici une table de conversion :

• Pour le RSSI 0 signifie que RSSI <-‐120 dBm 1 signifie que -‐120 dBm < RSSI <-‐119 dBm 2 signifie que -‐119 dBm < RSSI <-‐118 dBm 3 signifie que -‐118 dBm < RSSI <-‐117 dBm ..


43

95 signifie que -‐26 dBm < RSSI <-‐25 dBm 96 signifie que -‐25 dBm < RSSI

• Pour le RSCP 0 signifie que RSCP <-‐120 dBm 1 signifie que -‐120 dBm < RSCP <-‐119 dBm 2 signifie que -‐119 dBm < RSCP <-‐118 dBm 3 signifie que -‐118 dBm < RSCP <-‐117 dBm .. 95 signifie que -‐26 dBm < RSCP <-‐25 dBm 96 signifie que -‐25 dBm < RSCP

• Pour le Ec/Io 0 signifie que Ec/Io <-‐32 dBm 1 signifie que -‐32 dBm < Ec/Io <-‐31,5 dBm 2 signifie que -‐31,5 dBm < Ec/Io <-‐31 dBm … 63 signifie que -‐1 dBm < Ec/Io <-‐0,5 dBm 64 signifie que -‐0,5 dBm < Ec/Io < 0 dBm 65 signifie que 0 ≤ Ec/Io

12.5 Autre script python développés et utilisés.

Pour le bon fonctionnement de l’ensemble du capteur (banana pi + con-‐hytelog-‐usb + Huawei E3531), le banana pi fait appel à deux autres scripts : un pour une raison de stabilité, l’autre pour envoyer les données au travers du modem UR5i V2.

12.5.1 Crontest.py

Ce script est fait pour réinitialiser le script principal en cas de problème. En effet dans certains cas, le programme rencontre quelques difficultés surtout quand il s’agit de communiquer avec les réseaux, et peut rester enfermé dans une boucle. Pour éviter cela, le programme principal sauvegarde à chaque début de mesure un horodatage dans un fichier appelé error.txt et un autre horodatage à la fin de la mesure dans un autre fichier appelé seveerror.txt. Crontest.py va ensuite, toutes les minutes, comparer ces 2 valeurs avec le temps actuel. Si la différence avec le temps dans error.txt est supérieure à 5 minutes, crontest,py arrêtera le processus principal pour le réinitialiser. Si la différence avec le temps dans severeerror.txt est supérieure à 10 minutes, crontest.py arrêtera le script principal et redémarrera l´ordinateur.

Pour plus de détails sur cron, consulter le paragraphe 13.7.


44

12.5.2 Crontest2.py

Ce script permet de sauver la base de données sur un serveur sftp. Grâce à cron, ce script est lancé toutes les heures.

13 LES AUTRES PARAMETRES OU OUTILS UTILISES

13.1 Périphérique USB

13.1.1 Usb Modeswitch

De plus en plus les appareils USB ont leur driver installé dans leur mémoire : ainsi, quand ils sont connectés à un ordinateur, ils se comportent comme une clef USB et installe leur driver. Après installation, le driver change de mode, et la clef USB disparait et le nouveau mode (utilisation principale de l’appareil) est lancé.

USB modeswitch est un outil pour contrôler le multi-‐mode de différents appareils USB (dans notre cas il s’agit du modem). Il nous donne l’opportunité d’utiliser le modem selon différents modes. Pour exécuter USB Modeswitch, il est indispensable d’être en root ou sudo.

Dans notre programme nous utilisons une seule commande :

"usb_modeswitch -‐W -‐I -‐v 12d1 -‐p 1f01 -‐M '55534243123456780000000000000011062000000100000000000000000000'"

Cette commande force le modem à passer en mode série, et permet au script de communiquer

avec lui à l’aide de commandes AT. A noter que 12d1 et 1f01 sont les code d’identité vendeur (-‐v) et produit (-‐p) du modem qu’il est possible d’obtenir grâce à la commande linux lsusb.

‘55534243123456780000000000000011062000000100000000000000000000’ est la commande USB modeswitch qui permet de passer en mode serial.

13.1.2 Udev et udev rules

Dans un système basé sur linux, le répertoire /dev comporte les différents appareils comme des dossiers, appelés « node » (qui signifie nœud en anglais). Chaque nœud correspond à un appareil, qui peut exister ou ne pas exister. L’utilisateur peut ainsi utiliser ces nœuds pour interagir avec les appareils. Par exemple, le serveur graphic X écoutera le nœud /dev/input/mice, qui correspond à la souris, et qui fait bouger le pointeur.

A l’origine, le répertoire /dev contenait tous les appareils et périphériques du système, mais cela le rendait bien trop volumineux. C’est pourquoi Udev a été développé pour prendre en charge le répertoire /dev, conçu pour repousser les limites offertes à l’utilisateur et le rendre plus stable. En créant et nommant chaque appareil dans /dev, Udev fait le lien entre les informations données par sysf et les règles (appelées udev rules) données par l’utilisateur.


45

Les udev rules sont très pratiques et polyvalentes, et permettent, par exemple de : • Changer le nom par défaut attribué à l’appareil. • Changer les permissions et les propriétés de l’appareil. • Renommer l’interface d’un réseau. • Lancer un script lorsqu’un certain appareil est connecté.

Voici un exemple de udev rules, utilisé dans notre projet :

ACTION=="add" SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="0718", ENV{ID_MODEL_ID}=="0619", ENV{ID_SERIAL_SHORT}=="CB00524932077759", RUN+="/bin/mount /dev/sda1 /media/usb" ACTION=="add" SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="0718", ENV{ID_MODEL_ID}=="0619", ENV{ID_SERIAL_SHORT}=="CB00524932077759", RUN+="/bin/ScriptCopy" ACTION=="add" SUBSYSTEM=="block", ENV{ID_VENDOR_ID}=="0718", ENV{ID_MODEL_ID}=="0619", ENV{ID_SERIAL_SHORT}=="CB00524932077759", RUN+="/bin/umount /media/usb"

Cette règle, associée à un script appelé ScriptCopy, a été conçue pour transférer notre base de données vers une clef usb spécifique lorsque cette dernière est connectée. ACTION: détecte si une appareil est connecté ou déconnecté. SUBSYSTEM: identifie le sous-‐système de l’appareil. ENV: clef d’identification, qui peut être utilisée pour assigner ou identifier. RUN: Lance un programme.

13.2 Transfert des données et contrôle à distance

Plusieurs solutions ont été envisagées pour transférer les données du banana pi ver un autre périphérique, ainsi que pour avoir un certain contrôle à distance de ce dernier. Dans les paragraphes suivants, sont exposées les trois solutions les plus abouties.

13.2.1 Envoie des données par SMS

La première solution envisagée, fut d’envoyer au moyen de commandes AT, de transmettre les données sous forme de texte par SMS. Le script était assez simple, et fonctionnait plutôt bien. Les principaux inconvénients étaient qu’il fallait avoir un autre périphérique munis de la technologie GSM/UMTS pour recevoir les informations, et que le coût trop élevé d’un SMS limitait la quantité de données à transférer et le nombre de mises à jour. Cependant voici le script qui permettait d’envoyer les données :

def sendSms(usbPort, mess) :#sending an sms with the data in it


46

ser = serial.Serial(usbPort, 9600, bytesize=8, parity='N', stopbits=1, timeout=1, rtscts=False, dsrdtr=False)# connect to the serial with pySerial

cmd="AT&F\r\n" checkATCommand(cmd,'OK',ser) sleep(0.3) cmd2="AT+CMGF=1\r\n" checkATCommand(cmd2,'OK',ser) sleep(0.3) cmd3='AT+CSCS="GSM"\r\n' checkATCommand(cmd3,'OK',ser) sleep(0.3)

cmd3='AT+CMGS="+43*********"\r\n'#number of the other device for the reception of the sms

checkATCommand(cmd3,'>',ser) sleep(0.3) cmd3=mess+'\x1A\r\n' checkATCommand(cmd3,'OK',ser)

13.2.2 /bin/ScriptCopy

Ce script associé à une règle udev, permet le transfert automatique de notre base de données vers un périphérique USB. Ce fut la seconde solution envisagée. Simple à mettre en œuvre, peu coûteuse (prix d’une clef USB) et efficace, nous avons continué à l’utiliser comme solution de secours lorsque les autres moyens mis en œuvre ne fonctionnaient pas. Le gros inconvénient est qu’il faut avoir accès au capteur pour pouvoir connecter la clef USB. Voici le script utilisé :

/bin/ScriptCopy #!/bin/bash set -vx cp /root/[email protected]/analysedata.db #chemin d’accès à la base de données sur le banana pi /media/usb/database/analyse.db #chemin d’accès à la clef USB ldconfig echo "Done!" exit 0 Ce script est situé dans le répertoire /bin.


47

13.2.3 SSH et /etc/network/interfaces

Le SSH (Secure Shell), est à la fois un protocole de communication et un programme informatique.

Pour utiliser le SSH sur le banana pi, nul besoin d’installer un nouveau programme, tant qu’on utilise bananian qui a par défaut un serveur SSH. Seulement, pour autorisation avec un autre ordinateur, le banana pi doit changer son adresse IP et être connecté à l’aide d’un câble Ethernet dit « crossover ».

Pour changer l’adresse du banana pi, il est possible de lui attribuer une adresse IP statique en passant par /etc/network/interfaces. Il suffit de modifier quelques lignes de ce dernier :

# interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback # dhcp configuration #allow-‐hotplug eth0 iface eth0 inet dhcp #static ip configuration auto eth0 #iface eth0 inet static #address 169.254.74.186 #netmask 255.255.255.0 #gateway 169.254.74.185 Avec cette configuration le banana pi utilise une adresse IP dynamique. En retirant les # et en mettant un # devant auto eth0, le banana pi utilisera alors une adresse IP statique (dans notre cas 169.254.74.186). Cela nous a permis de contrôler le banana pi à travers un autre ordinateur, et par la même occasion, de ne plus utiliser un écran, un clavier et une souris pour le banana pi. Cependant en cas de problème important, ou de restructuration du script il était bien plus pratique de revenir à la configuration complète d’origine du banana pi.

13.2.4 SFTP

SSH File Transfer Protocol, le SFTP, a été la solution retenue finalement pour le transfert de données. En effet le SFT est à la fois un protocole de communication fonctionnant à partir de SSH, mais aussi un programme en ligne de commande ce qui permettait de placer le capteur où bon nous semblait , de recevoir les données et d’ avoir accès à certains paramètres du banana pi.

Ce fut dans un premier temps la solution la plus pratique, car en association avec un crontab, il est alors possible de sauvegarder la base de données sur le serveur de l’entreprise, ce qui permet d’y avoir accès de n’importe quel autre ordinateur de l’entreprise. Ce fut aussi une solution peu couteuse car il a


48

suffit d’utiliser un autre modem (en l’occurrence le UR5i V2) muni d’une carte SIM avec un crédit de transfert de données par 3G assez élevé, pour transférer les données par le réseau.

13.3 Stabilité et sécurité

13.3.1 Tee

Tee est une commande utilisant les flux standards (sdtout, stdin) , qui lit une entrée et qui l’écrit dans la sortie standard et vers un ou plusieurs autres fichiers. Dans notre cas, tee est utilisé pour diviser la sortie de notre scripte et nous aider à comprendre ce qu’il se passe et pourquoi un crash peut arriver. Nous l’utilisons dans notre script crontest.py, pour exécuter

notre script principal avec cette syntaxe : python -u /root/roamingtempaveragenetworklist.py 2>&1 | tee -a output.txt Avec “2>&1” qui signifie “ 1 est la sortie standard de notre scripte (stdout), et 2 est la sortie standard des erreurs d’un script (stderr)”. Plus, le “tee –a output.txt “ qui signifie ajouter le tout dans le fichier output.txt.

13.3.2 Cron et Crontab

Cron est un programme linux qui permet à l’ordinateur d’exécuter des programmes, des commandes ou des logiciels automatiquement à une date ou une fréquence déterminées. Crontab est un programme où il est possible d’éditer la configuration de cron au travers de tableaux. Dans ces tables il est possible de voir quelle tâche va être exécutée, quand et éventuellement avec quelle périodicité. Ces tableaux s’organisent de cette manière : Mm hh jj MMM JJJ tâche

• mm représente les minutes (de 0 à 59) • hh représente les heures (de 0 à 23) • jj représente les jours du mois (de 1 à 31) • MMM représente les mois (jan, feb… ou de 1 à 12) • JJJ représente les jours de la semaine (0=Dimanche, 1 =Lundi, 2=Mardi… et 7=Dimanche pour les deux

types de calendriers)

FIGURE 22: FONCTION DE TEE


49

Ensuite pour chaque paramètre il existe différentes syntaxes, par exemple : • *: exécute à chaque unité du paramètre (0,1,2,3,4…). • 5,8: exécute à l’unité 5 et 8 • 2-‐5: exécute à chaque unité entre 2 et 5 (2,3,4,5). • */3: exécute chaque 3 unités (0,3,6,9,12…). • 10-‐20/*3: exécute chaque 3 unités, entre 10 et 20 (10,13,16,19)

Comme exemple voici une crontab que nous utilisons pour exécuter le script python chaque

minute :

* * * * * root python /root/crontest.py

Pour éditer ou ajouter une crontab, il faut exécuter dans le terminal cette commande : • gedit /etc/crontab

13.4 Cell ID et LAC : bases de données publiques

Grâce LAC et au cell ID, il est possible de d’obtenir plus d’informations sur les antennes avec lesquelles le modem est connecté, comme par exemple, ce qui nous intéresse particulièrement dans notre étude, la position GPS. Pour cela nous avons fait appel à une des bases de données publiques et libres d’accès. Pour obtenir ces informations il est nécessaire d’avoir aussi le MCC et MNC de l’antenne (qui sont assez faciles à obtenir). Les deux sites utilisés sont : • http://opencellid.org/ Opencellid est la plus grande communauté collaborative du monde collectant les données GPS des antennes, gratuit, pour un grand nombre d’activités commerciales ou privées. Plus de 49000 collaborateurs sont déjà enregistrés sur OpenCellID, envoyant en moyenne plus d’un million de nouvelles mesures chaque jour, améliorant ainsi considérablement la base de données. Et il est possible de de télécharger gratuitement cette dernière sur leur site. • http://www.cell2gps.com/ Ce localisateur d’antenne utilise le LAC et le cell ID ou les SID/NID/BID pour déterminer les positions des antennes avoisinantes. Chaque station couvre une zone particulière, et plus il y a d’antennes dans votre voisinage, plus le résultat de votre recherche sera précis.


50

14 RESULTATS ET ANALYSES

14.1 Tous premiers résultats

Cette courbe, relevée entre le 25 et le 27 Mai, est le premier résultat que nous avons obtenu après

un peu plus de 36 heures de mesures. La courbe bleue représente la température en degrés C°, la courbe rouge représente l’humidité en rH et la courbe verte représente le RSSI en dBm (mais en valeur brute du modem, c’est à dire que pour avoir la réelle valeur du RSSI, il faut se référer au paragraphe 12.4). Dans cette configuration, le capteur relève toutes les 5 minutes la température l’humidité et le RSSI. Ces résultats ne sont pas très intéressants au regard de notre but final, mais ils nous ont montré que nous devions forcer le modem à rester connecté à une seule et même antenne. En effet, dans cette configuration, le modem se connectait à une seule antenne et choisissait celle avec le meilleur signal. Ce qui rendait toute forme d’interprétation très difficile car en cas de baisse de qualité du signal, le modem se connectait à un réseau différent.

C’est donc suite à ces résultats que nous avons étudié la possibilité d’utiliser une carte SIM roaming. Nous avons aussi décidé d’augmenter la résolution de nos mesures.

14.2 Premiers résultats avec une carte SIM roaming.

FIGURE 23: PREMIERS RÉSULTATS


51

Les premiers résultats réalisés avec une carte SIM roaming ont été analysés avec Excel, pour avoir un aperçu rapide sur ce qu’il se passait. Nous avons pu voir que le GSM n’avait strictement aucune variation au court du temps (aucune variation perceptible un jour de pluie). Ces premiers résultats nous ont aussi permis de valider la nouvelle résolution choisie pour la température et l’humidité (mesurer en permanence, et faire une moyenne des mesures effectuées lorsque le relevé de RSSI, RSCP and Ec/Io est fini). En effet, les courbes sont plus lisses et comportent moins de sauts de valeurs.

L’étude attentive des courbes de l’évolution de RSSI et Ec/Io, nous a laissé perplexe. Sur ces courbes la on peut voir deux évènements pluvieux majeurs. Et les signaux semblent être influencé par ces phénomènes. Mais on distingue aussi une tendance journalière de variation sur l’ensemble des antennes, qui elle semble être liée à la température. Sur la figure 25, on peut voir différents phénomènes. Premièrement il existe de grands sauts de valeurs (entouré en rouge sur les figures 25 et 26), que nous ne pouvons pas expliquer. Deuxièmement, Il apparaît une baisse significative de la valeur du RSSI (entourée en vert sur les figures 25 et 26) au début de la première pluie. Enfin, on peut apercevoir une tendance journalière (mise en avant sur la courbe de Ec/Io en pointillés noirs), phénomène observé sur la grande majorité des courbes. Nous avons donc décidé de garder la même configuration pour faire le reste des mesures, mais de les analyser avec Matlab cette fois-‐ci, pour avoir plus de possibilités dans le traitement des données.

FIGURE 24: MESURE DU RSSI DE L'ANTENNE GSM DE T-‐MOBILE

AVEC POUR LAC: 12061 ET POUR CELLID: 14242


52

FIGURE 26: MESURE DU RSSI ET DU EC/IO DE L'ANTENNE UMTS DE LA COMPAGNIE ORANGE AVEC POUR LAC: 2012 ET POUR CELL: 6783489

FIGURE 25: MESURE DU RSSI ET DU EC/IO DE L'ANTENNE UMTS DE LA COMPAGNIE 3 AVEC POUR LAC: 2012 ET POUR CELL: 6784489


53

14.3 Analyse d’un mois de mesures

Au final nous avons mesuré du 22 juillet au 7 septembre 2015, et obtenu 92 443 mesures. Au total, le modem s’est connecté avec 33 antennes UMTS. Les conditions météorologiques n’ont pas été favorables à notre expérience, et il a été difficile d’établir une réelle connexion entre la qualité du signal UMTS et le peu de précipitations qu’il y a eu. Cependant nous avons pu observer certains phénomènes. Dans les courbes suivantes à nouveau la température est en degrés C°, l’humidité est en rH et le RSSI, le Ec/Io et le RSCP sont en dBm mais avec un offset, pour pouvoir les distinguer plus facilement.

Dans un premier temps, on retrouve la tendance journalière observée plus tôt (en pointillés rouges sur la figure 27). Nous pensions que ce phénomène était du à la surchauffe du modem, car il était en extérieur dans une boite étanche mais en contact direct avec le soleil (ce qui explique aussi les température de plus de 50° C). Mais il apparaît même les jours sans forte chaleur. Le cercle vert met en avant un phénomène observé après avoir déplacé le capteur de l’autre côté de l’immeuble. Ce creux dans les mesures de température est du à l’ombre d’une tour a proximité de nos bureaux.

FIGURE 27: RELEVÉ DU RSSI, RSCP ET ECIO DE L'ANTENNE UMTS T-‐MOBILE AVEC POUR LAC: 58160 ET POUR CELLID: 2001859


54

Malgré une analyse attentive des différentes données il n’a pas été possible d’établir une relation solide entre la variation de la qualité du signal UMTS ou GSM et les précipitations. Vous pouvez trouver d’autres courbes en annexe.

15 CRITIQUES ET FUTURES AMELIORATIONS

15.1 Critiques et problèmes

15.1.1 Difficultés pour rester connecté à un seul réseau

Une des principales difficultés que nous avons rencontrée, et qui nous cause encore des problèmes aujourd’hui même en utilisant une carte SIM roaming, est qu’il nous est pas possible de choisir un réseau en particulier. La carte SIM roaming nous aide seulement à se connecter à plus de réseaux à chaque boucle réalisée par le scripte, donc avoir plus de chance de se connecter avec la même antenne. Cependant, ce problème rend la résolution des mesures totalement aléatoire et cela rend l’analyse de ces données plus difficile car nous n’avons un relevé continu dans le temps. En bref, il nous est impossible de voir le comportement du signal émis par une antenne sur une longue période, tout ce que nous pouvons faire c’est espérer que le modem ce que connectera assez souvent à une antenne pour avoir un nombre de données assez important pour pouvoir être exploité.

15.1.2 Erreurs de script non résolues

Il arrive parfois que le script rencontre des erreurs que nous n’avons pas pu résoudre, et que nous avons essayé d’éviter grâce au scripte appelé crontest.py. Ces erreurs étant souvent aléatoires et inconnues, le seul moyen de les éviter étant de créer un programme qui vérifiait l’état du scripte principal. En plus de cela, crontest.py nous a permis de savoir à quel moment ces erreurs avaient lieux, et on pouvait ainsi déterminer la cause d’un tel crash dans le programme. La liste suivante, donne les dates et heures des différentes erreurs au cours d’un mois de mesures :

2015-07-24 16:00:04 2015-07-28 02:14:02 2015-07-28 14:41:03 2015-07-30 10:29:03 2015-08-04 21:38:03 2015-08-11 00:12:04 2015-08-15 20:59:03 2015-08-19 12:45:03 2015-08-21 12:44:04 2015-08-23 09:58:02 2015-08-23 12:12:05 2015-08-24 09:55:09


55

2015-08-24 14:05:05 2015-08-24 14:16:04

On peut voir qu’il n’y a pas de régularité particulière, cependant nous avons pu relever trois types

d’erreurs :

• CME ERROR:

Quand on communique avec un modem par commandes AT, l’appareil peut répondre « OK » ou « ERROR ». Ces messages d’erreur arrive assez aléatoirement, et parfois le modem ne va répondre que ce genre de message tant qu’il n’est pas réinitialisé. Au total nous avons reçu trois types d’erreurs CME :

+CME ERROR: 30 No network service +CME ERROR: 31 Network timeout +CME ERROR: 50 Quand l’erreur commence par "+CME ERROR", cela signifie que c’est une erreur spécifique. Par

exemple, si vous essayez d’envoyer un message avant de rentrer le code pin. Le problème avec ces erreurs est que la plupart du temps ce sont des erreurs dues au réseau, et a priori il est impossible de faire quoi que ce soit. Enfin il est surprenant de constater que la CME ERROR : 50 est une erreur qui n’existe pas dans la documentation du modem.

• Pas de réponse du modem

Il arrive aussi que le modem ne donne aucune réponse, sans aucune raison apparente. Et il arrive parfois que le modem ne réponde toujours par après plus de mille demandes. Cela arrive en particulier avec ce type de commande AT :

AT+COPS=1,2,"*****",*

Pour résoudre ce problème nous avons limité le nombre (à 100) de demande que le scripte peut

faire au modem.

• Les erreurs propres au scripte : Enfin deux erreurs, dues au script lui-‐même, peuvent avoir lieu sans que nous puissions en déterminer l’origine. Voici la première : Exception in thread initiating: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 505, in run self.__target(*self.__args, **self.__kwargs) File "/root/roamingtempaveragenetworklist.py", line 866, in initiating Analysedata()


56

File "/root/roamingtempaveragenetworklist.py", line 124, in Analysedata conn2.commit()

OperationalError: database is locked

Et la deuxième :

Exception in thread initiating: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 505, in run self.__target(*self.__args, **self.__kwargs) File "/root/roamingtempaveragenetworklist.py", line 820, in initiating usbPort=searchModem() File "/root/roamingtempaveragenetworklist.py", line 307, in searchModem return usbPort

UnboundLocalError: local variable 'usbPort' referenced before assignment Ce sont des erreurs qui n’apparaissent qu’après un certain temps de fonctionnement, ce qui est un peu étrange pour la seconde erreur car usbPort est déterminé au tout début du scripte. Pour la première erreur, cela est surement dû à un conflit entre deux scriptes utilisant la même base de données.

15.1.3 Matériel

Le but de ce projet était de réaliser à moindre coût, un capteur pour détecter les variations de la qualité du signal cellulaire. Il a donc fallu utiliser un matériel bon marché, qui reste parfois très limité. Pour le modem par exemple, il n’était possible d’utiliser qu’un nombre de commandes AT restreint. De plus le modem n’était pas muni d’antenne, ce qui nous a contraints à le placer dehors, où il a été influencé par les conditions climatiques (fortes chaleurs) dans son fonctionnement.

De mon point de vue, tout ce matériel bon marché a limité les recherches. J’aurai trouvé plus judicieux d’utiliser un matériel un peu plus précis, bien qu’un peu plus cher, car finalement après six mois de recherche nous ne savons pas exactement quelles sont les conséquences des précipitations sur la qualité du signal cellulaire, et nous allons probablement acheter ce matériel un plus cher pour pouvoir continuer les recherches. En commençant avec du matériel plus performant, on aurait pu déterminer si étudier la qualité du signal cellulaire valait le coût, et ensuite adapter des appareils bon marché pour qu’ils détectent ces variations.

15.1.4 Manque de données

Pour observer et trouver un modèle à travers l’étude des données et des courbes, il est nécessaire d’avoir un très grand nombre de données. Même si les conditions climatiques peuvent changer relativement vite, pour déterminer un certain modèle de variation, il faut pouvoir observer ce phénomène un très grand nombre de fois. Malheureusement avec seulement un mois de mesures, et surtout un mois


57

avec très peu de pluie, cela n’a pas rendu la tâche facile. En effet au cours du mois de relevés, il n’a plu qu’une seule fois, mais dans des proportions suffisantes pour pouvoir être détectées par notre capteur. En laissant le capteur mesurer encore quelques mois peut être sera-‐t-‐il possible d’avoir des résultats plus intéressants.

15.2 Futurs travaux et améliorations

15.2.1 Stabilité et précision du capteur

Comme décrit plus tôt, le capteur a encore quelques problèmes de stabilité, malheureusement incontrôlables. Ceci à bien sur une influence négative sur la qualité des résultats. En effet lorsqu’ un crash se produit, comme décrit plus haut, aucune donnée n’est collectée pendant au minimum dix minutes, ce qui est une source supplémentaire de manque de données et de problèmes de résolution. Un des futurs travaux serait donc de résoudre ces différentes erreurs, pour éviter leur conséquence.

En plus de cela, le modem utilisé (Huawei E3531), a une résolution de 1 dBm pour le RSSI, RSCP et ECIO. Comme nous ne connaissons pas la réelle influence des précipitations sur le signal radio, ce modem n’est peut être pas capable de capter les variations de qualité. Un modem avec une sensibilité plus grande pourrait être plus utile.

15.2.2 Ajout de fonctionnalités

Jusqu’ici nous utilisons deux modems : un pour scanner les différentes antennes et un autre pour envoyer les données sur notre serveur. Une des fonctionnalités à ajouter à notre capteur serait d’utiliser un seul et unique modem pour les actions énoncées ci-‐dessus.

En plus de cela, pour une implantation du capteur à grande échelle, il faudra ajouter un module GPS à chaque capteur pour pouvoir quadriller une zone en ayant la position exacte des capteurs.

Ensuite l’utilisation d’un nouveau modem, type gemalto, pourra nous permettre de comparer les performances d’un modem industriel avec celles d’un modem grand public. Il faudra alors adapter le scripte actuel aux gemalto, car les commandes AT varient d’un modem à l’autre.

Enfin une restructuration des bases de données sera nécessaire. En effet, à partir du moment où l’on utilise plusieurs capteurs, il faudra donner un nom unique à chaque capteur, ainsi que sa position. Une éventuelle réorganisation, consisterait à rajouter ces différentes colonnes dans la base de données :

• SensorLoc, string pour la position de capteur. • SensorLocID, int (pour filtrage rapide) • DeviceName, string pour le nom du capteur • DeviceID, int (pour filtrage rapide) • NetworkID, int (pour filtrage rapide) • NetworkTypeId, int (pour filtrage rapide)

A noter que les deux dernières ligne serviraient à mieux filtrer la base de données déjà existante.


58

15.2.3 Utilisation d’autres types de capteurs

Il a été évoqué de changer littéralement de capteur, c’est-‐à-‐dire d’arrêter de travailler avec des modems, mais d’utiliser soit des capteurs dédiés à l’analyse de signaux GSM/UMST/LTE, soit utiliser un scanneur signaux radio.

La première solution, qui serait surement la plus efficace, a un problème majeur : son coût. En effet un capteur de ce type-‐là coûte plusieurs milliers d’euros il sera donc impossible de l’équiper à tous les appareils.

La deuxième solution quant à elle, présente aussi un autre problème majeur : l’investissement en moyens humains. En effet utiliser un simple scanneur de signaux radio, nécessitera de développer un programme complet d’interprétation des signaux pour retrouver les informations nécessaires à une analyse pertinente.

15.2.4 Etudes d’une possibilité d’implantation des capteurs dans le sud de la France.

Nous avons étudié l’implantation de nos capteurs dans le Gard. Pour cela nous avons analysé la densité de réseau cellulaire dans cette région, à l’aide des différents sites cités en 13.4 et en croisant les différentes locations disponibles selon notre contact en France. Pour la voir, consulter les annexes au 19.7.


59

16 CONCLUSION

Le projet n’a pas permis d’établir un lien réel entre les précipitations et les variations de qualité du signal GSM/UMTS. Cela peut être expliqué par des conditions météorologiques non favorables à ce type d’expérience. En effet, seulement de très faibles pluies ont eu lui durant le mois de relevé, ce qui n’a pas permis d’affirmer une réelle influence de l’hydrométrie sur les communications GSM/UMTS. Le matériel utilisé n’étant pas le plus adéquat pour atteindre avec succès l’objectif de ce projet, la précision du système actuel pourra être mise à l'épreuve pendant la prochaine saison d'hiver où de plus grosses intempéries sont théoriquement prévues. Néanmoins, ce domaine de recherche est nouveau et de nombreuses de pistes restent à exploiter. En effet , une amélioration de nombreux paramètres tels que la résolution du modem, la durée des relevés ou une augmentation du nombre de capteurs pourrait apporter plus d’éléments à la recherche. De plus, le GSM et l’UMTS sont des technologies qui utilisent des fréquences relativement basses, et conséquent peu sensibles aux intempéries. Mais les technologies actuelles et futures, telle que la 4G (LTE) et la 5G utilisent des fréquences bien plus élevées. Une étude similaire utilisant ces technologies est envisageable dans le futur, lorsqu’elles seront plus répandues à travers le monde. Cependant l’étude complète et attentive du réseau et des différents appareils que nous avons assemblés, nous a permis de construire un capteur de RSSI, de RSCP et d’Ec/Io qui fonctionne dans les limites qui lui étaient technologiquement imposées. Effectivement, le capteur construit a été capable de relever l’ensemble des informations nécessaires pendant plus d’un mois et demi sans interruption, nous permettant de tirer des enseignements concernant les limites des techniques utilisées. Ce qui prouve que le premier objectif de ce projet a été atteint. J ‘ai travaillé seul sur ce projet pendant les six mois de stage, mais j’ai transmis, au cours des deux derniers mois, mes connaissances et les résultats de mon travail , à plusieurs de mes collègues, car AIT a décidé de continuer les recherches dans cette direction et le capteur continue et continuera à relever des informations. D’un point de vue personnel, cette expérience m’a permis de découvrir un volet du métier d’ingénieur avec lequel je n’avais jamais vraiment eu contact : la recherche. J’ai appris à chercher, analyser et synthétiser un grand nombre de connaissances pour pouvoir choisir la solution ad hoc. Il aussi fallu apprendre l’autonomie, aucun de mes collègues n’étant officiellement impliqué dans le projet, j’ai principalement progressé seul dans mes recherches et mes solutions pendant les quatre premiers mois. Cependant je profitai de moments de pause ou des repas pour discuter des problèmes rencontrés ou des difficultés liées à l’inexpérience ou le manque de connaissances, et j’obtenais très souvent des réponses appropriées. Ce poste, comme l’ensemble des stages que j’ai réalisé au cours de ma scolarité, m’a permis enrichir ma formation d’ingénieur en Génie Electrique de l’INSA de Strasbourg.


60

17 BIBLIOGRAPHIE ET SOURCES

GSM et UMTS -‐ Rahnema, M. (1993) , Overview Of the GSM System and Protocol Architecture, IEEE Communications

Magazine. -‐ Helhel S., Özen S. Et Göksu H. (2008), Investifation of GSM signal variation dry and wet earth effects.

Progress in electromagnetics researche B, Vol. 1, 147-‐157. -‐ Werner M., Junge T. Et Vary P. (2004), Quality control for AMR speech in GSM networks. Institute of

Communication Systems and Data Processiong. -‐ http://www.telecomhall.com/what-‐is-‐ecio-‐and-‐ebno.aspx -‐ http://simcom07.blogspot.co.at/2011/08/gsm-‐logical-‐channels.html -‐ http://en.wikipedia.org/wiki/Common_pilot_channel -‐ http://www.telecom.ulg.ac.be/publi/publications/mvd/Demoulin2004Principes/ -‐ http://www.differencebetween.net/technology/difference-‐between-‐tdma-‐and-‐cdma/

Commandes AT

-‐ http://www.codeproject.com/Questions/788129/AT-‐Command-‐ATplusCMGS-‐giving-‐error-‐CMS-‐Invalid-‐tex

Linux -‐ https://www.howtoforge.com/community/threads/re-‐static-‐ip-‐and-‐network-‐configuration-‐in-‐debian-‐

linux.66095/ Python -‐ http://blog.scphillips.com/posts/2013/07/getting-‐a-‐python-‐script-‐to-‐run-‐in-‐the-‐background-‐

as-‐a-‐service-‐on-‐boot/ -‐ http://stackoverflow.com/ Ondes radios -‐ TAMIR, T. (1977), Radio Wave Propagation Along Mixed Paths in Forest Environments. IEEE

TRANSACTIONS ON ANTENNAS AND PROPAGATIO, VOL AP-‐25. -‐ Klaasen, W. (1990), Attenuation and reflection of radio waves by a melting layer of precipitation. IEEE

Proceedinfs, Vol.137, Pt. H, No.1. -‐ Milda Tamošiūnaitė, Mindaugas Žilinskas, Milda Tamošiūnienė et Stasys Tamošiūnas (2011)

Atmospheric Attenuation due to Humidity, Electromagnetic Waves,Prof. Vitaliy Zhurbenko (Ed.), ISBN: 978-‐953-‐307-‐304-‐0,InTech


61

18 LEXIQUE ET ACRONYMES

Acronyme Nom complet Définition ARFCN Absolute radio-‐frequency channel number Code qui spécifie quelle paire de

fréquences porteuse utiliser pour la transmission et la réception dans un système de radio-‐télécommunication terrestre.

BBS Bulletin board system Serveur équipé d'un logiciel offrant les services d'échange de messages, de stockage et d'échange de fichiers, de jeux via un ou plusieurs modems reliés à des lignes téléphoniques.

BER Bit error rate valeur relative au taux d'erreur mesuré à la réception d'une transmission numérique, relative au niveau d'atténuation et/ou de perturbation d'un signal transmis.

BLER Block error rate Ratio du nombre de blocs avec erreur(s) sur le nombre total de blocs reçus par le système digital. Il est utilisé dans la W-‐CDMA pour les tests de performance.

BSS Base station subsystem Partie radio (RAN) d'un réseau de téléphonie mobile GSM, chargée de la connexion entre les stations mobiles (MS), c'est-‐à-‐dire les téléphones mobiles, et la partie commutation du réseau GSM (vers le MSC).

BTS Base transceiver station Elément de base du système cellulaire de téléphonie mobile GSM, appelé plus communément antenne-‐relais GSM. Elle est chargée de la liaison radio avec les stations mobiles.

CID Cell ID Nombre unique associé à chaque BTS dans une zone délimitée (LAC).

CRC Cyclic redundancy check Outil logiciel permettant de détecter les erreurs de transmission ou de transfert par ajout, combinaison et comparaison de données redondantes, obtenues grâce à une procédure de hachage.


62

dBm Rapport de puissance en décibels (dB) entre la puissance mesurée et un milliwatt (mW). Elle est utilisée dans les réseaux radio, micro-‐ondes et fibre optique comme une mesure commode de puissance absolue en raison de sa capacité à exprimer à la fois des valeurs très grandes et très petites sous une forme abrégée.

DL Downlink Communication de la BSS en direction de la MS. Appelé aussi bande descendante.

DTX Discontinuous transmission La transmission discontinue est un mécanisme qui permet à l’émetteur radio de s’interrompre pendant la majorité du temps pendant les pauses de la parole, pour les deux raisons : économiser la puissance dans le terminal mobile et réduire l’interférence globale par rapport à l’interférence dans l’air.

EIR Equipment Identity Register C'est une base de données comportant les informations de sécurité et d'identification relatives à un téléphone mobile GSM ou UMTS. C'est à partir de cet équipement qui stocke le code IMEI des terminaux qu'un opérateur de téléphonie mobile peut bloquer un téléphone portable volé.

FER Frame error ratio Rapport entre les données reçues avec erreurs et les données reçues sans erreurs. Utilisé pour déterminer la qualité de la connexion.

FDMA Frequency Division Multiple Access Mode de multiplexage destiné à la téléphonie mobile. Il s'agit d'un découpage en bandes de fréquences de manière à attribuer une partie du spectre à chaque utilisateur. De cette manière, chaque utilisateur se voit attribuer une ou plusieurs bandes de fréquences distinctes

Handover Ensemble des opérations mises en œuvre pour permettre qu'un téléphone mobile ou un smartphone change de cellule radio sans interruption de la conversation ou du transfert des données.

HLR Home Location Register Il s'agit de la base de données centrale d’un opérateur de réseau mobile, comportant les informations relatives à tout abonné autorisé à utiliser ce réseau et notamment sa localisation dans le réseau.


63

HSDPA High-‐speed Downlink Packet Access Protocole pour la téléphonie mobile offrant des performances dix fois supérieures à la 3G.

IMSI International mobile subscriber identity Numéro unique, qui permet à un réseau mobile GSM, UMTS ou LTE d'identifier un usager.

LAC Local area code Ensemble de BSS groupée pour améliorer le signal.

MCC Mobile country codes. Code pays sur trois chiffres, standardisé par l'Union internationale des télécommunications (UIT) dans sa recommandation E.212, pour les réseaux de téléphonie mobile, plus particulièrement dans les technologies GSM et UMTS.

MNC Mobile network codes Utilisé en combinaison avec le Mobile country code (MCC) pour l'identification univoque du réseau d'un opérateur de téléphonie mobile.

MS Mobile station Terme qui désigne un élément de base d'un système cellulaire de téléphonie mobile. Il s’agit du terminal physique et de la carte SIM.

MSC Mobile Switching Center Equipement de téléphonie mobile (GSM/2G) chargé du routage dans le réseau, de l'interconnexion avec les autres réseaux (réseau téléphonique classique par exemple) et de la coordination des appels

Nobe B Equivalent du BTS, mais en UMTS. PLMN Public Land Mobile Network Réseau de télécommunications qui

permet aux utilisateurs autorisés d'accéder à différents services en situation de mobilité à partir de terminaux mobiles ou portatifs.

PTSN Public switch telephone network Réseau téléphonique commuté, construit par un opérateur publique.

Retour chariot Désigne originellement le mécanisme physique permettant au chariot d'une machine à écrire de revenir en butée à gauche. Par extension, le terme désigne usuellement le retour à la ligne sur les traitements de texte : un passage à la ligne suivante.

rH Humidité relative Rapport de la pression partielle de la vapeur d'eau contenue dans l'air sur la pression de vapeur saturante (ou tension de vapeur) à la même température.

RISC Reduced instruction set computer Type d'architecture matérielle de microprocesseurs qui se caractérise


64

par un jeu d'instructions réduit, facile à décoder et comportant uniquement des instructions simples.

RSSI Received signal strength indicator Mesure de la puissance en réception d'un signal reçu d'une antenne (classiquement un signal radio).

RX Réception. RxLev Niveau de champ provenant de la BTS

mesuré au niveau du mobile. RxQual Paramètre qui évalue la qualité du

signal. SC Scrambling Code Code de brouillage. SIM Subscriber identity module Puce contenant un microcontrôleur et

de la mémoire. Elle est utilisée en téléphonie mobile pour stocker les informations spécifiques à l'abonné d'un réseau mobile

SIR Signal to interference ratio Quotient entre la puissance reçue de la porteuse du signal et les interférences dues aux autres signaux utilisant la même porteuse

SNR Signal to noise ratio Indicateur de la qualité de la transmission d'une information.

SoC System on a chip Système complet embarqué sur une seule puce, pouvant comprendre de la mémoire, un ou plusieurs microprocesseurs, des périphériques d'interface, ou tout autre composant nécessaire à la réalisation de la fonction attendue.

Sysfs Sysfs Système de fichiers virtuel introduit par le noyau Linux 2.6. Sysfs permet d'exporter depuis l'espace noyau vers l'espace utilisateur des informations sur les périphériques du système et leurs pilotes, et est également utilisé pour configurer certaines fonctionnalités du noyau

TDMA Time division multiple access Mode de multiplexage permettant de transmettre plusieurs signaux sur un seul canal. Il s’agit de multiplexage temporel, dont le principe est de découper le temps disponible entre les différentes connexions.

Throughput Taux de production ou la vitesse à laquelle quelque chose peut être traitée.

TS Time slot Créneau ou espace temporel. TX Transmission. UE User equipment Appareil employé par un utilisateur.


65

UMTS Universal mobile telecommunication system Troisième génération de réseau téléphonique basée sur le standard GSM.

UP Uplink Communication de la MS vers la BSS. VLR Visitor Location Register Le VLR est une base de données

temporaire contenant des informations sur tous les utilisateurs (Mobile Stations) d'un réseau, et qui est parfois intégré dans le Mobile service Switching Center(MSC).

W-‐CDMA Wideband Code Division Multiple Access Technique de codage utilisée dans la partie radio (UTRAN) des réseaux de téléphonie mobile UMTS, de troisième génération.

Projet!de!Fin!d’Etudes!: Détectiondesprécipitations!...

Documents

Transcript of Projet!de!Fin!d’Etudes!: Détectiondesprécipitations!...