Rapport Habboub

:
Ministre de lEnseignement Suprieur

et de la Recherche Scientifique
Universit de Carthage
Institut National des Sciences

Appliques et de Technologie
. :
Projet de Fin dEtudes

Pour lobtention du
Diplme National dIngnieur
en Sciences Appliques et en Technologie
Filire: Gnie Logiciel
Sujet:
TITRE EN FRANAIS : CONCEPTION ET DVELOPPEMENT DUN MODULE

GOGRAPHIQUE POUR LE SUIVI DE LA PLATEFORME RSEAU
Rsum : Ce projet de fin dtudes effectu au sein dOOREDOO sinscrit dans le
cadre du projet de fin dtudes pour lobtention du Diplme dIngnieur en Gnie

Logiciel. Ce projet consiste concevoir et dvelopper un systme dinformation
gographique intgr dans un tableau de bord.
Mots-cls: Geoserver, systme dinformation gographique, PostGIS, ETL Spatial
Data Integrator, Symfony 2.
CONCEPTION ET DVELOPPEMENT DUN

MODULE GOGRAPHIQUE POUR LE SUIVI DE
LA PLATEFORME RSEAU
Ralis par: Habib HALAOUI
Entreprise daccueil:
TITRE EN ANGLAIS: DESIGN AND DEVELOPMENT OF A GEOGRAPHICAL

UNIT FOR MONITORING PLATFORM NETWORK
Abstract: This project which was carried out within OOREDOO comes up with the
graduation scheme for the purpose of obtaining the diploma of Software
Engineering. This project intended to design and to develop a Geographic
Information System integrated into a dashboard.
Key Word: Geoserver, Geographic Information System, PostGIS, ETL Spatial Data
Integrator, Symfony 2.
Soutenu le /09/14
Intitule et adresse complte de lentreprise :
Responsable entreprise:
Responsable INSAT:
Mr. Wael TARHOUNI

Mme. Saloua BEN YAHIA
Anne Universitaire:2013/2014
Entreprise : OOREDOO.
Adresse : 1053 Les Berges du Lac Tunis, Tunis.



Pour lobtention du
Filire : Gnie Logiciel
Sujet :

MODULE GOGRAPHIQUE POUR LE SUIVI DE LA
PLATEFORME RSEAU
Ralis par : Habib HALAOUI
Entreprise daccueil :
Soutenu le /09/14
Responsable entreprise:
Responsable INSAT:
Mr. Wael TARHOUNI

Mme. Saloua BEN YAHIA
Anne Universitaire : 2013/2014



Pour lobtention du
Filire : Gnie Logiciel

Sujet :

MODULE GOGRAPHIQUE POUR LE SUIVI DE LA
PLATEFORME RSEAU
Ralis par : Habib HALAOUI
Entreprise daccueil :
Soutenu le /09/14
Responsable lentreprise:
Prnom et NOM: Mr. Wael TARHOUNI
(Cachet & Signature)
Responsable lINSAT:
Prnom et NOM: Mme. Saloua BEN YAHIA
(Signature)
Anne Universitaire : 2013/2014
Remerciements
Les mots ne seront jamais forts pour exprimer notre reconnaissance envers tous ceux
qui, par leurs conseils, leurs soutiens et leurs aides, ont permis ce travail de voir le jour.
Jexprime mes vifs remerciements Monsieur Wael TARHOUNI ingnieur support

radio
de la direction technique dOoredoo TN pour mavoir si bien accueillie et permis de
faire ce stage.
Mes
remerciements sadressent galement, tout le personnel de lquipe Radio
dOOREDOO TN qui ma apport une aide prcieuse chaque fois que jen ai formul le
besoin en particulier Monsieur Nabil EZZEHRI auquel jexprime toute ma reconnaissance
et mes respects.
Je tiens galement adresser mes remerciements et ma gratitude Madame Saloua

BEN YAHIA pour sa disponibilit, son soutien, son aide prcieux et ses conseils judicieux
tout au long de ce projet.
Je
suis particulirement reconnaissant lINSAT Institut National des Sciences
Appliques et de Technologie pour mavoir offert lopportunit dacqurir cette exprience

qui,
sans
doute,
me
sera
dun
grand
apport
dans
ma
vie
professionnelle.
Ddicaces
De plus profond de mon cur je ddie ce travail
A mon cher pre que nulle ddicace ne peut exprimer ce que je lui
dois, pour sa bien vaillance de plus jeune enfance, son affection et
son soutien.
Trsor de bont, de gnrosit et de tendresse, en tmoignage de
mon profond amour et ma grande reconnaissance.
Que Dieu vous garde,
A ma chre mre pour son amour et tous ses sacrifices.
Maman qui je dois ma russite, aucun mot ne saurait tmoigner
de ltendu des sentiments que jprouve son gard.
A toute ma famille et mes ami(e)s que je ne peux tous citer,
Que Dieu les bnisse tous et leurs prserve la sant et le bonheur.
HABIB
Table des matires

Introduction Gnrale......................................................................................... 1
Chapitre1. Contexte du projet ........................................................................... 3
1.
Cadre gnral du projet ................................................................................................ 3

1.1.
Prsentation de lorganisme daccueil ..................................................................... 3
1.2.
Charte dOoredoo TN .............................................................................................. 3
1.3.
Structure organisationnelle : .................................................................................... 4
2.
Prsentation du sujet ..................................................................................................... 5
3.
Mthodologie de travail ................................................................................................ 6
4.
Chronogramme : ........................................................................................................... 7
Chapitre2. Etude pralable ................................................................................ 9

1.
2.
Les rseaux mobiles ....................................................................................................... 9

1.1.
Les diffrents standards technologiques .................................................................. 9
1.2.
Architecture gnrale du rseau GSM ................................................................... 10
1.3.
Critres dvaluation de la qualit de service dans un rseau GSM ...................... 11
1.3.1.
Les diffrents critres dvaluation ................................................................ 11
1.3.2.
Les indicateurs de cl de performance KPI (Key Performance Indicators) ... 12
Les Systmes dinformations gographiques (SIG) ................................................. 12

2.1.
Dfinition de SIG ................................................................................................... 13
2.2.
Rle des SIG dans la supervision des rseaux GSM : ........................................... 13
2.3.
Reprsentation de larchitecture rseau travers le SIG ....................................... 14
2.3.1.
Reprsentation gographique des BTS ........................................................... 14
2.3.2.
Reprsentation gographique des cellules ...................................................... 15
3.
Etude de lexistant ....................................................................................................... 16
4.
Problmatique.............................................................................................................. 17
5.
Solution envisage ....................................................................................................... 17
Chapitre3. Spcification des besoins ............................................................... 19

1.
Identification des acteurs ............................................................................................ 19
2.
Analyse des besoins ..................................................................................................... 19

i
2.1.
Besoins fonctionnels .............................................................................................. 19
2.3.
Besoins non fonctionnels ....................................................................................... 21
2.4.
Organisation des cas utilisations ............................................................................ 21
2.5.
Raffinement des cas dutilisations ......................................................................... 24
2.6.
Diagramme des squences ..................................................................................... 26
Chapitre4. Architecture et Conception ........................................................... 28

1.
Architecture ................................................................................................................. 28
1.1.
1.1.1.
Module dextraction, de transformation et de chargement des donnes ........ 28
1.1.2.
Module de publication des donnes gographiques ....................................... 30
1.1.3.
Module daffichage des donnes gographiques ............................................ 31
1.1.
1.
Architecture Technique .......................................................................................... 28
Diagramme de dploiement ................................................................................... 33
Conception dtaille .................................................................................................... 34

1.2.
Vue statique du systme ......................................................................................... 34
1.2.1.
Diagramme des packages ............................................................................... 34
1.2.2.
Diagramme des classes gnral ...................................................................... 35
Chapitre5. Ralisation de la solution ............................................................... 37

1.
Environnement de dveloppement ............................................................................ 37

1.1.
Environnement matriel ......................................................................................... 37
1.2.
Environnement logiciel .......................................................................................... 38
1.2.1.
Outil pour la gestion de la base de donnes : ................................................. 39
1.2.2.
Outil pour le tlchargement du fond de carte : ............................................. 39
1.2.3.
Outil pour lETL : ........................................................................................... 39
1.2.4.
Outil pour la reprsentation des cartes Gographiques : ................................ 41
1.2.5.
Serveur Gographique : .................................................................................. 41
1.2.6.
Framework Web ............................................................................................. 42
2.
Interfaces graphiques de lapplication ...................................................................... 43
3.
Problmes rencontrs .................................................................................................. 49
Conclusion et Perspectives................................................................................ 50
Rfrences Bibliographiques ............................................................................ 51
Annexes ............................................................................................................... 52
ii
Liste des figures

Figure 1: Structure organisationnelle Ooredoo TN .............................................................. 4
Figure 2: Cycle en V ................................................................................................................. 7
Figure 3: Diagramme de Gantt de notre projet de fin dtudes .......................................... 8
Figure 4: Architecture gnrale du rseau GSM ................................................................ 10
Figure 5: Sous rseau BSS ..................................................................................................... 14
Figure 6: Reprsentation des azimuts sur un site tri-sectoris .......................................... 15
Figure 7: Exemple de BTS ..................................................................................................... 15
Figure 8: Diagramme de cas d'utilisation global ................................................................. 23
Figure 9: Exploiter les fonctionnalits de la barre d'outils ................................................ 24
Figure 10: Diagramme de cas d'utilisation dtaill du golocalisation dune cellule ....... 25
Figure 11: Cas d'utilisation du changement des paramtres de configuration des couches
.................................................................................................................................................. 25
Figure 12: Cas d'utilisation de la consultation des cellules ayant les mmes cas de
rutilisation des canaux ......................................................................................................... 26
Figure 13: Diagramme de squence ...................................................................................... 27
Figure 14 Principe de l'ETL .................................................................................................. 29
Figure 15: Module Extraction-Transformation-Chargement des donnes ...................... 30
Figure 16: Module de publication des donnes Gographiques ........................................ 31
Figure 17: Architecture Technique avec le module de publication des donnes
gographiques ......................................................................................................................... 32
Figure 18: Architecture du module de gestion de GeoServer ............................................ 33
Figure 19: Diagramme de dploiement de l'application ..................................................... 34
Figure 20: Diagramme des packages .................................................................................... 34
Figure 21: Diagramme de classe de notre application ........................................................ 35
Figure 22: Job chargement des BTS dans Postgis aprs transformation ......................... 40
Figure 23: Job chargement des donnes des cellules du rseau dans une Base de donnes
Gographique ......................................................................................................................... 41
Figure 24: Architecture Dtaill Symfony 2[5].................................................................... 42
Figure 25: Page d'accueil de SIG aprs authentification .................................................... 43
Figure 26: Menu de Recherche d'un emplacement gographique .................................... 44
Figure 27: Exemple de fond de carte cartographique ........................................................ 44
Figure 28: Projection des informations d'adjacence ........................................................... 45
Figure 29: Projection des alarmes de performance sur la carte ........................................ 46
Figure 30: daffichage des cas probables d'interfrence .................................................... 47
Figure 31: Affichage des cellules ayant un changement de paramtres............................ 48
Figure 32: Module de suivi de ltat des cellules rseau travers les KPI ....................... 49
Figure: 33 Liste des KPI ........................................................................................................ 52
Figure 34: Prvisualisation des couches avec Geoserver .................................................... 53
iii
Figure 35: Styled Layer Descriptor (SLD) from Geoserver ............................................... 54

Figure 36: Chargement du Workspace 2G dans une base de donnes Postgis ................ 54
Figure 37: Chargement et transformation des donnes Alarmes dans Postgis ................ 55
Figure 38: Chargement du Nom Site Physique dans une base de donnes
cartographique ....................................................................................................................... 55
Figure 39: Job Global pour l'excution de tous les sous Job .............................................. 56
Figure 40: Formule de projection des points d'une cellule ................................................. 56
Figure 41: Syntaxe de cration d'un polygone..................................................................... 57
Figure 42: Rsultat de transformation des coordonnes BTS dans une carte .................. 57
iv
Liste des tableaux

Tableau 1: cas dutilisations pour lAdministrateur ........................................................... 21
Tableau 2: cas dutilisations pour lAnalyste ...................................................................... 22
Tableau 3: Environnement matriel ..................................................................................... 37
Tableau 4: Environnement technique .................................................................................. 38
Glossaire
B:
BSC: Base Station Controller
BTS: Base Transceiver Station
BSS: Base Station Sub-system
E:
ETL: Extract Transform and Load
G:
GSM: Global System for Mobile communication
GPS: Global Positioning System
H:
HLR: Home Location Register
K:
KPI: Key Performance Indicator
O:
OGC: Open Geospatial Consortium
S:
SIG: Systme dInformation Gographique
SDI: Spatial Data Integrator
V:
VLR: Visitor Location Register
W:
WCS: Web Coverage Service
WGS: Web Geodetic System
WMS: Web Map Service
WFS: Web Feature Service
vi
Introduction Gnrale
Avec lvolution des rseaux mobiles, lindustrie des tlcommunications cherche

orienter sa technologie de manire permettre aux oprateurs de demeurer comptitifs dans
un secteur caractris par une volution trs rapide.
La comptitivit de ces entreprises est directement lie la qualit de gestion et
dexploitation des donnes de leurs rseaux tlcoms.
De ce fait, loprateur de tlcommunication Ooredoo cherche assurer une meilleure
gestion de la qualit du rseau par la bonne matrise des infrastructures dans les diffrentes
zones gographiques. Ceci ncessite la prsence des outils capables dassurer le suivi, la
traabilit et le contrle des diffrents quipements. Dans ce contexte que dcline lobjectif de
notre projet : il sagit de concevoir et dvelopper un outil volutif qui permet dimporter et
dafficher les donnes radio sur une carte gographique. Il permet ainsi aux ingnieurs Radio
dtudier ltat des cellules
tout en effectuant une analyse complte en se basant sur les
fonctionnalits offertes par notre projet que nous dtaillerons dans la partie spcification des
besoins
En consquence, ce rapport sarticule autour de cinq chapitres : nous commenons dans
le premier chapitre par une prsentation du contexte dans lequel s'inscrit notre projet. Puis, le
deuxime chapitre prsente ltude pralable de notre projet, ensuite le troisime chapitre
dcrit la spcification des besoins non fonctionnels et fonctionnels. Tout au long du quatrime
chapitre, nous dtaillerons la conception de lapplication et nous clturons par le dernier
chapitre qui expose lenvironnement utilis pour le dveloppement de notre application et
prsente
les
interfaces
dcrivant
les
principales
fonctionnalits
implmentes.
CHAPITRE 1
Contexte du projet
Chapitre 1 : Contexte du projet
Chapitre1. Contexte du projet

Introduction :
Ce chapitre prsente le contexte gnral de notre projet. Nous commenons par la
prsentation de lorganisme daccueil, nous enchanons par la prsentation du projet et
finalement on introduit la mthodologie de travail adopte.
1. Cadre gnral du projet

1.1. Prsentation de lorganisme daccueil
Ce projet de fin dtude a t ralis au sein de la socit Ooredoo : le premier oprateur
de tlcommunications priv en Tunisie.
En mai 2002, la deuxime licence tunisienne de tlphonie mobile a t attribue
Orascom Telecom Tunisie. Cette licence, qui a cot 454 millions de dollars, a marqu la
naissance du premier oprateur de tlcommunications priv en Tunisie : TUNISIANA.
Cest une socit tunisienne anonyme ayant pour capital 330 millions de dinars dont le
principal actionnaire est watanya Telecom qui dtient la moiti des actions, associe
Orascom Tunisia Holding (35% des actions) et Carthage Consortium (15% des
actions).
Le 24 avril 2014, Tunisiana change de nom et devient Ooredoo Tunisie. Le 30 avril, ils
ont annoncs la nomination de Mohammed Bin Issa Al Mohannadi au poste de prsident du
conseil d'administration.
1.2. Charte dOoredoo TN

La charte dOoredoo est base sur quatre principes fondamentaux qui sont :
La transparence :
Choisir la transparence comme valeur, cest en quelque sorte opter pour lquit comme
principe. Ne pas frustrer le client, viter la discrimination entre abonns et avoir des mthodes
rigoureuses et justes sont les axes de cette transparence.
3
L'innovation
Les nouvelles technologies des TIC ne cessent dvoluer, pour cela, Ooredoo se doit de
proposer des services et des offres attractifs et performants, innover pour se distinguer et se
distinguer pour satisfaire, voil le moteur de nos engagements.
L'orientation Client
Il est essentiel de mesurer l'impact de nos moindres actes sur notre client final, quel que
soit le poste qu'on occupe. Le client est le centre de nos proccupations et lobjectif
primordial de nos employs est sa satisfaction.
Le professionnalisme
Adopter une attitude professionnelle, c'est fournir un travail de qualit, et s'autovaluer

en permanence. Ooredoo respecte autant ses clients que ses employs et reste toujours
lcoute pour offrir un meilleur service.
1.3. Structure organisationnelle :

Afin dassurer une bonne prestation de services ses clients et un bon fonctionnement
de son rseau de transmission GSM, OOREDOO TN est base sur linteraction de plusieurs
directions et dpartements complmentaires.
Figure 1: Structure organisationnelle Ooredoo TN
2. Prsentation du sujet
Notre projet de fin dtudes, propos par
loprateur
de
tlcommunications
OOREDOO consiste mettre en place un systme dinformation gographique pour le suivi

de la plateforme rseau. Il sagit de concevoir et dvelopper un outil volutif qui permet de
centraliser les donnes gographiques, rassembler les fonctionnalits des outils existants et
remdier leurs insuffisances.
En effet cet outil permet :
Lextraction, la transformation et le chargement des donnes gographiques dans un
entrept de donnes spatial : Cest la conversion des donnes arithmtiques en afin dobtenir
de nouvelles donnes gographiques utilisant de simples rgles gomtriques, logiques et/ou
arithmtiques.
Lanalyse de voisinage dans le rseau : La reprsentation gographique des relations de
voisinages entre les cellules du rseau, cette fonctionnalit assure le bon suivi de la
configuration des relations de voisinage entre les cellules tout en ayant une projection
gographique des lments en question.
La dtection des interfrences dans le rseau : Le signal mis est reu par un terminal
mobile est une onde lectromagntique. A cause des interfrences, il nest pas possible
dutiliser une mme bande de frquence dans deux cellules adjacentes du rseau. Le nombre
de frquences disponibles dans chaque cellule doit permettre dacheminer un nombre suffisant
de communications.
La golocalisation des cellules dgrades du rseau tout en projetant les valeurs des
indicateurs de performance sur carte (Les maps thmatiques)
Lintgration de plusieurs fonds de carte pour la visualisation gographique : en ligne
comme Google Maps, Bing, openstreetMap Et galement des fonds de carte hors-ligne tout
en utilisant notre base de donnes spatiale locale.
3. Mthodologie de travail
Dans le domaine de lingnierie de logiciel, il est indispensable de dfinir une mthode
de travail et suivre le processus de dveloppement le mieux adapt pour la ralisation de
lapplication.
Le model en Va fait ses preuves dans la gestion des projets. Il nous a t recommand par
lquipe radio Ooredoo TN de ladopter pour dvelopper lapplication.
Le cycle en V est un modle conceptuel conu pour pallier aux pnuries du modle en
cascade, il comprend les tapes suivantes :
Expression de besoin : Au cours de cette tape nous rdigeons un document
d'expression des besoins suite une runion avec lencadrant et le Chef du support
Radio Ooredoo afin de formaliser les grandes lignes du projet, ainsi que son primtre
fonctionnel.
Spcification fonctionnelle : Aprs la validation des besoins par le matre douvrage de
lquipe radio, nous passons la rdaction du cahier des charges contenant les diffrents
cas dutilisations du produit final.
Spcification technique : Au cours de cette phase nous effectuons le choix des
technologies utiliser pour dvelopper le produit ainsi que la conception de son
architecture logicielle.
Codage : Cest ltape de ralisation du projet pendant laquelle les diffrentes parties
du projet sont appeles briques, nous passons dune fonctionnalit une autre si la
brique dveloppe est valide par le chef service Radio et lencadrant Technique, afin
de bien former le produit final.
Test unitaires : Ces types de test se font sur les briques afin de vrifier que ces derniers
ont t dvelopps de manire respecter le cahier des charges, cette phase sera
excute aprs le dploiement de lapplication dans le serveur local de lentreprise
Ooredoo.
Test dintgration : les tests sont effectus sur le produit fini dans le but de sassurer
quil suit les spcifications techniques de mme que les tests unitaires seront valids
quaprs lachvement de la mise en service de lapplication.
Validation : consiste tester le produit vis--vis de la spcification fonctionnelle. Tous
les cas dutilisation du projet doivent tre vrifis sur le plan rel.
Mise en production et recette : consiste une dernire vrification du produit auprs des
ingnieurs Radio avant la mise en production.
Le schma suivant montre les tapes du cycle en V consiste associer chaque tape de
conception une autre tape de test.
Figure 2: Cycle en V
4. Chronogramme :
En tudiant lensemble des aspects de la mise en place de notre application, nous
schmatisons toutes les tapes de celui-ci en se basant sur le diagramme de Gantt, pour mettre
en uvre les parties, qui ont des rles primordiaux, en fonction du temps.
Cet outil est utilis lors de lordonnancement et la gestion de tous les types de projets. Il
donne la possibilit de visualiser dans le temps plusieurs tches qui composent un projet ainsi
que la reprsentation graphique de lavancement de celui-ci. Ses principaux avantages sont la
planification optimale et la communication du planning.
La figure 3 illustre le diagramme de Gantt de notre projet :
Figure 3: Diagramme de Gantt de notre projet de fin dtudes

Nous avons effectu une bonne bibliographie pour bien comprendre le contexte du
projet. Puis, nous avons tudi lexistant pour quon puisse dceler les besoins satisfaire.
Nous avons ensuite fait la conception de notre application et des croquis de nos interfaces.
Aprs la phase de conception, nous avons entam la phase de ralisation. Les derniers
jours sont consacrs pour les tches de finalisation et validation de loutil et la rdaction du
rapport.
Conclusion
Lorganisme daccueil tant prsent et le projet mis dans son cadre gnral par une
description gnrale du sujet avec ses diffrentes rubriques, la mthodologie adopte et le
chronogramme de gestion du projet, il sera procd dans le chapitre suivant parla clarification
de certaines notions
techniques utiles dans
le dveloppement
de lapplication.
CHAPITRE 2
Etude pralable
Chapitre 2 : Etude pralable
Chapitre2. Etude pralable

Introduction :
Ltude pralable est la premire tape de tout projet afin de russir la partie conception
et limplmentation. Dans ce chapitre, on va mettre laccent sur les rseaux mobiles :
nous jetons un coup dil sur lvolution des rseaux GSM, ensuite nous nous intressons
aux critres dvaluation de la qualit de service du rseau et les indicateurs de performances
choisis par OOREDOO pour amliorer cette qualit, aprs nous tudierons les systmes
dinformation gographiques et enfin nous mettons laccent sur limportance des SIG pour
lobservation et lvaluation de la qualit rseau.
Toutes ces informations sont des connaissances indispensables pour llaboration du
projet.
1. Les rseaux mobiles

Chaque gnration de rseau mobile (2G, 3G, 3G+) correspond une nouvelle
technologie (GSM, GPRS, Edge, UMTS). A chaque volution technologique, le rseau
mobile gagne en performance : les donnes transitent plus rapidement. Ces meilleurs dbits
amliorent la qualit du service existant et permettent de nouveaux usages (internet mobile,
visiophonie, tlvision, etc.).
1.1. Les diffrents standards technologiques
GSM : Le Global System for Mobile Communications (rseau GSM) est le

systme standard utilis par la plupart des tlphones mobiles des rseaux
travers le monde. Ce standard utilise les bandes de frquences 900 MHz et 1800
MHz .Il s'agit d'un standard de tlphonie dit << de seconde gnration >> (2G).
GPRS : Le standard GPRS (General Packet Radio Service) est une volution de
la norme GSM. On parle gnralement de 2.5G pour classifier ce standard.
EDGE : Le passage de la 2G la 3G est couteux car il faut dployer un nouveau

rseau physique. Les oprateurs ont donc cherch des alternatives. Lune dentre
9
elles est lEDGE (Enhanced Data Rates for GSM Evolution.), technologie
prsente comme la gnration 2,75.
UMTS : LUMTS (Universal Mobile Telecommunications System) est l'une des

technologies de tlphonie mobile de troisime gnration (3G) europenne. Le
procd employ pour faire transiter la voix et les donnes a t entirement
reconsidr. Ce nouveau standard permet d'atteindre un dbit 10 Mb/s en
rception et 5Mb/s en mission. Afin de faire transiter toutes ces donnes, une
nouvelle bande frquences a t alloue l'UMTS dans le spectre radio, aux
alentours de 2100 MHz.
1.2. Architecture gnrale du rseau GSM

Un rseau GSM s'articule en deux parties : Le BSS (Base Sub System) est le soussystme radio. Il comprend les metteurs-rcepteurs et leur supervision (BTS et BSC).
Le NSS (Network Sub System) est le sous-systme rseau. Il comprend des
commutateurs et des bases de donnes (MSC, VLR, HLR).
Le schma de larchitecture gnrale du rseau GSM est illustr dans la figure suivante :
Figure 4: Architecture gnrale du rseau GSM
10
Nous pouvons identifier plusieurs lments primordiaux pour la mise en place dun
rseau GSM :
BTS (Base Tranceiver Station) : Une station de base fournit le point d'entre
dans le rseau aux abonns prsents dans sa zone de couverture, appele cellule.
BSC (Base Station Controller) : Un contrleur de stations de base gre le
routage des communications et l'exploitation d'une ou plusieurs BTS.
MSC (Mobile Service Switching Center) : Ce commutateur est un nud
important du rseau : il gre le transfert intercellulaire, les abonns visiteurs et
l'interconnexion avec le rseau tlphonique public.
HLR (Home Location Register) : L'enregistreur de localisation nominal contient
les informations relatives aux abonns.
VLR (Visitor Location Register): L'enregistreur de localisation des visiteurs
stocke les informations dynamiques relatives aux abonns de passage dans le
rseau.
OMC (Operation and Maintenance Center): Le centre d'exploitation et de
maintenance est l'entit de gestion et d'exploitation du rseau.
1.3. Critres dvaluation de la qualit de service dans un rseau

GSM
1.3.1. Les diffrents critres dvaluation
La qualit du rseau peut tre value selon plusieurs aspects fondamentaux. Dans cette
partie, nous citons les critres les plus importants :
-
La couverture : Cest le niveau de puissance chaque point de la surface couverte.

Elle est indique par les barrettes affiches sur le mobile, cest le critre le plus
trivial partir duquel labonn peut estimer la qualit du rseau.
La qualit de la voix :
le rapport entre la puissance du signal reu et la densit de puissance du bruit en

rception.
le rapport signal sur interfrence C/I (Canal/Interfrence) : Cest le rapport de lintensit
du signal de la cellule de service courante par un signal non dsir.
11
Ces deux critres sont mesurs travers :

-
Le taux dtablissement dappel : Dans le cas dchec de communication alors

que les ressources sont disponibles.
Le taux de blocage : Dans le cas dchec de communication cause dune

congestion des canaux de trafic ou bien une congestion des canaux de signalisation.
1.3.2. Les indicateurs de cl de performance KPI (Key Performance Indicators)
"Lindicateur cl de performance ou Key Performance Indicator est un indicateur

daide la dcision. Son but est dvaluer lvolution dun lment mesur et de le
confronter aux objectifs pour lequel il a t cr."
[1]
La plupart des oprateurs tlphoniques dtectent les problmes partir des indicateurs
de performance rseau, des plaintes des abonns et des mesures Drive Test1 effectues sur
terrain. Ainsi il peut envisager des amliorations sur le rseau qui permettent davoir une
meilleure qualit de communication.
Un indicateur de performance (KPI) est une mesure quantifiable de la performance dun
rseau. En effet, il sagit dun ensemble de calculs associs un groupe de mesures fournis
par plusieurs compteurs. (Voir Annexe A).
Aprs avoir prsent le concept cellulaire et larchitecture gnrale des rseaux GSM et
le critre dvaluation de la qualit de service tudi, nous tudierons dans la partie suivante
les Systmes dInformations Gographiques et leur importance dans lvaluation de la qualit
de service.
2. Les Systmes dinformations gographiques (SIG)

Si linformatique a dabord permis des progrs dans lautomatisation de la production
cartographique, les SIG vont bien au-del dune simple fonction de stockage et de restitution
graphique :par leurs possibilits de modlisation et de gestion, par leurs fonctions danalyse et
dinterrogation, par les possibilits de mises en relation des objets les uns par rapport aux
Drive Test sont des mesures pour tester la qualit de signal des cellules du rseau
12
autres, par leurs capacits stocker et traiter de gros volumes dinformation, les SIG ont
profondment boulevers les mthodes traditionnelles danalyse et de gestion de lespace.
2.1. Dfinition de SIG

Un systme dinformation gographique, souvent abrg en SIG, est un ensemble
organis de matriels informatiques, de logiciels, de donnes gographiques, et de personnel
capable de saisir, stocker, mettre jour, manipuler, analyser et prsenter toutes formes
dinformations gographiquement rfrences .[2]
Le SIG est un ensemble de donnes repres dans l'espace, structures de faon

pouvoir en extraire commodment des synthses utiles la dcision. (Michel DIDIER, 1990)
De ce fait, lintroduction du Systme dinformation Gographique (SIG) au sein
des oprateurs tlcoms, est une dmarche bnfique. Son apport se traduit en offrant un
ventail de services pour permettre une vision globale de linfrastructure tlcom par la mise
en uvre doutils qui associent des informations des cartes dans un environnement facile
dutilisation.
La technologie SIG permet aussi aux ingnieurs tlcom, dintgrer des donnes
golocalises dans le processus danalyse, de la planification spatiale et la supervision
de linfrastructure du rseau.
Comme lvolution et lextension dun rseau ainsi que le dploiement de ses services
sont coteux, la mise en place dun SIG efficace apparat en tablissant une plateforme
commune qui amliore la manipulation de linformation gographique et augmente
considrablement la communication interne et la collaboration avec divers acteurs.
Un autre avantage considrable du SIG est sa capacit aider dans la supervision de la
qualit de service. En effet, une fois le rseau tlcom est oprationnel, le SIG va incorporer
lexpertise des ingnieurs ainsi que les donnes du rseau pour les analyser et faire le suivi et
loptimisation de la qualit du service.
2.2. Rle des SIG dans la supervision des rseaux GSM :

Nous allons montrer dans cette partie la porte des Systmes dInformation
Gographique dans lvaluation de la qualit de service des rseaux GSM.
13
Prenons le cas une dgradation du niveau du signal dune cellule donne, lanalyste
doit avoir toutes les informations ncessaires telles que :
-
Lidentifiant de la station de base BTS.
-La BSC laquelle elle appartient.

- Lemplacement gographique de cette cellule : Est-ce quil ya un relief dans cet
emplacement ou non ? Cette cellule est la proximit dun btiment ? Dans une zone
urbaine, suburbaine ou rurale?
On naura les rponses ces questions quavec une observation gographique des
diffrents lments rseau.
2.3. Reprsentation de larchitecture rseau travers le SIG

La transmission des ondes rseaux se fait laide des BTS qui regroupent un ensemble
des cellules quils appartiennent, donc dans cette partie nous allons dtailler la reprsentation
gographique pour chaque lment de linfrastructure rseau.
2.3.1. Reprsentation gographique des BTS
Le sous rseau BSS est compos de :
-
BTS (Base Tranceiver Station).
Cellules engendres par les antennes du BTS.
BSC (Base Station Subsystem).
MS (Mobile Station)
Figure 5: Sous rseau BSS

Chaque antenne dun BTS est dirige dans une direction dtermine par des
simulations, de manire couvrir exactement la zone dfinie. La direction principale de
14
propagation de lantenne, c'est--dire la direction dans laquelle lantenne met sa puissance

la plus importante est dirige dans lazimut tabli. Lazimut est un angle qui se compte en
degrs, positivement dans le sens horaire, en partant du nord (0). De cette faon, lazimut
90 correspond lest, lazimut 180 au sud, etc. (Voir Figure 6)
Figure 6: Reprsentation des azimuts sur un site tri-sectoris
2.3.2. Reprsentation gographique des cellules

Chaque BTS reprsente n cellules, avec n est le nombre dantennes dune BTS. Le
rayon de couverture dpend de lazimut comme le montre la figure7:
Figure 7: Exemple de BTS
15
3. Etude de lexistant
Une tape essentielle de tout projet informatique consiste effectuer une tude complte
des outils actuels pour lesquels nous voulons dceler les dfaillances et les insuffisances En
effet, dans la majorit, voir dans la totalit des cas, la mise en place d'un projet est due un
problme ou un manque dans l'entreprise. Il faut donc bien tudier l'existant pour aboutir
une spcification efficace des besoins de l'entreprise.
Dans cette partie, nous commenons par une tude des outils utiliss par lquipe
Radio, lidentification de ses limites, et la prsentation de la solution propose.
Outils de visualisation des donnes gographiques :
Lors de cette phase, nous avons essay d'acqurir les outils et les applications existantes
qui paraissent intressantes et qui sont en relation avec le travail demand. Nous commenons
par l'outil Optimi et MapInfo de visualisation des donnes spatiales au sein de l'quipe Radio,
ensuite nous tudierons les performances de ces outils. Ainsi, non seulement on disposera de
ses ides, mais on pourra par analogie, spcifier les fonctionnalits mettre en place dans
notre solution et en ajouter dautres.
Les principales se rsument dans les points suivants :
Acquisition des donnes gographiques.
Mise jour et manipulations des donnes gographiques.
Traitement des donnes gographiques.
Analyse gographique de la qualit du service.
Effectuer des oprations spatiales sur les donnes.
Cependant, ces outils prsentent des limites pour lquipe Radio :
Ce sont des outils propritaires.
Absence de larchitecture Client-serveur.
Les donnes gographiques ne sont pas centralises dans un seul entrept de donnes.
Les fonctionnalits mtiers offertes ne sont pas extensibles.
Consolidation et synchronisation des donnes non automatise.
Absence de mcanisme de golocalisation des lments dgrads.
La difficult dintgration des modules supplmentaires.
16
4. Problmatique
Les outils utiliss par les ingnieurs Radio dOoredoo deviennent incontrlables cause
du grand volume de donnes traites. Ils ne rpondent plus quelques fonctionnalits
primordiales daide la dcision, ce qui ne garantit pas la qualit du rseau comme lanalyse
de voisinage, linterfrence Co-canal dans les rseaux (trait manuellement)
que nous
dtaillerons dans le chapitre spcification des besoins.

Ces outils sont implments selon une architecture client/serveur. Do le problme de
la mise jour et de la synchronisation des donnes.
Lquipe radio est affecte par rgion. Donc chaque sous quipe est responsable du
suivi de la qualit de service dune zone gographique bien dtermine. Les donnes
collectes de toutes les quipes, qui sont importes sous formats Excel risquent dincohrence
et de perte, ce qui pose un grand problme de mise jour. De plus, les outils utiliss ne
traitent quun seul ensemble de technologies rseaux (fourni par le fournisseur).
Certes que lexistant utilis par lquipe Radio permet dapporter une richesse au
niveau de lobservation des couvertures pour effectuer le suivi journalier et lanalyse dtaille
de la qualit de service, mais a nempche que ces outils manquent quelques fonctionnalits
qui facilitent leurs tches pour une meilleure prise de dcision.
5. Solution envisage
Le diagnostic des limites signes dans la partie problmatique nous incitent faire des
mises niveau architecturales et techniques. En effet, il est indispensable de migrer dune
architecture client-serveur vers une architecture n-tiers. Larchitecture n-tiers est base sur la
sparation par des couches de responsabilits. Cette sparation permet de dcoupler au
maximum une couche de l'autre afin d'viter l'impact d'volutions futures de l'application.
Cette architecture nous pousse centraliser les donnes qui reprsentent une solution
primordiale pour garder la mise jour et la consolidation des donnes et maintenir la
synchronisation de lquipe Radio Ooredoo.
Ces donnes doivent tre finalement restitues et reprsentes dune manire ou dune
autre aux dcideurs. Il existe de nombreuses manires de prsenter ou de visualiser ces
donnes :
17
-Les tableaux sont trs puissants lorsque les donnes visualiser sont de petite taille.
-Les graphiques permettent dassocier certains aspects des donnes aux proprits
visuelles de formes gomtriques et dutiliser des diffrentes chelles pour explorer les
donnes.
-Les cartes gographiques son pouvoir rside dans leur capacit relier les donnes
notre monde bien physique.
Chaque outil de visualisation de donnes disponible prsente des avantages et des
inconvnients. Les cartes gographiques donnent une meilleure visibilit des donnes tout en
projetant des informations utiles de notre choix ce qui rpond aux exigences de notre projet.
Notre solution traite en plus les insuffisances fonctionnelles dans lanalyse de la qualit
du rseau et ceci par lanalyse du voisinage travers les diffrentes couches gographiques et
par la dtection de la dgradation des cellules du rseau travers la projection des indicateurs
de performance sur les lments reprsents gographiquement, limplmentation des
algorithmes de prdiction des cas dinterfrence, la golocalisation des toute cellule
appartenant au rseau via les diffrents critres de recherche (nom, id et rgion), affichage des
cas de changement de paramtres, affichage des lments dgrads
Conclusion :
Dans ce chapitre, nous avons introduit de concepts ncessaires pour llaboration de
notre projet : les rseaux GSM, les systmes dinformation gographiques et leurs rle dans
lanalyse de la qualit du rseau. Puis, nous avons enchain par ltude de lexistant afin de
proposer finalement la solution envisage.
On poursuit alors, dans le chapitre suivant, par la spcification des besoins de notre
projet.
18
CHAPITRE 3
Spcification des besoins
Chapitre 3 : Spcification des besoins
Chapitre3. Spcification des besoins

Introduction :
Etant la premire tape dans le cycle de vie de dveloppement dun logiciel, lanalyse et
spcification des besoins est trs importante afin de bien comprendre les dfis mis en jeu.
Durant cette phase, les acteurs sont identifis dans un premier temps. Par la suite, une analyse
fonctionnelle des besoins de lapplication ainsi que la spcification des besoins de
lapplication sont labores successivement.
1. Identification des acteurs

Un acteur est un utilisateur qui entre en interaction avec le systme. Dans notre projet,
les diffrents acteurs sont:
Administrateur : ladministrateur a le droit daccder tous les menus pour effectuer
tout type de modification y compris la gestion des donnes gographiques.
Lanalyste : lanalyse a comme rle le suivi de ltat du rseau.
2. Analyse des besoins

Lanalyse des besoins permet de bien comprendre les besoins de lutilisateur pour
pouvoir identifier les diffrentes fonctionnalits de lapplication. Ces besoins se divisent en
besoins fonctionnels et besoins non fonctionnels.
2.1. Besoins fonctionnels

Les besoins fonctionnels expriment lensemble des actions que doit raliser le systme
pour rpondre une demande de lutilisateur. Les besoins fonctionnels de notre projet sont les
suivants :
Afficher lensemble des couches rseaux selon la technologie (2G, 3G, etc.) et selon la
bande de frquence lui est associe.
Golocaliser une cellule par nom, longitude et latitude ou par nom de rgion.
19
Personnaliser le fond de carte gographique : Changer les fonds de carte satellite,

routire, ou hybride.
Mesurer la distance entre BTSs et la superficie dune zone gographique.
Afficher les informations correspondantes une cellule (nom site physique, la bande y
appartenant, lensemble de ses frquences).
Grer la dclaration de voisinage des cellules pour maintenir la communication en cours
de mobilit. Lutilisateur peut ajouter ou modifier des relations de voisinage. En effet, le
voisinage est une fonctionnalit trs importante vue que chaque cellule vit de sa
capacit pouvoir transfrer la connexion entre tlphone mobile et le rseau dune
cellule une autre. Afin de pouvoir transfrer la communication existante une autre
cellule, les cellules proches dune station de base doivent tre identifies. Pour cela des
listes de voisinage sont stockes dans toutes les stations de base avec les informations
de voisinage. En cas dabsence de station de base importante dans la liste de voisinage
une coupure de liaison peut survenir pour certains profils de dplacement.
Dtecter linterfrence 2G par une interface dinspection des frquences radio pour
augmenter la couverture et lamlioration de la qualit rseau. La dtection des
ventuelles interfrences dans un rseau est aussi importante que la dcouverte
dabsence de relations de voisinage, tant donn que toutes les stations mettent sur la
mme frquence, les stations de base absentes de la liste sont considres comme un
perturbateur potentiels, do leur dsignation sous le terme Pilote Pollution2 .
Faire le suivi de ltat des cellules rseau travers les KPI 3afin de prendre les actions
ncessaires pour augmenter la perception des clients.
Golocalisation des cellules dgrades en projetant les alarmes performances sur carte.
Crer des thmatique Map afin davoir une visibilit sur la performance des cellules et
analyser les causes probables via les indicateurs de performance .s diffrents indicateurs
de performance. Lutilisateur peut personnaliser laffiche des KPIs en changeant les
couleurs de cellules afin dindiquer visuellement leur tats.
Pilote Pollution : est lutilisation dune mme frquence dans des cellules voisines
Key Performance Indicators (KPI), sont des indicateurs mesurables d'aide dcisionnelle.
20
2.3. Besoins non fonctionnels

Nous commenons nos besoins non fonctionnels par la mise en place de la nouvelle
Architecture technique : Centralisation des donnes gographiques et mise en place dune
architecture n-tiers.
Plus que la centralisation de donnes, notre application doit rpondre aux besoins non
fonctionnels suivant :
Reprsentation fiable et jour des BTS et de toute informations relative (voisinage, Cocanal, Interfrence, changement de paramtres, etc.).
Partage des donnes entre les quipes.
Avoir une visibilit sur les caractristiques de lemplacement gographique des cellules.
Consolider les donnes : chargement automatique et planifi des donnes gographiques
partir des sources multiples.
Le code doit tre clair et lisible pour permettre dventuelles volutions ou
amliorations.
Lapplication doit tre ergonomique en assurant une interface conviviale et facile
utiliser.
Lapplication doit respecter la confidentialit des donnes en suivant les normes de
scurit.
Loutil doit Garantir lintgrit et la cohrence des donnes chaque mise jour et
chaque insertion.
2.4. Organisation des cas utilisations

Nous organisons dans le tableau ci-dessous les cas dutilisation de notre application par
acteur.
Tableau 1: cas dutilisations pour lAdministrateur
Cas dutilisation
Acteur
-Gestion des utilisateurs

-Changement des paramtres de configuration des
Administrateur
couches.
-Mesurer la superficie d'une zone gographique.
-Mise jour des donnes Gographiques.
21
Cas dutilisation
Acteur
-Personnaliser le fond de carte gographique.

- Mesurer la distance entre BTSs et la superficie
dune zone gographique
-Golocaliser une cellule.
-Afficher l'information d'une cellule
-Afficher les cas probables d'interfrence.
-Afficher les cellules ayant du changement de
paramtres.
-Changer les paramtres de configuration des
Analyste
couches.
-Consulter les cellules ayant les mmes cas de
rutilisation des canaux.
-Mise jour des donnes Gographiques.
-Mesurer les distances entre cellules.
-Projeter les alarmes de performance sur la carte.
-Projeter les informations d'adjacence
-Rinitialiser l'tat des cellules.
Tableau 2: cas dutilisations pour lAnalyste
La figure 8 illustre le diagramme du cas dutilisation global du systme qui donne une
vue complte du fonctionnement de lapplication. En effet, un cas dutilisation reprsente
linteraction entre acteur et systme en apportant une valeur ajoute lacteur.
22
uc Diagramme de cas d''utilisation Gneral
Golocaliser une cellule
extend
Choisir le fond
cartographique
extend
Exploiter les fonctionnalits de
la barre d'outils
Proj eter les informations
d'adj acence
extend
include
Analyste
extend
s'authentifier
Consulter les cellules ayant les
mmes cas de rutilisation des
canaux
extend
extend
Afficher les cas probables

d'interference
extend
Proj eter les alarmes de

performance sur la carte
include
include
Administrateur
Afficher les cellules ayant du
chagment de parmtres
Gestion des utilisateurs
Changment des parametres de

configuration des couches
Figure 8: Diagramme de cas d'utilisation global

23
2.5. Raffinement des cas dutilisations

Les cas dutilisation raffins permettent une description dtaille du cas dutilisation
global afin de mieux comprendre le projet.
Diagramme dExploitation des fonctionnalits de la barre d'outils :
La figure 9 montre la description de lensemble des fonctionnalits qui sont lutiliss
par lutilisateur final de lapplication regroup dans un menu l
uc Exploiter les fonctionnalits de la barre d'outils
Mesurer la superficie
d'une zone
gographique
extend
Afficher l'information
d'une cellule
extend
Exploiter les fonctionnalits
de la barre d'outils
extend
Analyste
Msurer les distances

entre cellules
extend
Rnitiliser l'affichage des

cellules
Figure 9: Exploiter les fonctionnalits de la barre d'outils

Diagramme de cas dutilisation Golocalisation dune cellule
Lanalyste peut, aprs authentification, faire une recherche des cellules soit par nom de
ou utiliser les paramtres de localisation gographique par la longitude et la latitude, ou par la
rgion y appartient. La figure 10 donne une description dtaille sur le cas dutilisation trait :
24
uc Golocaliser une cellule
Selectionner le nom
de cellule
extend
Golocaliser une cellule
extend
Analyste
Saisir le nom de
region
extend
Saisir la v aleur de
langitude et latitude
de cellule
Figure 10: Diagramme de cas d'utilisation dtaill du golocalisation dune cellule

Diagramme de cas dutilisation Changement des paramtres de configuration
des couches
Dans le diagramme ci-dessous donne une description sur la mise jour des
configuration des couches gographiques cest--dire paramtrer les couches par le choix des
couleurs par dfaut affich dans la carte , modifier les tailles des formes gomtriques et la
dgre douverture des polygones.
uc Changment des parametres de configuration des couches
Modifier la taille
extend
Changment des parametres de
configuration des couches
Administrateur
extend
Changer la couleur
extend
Changer la degre
d'ouv erture
Figure 11: Cas d'utilisation du changement des paramtres de configuration des couches
25
Diagramme de cas dutilisation Consultation des cellules ayant les mmes cas de
rutilisation des canaux
La figure 12, illustre le cas dutilisation de consultation des cellules qui interfrent entre
elles :
Lanalyste peut effectuer lopration de consultation des cellules ayant les mmes cas de
rutilisation des canaux par la slection de la bande, ensuite, il passe la slection de la
frquence observer dans la carte, puis il choisira lopration quil veut lanalyser, par
laffichage des cellules ayant la mme frquence choisie, ou laffichage des cellules ayant les
mmes frquences et dclar voisine, ou les cellules ayant les mmes BCCH celle du
frquence slectionn.
uc Consulter les cellules ayant les mmes cas de rutilisation des canaux
Choisir la frequence
Afficher les cellules ayant du
Choisir la bande
chagment de parmtres
include
include
Analyste
extend
extend
Afficher les cellules

CO-cannal
Co-voisine-canal
extend

Co-canal-BCCH
Figure 12: Cas d'utilisation de la consultation des cellules ayant les mmes cas de
rutilisation des canaux
2.6. Diagramme des squences

Pour analyser notre solution, nous illustrons le diagramme squence qui est une
reprsentation graphique des interactions entre les acteurs et le systme en considrant cette
dernire commune boite noire. Le diagramme de squence est le suivant :
26
sd Use Case Mo...

SIG_Dashborad
Analyste
Administrateur
S'authentifier()
Verifier()
alt
[Authentif]
Exploiter les donnes

geograpiques()
Afficher le menu de consultation
des donnes SIG ()
Effectuer des oprations
d'analyse du rseau()
Afficher le menu des operations
d'analyse du rseau()
S'authentifier()
alt
[Authentifi]
Gerer les donnes

Geographique()
Afficher le menu de gestion des couches

rseau()
Figure 13: Diagramme de squence
Conclusion
Dans ce chapitre les besoins fonctionnels et non fonctionnels sont analyss. Les
diffrents acteurs ainsi que leur interaction avec le systme sont prcis moyennant les
diagrammes des cas dutilisation.
27
CHAPITRE 4
Architecture et Conception
Chapitre 4 : Architecture et Conception
Chapitre4. Architecture et Conception

Introduction :
Le prsent chapitre consiste exposer laspect conceptuel de la solution dvelopper.
Dans un premier temps, larchitecture globale du systme est prsente afin den
extraire les diffrents modules qui la composent. Ensuite chaque module sera dtaill travers
les diagrammes des squences et dactivits.
1. Architecture
1.1. Architecture Technique
Cette section dvoile larchitecture globale du systme et identifie ses diffrents
composants.
Nous allons dans cette partie dcrire la structure gnrale de notre systme,
lorganisation des lments du systme et les relations entre les diffrents lments du
systme. Cette structure est le dnouement dun ensemble de dcisions stratgiques prises
durant la phase de conception de toute partie du systme.
Nous avons dcid dans cette phase de diviser larchitecture de lapplication en trois
modules:
Module 1 : Module dextraction, de transformation et de chargement des donnes
gographiques.
Module 2 : Module de publication des donnes gographiques.
Module 3 : Module daffichage des donnes gographiques.
1.1.1. Module dextraction, de transformation et de chargement des donnes
Les systmes de gestion des donnes gographiques sont assez htrognes autant sur le
plan technique que sur le plan logique. Les donnes collecter sont en effet stockes dans des
systmes de nature diffrente, sous des formats diffrents, selon des structures diffrentes.
Subsquemment, il faut chercher linformation essentielle et lexploiter proprement. En
effet, les donnes sont assez htrognes sur le plan logique, pour les rapprocher, il faut
28
comprendre la structure des diffrents types des donnes gographiques, les synchroniser en
les migrant vers le mme systme de rfrence de coordonnes et les charger dans le mme
systme de stockage des donnes spatiales.
On est par consquent dans lobligation dpasser par les tapes suivantes :
Extraire les donnes gographiques (Extract) : Accder aux systmes de stockage de
donnes afin de rcuprer les donnes identifies et slectionnes tout en tenant en
compte les question de synchronisation, de la priodicit et de rafrachissement.
Transformer les donnes (Transform) : Dans cette phase, on fait toutes les
transformations ncessaires sur les donnes pour quelles soient exploitables
proprement, par exemple, des oprations de projection dans le mme systme de
rfrence de coordonnes ou des oprations doptimisation.
Chargement (Load) : Cette tape consiste charger les donnes transformes et
raffines dans la base de donnes spatiales
Cest la raison pour laquelle nous avons eu recours aux ETL (Extract Transform and
Load) et leurs extensions spatiales. Il sagit en effet de lensemble des technologies
informatiques permettant deffectuer des oprations de chargement, de synchronisation et de
chargement massives des donnes.
Figure 14 Principe de l'ETL
29
Le module de chargement des donnes gographiques est illustr ci-dessous :
Figure 15: Module Extraction-Transformation-Chargement des donnes

1.1.2. Module de publication des donnes gographiques
A ce stade, les donnes sont transformes, raffines et charges dans la base de donnes
spatiale. Il est temps de partager les donnes gographiques et de les modifier si cest
ncessaire.
Par consquent, il faut mettre en place un serveur assurant linteroprabilit et la
publication des donnes de toutes les sources principales de donnes spatiales charges avec
les ETL4 dans la base de donnes.
ETL : Extraction, transformation et chargement des donnes des diffrentes sources dans un entrept de
donnes
30
A ce stade, larchitecture forme des deux serveurs est la suivante :
Figure 16: Module de publication des donnes Gographiques

1.1.3. Module daffichage des donnes gographiques
Cette couche interagit avec :
Le serveur cartographique pour laffichage des donnes gographiques par la rception
des requtes WFS (Web Feature Service) qui est un protocole de communication au
moyen d'une URL formate, permet d'interroger des serveurs cartographiques afin de
manipuler des objets gographiques (lignes, points, polygones...). A la rception, le
serveur Geoserver envoie un flux sous forme de requte SQL au serveur Postgres pour
avoir les informations relatives la couche demand (coordonnes, forme gomtrique,
nom de la couche,..).De mme le serveur postgis, met une rponse sous format
GML5qui sera interprt ensuite par le serveur cartographique, afin de visualiser la
couche.
GML : Geography Markup Language est un langage driv du XML pour encoder, manipuler et changer des
donnes gographiques.
31
le serveur web
pour laffichage des couches cartographiques par lmission des
requtes de WMS6 contenant linformation de la couche demand par lutilisateur ou

invoquer de Web service restful pour paramtrer ou lire les mtadonnes spcifiques
une couche gographique, ou lancer une requte au serveur Google laide de son API
gocoder pour assurer la recherche fiable et efficace dune zone gographique( nom de
rgion , rue , ville, etc.,...).
Larchitecture gnrale des trois modules depuis le chargement des donnes
gographiques jusqu la phase daffichage des donnes est la suivante :
Figure 17: Architecture Technique avec le module de publication des donnes

gographiques
Pour assurer la communication entre serveur Web et le serveur GIS geoserver nous
avons dvelopp un Web Service Rest qui interagie avec les oprations correspondante aux
besoins de lutilisateur final. Ce Web service se compose de trois couches :
Web Map Service ou WMS : est un protocole de communication standard qui permet d'obtenir des cartes de
donnes gorfrences
32
Couche routage : Cette couche effectue le routage de la requte selon lopration

effectuer : la gestion des couches, les styles appliquer dans une couche, ltat du
serveur.
Couche Controller : Cette couche est responsable du contrle des requtes avant de
lancer le service. Il faut vrifier par exemple que GeoServer est lanc avant de lancer le
service dajout dune couche
Couche Service : Cette couche lance les services invoqus en invoquant le web service
restful par dfaut de GeoServer.
La figure ci-dessous montre une description dtaille des trois couches :
Figure 18: Architecture du module de gestion de GeoServer
1.1. Diagramme de dploiement

Pour une meilleure prsentation des besoins techniques, il est judicieux de dterminer
nos besoins matriels qui reprsentent un choix stratgique et organisationnel pour lefficacit
de notre application.
33
Le diagramme de dploiement met en vidence linteraction entre les composants

ncessaires pour lapplication et montre la disposition physique des diffrentes sources
matrielles
deployment Use Case Mo...
Serv eur de Base de donnes
Serv eur
device
PosteAnalyste
<< HTTP + WMS >>
device
PosteAdministrateur
Serv eurCartographique
Serv eur de base de

donnes Spatiale
<< HTTP + WMS >>

Serv eur Web
Serv eur de base de

donnes
Relationnelle
Figure 19: Diagramme de dploiement de l'application
1. Conception dtaille
Dans cette partie, nous allons prsenter la conception dtaille : Nous commenons par
le diagramme des classes. Ensuite, nous dcrivons des scnarios par des diagrammes
dactivits et des squences.
1.2. Vue statique du systme

1.2.1. Diagramme des packages
Nous avons divis notre application en deux packages :
- Package User Management : Pour la gestion des utilisateurs.
- Package SIG Management: Pour la gestion des donnes gographiques.
Le diagramme des packages de notre package illustre cette division en packages.
pkg Use Case Mo...
PackageGISDataManagement
PackageUserManagement
use
Figure 20: Diagramme des packages

34
1.2.2. Diagramme des classes gnral

Ce diagramme des classes reprsente la majorit des services de notre application. En
effet, il intgr les deux modules principaux de lapplication. Chacun de ces modules est
reprsent par un ensemble de classes lies entre elles. Nous citons les diffrentes classes en
interaction dans le diagramme ci-dessous :
class Use Case Mo...
Raised_Alarms
Adjacency
-
Date_time: Date
Vendor: String
Source_CI: String
Source_Band: String
Traget_CI: String
Target_Band: String
Target_Technology: String
ThemticMap
Channel_Reuse
- id_Style: int
- Style_Name: String
- Color_Style: String
- Band: String
- Freq_Min: int
- Freq_Max: int
+ Get_Feq_Min_Max_By_Band(String) : int
+ Get_Adjacency(Adjacency) : Adjacency
+ Set_Adjacency(Adjacency) : void
0..*
+ Get_All _Themati c_Map() : ThemticMap[]

+ Set_Themetic_Map(ThemticMap) : void
Layers
-
Creer
0..*
1..*
1..*
0..1
Consulter
0..*
USER
0..*
-
Delta_Params
-
Date1: Date
Date2 : Date
Param: String
Name: String
Val1: String
Val 2: String
Consulter
1..*
ID_User: int
First Name: String
Name: String
Login: String
Password: String
Team: String
Privilege: String
1..*
+ Set_user(User) : void
+ Get_User() : User
Changer
Consulter
2G_Layer
Alarms_Name
OsmLayer
- Alarms_Definition_Name: Stirng
0..*
- Technology: String
+
+
+
+
ADD_alarms(String, String) : void

Update_Alarms() : void
Get_All_Alarms() : Alarms_Name
Delete_Alamrs() : void
KPI
-
osmID: int
aerialWay: String
Boundary: String
Brand: String
wayarea: float
place: String
way: geometry
0..*
Administrer
0..*
+ Get_all_Params() : Delta_Params
id_Layer: int
Name: String
degree: float
length: float
+ Set_Layers() : void
+ Get_Layers() : Layers[]
+ Search_Alarms_ByTechno(String) : Raised_Alarms
+ Get_All_Alarms() : Raised_Alarms
0..*
0..*
Definition_Name: Sring
Vendor: String
Technology: String
element_ID: int
Sql_Date_Time: Date
Hier_element: String
Problem_Text: String
Cell_ID: int
Status: boolean
0..*
DateTime: Date
Cell_Name: String
BSC_NAME: String
CALL_DROP_RATE: Float
TCH_TRAFIC: Float
SDCCH_ASSIGN_FAIL_RATE: Float
...: Float
1..*
Administrator
- Privilege: char
+
+
+
+
Get_Privilege() : String
Set_user(User) : void
Get_User() : User
Set_Privilege() : void
+ Get_Info_KPI () : KPI
Figure 21: Diagramme de classe de notre application
35
Vendor: String
BSC: String
Site_Phy: String
BTS: String
CELL_ID: int
X: float
Y: float
AZIMUT: int
Tilt: int
Cell_NAME: String
3G_Layer
-
Vendor: String
RNC: String
RNC_ID: int
WBTS: String
X: float
Y: float
AZIMUT: float
RAC: String
SAC: String
Le diagramme de la figure 20 illustre lensemble des classes et leurs associations. Nous

avons essay de simplifier ce diagramme travers une description globale:
La classe Layers modlise les tables de technologies utilis par loprateur Ooredoo, 2G
et 3G avec la configuration des couches.
La classe User est en association directe avec les classes dactions, qui corresponde aux
fonctionnalits excute par un utilisateur,
Conclusion :
Cette phase de conception permet de dcrire dune manire globale et dtaille, le
fonctionnement dsir du systme afin den faciliter la ralisation de lapplication. Nous
avons prsent les diagrammes qui dcrivent la conception de notre application. Cette phase
est une prparation pour ltape de ralisation que nous dtaillerons dans le chapitre suivant.
Nous prsenterons ainsi laboutissement de notre travail en dcrivant les langages et les
environnements utiliss.
36
CHAPITRE 5
Ralisation de la solution
Chapitre 5 : Ralisation de la solution
Chapitre5. Ralisation de la solution

Introduction :
Ce chapitre, venant de clturer ce rapport, dcrit les diffrentes tches de la ralisation
de la solution propose. Lenvironnement matriel et logiciel utilis pour le dveloppement
est lobjet de la premire partie suivi par une prsentation du travail effectu taye par des
imprimes cran. De mmes les diffrents outils de test et de simulation adopts font partie de
cette prsentation.
1. Environnement de dveloppement
Cette section est consacre la prsentation de lenvironnement matriel et logiciel
utilis pour la ralisation du projet.
1.1. Environnement matriel

Nous prsentons travers le tableau ci-dessous lenvironnement matriel qui nous a
permis de raliser notre application. Nous dcrivons, travers le tableau 2 lenvironnement
matriel qui nous a permis de raliser notre application :
Aspect technique
Description
Systme dexploitation
Windows 7
Systme dexploitation Entreprise
Service Pack 1, 64 bit
Processeur
Intel Core TM2 Duo CPU E4400

@2.00GHz 20.6 GHz
Mmoire installe
2Go
Disque dur
75Go
Tableau 3: Environnement matriel

37
1.2. Environnement logiciel

La mise en place de ce projet a ncessit lutilisation des logiciels et des outils suivants :
Tableau 4: Environnement technique
Aspect technique
Description
Outil pour le chargement de fond de

carte
Osm2pgsql
Framework WEB
Symfony 2
Languages
Java, Python,
HTML5, Javascript , PHP,SQL
Serveur dapplication
Apache
Serveur Gographique
Geoserver 2.5
Plateforme de dveloppement web
EasyPHP
SGBD
ORACLE, Postgres
SGBD Spatial
Postgis : Extension spatiale de Postgresql
IDE (Environnement de dveloppement)
Netbeans IDE 8.0
ETL
Talend Spatial Data Integrator
Gestion de la base de donnes
PgAdminIII (Postgis) : Interface de gestion

des donnes spatiales.
Outils de conception
Entreprise Architect
API Ajax Jquery pour la gestion des
intractions clients
API
API OpenLayers pour laffichage des
donnes gographiques sur une map.
38
1.2.1. Outil pour la gestion de la base de donnes :

POSTGRES est un gestionnaire de base de donnes relationnelle. Il offre une extension
Postgis pour la gestion des bases de donnes gographique utilis dans notre projet de
systme dinformation gographique.
1.2.2. Outil pour le tlchargement du fond de carte :
Osm2pgsql : est un programme en ligne de commande qui convertit les donnes
d'OpenStreetMap pour bases de donnes PostgreSQL PostGIS. Nous avons utilis cet outil
pour la transformation du fichier export du carte OpenStreetMap de la Tunisie en une base
de donnes Postgres afin dexploiter une carte gographique.
1.2.3. Outil pour lETL :
Talend Open Studio (TOS) Talend offre un produit Big Data Open source puissant et
flexible simplifiant le fonctionnement les technologies Big Data et permettant de contrler et
damliorer les performances dune entreprise, sans avoir besoin de connaissances ou de
ressources spcialises.[3].
Il offre une extension spatiale SDI (Spatial Data Integrator)
pour la gestion de
linformation go-spatiale qui rpond nos exigences.

En se basant sur sa compatibilit avec nos besoins, nous avons utilis Talend Spatial
Data Integrator pour effectuer lopration de lextraction, la transformation et le chargement
des donnes spatiales dans la base de donnes spatiale Postgis.
Pour raliser lopration dextraction, transformation et le chargement des donnes dans
la base de donnes PostGIS, on cre un job pour le chargement de donnes partir de la base
de donnes relationnels oracle.
Job1 : la reprsentation des BTS Consiste
Extraire les informations correspondantes aux BTS de la base de donnes Oracle (nom,
position)
transformer les coordonnes (X : longitude, Y : latitude) en un point laide du
composant s2DPointReplacer.
Lamlioration de la visibilit du BTS dans la carte gographique sous forme dun
cercle, nous avons augment le rayon partir du centre du point cre lavance en
utilisant le composant sBufferCalculator.
39
On finit par ltape de chargement dans la base de donnes Postgis.
Figure 22: Job chargement des BTS dans Postgis aprs transformation
Job 2 : Chargement du Workspace de la base Oracle dans un entrept Postgis

Ce Job joue un rle important dans la reprsentation des couches travers la
transformation des donnes arithmtiques reprsent sous forme dun point de coordonnes
(X, Y, Azimut) pour chaque BTS en polygone. Cette transformation ralise en utilisant
lobjet T_Map afin de tracer les points formant le polygone donc partir du point dorigine du
site physique nous calculons les points extrmes laide dune fonction mathmatique
combinant les trois lments cls : la longitude, la latitude et lazimut. Puis, nous passons la
liaison des points afin de former le polygone laide du langage WKT7.Enfin, nous projetons
les donnes sous le systme de projection WGS848avant linsertion des donnes dans la base
PostGIS et cela en appliquant un filtre sur les bandes de frquences 2G et 3G. La figure 22
illustre un exemple de chargement dun Workspace 2G dans la base de donnes spatiale
PostGIS.
WKT : (Well-known text) C'est un format standard en mode texte utilis pour reprsenter des objets
gomtriques vectoriels issus des systmes dinformations gographiques
8
WGS84 systme godsique standard mondial est un systme de rfrence permettant d'exprimer les
positions au voisinage de la Terre.
40
Figure 23: Job chargement des donnes des cellules du rseau dans une Base de donnes
Gographique
1.2.4. Outil pour la reprsentation des cartes Gographiques :
Openlayers: Il sagit un client Web Mapping libre. Cest aussi une bibliothque JS
qui peut sintgrer directement dans le code de la page web et elle est compatible avec tous les
navigateurs web. Openlayers supporte les donnes transmises par un serveur cartographique
via les protocoles WMS et WFS. Elle se caractrise aussi par une documentation exhaustive,
une possibilit dinteragir avec les diffrents fournisseurs de cartes (Map providers) et un bon
nombre de fonctionnalits. [..]" La cartographie SIG en ligne ou Web mapping: les outils
libres "[4]
1.2.5. Serveur Gographique :
GeoServer : est un serveur informatique open source dvelopp en Java ddi au
partage et la manipulation des donnes gographiques, il implmente le Web Map
Service(WMS) de lOGC. GeoServer se base sur la bibliothque Java GeoTools qui intgre
un grand nombre de fonctions pour assurer linteroprabilit des donnes SIG.
41
1.2.6. Framework Web

Symfony 2 : est un Framework MVC9 libre crit en PHP 5. En tant que Framework, il
facilite et acclre le dveloppement de sites et d'applications Internet
Comme Symfony2a lev la qualit du code, il utilise un ensemble de design pattern qui
facilite le traitement et mise jour de lapplication.
Figure 24: Architecture Dtaill Symfony 2[5]

Foctory : Fournit une interface pour crer des familles d'objet lis ou dpendants sans
avoir spcifier leurs classes concrtes.
Faade : Fournit une interface unifie un ensemble d'interfaces dans un sous-systme.
La Faade dfinit une interface de plus haut niveau qui rend le sous-systme plus facile
utiliser.
MVC : Model View Controller est un pattern pour la sparation des couches.
42
Builder : Spare la construction d'un objet complexe de sa reprsentation, afin que le

mme processus de construction puisse crer des diffrentes reprsentations.
Composite : Compose des objets en structures d'arbres pour reprsenter des hirarchies.
Composite permet des clients de traiter des objets ou des compositions d'objets de la mme
manire.
Flyweight : instancier qu'une seule fois l'objet en question, et de l'hydrater au fur et
mesure du besoin.
2. Interfaces graphiques de lapplication

Nous allons dans cette partie prsenter les principales fonctionnalits du SIG
Dashboard
Aprs la phase de lauthentification, lutilisateur peut consulter toutes les fonctionnalits
offertes pour lanalyse de la qualit du rseau dans la page daccueil ci-dessous :
Figure 25: Page d'accueil de SIG aprs authentification

43
La page daccueil du module SIG contient deux volets : le premier volet pour
laffichage de la carte gographique et le deuxime volet pour les oprations gomtriques.
Nous allons dtailler chaque fonctionnalit comme suit :
Module de Golocalisation :
La figure 25 permet lanalyste deffectuer des oprations telles que la golocalisation
par rgion, par longitude et latitude et par nom du BTS.
Figure 26: Menu de Recherche d'un emplacement gographique

Module du choix du fond cartographique:
Cette fonctionnalit permet aux ingnieurs Radio la personnalisation de la visibilit du
Map par la slection du fond de carte satellite, routire ou hybride aidant de lanalyse de
limpact des caractristiques gologiques de lemplacement de la cellule dans sa qualit du
rseau et de :
- rpertorier lensemble des lments de rseau de loprateur et leurs paramtres de
fonctionnement : hauteur et orientation des antennes, puissance des metteurs, etc. ;

- de modliser la propagation des ondes radiolectriques, cest--dire lattnuation quelles
subissent en fonction de la distance, qui varie suivant la frquence dmission ainsi que la
typologie de lenvironnement (urbain, plaine, fort, obstacles naturels ou artificiels, etc.)
- dintgrer et de mettre jour des bases de donnes gographiques reprsentant la ralit du
terrain, en particulier la typologie de lenvironnement.

Ceci est illustr par la figure 26 :
Figure 27: Exemple de fond de carte cartographique

44
Module de Projection des informations d'adjacence:

Cette fonctionnalit projette sur carte les relations dadjacence entre les cellules du
rseau : fonctionnalit originale et non dveloppe dans les outils acquis. Ceci permet
danalyser les causes probables de coupure de communication cause dun problme de
paramtrage des relations de voisinage.
La figure 27 illustre une projection relle des cellules ayant des relations de voisinage
avec la cellule en question (en jaune). Si le niveau de signal atteint un certain seuil de
dgradation, lappareil mobile cherche la prochaine station ayant un niveau de signal plus
lev et cette nouvelle cellule doit obligatoirement tre dclare voisine avec lancienne
cellule pour poursuivre la communication sans avoir un impact client, do limportance de la
configuration
de
ces
relations
de
voisinage
dans
Figure 28: Projection des informations d'adjacence
45
le
rseau.
Module de Projection des alarmes de performance sur la carte:

Les alarmes performance ont t dveloppes par les quipes dOoredoo afin de dtecter
les ventuelles dgradations en temps rel. Ces alarmes ne sont visibles qu partir des
consoles des outils propritaires sans avoir une ide sur lemplacement exact des cellules en
question. Alors, en vue de centraliser les donnes, nous avons reprsent les cellules
dgrades portant des alarmes sur la map afin daider les analystes interprter les causes
probables de ces perturbations de la qualit de service.
Dans la figure ci-dessous, nous pouvons identifier les cellules portant des alarmes tout
en identifiant lindicateur de performance dgrad qui a t la cause du dclenchement de
lalarme :
Figure 29: Projection des alarmes de performance sur la carte

Module daffichage des cas probables d'interfrence :
Le principe de rseau est de diviser le territoire en de petites zones, appeles cellules, et
de partager les frquences radio entre celles-ci. Ainsi, chaque cellule est constitue d'une
station de base laquelle est associ un certain nombre de canaux de frquences bande
46
troite, sommairement nomms frquences. Comme prcdemment, ces frquences ne

peuvent pas tre utilises dans les cellules adjacentes afin d'viter les interfrences. En se
basant sur ce principe laffichage du des cas probables dinterfrences travers le SIG, on
pourra donner une meilleure visibilit des cellules interfres comme le montre la figure
29.Nous pouvons ainsi utiliser un filtre sur les cellules portant les mmes frquences :
Figure 30: daffichage des cas probables d'interfrence
Module daffichage des cellules ayant du changement de paramtres :

Les lments du rseau ou bien les cellules sont configurables travers des paramtres bien
dfinis (Le niveau de signal partir duquel le Handover sera dclench, lactivation du 3G, le
paramtrage des frquences ). Toute mauvaise configuration des paramtres sera
ventuellement lorigine des dgradations de la qualit de service et cette dgradation sera
ventuellement rsolu laide de la bonne reconfiguration des paramtres en question, do
limportance davoir une visibilit de lhistorique des changements des paramtres effectus
47
Comme le montre la figure 30. Ceci aide les analystes rtablir les situations travers le
changement convivial du paramtrage.
Figure 31: Affichage des cellules ayant un changement de paramtres
Module de suivi de ltat des cellules rseau travers Les KPI :

Les rseaux mobiles sont valus par des indicateurs de paramtre de performance KPI.
Les indicateurs cls de performance correspondent aux mesures donnant une information sur
les performances du rseau. Les KPI sont obtenus l'aide de formules et par la compilation
des diffrentes donnes. Les KPI valuent essentiellement le maintien de l'appel, le volume de
trafic, la qualit du service sur l'ensemble du rseau. Les KPI permettent, ainsi, de dtecter les
cellules en faute, les heures de pointe. Un seuil limite est dtermin pour chaque KPI, s'il est
dpass une alarme est envoye la supervision pour indiquer la prsence d'un problme de
performance dans le KPI mentionn. Dans la figure ci-dessous, on peut identifier ltat de
chaque cellule dans la carte en affectant chaque intervalle une couleur selon la criticit.
48
Figure 32: Module de suivi de ltat des cellules rseau travers les KPI
3. Problmes rencontrs
Lors de la ralisation, de nombreuses difficults ont contraint lavancement du
projet et qui, malgr le dsagrment quelles nous ont caus, ont t une bonne opportunit
pour effectuer des recherches et dcouvrir de nouveaux concepts. Ces difficults sont
essentiellement :
- PostGIS version 2, qui est la dernire version actuellement, est incompatible avec SDI
(Spatial Data Integrator), nous a eu recours alors une version postrieure qui est la version
1.5.
- Lintgration dOpenLayers 3 version beta nest pas encore une version stable, elle est
en cours de dveloppement. Nous avons essay au dbut de lintgrer afin dexploiter les
fonctionnalits nouvellement dveloppes mais nous avons trouv dautres fonctions
primordiales qui nont pas encore t dveloppes ce qui nous ramen retourner vers la
version 2.
Conclusion :
Dans ce chapitre, nous avons dcrit lenvironnement de travail matriel et logiciel de
notre projet. Aprs, nous avons prsent les principales interfaces de lapplication avec des
imprimes
crans
afin
de
donner
une
49
image
relle
sur
le
travail
ralis.
Conclusion et Perspectives
Conclusion et Perspectives
Dans le cadre de lamlioration de la qualit de ses services et des quipements
fonctionnant au niveau de son rseau, et afin de faciliter et anticiper les tches effectues par
ses ingnieurs dans la phase de supervision, Ooredoo TN nous a propos de mettre en place
une application web qui supervise la qualit du service, ses quipements via les alarmes
engendres en cas de problmes.
Lobjectif de ce projet de fin dtudes tait la conception et la ralisation dune
application pour le suivi de la qualit sur le rseau Ooredoo TN.Nous avons fait alors une
tude sur les concepts gnraux des rseaux GSM en sintressant aux deux volets :
larchitecture gnrale et la qualit de service. Nous avons aprs men une recherche
bibliographique approfondie sur les systmes dinformation gographiques pour enfin dgager
limportance de ces derniers dans la supervision de la qualit de service.
Ce travail a suivi plusieurs tapes qui ont t trs importantes pour la phase de
ralisation et le dveloppement. La premire tape tait de mettre le sujet dans son contexte
gnral, ce qui a permis de dgager les diffrents besoins dont l'application est charge d'y
rpondre. Ces besoins ont t bien traits et analyss dans la phase de spcification des
besoins. L'tape suivante, tait la conception. Durant toute cette phase, une tude globale et
dtaille des fonctionnalits du systme a t faite pour aboutir enfin l'application qui vise
aider l'oprateur amliorer la qualit de service offert.
En termes de perspectives, on peut suggrer limplmentation de SIG dans une carte en
trois dimensions, dveloppement des algorithmes automatisant la prise de dcision partir des
bases de connaissances des ingnieurs radio, inclure le Geo-BI dans lanalyse rseau qui
permet de dployer les donnes spatiales dans un systme daide la dcision. Cette
intgration fera de notre application un excellent outil intgrant de lintelligence artificielle
permettant aux ingnieurs de superviser le rseau dOoredoo.
Au terme de ce rapport, nous pouvons conclure que ce stage de fin dtudes nous a
donn une occasion opportune qui nous a permis de confronter lacquis thorique
lenvironnement pratique. Lexprience que nous avons vcue au sein de lentreprise
Ooredoo TN , nous a permis non seulement dacqurir de nouvelles connaissances mais
aussi de ctoyer les membres dune quipe professionnelle.
50
Rfrences Bibliographiques
[1] V. Limouza, Dfinition des indicateurs cls de performance, 01 01 2013. [En ligne].
Available: http://acquisitiondetrafic.com/20120907-21-definition-des-indicateurs-cles-deperformance. [Accs le 05 2014].
[2] M. Rouse, GSM, May 2007. [En ligne]. Available:
http://searchmobilecomputing.techtarget.com/definition/GSM .
[3] TALEND, [En ligne]. Available: https://fr.talend.com/products/big-data. [Accs le 06
2014].
[4] Openlayers, [En ligne]. Available:
http://mappemonde.mgm.fr/num8/internet/int05401.html. [Accs le 11 05 2014].
[5] Juanmf, Design patterns used in symfony2, Sep 13 '13 at 17:26. [En ligne]. Available:
http://stackoverflow.com/questions/13696059/design-patterns-used-in-symfony2. [Accs
le 07 2014].
[6] GeoServer Developer Manual, [En ligne]. Available:
http://docs.geoserver.org/stable/en/developer/. [Accs le 05 2014].
[7] Postgis, [En ligne]. Available: http://postgis.refractions.net/. [Accs le 05 2014].
[8] OpenLayers: Free Maps for the Web, [En ligne]. Available: http://openlayers.org/.
[Accs le 05 2014].
[9] The Symfony Book, [En ligne]. Available: http://symfony.com/. [Accs le 06 2014].
Annexes
Annexe A
Tables des KPI :
Figure: 33 Liste des KPI
Annexe B
La figure suivante montre la liste des couches publies dans Geoserver :
Figure 34: Prvisualisation des couches avec Geoserver
La figure 35 illustre la personnalisation des styles daffichage des couches avec

Geoserver
Figure 35: Styled Layer Descriptor (SLD) from Geoserver

La figure 36 montre le sous Job du chargement du Workspace 2g dans lentrept de
donnes Postgis
Figure 36: Chargement du Workspace 2G dans une base de donnes Postgis
Phase ETL pour le chargement de la table Raised_Alarms dans la base donnes Postgis
illustr dans la figure ci-dessous :
Figure 37: Chargement et transformation des donnes Alarmes dans Postgis
Chargement des noms des Site_Physique dans une base de donnes gographique
Figure 38: Chargement du Nom Site Physique dans une base de donnes cartographique
Implmentation dun job global pour automatiser linsertion des donnes gographiques
interprt dans la figure 39
Figure 39: Job Global pour l'excution de tous les sous Job
Formule utilise pour la cration des points construisant le polygone illustre dans la
figure ci-dessous :
Figure 40: Formule de projection des points d'une cellule
Syntaxe pour linsertion du polygone dans la base de donnes Postgis comme la montre
la figure 41
Figure 41: Syntaxe de cration d'un polygone
Figure 42: Rsultat de transformation des coordonnes BTS dans une carte

Rapport Habboub

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Habboub

Uploaded by

Copyright:

Available Formats

:

Ministre de lEnseignement Suprieur

Institut National des Sciences

Projet de Fin dEtudes

TITRE EN FRANAIS : CONCEPTION ET DVELOPPEMENT DUN MODULE

cadre du projet de fin dtudes pour lobtention du Diplme dIngnieur en Gnie

Data Integrator, Symfony 2.

CONCEPTION ET DVELOPPEMENT DUN

TITRE EN ANGLAIS: DESIGN AND DEVELOPMENT OF A GEOGRAPHICAL

Mr. Wael TARHOUNI

Ministre de lEnseignement Suprieur

Institut National des Sciences

Projet de Fin dEtudes

Filire : Gnie Logiciel

CONCEPTION ET DVELOPPEMENT DUN

Mr. Wael TARHOUNI

Anne Universitaire : 2013/2014

Ministre de lEnseignement Suprieur

Institut National des Sciences

Projet de Fin dEtudes

Filire : Gnie Logiciel

CONCEPTION ET DVELOPPEMENT DUN

(Cachet & Signature)

Anne Universitaire : 2013/2014

Jexprime mes vifs remerciements Monsieur Wael TARHOUNI ingnieur support

de la direction technique dOoredoo TN pour mavoir si bien accueillie et permis de

remerciements sadressent galement, tout le personnel de lquipe Radio

Je tiens galement adresser mes remerciements et ma gratitude Madame Saloua

suis particulirement reconnaissant lINSAT Institut National des Sciences

Appliques et de Technologie pour mavoir offert lopportunit dacqurir cette exprience

Table des matires

Cadre gnral du projet ................................................................................................ 3

Prsentation de lorganisme daccueil ..................................................................... 3

Charte dOoredoo TN .............................................................................................. 3

Structure organisationnelle : .................................................................................... 4

Prsentation du sujet ..................................................................................................... 5

Mthodologie de travail ................................................................................................ 6

Chapitre2. Etude pralable ................................................................................ 9

Les rseaux mobiles ....................................................................................................... 9

Les diffrents standards technologiques .................................................................. 9

Architecture gnrale du rseau GSM ................................................................... 10

Critres dvaluation de la qualit de service dans un rseau GSM ...................... 11

Les diffrents critres dvaluation ................................................................ 11

Les indicateurs de cl de performance KPI (Key Performance Indicators) ... 12

Les Systmes dinformations gographiques (SIG) ................................................. 12

Dfinition de SIG ................................................................................................... 13

Rle des SIG dans la supervision des rseaux GSM : ........................................... 13

Reprsentation de larchitecture rseau travers le SIG ....................................... 14

Reprsentation gographique des BTS ........................................................... 14

Reprsentation gographique des cellules ...................................................... 15

Etude de lexistant ....................................................................................................... 16

Solution envisage ....................................................................................................... 17

Chapitre3. Spcification des besoins ............................................................... 19

Identification des acteurs ............................................................................................ 19

Analyse des besoins ..................................................................................................... 19

Besoins fonctionnels .............................................................................................. 19

Besoins non fonctionnels ....................................................................................... 21

Organisation des cas utilisations ............................................................................ 21

Raffinement des cas dutilisations ......................................................................... 24

Diagramme des squences ..................................................................................... 26

Chapitre4. Architecture et Conception ........................................................... 28

Module dextraction, de transformation et de chargement des donnes ........ 28

Module de publication des donnes gographiques ....................................... 30

Module daffichage des donnes gographiques ............................................ 31