PFE 2019 Finale1

Remerciements
Avant de commencer la présentation de ce travail, nous profitons de l’occasion pour re-

mercier toutes les personnes qui ont contribué de près ou de loin à la réalisation de ce projet
de fin d’études.
Nous tenons à exprimer nos immenses respects et gratitude à Mr Houssem Eddine Tounsi,
de nous voir accepté en tant que stagiaires au sein de son entreprise et de nos permettre de
réaliser notre projet.
Nous saisissons également cette occasion pour remercier tout le personnel de TELCOTEC
pour les informations précieuses dont ils nos ont fait part afin de nous aider à confectionner
ce rapport.
Un merci tout aussi grand à Mr Taeib Masmoudi notre tuteur qui nous a accompagnés
de près durant tout ce travail, pour sa disponibilité, pour la confiance qu’il a su nous accor-
der et les conseils précieux qu’il nous a prodigués tout au long de la réalisation de ce projet.
Nos remerciements vont aussi à tous nos professeurs, enseignantes et toutes les personnes
qui nous ont soutenu jusqu’au bout, et qui n’ont pas cessé de nous donner des conseils très
importantes en signe de reconnaissance.
i
Table des matières
1 Présentation générale et étude de l’existant 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Les différents division . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Astellia [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 SunVizion [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 Nemo Outdoor[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.4 Atoll[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.5 Actix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Solution Proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Méthodologie et approche adoptée . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1 Argumentation du choix . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.2 Le processus 2TUP[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 État de l’art 13
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Ingénierie et optimisation des réseaux mobiles . . . . . . . . . . . . . . . . . 13
2.2.1 Ingénierie des réseaux mobiles . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Optimisation radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Audit de la capacité des réseaux radio mobile . . . . . . . . . . . . . 16
2.3 La qualité de service et les indicateurs clé de performance . . . . . . . . . . . 19
2.3.1 Les principes de la qualité de service . . . . . . . . . . . . . . . . . . 19
2.3.2 Les indicateurs de qualité de service . . . . . . . . . . . . . . . . . . 20
ii
Table des matières
2.3.3 Les indicateurs clés de performance . . . . . . . . . . . . . . . . . . . 20

2.4 Méthodologie d’évaluation de la qualité de service . . . . . . . . . . . . . . . 21
2.4.1 Les mesures de performance . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Les compteurs OMC . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Benchmarking End-To-End Drive Test . . . . . . . . . . . . . . . . . 22
2.4.4 Classes des KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Planification et Conception 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Besoins fonctionnels et non fonctionnels . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.2 Besoins Non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 architecture 3-tiers[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Modèle architectural MVC[9] . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 La modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.1 Présentation d’UML[10] . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.6.2 Les avantages d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.1 Diagramme de cas d’utilisation général[11] . . . . . . . . . . . . . . . 36
3.7.2 Diagramme de cas d’utilisation raffiné du suivi de la performance du
réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.8 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8.1 Diagramme de séquences «Ajouter Formule» . . . . . . . . . . . . . . 39
3.8.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8.3 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4 Réalisation : Eagle Vision Network Monitoring 43

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
iii
Table des matières
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Menu de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.2 Tableau de Bord de l’application . . . . . . . . . . . . . . . . . . . . 48
4.3.3 Interface Visualisation des formules . . . . . . . . . . . . . . . . . . . 49
4.3.4 Importer un fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.5 Interface Supervision des performances . . . . . . . . . . . . . . . . . 50
4.3.6 Interface Benchmarking Drive Test . . . . . . . . . . . . . . . . . . . 54
4.3.7 Interface Benchmarking Drive Test de deux opérateurs . . . . . . . . 56
4.3.8 Géolocalisation sites . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3.9 Interface Audit de la capacité du réseau UMTS . . . . . . . . . . . . 58
4.3.10 Interface Audit du trafic réseau UMTS . . . . . . . . . . . . . . . . . 60
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A Annexe 63
Bibliographie 76
iv
Table des figures
1.1 Organigramme Telcotec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Méthodologie 2TUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Schéma général du processus de l’optimisation. . . . . . . . . . . . . . . . . . 16

2.2 Méthodologie d’audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Clase KPI UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4 Classe KPI LTE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Diagramme de cas d’utilisation général. . . . . . . . . . . . . . . . . . . . . . 36
3.4 Diagramme de cas d’utilisation raffiné du suivi de la performance du réseau. 37
3.5 Diagramme de séquences « Ajouter une formule». . . . . . . . . . . . . . . . 39
3.6 Diagramme de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7 Diagramme d’activité «Télécharger un fichier» . . . . . . . . . . . . . . . . . 41
4.1 Menu de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2 Dashboard UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Visualisation des formules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Visualisation du KPI par rapport au temps. . . . . . . . . . . . . . . . . . . 51
4.5 Analyse de deux KPIs par rapport au temps. . . . . . . . . . . . . . . . . . . 52
4.6 Post-processing Drive Test 3G. . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 Affichage Drive Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8 Chart Benchmarking Drive Test. . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Statistiques Benchmarking deux opérateurs. . . . . . . . . . . . . . . . . . . 56
4.10 Statistiques Benchmarking deux opérateurs. . . . . . . . . . . . . . . . . . . 56
4.11 Géolocalisation des sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.12 Audit de la capacité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
v
Table des figures
4.13 RTWP analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.14 Audit du trafic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.15 Analyse détaillée du trafic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.1 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.2 Dashboard 2G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3 Dashboard 4G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.4 Tableau à imprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.5 Ajouter formule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.6 Formule ajoutée avec succès. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.7 Sélectionner Formule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.8 Formule supprimée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.9 Importer un fichier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
A.10 Sélectionner un fichier. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.11 Fichier importé avec succés. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.12 Formulaire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.13 Affichage Drive Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.14 Post-processing Drive Test 2G. . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.15 Post-processing Drive Test 4G. . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.16 Benchmarking Drive Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.17 HandOver Success Rate UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.18 Call Drop Rate UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.19 Analyse de fréquence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.20 Sélection de la bande de fréquence. . . . . . . . . . . . . . . . . . . . . . . . 73
A.21 Valeur de la fréquence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.22 Distribution du trafic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.23 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
vi
Liste des tableaux
1.1 Comparaison entre les méthodologies de travail . . . . . . . . . . . . . . . . 9
2.1 Indicateurs clés de performance de capacité . . . . . . . . . . . . . . . . . . . 17
3.1 Description du cas suivre la performance . . . . . . . . . . . . . . . . . . . . 38
vii
Liste des acronymes
* GSM Global System for Mobile Communications.
* UMTS Universal Mobile Telecommunication System.
* LTE Long Term Evolution.
* WCDMA Wideband Code Division Multiple Access
* LTE-A Long Term Evolution Advanced.
* XP eXtreme Programming.
* RUP Rational Unified Process.
* 2TUP Two Tracks Unified Process.
* QOS Quality Of Service.
* KPI Key Performance Indicator.
* OMC Operation and Maintenance Center
* OSS Operations Support System
* RF Radio Frequency.
* DT Drive Test
* HO HandOver
* RTWP Received Total Wideband Power.
* PCH Physical CHannel
* BTS BTS Base Transceiver Station
* RSCP Received Signal Code Power
* RSRP Reference Signal Received Power
* RSRQ Reference Signal Received Quality
* RSSI Received Signal Strength Indicator
* Sc Scrambling Code
viii
Liste des tableaux
* RRC Radio Resource Control
* RAB Radio Access Bearers
* ERAB EPS Radio Access Bearer
* UTRAN UMTS Terrestrial Radio Access Network
* eUTRAN Evolved UMTS Terrestrial Radio Access Network
* CSV Comma Separated Value
* xlsx Excel spreadsheet
* MVC Model-View-Controller
* UML Unified Modeling Language
* CS Circuit Switching
* PS Packet Switching
* SINR Signal to Interference Noise Ratio
* PHP HyperText Preprocessor
* SGBD Système de gestion de base de données
* WAMP Windows Apache MySQL PHP
ix
Introduction générale
Le monde d’aujourd’hui est témoin d’un progrès énorme dans les différents domaines et
plus particulièrement dans le domaine des réseaux mobiles, cette progression remarquable
pousse les sociétés et les opérateurs à considérer les sites et les applications d’optimisation
et de suivi de qualité de service comme un dispositif global fournissant à ces derniers un
pont de passage à un ensemble de réseaux optimisés et répondants aux exigences des clients
et opérateurs en termes de qualité de service et d’optimisation des réseaux dont le but est
d’avoir une satisfaction des besoins et une atteinte d’objectifs d’une façon plus rapide et plus
efficace.
Les opérateurs des réseaux mobiles utilisent différentes techniques pour la supervision de la
qualité de service. Pour cela, sont utilisés les compteurs OMC pour les indications et des
fichiers de traces capturés au niveau de l’interface radio (Drive test).
Cependant, cette supervision n’est pas une tâche facile à réaliser vue la complexité de l’ar-
chitecture du réseau et la configuration de ses différents éléments.
Ainsi, on a pensé à créer une application logicielle intitulée "Eagle Vision Network Monito-
ring" pour faciliter les tâches de surveillance de la qualité des services des opérateurs du
réseau mobile.
Le choix du nom de notre application c’est inspiré du proverbe :
"L’aigle ne fuit jamais la tempête. Par contre il s’en sert pour prendre de la hauteur."
Fred Bulobo Mbayo.
L’aigle se focalise sur sa proie du début à la fin de la chasse et il est réputé pour son regard
perçant.
Le présent travail s’inscrit dans le cadre de notre projet de fin d’études en vue de l’ob-
tention du diplôme d’Ingénieur en télécommunications et réseaux de l’Université libre de
Tunis (ULT).
1
Liste des tableaux
Ce projet vise à compléter notre formation universitaire acquise au sein de cet établisse-
ment, et de nous introduire dans la vie professionnelle grâce à une mise en pratique de nos
connaissances et à mettre à l’épreuve notre esprit d’ingénieur.
Notre rapport sera organisé de la manière suivante :
Dans le premier chapitre, nous commençons par la présentation du cadre et du contexte

général de notre projet, ensuite nous présenterons la problématique tout en critiquant les
solutions existantes pour dégager leurs insuffisances et proposer les orientations de notre
solution future.
Dans le second chapitre nous serons chargés d’identifier les termes principaux qui englobe
notre application à savoir l’optimisation et la qualité de service , et nous allons définir l’in-
génierie des réseaux mobiles.
Le troisième chapitre est une formalisation des étapes préliminaires du développement d’un
système afin de le rendre plus fidèle aux besoins du client qui sont divisés en besoins fonc-
tionnels, besoins non fonctionnels et besoins techniques et à détailler la partie analyse et
conception.
Au cours du quatrième chapitre nous présenterons l’environnement de développement ma-

tériel et logiciel que nous allons adopter pour notre application ainsi qu’un aperçu sur le
travail réalisé.
Finalement, nous clôturons le rapport par une conclusion générale qui synthétise notre travail
et ouvre sur de nouvelles perspectives.
2
Présentation générale et étude de l’existant
1
1.1 Introduction
Ce présent chapitre est une introduction à notre projet de stage de fin d’études, il a
pour but de définir le contexte général du projet afin de le situer dans son environnement
organisationnel et contextuel.
1.2 Présentation de l’organisme d’accueil
1.2.1 Historique
TELCOTEC est une entreprise créée en Janvier 2015, elle est située au sein du pépinière
du parc technologique EL GHAZELA.
Elle se spécialise dans les domaines des télécommunications et des signaux radio ainsi que
celui de l’informatique orientée vers ce domaine.
C’est une société issue de prés de vingt ans d’expérience dans les domaines techniques et
de management des télécommunications. Ces ingénieurs/consultants ont géré et optimisé
plusieurs réseaux fixes et mobiles de plusieurs millions d’abonnés et ont conduit des dizaines
de projets d’études et d’infrastructure de plusieurs milliers d’euro ainsi qu’une réalisation de
1
Chapitre 1. Présentation générale et étude de l’existant
nombreuses missions d’audit, d’étude, d’optimisation et de conseil de formation dans leurs

domaines d’expertise.
1.2.2 Les différents division
L’organigramme de la société TELCOTEC est représenté par la figure suivante.
Figure 1.1: Organigramme Telcotec
1.3 Cadre du projet

Le monde d’aujourd’hui est caractérisé par une évolution énorme dans le domaine des
télécommunications et des réseaux mobiles.
Le monde est témoin d’une révolution enracinée dans notre quotidien dont on constate un
impact influant la façon dont nous, utilisateurs des services, souhaitons bénéficier des services
avec une qualité satisfaisante qui répond à nos besoins divers.
2
Au vu de ce constat on ne peut pas négliger la complexité d’évolution des réseaux, ce qui nous
oblige à trouver les moyens d’optimiser les réseaux et d’avoir la qualité de service souhaitée.
Ce sont les opérateurs et sociétés d’optimisation qui sont responsables de ces traitements.
Le défi alors est de créer une application qui facilite la tâche des opérateurs et des sociétés
d’optimisation à travers une interface simple et performante.
Dans cette perspective, on trouve que les outils d’optimisation occupent une place importante
sur le marché. Ces outils sont très utilisés dans l’optimisation et le suivi de la qualité de service
des réseaux mobile, ce qui nous pousse tout d’abord à présenter ces solutions existantes sur
le marché avant de les analyser et les critiquer.
1.4 Étude de l’existant

La réalisation de tout projet doit être précédée par une étude de l’existant qui détermine
les points faibles et les points forts des systèmes et applications actuels et les besoins du
client en vue de les prendre en considération lors de la conception et de la réalisation.
Cela nous menés à une étude basée sue les observations de différentes applications spéciali-
sées dans le domaine de l’optimisation des réseaux.
Cette étude nous permet de dégager et donner leurs atouts et leurs faiblesses afin de déter-
miner les besoins et les traiter.
Commençons par la définition et la citation des points faibles et des points forts des
applications présentes sur le marché :
1.4.1 Astellia [1]
Leader mondial des solutions d’analyse de la performance des réseaux mobiles et de l’expé-
rience des abonnés, Astellia aide les opérateurs à améliorer la qualité de service, à maximiser
3
leur efficacité opérationnelle, à réduire les taux de désabonnement et à accroître leurs reve-
nus. Les solutions de monitoring et de troubleshooting en temps réel d’Astellia optimisent
l’ensemble des réseaux, de bout en bout depuis l’accès radio jusqu’au cœur du réseau.
Nova Geo[2]
C’est une solution de monitoring, d’analytique et de troubleshooting en temps réel d’Astellia

destinée aux réseaux mobiles multi-équipementiers.
Nova Geo est un outil d’optimisation radio multi-technologies et multi-fournisseurs qui me-
sure la couverture RF et la qualité du réseau .
Il facilite les tâches quotidiennes d’optimisation radio en automatisant les analyses récur-
rentes et réduit considérablement le nombre de drive test. La solution Nova Geo entièrement
virtualisée d’ Astellia prend en charge les techniques de géolocalisation les plus avancées,
garantissant ainsi une précision de premier ordre en matière de localisation des dispositifs et
des conditions radio sur des réseaux multi-technologies (2G / 3G / 4G / LPWAN).
1.4.1.1 Points forts
â Amélioration de l’efficacité opérationnelle,

â Économies de capital et capacité accrue,
â Déploiement plus rapide du réseau.
1.4.1.2 Points faibles
â Coûteuse,
â Pas de personnalisation,
â Pas d’analyse POST-PROCESSING,
4
1.4.2 SunVizion [3]
La solution SunVizion Network Performance Monitoring est spécialement conçue pour détec-
ter la dégradation des performances d’un réseau de télécommunication et garantir le service.
Le système améliore l’efficacité opérationnelle et réduit considérablement le coût total de
possession.
â Surveillance en temps réel,

â Flexibilité et grande évolutivité,
â Compatible avec une large gamme de services, technologies et protocoles,
â Examen facile des rapports KPI,
â Pas de personnalisation (Formules KPI),

â Pas de visualisation des statistiques,
â Interface compliquée.
1.4.3 Nemo Outdoor[4]
Nemo Outdoor permet aux opérateurs de tester et de vérifier la capacité des réseaux sans fil
LTE-A.
Il offre un support incomparable pour plus de 300 terminaux de test et récepteurs de numé-
risation.
Nemo Outdoor est parfaitement adapté aux problèmes de réseau ciblés dans toutes les phases
établies et émergentes du cycle de vie du réseau.
Il peut être étendu pour couvrir des mesures étendues et puissantes, allant des drive tests
5
aux analyses comparatives et aux mesures de qualité de service.
â Parfaitement adapté aux problèmes de réseau,

â Analyses comparatives,
â Mesures de qualité de service.
â Limitée au Drive Test,

â Solution Coûteuse,
1.4.4 Atoll[5]
ATOLL est une plate-forme d’optimisation et de conception de réseau sans fil multi-
technologie, ouvert, évolutif, flexible,offre la possibilité de se placer dans les conditions les
plus vraisemblables et prend en charge les opérateurs de téléphonie mobile tout au long du
cycle de vie du réseau, de la conception initiale à la densification et à l’optimisation.
â Couverture par niveau de champ.

â Couverture par émetteur,
â Etude du trafic,
â Zone de recouvrement.
â Solution coûteuse,
â Pas de personnalisation (Formules statiques),
â Une manipulation difficile de l’interface.
6
1.4.5 Actix
Actix Analyzer est la plate-forme multi-fournisseurs et multi-technologies la plus puis-

sante et la plus largement déployée sur le marché, qui prend en charge toutes les sources
de données de réseau mobile clés, intègre des diagnostics automatisés et des algorithmes de
recherche de solutions, et fournit des fonctionnalités logicielles de visualisation, d’analyse et
d’optimisation via une interface Web.
â Création du réseau,
â Optimisation des performances du réseau ,
â Test des fonctionnalités .
â Analyse comparative du réseau.
â Solution coûteuse,
â Pas de personnalisation (Formules statiques),
â Une manipulation difficile de l’interface,
â Limitée au réseau d’accès.
1.5 Solution Proposée

Après avoir analysé les différentes solutions existantes. La question suivante se pose :
Est ce que les applications existantes peuvent représenter une solution qui ré-
pond à nos besoins ?
Comme nous pouvons le constater les applications sur le marché sont privées et très coû-
teuses. Cependant nous avons besoin d’une solution spécifique, personnalisable et moins
7
coûteuse qui répond parfaitement aux besoins spécifiés par la société cliente en respectant
son indépendance et son autonomie.
Par conséquent, nous avons pensé à analyser et développer une application WEB qui répond
aux besoins des clients, d’où la naissance de notre application EAGLE VISION NET-
WORK MONITORING.
Ce projet de fin d’études consiste à mettre en place une application qui assure une vue globale
sur le comportement du réseau de télécommunications, suivre de près les dégradations ou les
améliorations du réseau et l’identification des facteurs causant les problèmes afin d’assurer
la qualité de service des réseaux mobiles.
EAGLE VISION NETWORK MONITORING c’est une application personnalisable,
multi-vendor, multi-technology , qui permet de :
4 Avoir une vue globale sur le comportement du réseau,
4 Auditer les différents éléments du réseau(Paramètres, KPI ..),
4 Identifier les causes et les facteurs du mauvais fonctionnement du réseau (interférence,
HandOver non déclarés, conflit PCI ... ),
4 fournir une analyse pour le Post-Processing Drive Test,
4 Fournir une analyse comparative du réseau de différent opérateur.
4 Fournir une analyse comparative du réseau.
1.6 Méthodologie et approche adoptée

La gestion du projet consiste dans la mise en œuvre d’une méthodologie pour faire en
sorte que l’ouvrage soit livré dans les conditions de coût et de délai initialement prévus. En
effet, son objectif capital est d’assurer la coordination des acteurs et des tâches dans un souci
d’efficacité et de rentabilité.
Afin d’appliquer cette gestion, plusieurs méthodologies ont été conçues parmi lesquelles nous
citons particuliérement XP, RUP,2TUP.
C’est pour cette raison qu’on a eu recours à une étude comparative pour adopter la métho-
dologie la plus adéquate à notre projet.
8
Table 1.1: Comparaison entre les méthodologies de travail
1.6.1 Argumentation du choix
Cette étude comparative nous a permis de tracer les règlements suivants :

+ Le processus RUP (Rational Unified Process ) néglige les contraintes techniques
qui sont primordiales dans notre projet, c’est pourquoi ce choix n’est pas le meilleur dans
notre cas.
+ Le processus XP (eXtreme Programming) néglige la phase de spécification des be-
soins fonctionnels et techniques ,et la phase de conception, du coup il est découragé.
+ Le processus 2TUP (Two Tracks Unified Process) permet de séparer les contraintes
fonctionnelles des contraintes techniques en les présentant sous forme de deux branches afin
d’être exploités parallèlement.
Après une étude comparative approfondie de ces processus de développement et afin de
contrôler les risques et de mener à terme notre projet vu sa complexité, notre choix s’est
orienté vers le processus 2TUP pour multiples raisons :
9
2TUP privilège la technologie ce qui est important pour notre projet.

2TUP est un processus en « Y » qui possède une branche technique, une branche fonction-
nelle et une branche réalisation qui peuvent être exploitées en parallèle.
Donc, au cas ou la technologie évolue ou il y’a modification d’un besoin technique au cours
du projet, la branche technique peut être modifiée puis réintégrée dans le projet facilement.
De même s’il y’a une nouvelle fonctionnalité présentée, seule la branche fonctionnelle sera
traitée.
1.6.2 Le processus 2TUP[6]
Le processus 2TUP (Two Track Unified Process) est un processus unifié. Il gère la
complexité technologique en donnant part à la technologie dans son processus de développe-
ment (Franck,2004).
Le 2TUP propose un cycle de développement qui sépare les aspects techniques des aspects
fonctionnels et propose une étude parallèle des deux branches : fonctionnelle (étude de l’ap-
plication) et la technique (étude de l’implémentation).
Le processus 2TUP s’articule autour de trois branches :
â Une branche technique,
â Une branche fonctionnelle,
â Une branche de conception et réalisation.
10
La figure suivante 1.2 détaille les étapes de développement des trois branches du proces-
sus 2TUP.
Figure 1.2: Méthodologie 2TUP.
â Branche fonctionnelle : Les principales étapes de la branche fonctionnelle se pré-

sentent comme suit :
f L’étape capture des besoins fonctionnels : Cette phase a pour objectif de définir la
frontière fonctionnelle entre le système et son environnement et les activités attendues des
différents utilisateurs par rapport au système.
f L’étape d’analyse : consiste à étudier précisément les spécifications fonctionnelles de ma-
nière à obtenir une idée de ce que va réaliser le système en terme de métier.
â Branche technique :Les principales étapes de la branche technique se présentent

comme suit :
11
f L’étape capture des besoins techniques : Cette étape recense toutes les contraintes sur les
choix de technologies pour la conception du système. Les outils et le matériel sélectionnés
ainsi que la prise en compte des contraintes d’intégration avec l’existant (pré requis d’archi-
tecture technique).
f L’étape conception générique : Définit les composants nécessaires à la construction de
l’architecture technique. Cette conception est complètement indépendante des aspects fonc-
tionnels. Elle permet de générer le modèle de conception technique qui définit les Frameworks.
â Phase conception - réalisation Les principales étapes de cette branche se présentent
comme suit :
f L’étape conception préliminaire : Cette étape permet de produire le modèle de conception
système. Ce dernier organise le système en composants, délivrant les services techniques et
fonctionnels, Ce qui induit le regroupement des informations des branches technique et fonc-
tionnelle.
f L’étape conception détaillée : permet d’étudier comment réaliser chaque composant.le ré-
sultat fournit l’image prête à fabriquer du système complet.
f L’étape de codage : permet d’effectuer la production des composants et les tests des unités
de code au fur et à mesure de leur réalisation.
f L’étape de recette : consiste à valider les fonctionnalités du système développé.
1.7 Conclusion
Ce chapitre introductif nous a permis de détailler le cadre général en présentant l’entre-
prise d’accueil, l’application que nous allons concevoir, ainsi que de présenter les différentes
solutions existantes.
Dans ce qui suit, nous allons entamer la première étape de notre projet «État de l’art» pour
étudier les différentes notions théoriques principales pour bien comprendre le projet.
12
État de l’art
2
2.1 Introduction
L’objectif de ce chapitre est de rattacher le projet à son cadre théorique, à rappeler
l’évaluation de la qualité de service et des performances qui sont des notions fondamentales
dans les réseaux mobiles.
Nous allons donc définir les deux termes qualité de services et optimisation tout en définissant
les termes relatifs à ces deux notions.
2.2 Ingénierie et optimisation des réseaux mobiles

Le domaine des Télécommunications est l’un des plus dynamiques et répandu dans le
monde. Il est nourri par une association de dérégulations et de consolidations favorisant sa
complexité et son émergence permanente de nouveaux acteurs.
13
Chapitre 2. État de l’art
2.2.1 Ingénierie des réseaux mobiles
L’ingénierie des réseaux mobiles permet d’identifier les paramètres de QoS dans les ré-
seaux radio mobiles, évaluer les paramètres et modéliser les réseaux et les méthodes d’opti-
misation.
L’importance de l’ingénierie des réseaux mobiles consiste à concevoir et réaliser des réseaux
mobiles pour répondre aux objectifs de qualité de service des opérateurs.
L’optimisation des réseaux mobiles permet aux opérateurs de délivrer des services de plus
grandes capacités et de supporter les nouvelles applications dévoreuses de bande passante,
telles que le trafic engendré par les Smart-phones, sans augmenter les coûts d’investissement.
Les données associées pendant les campagnes de couverture radio (drive test qui représentera
aussi une partie importante dans notre application) facilitent la configuration du réseau selon
les besoins de la qualité de service définis en fonction des critères bien connus des opérateurs
mobiles tels que :
— Zones urbaines ou rurales, Immeubles, Aéroports, etc.
— Taux de réussite d’appel, Taux d’erreur de transfert de cellules (Handover), Qualité
de réception RF, etc.
Les solutions de test des cas cibles doivent proposer une collecte crédible des données et
des fonctions détaillées en analyse de données pour garantir la performance du réseau et la
qualité d’expérience de l’utilisateur final.
L’évaluation et l’identification de la qualité de service du réseau et les facteurs de perfor-
mance réalisées par les opérateurs sont assurés d’une façon systématique et efficace par les
données et les renseignements associés.
Des informations pertinentes, générées à partir de données fiables et précises, aident les opé-
rateurs à prendre des décisions judicieuses et basées sur des faits pour leurs investissements
stratégiques.
Les opérateurs sont aidés par les informations générées à partir de données précises et fiables
,collectées et mesurées par les ingénieurs, pour prendre des décisions basées sur des faits pour
leurs investissements stratégiques.
Afin de bien déployer un réseau, une bonne configuration des antennes RF est nécessaire
pour avoir une bonne performance et une bonne adaptation de la capacité.
14
2.2.2 Optimisation radio
Afin de gagner la satisfaction de leurs clients, les opérateurs essaient d’assurer la conti-
nuité de la fourniture des services avec une qualité optimale. L’optimisation est une phase
importante pour maintenir et améliorer la qualité et la capacité d’un réseau.
La phase d’optimisation permet aussi de minimiser ses coûts et d’optimiser les ressources
rares, c’est une étape des plus cruciales du cycle de vie d’un réseau cellulaire. Une fois le
réseau est opérationnel, l’opérateur doit veiller sur son bon fonctionnement. Ceci est néces-
saire afin de réaliser un suivi de la qualité de service et dadapter le réseau aux différentes
fluctuations en vue de son amélioration et de son expansion. Ainsi l’optimisation d’un réseau
cellulaire est motivée par deux objectifs principaux : améliorer la qualité de service offerte
aux utilisateurs et augmenter le volume de trafic écoulé par le réseau avec les équipements
existants.
Schéma général du processus de l’optimisation
Le processus d’optimisation est un cycle périodique à qui on peut faire appel plusieurs fois
dans un même réseau de communication mobile, soit juste après le déploiement du réseau et
c’est ce qu’on appelle la pré-optimisation, ou après le lancement du réseau et c’est ce qu’on
va détailler tout au long de notre sujet. Ce cycle comme le montre le schéma ci-dessous 2.1
commence par la supervision des performances à travers les statistiques (KPI), puis lanalyse
de ces statistiques afin de sélectionner les zones où il y a des problèmes, pour lancer des
parcours de tests (Drive Tests) afin de mieux connaître la cause de ces problèmes. Ensuite
une analyse globale des KPI et des résultats des parcours de tests permettra d’énumérer
un nombre d’actions à entreprendre. Après validation et implémentation de ces actions, on
reprend le cycle dès le début pour voir les résultats et ainsi de suite.
15
Figure 2.1: Schéma général du processus de l’optimisation.
2.2.3 Audit de la capacité des réseaux radio mobile
A toute phase du cycle de vie du réseau mobile, l’analyse de la capacité suit un processus
de drill-down. Au sommet, il y a un nombre réduit de critères de la capacité qui résume
l’accomplissement de la capacité. L’audit de la capacité, se base sur l’audit du débit,ce der-
nier dépend de certaines paramètres. L’analyse du réseau est primordiale pour détecter les
mauvaises configuration, l’interférence, le conflit du PCI ... .
La rentabilité du réseau est étroitement liée à sa capacité, c’est-à-dire à la quantité d’infor-
mation pouvant être échangée simultanément. Dans un contexte mono service, le nombre
d’utilisateurs définit la capacité.
Dans le système WCDMA, où plusieurs services seront offerts et où la consommation en
ressources radio diffère d’un service à l’autre, plutôt que de raisonner sur le nombre de mo-
biles, la capacité peut être définie comme le débit global écoulé dans le réseau par exemple,
le nombre maximal de communications ne dépend pas uniquement des ressources "dures", à
savoir du nombre de codes disponibles, mais aussi des interférences, dont la distribution de
trafic dans le réseau et de ses caractéristiques. On parle alors de "soft capacity".
2.2.3.1 Les paramètres de performance de la capacité
En effet, si un des KPIs dépasse les seuils fixés par l’opérateur, le responsable d’audit
du réseau constate qu’un problème est survenu au niveau de la fonctionnalité qu’assure cet
indicateur.
16
KPI Seuil (%) Risque de congestion

TCP 70 défaillance du service
RTWP 75 Coupure d’appel , dégradation de la QOS
PCH 60 perte de pagging
FACH 70 pas de débit sur la cellule Cell_Fach
CODE 70 défaillance du service
IUB 70 défaillance du service
IU 70 défaillance du service
CNBAP 60 défaillance du service
CE 70 défaillance du service
SPU 50 rejeter l’établissement de service
DPU 60 dégradation de la QOS
MPU 50 rejeter l’établissement de service
INT 50 dégradation de la QOS
Table 2.1: Indicateurs clés de performance de capacité
Le tableau ci-dessus 2.1 présente quelques KPIs de capacité pour le réseau mobile UMTS
pour le fournisseur HUAWEI.
La figure ci-dessous 2.2 représente la méthodologie d’audit de la capcité d’un réseau 3G
(Phase end-to-end ).
Figure 2.2: Méthodologie d’audit.
17
Dans cette partie, nous allons présenter parmis ces paramètres, les paramètres qu’on a
pu utiliser dans la phase d’audit de capacité vu que certde notre application .
Le RTWP (Cell UL Power Ressource)[7] est lié aux interférences de liaison montante, et sa
surveillance permet de contrôler les interruptions d’appel.
Il est également important dans l’audit de la capacité, car il fournit des informations sur le
contrôle de congestion concernant les interférences sur la liaison montante (les interférences
sont la principale cause de dégradation des performances).
En effet, High RTWP indique en fait la présence d’interférences ou de mauvaise configu-
ration (RNC/NodeB).
Généralement, le problème peut être dû à :
— Un problème d’interférence,
— Une mauvaise configuration,
— Un Problème de couverture...
TCP (Cell DL Power Ressource) est l’une des ressources limitées en fonction de la puissance
de sortie totale ayant un impact direct sur la capacité et les performances de la cellule.
Pour avoir une vue d’ensemble du réglage de la puissance dans une cellule, nous pouvons
vérifier le paramétrage de la puissance totale et de la puissance CPICH.
CNBAP est utilisé pour évaluer la capacité de traitement du NodeB. La surcharge CNBAP
réduit la capacité de traitement de NodeB, ce qui affecte ensuite les indicateurs de perfor-
mance clés liés à NodeB. High CNBAP a de graves conséquences sur la qualité de service
de l’accessibilité, de la maintenabilité et des données.
Lorsque les charges CNBAP dépassent les 70% du seuil, les énormes déclenchements RL ont
échoué .
18
2.3 La qualité de service et les indicateurs clé de perfor-

mance
La Qualité de service c’est le degré de satisfaction des clients.
La signification de la qualité de service est très importante dans le domaine des télécommu-
nications.
En effet l’évaluation de l’état du système et la détection des dysfonctionnements sont des
tâches primordiales pour que l’opérateur puisse avoir une maîtrise sur le réseau et mener à
bien ses actions et interventions de maintenance.
2.3.1 Les principes de la qualité de service
Actuellement, la qualité de service est devenue un facteur déterminant pour les opérateurs
de télécommunication qui se sont donc aperçus que la qualité de leurs services doit être
constamment contrôlée.
D’une part leurs prestations doivent être suivies pour connaître l’état de fonctionnement de
leurs infrastructures et d’une autre part pour améliorer leur compétitivité.
Pour faciliter la compréhension et la mise en place d’une approche simple de qualité de
service, les principes suivants sont définis :
— La qualité de service ne concerne que des propriétés, caractéristiques et paramètres
pouvant être mesurés et comparés à des valeurs limites.
— L’évaluation de la qualité ne nécessite pas de définir et mesurer chaque propriété des
dispositifs de service.
— Il est important de définir un ensemble commun d’outils pour fournir des résultats
comparables pour faire face à la concurrence et pour fidéliser la clientèle.
Le terme indicateur signifie une valeur basée sur un ou plusieurs compteurs et qui représente
des performances du réseau.
Nous représenterons deux catégories de ces indicateurs :
Ê les indicateurs de qualité de services ,
Ë les indicateurs clé de performance.
19
2.3.2 Les indicateurs de qualité de service
Ces indicateurs ont pour objectifs :

ô La gestion de la qualité de service en identifiant les défauts dans les éléments du sous-
système radio et d’établir les actions correctives.
ô Détection et identification des problèmes radio d’une cellule.
ô Le suivi des changements du sous-système radio : Modèle de trafic, charge et évolution du
trafic.
2.3.3 Les indicateurs clés de performance
L’évaluation de la qualité de service dans les réseaux mobiles se base sur des indicateurs
de performance (Key Performance Indicator-KPI).
Ces indicateurs sont établis à partir des compteurs de performance.
Le responsable de l’établissement de ces compteurs est le centre d’opération et d’entretien
OMC.
Les compteurs de performance sont organisés sur 3 classes :
+ Les Compteurs cumulatifs : Indiquant le nombre d’évènements qui ont eu lieu dans une
période bien déterminée de temps.
+ Les Compteurs statiques : ce sont des données statiques collectées relativement à l’état
d’une ressource spécifique.
+ Les Évènements d’observations : ce sont des observations sur un événement système.
Les KPIs sont les mesures obtenues à l’aide des formules, qui donnent une information sur
l’état et les performances du réseau ou d’un processus.
Nous citerons plus en détails ces indicateurs dans la partie optimisation.
Les critères de performance chez l’opérateur Ce sont les aspects techniques en rap-
port avec les technologies et les composants du réseau. Ils font référence au cout consenti par
l’opérateur pour le déploiement, l’évolution et le maintien du fonctionnement du réseau le
réseau. L’opérateur fixent des objectifs garantissant une bonne qualité de prestation de leur
service tout en minimisant ses couts. Ces objectifs sont importants car ils conditionnent la
situation concurrentielle de l’opérateur.
Les critères de performance chez l’utilisateur Ces aspects décrivent la performance
du réseau tel qu’elle est perçue par les utilisateurs , ces critères sont directement mis en
20
rapport avec les attentes des abonnés et affectent profondément le degré de satisfaction de
service.
Ces attentes sont principalement liées à la disponibilité du réseau (probabilité d’obtention
d’un nouvel appel),le maintien de la communication (probabilité de coupure d’une commu-
nication) et la qualité auditive de la voix (puissance du signal, brouillage).
Ces aspects sont dépendant des mécanismes de fonctionnement du réseau (radio) tel que :
— Couverture et capacité du réseau.

— Taux de congestion.
— Maintien de la communication (Taux de coupure).
— Les interférences (qualité de la communication).
2.4 Méthodologie d’évaluation de la qualité de service

La méthodologie d’évaluation de la qualité de service se base sur trois axes :
— ECM, Questionnaire
— Compteur OSS,
— Benchmarking End-To-End (Drive Test).
Parmi les fonctionnalités majeur de notre application on trouve le suivi de la performance
des réseaux mobiles en utilisant les deux méthodes de mesure de QOS via les Compteur OMC
et Benchmarking End-To-End (Drive Test) .
2.4.1 Les mesures de performance
Les mesures de performances peuvent être classées sur la base des informations qu’elles
apportent en quatre grandes classes, Ces mesures sont relatives à :
— La détection des erreurs :Ces mesures permettent la détection des sources

d’erreurs pendant la phase de planification. Exemple : Les phénomènes d’interférences,
— La charge de trafic écoulé : Ce sont les mesures de la charge de trafic établies
dans dans le réseau offrant des données essentielles pour mieux exploiter les ressources
radio(Les canaux de transmission),
21
— La disponibilité des ressources : Ces mesures permettent d’avoir une idée et

de gérer la disponibilité et l’activité des ressources radio cela veut dire connaître si
des ressources radio sont actives ou inactives.
— La qualité de service : Les mesures de la qualité de service permettent instan-
tanément de garantir aux abonnées une qualité de communication satisfaisante.
2.4.2 Les compteurs OMC
Le centre d’opération et d’entretien du système OMC est responsable de la gestion des

performances et ses mesures se basent sur la collecte des compteurs calculés par les équipe-
ments du réseau.
Ces compteurs OMC fournit les données qui seront analysées avec des outils de traitement
des compteurs.
Cette tache sera une partie de notre application .
Les mesures OMC ne présentent qu’une vue statique et générale temporellement et géogra-
phiquement de l’état du réseau.
Les données des OMC sont sous forme de données brutes. Pour qu’elles soient exploitables,
elles sont transformées en KPI (Key Performance Indicators) .
2.4.3 Benchmarking End-To-End Drive Test
Les Drive Tests sont certes une partie primordiale pour optimiser de façon continue les
performances du réseau mobile afin de satisfaire les abonnés.
Le reporting est un processus permettant d’afficher le résumé des paramètres de performance
dans un résultat de Drive Test.
2.4.3.1 Post-processing GSM
Pour la technologie GSM,les KPI principales et nécessaires pour le Post Processing sont :
RXLEVEL : Ce terme signifie la puissance reçue par le récepteur, utilisé pour mesurer le
niveau reçu par la station mobile depuis la station de base afin de vérifier la couverture du
site.
RXQUAL :C’est un nombre compris entre 0 et 7 et qui reflète la qualité de la voix. 0 est
22
la meilleure qualité, 7 est la pire..

BSIC :Le code d’identité de la station de base (BSIC) est un code utilisé par GSM pour
identifier de manière unique une station de base.
BCCH : Un canal de contrôle de diffusion (BCCH) comporte un modèle répétitif de messages
d’information système décrivant l’identité, la configuration et les fonctions disponibles de la
station de base (BTS).
2.4.3.2 Post-processing UMTS
Pour la technologie UMTS les KPI prisent en considération pour le post-processing sont :
RSCP : désigne la puissance mesurée par un récepteur sur un canal de communication
physique particulier. Il est utilisé comme indication de la force du signal, comme critère de
transfert, pour le contrôle de puissance en liaison descendante, ainsi que pour le calcul du
path loss.
Scrambling Code : Les codes d’embrouillage sont utilisés dans la liaison descendante pour
distinguer différentes cellules afin de réduire les interférences entre les stations de base.
EC/N0 : Ec/No est le rapport RSCP / RSSI. Plus cette valeur est bonne, mieux le signal
d’une cellule peut être distingué du bruit global. La valeur est négative car le RSCP est
inférieur à la puissance totale reçue.
PSC : Code de synchronisation primaire, ce code est utilisé par toutes les cellules et permet
à l’équipement utilisateur de détecter l’existence de la cellule UMTS et de se synchroniser
sur les limites des tranches de temps.(Time slots limits).
Throughput 3G : La valeur du débit pour la technologie UMTS .
2.4.3.3 Post-processing LTE
Pour la technologie LTE les KPI et les codes prises en considération pour le post-
processing sont :
RSRP : Puissance de signal reçu de référence (RSRP), est définie comme la moyenne li-
néaire sur les contributions de puissance des éléments de ressource (ER).
RSRQ : Qualité de signal reçu de référence (RSRQ), défini comme le rapport entre le RSRP
et le RSSI (Received Signal Strength Indicator). Le RSSI représente la puissance totale du
signal reçu, cela englobe le signal transmis, le bruit et les interférences.
23
SINR : C’est le rapport entre le signal utile (signal avec information de l’utilisateur) et les
composants indésirables le perturbant (bruit et interférences).
Throughput 4G : La valeur du débit pour la technologie LTE.
PCI : l’allocation PCI (Physical Cell Identity Allocation) est cruciale pour la qualité de
service et un peu similaire à l’allocation de code d’embrouillage dans WCDMA.
Les Drive Test visant à recueillir des données de référence sur le réseau constituent la
seule façon pour les opérateurs de réseau de téléphonie mobile de collecter des données
concurrentielles précises sur le niveau réel de leurs performances techniques et de celles de
leurs concurrents.
2.4.4 Classes des KPI
KPI d’Accessibilité utilisés pour mesurer correctement si les services demandés par
les utilisateurs sont accessibles dans des conditions données, fait également référence à la
qualité de disponibilité lorsque les utilisateurs en ont besoin. Par exemple accès au réseau,
accès à l’appel vocal ou appel de données,...
KPI de continuité utilisés pour mesurer la capacité du réseau à rester en possession de
l’utilisateur ou à pouvoir conserver et fournir les services nécessaires aux utilisateurs.
KPI de Mobilité utilisés pour mesurer les performances de la capacité du réseau à gérer
le mouvement des utilisateurs tout en conservant une bonne qualité de service pour l’utili-
sateur, tel que le transfert intercellulaire,..
KPI d’intégrité utilisés pour mesurer le caractère ou l’honnêteté du service réseau vis-à-vis
de son utilisateur, tel que le débit, le temps de latence des utilisateurs servis.
KPI de disponibilité utilisés pour mesurer la disponibilité du réseau, appropriée ou prête
à être utilisée par les utilisateurs.
KPI d’utilisation utilisés pour mesurer l’utilisation des ressources du réseau. Ils servent
pour vérifier si la capacité des ressources réseaux est atteinte.
24
Les indicateurs de performance clés sont en réalité la mesure statistique de la qualité du

réseau et englobent tous les paramètres de qualité de service liés à l’accessibilité du réseau,
à l’utilisation du service, la mobilité et à la maintenabilité du réseau.
KPI réseau mobile GSM
« Indicateurs d’accessibilité
Call Setup Success Rate (CSSR) :Taux de réussite d’établissement d’appel .
C’est une mesure du nombre de tentatives d’appel réussies par rapport au nombre total de
tentatives d’appel.
Dropped Call Rate (DCR) : Taux d’appels abandonnés (DCR) DCR est une mesure des
appels perdus par rapport au nombre total d’appels avec succès.
« Indicateur de mobilité Handover Success Rate (HSR/HOSR) : Taux de réussite du
transfert (HSR / HOSR).
KPI réseau mobile UMTS
Représenté dans la figure 2.3 suivante.
Figure 2.3: Clase KPI UMTS.
25
« Indicateurs d’accessibilité
L’accessibilité RRC se mesure par le pourcentage de succès d’établissement de connexions
des ressources de contrôle radio RRC qui est déterminée par rapport à deux sortes de service
Circuit Switching et Packet Switching.
Dans le réseau UTRAN, par rapport à différents services, l’accessibilité se calcule sur deux
étapes : RRC et RAB.
L’accessibilité RAB se mesure par le pourcentage de succès d’établissement de RAB (pour
chaque RAB CS et PS et pour chaque débit de données UpLink et DownLink).
« Indicateurs de maintien de l’appel
Taux de coupure : on peut tirer des informations sur le taux de coupure d’appels sur l’inter-
face radio et le taux total de coupure d’appels détectés par UTRAN.
Causes de coupures voix : il y’a plusieurs KPI permettant d’identifier les causes de coupures
de la voix, ( la perte de synchronisation UL, le manque de relation de voisinage, déconnexion
due au soft handover,...)
«Indicateur de mobilité
Soft et softer Handover : Les indicateurs du taux de succès du Soft Handover (Radio Link
Addition) se calculent soit au niveau cellule soit au niveau Utran Relation.
Hard Handover : Les indicateurs du taux de succès du hard Handover (Radio Link Addition)
se calculent eux aussi soit au niveau cellule soit au niveau UTRAN Relation.
KPI réseau mobile LTE
Dans le domaine de LTE, la qualité est mesurée en se basant sur les KPIs représentés dans
la figure A.6 ci-dessous.
26
Figure 2.4: Classe KPI LTE.
«Indicateur d’accessibilité
RRC Setup Success Rate : Le taux de réussite de la configuration est calculé sur la base du
compteur du eNodeB lorsque ce dernier a reçu la demande de connexion RRC de l’UE.
ERAB setup success Rate : Le KPI du taux de réussite de la configuration de l’ERAB
indique la probabilité de succès de l’ERAB d’accéder à tous les services.
« La Maintenabilité du service
Call DROP : La perte d’appel VoIP se produit lorsque la libération VoIP ERAB n’est pas
normale. Chaque ERAB associé à des informations de qualité de service.
«Indicateur de mobilité
Intra-Frequency Handover Out Success Rate : Taux de réussite du transfert inter-fréquences
indique le taux de réussite du transfert Intra-fréquence de la cellule locale ou du réseau radio
vers la cellule ou le réseau radio voisin Intra-fréquence.
Inter-RAT Handover Out Success Rate : Taux de réussite du transfert inter-RAT indique
le taux de réussite du KPI HO d’une cellule LTE ou d’un réseau radio vers une cellule
WCDMA.
2.5 Conclusion
Après avoir présenté quelques notions théoriques pour réussir à cerner les différents no-
tions attachés à ce projet, il s’avère utile dans la réalisation de ce travail de spécifier les
besoins et la conception. C’est ce qui va être présenté dans le chapitre suivant.
27
Planification et Conception
3
3.1 Introduction
Dans le cycle de développement du projet, la première phase est la spécification des
besoins. En effet, c’est au cours de celle-ci que les besoins des différents acteurs sont précisés
et identifiés. Alors nous allons commencer tout d’abord par identifier les acteurs, ensuite,
citer les besoins fonctionnels et non fonctionnels de notre projet.
Après on passe à la phase d’analyse dans laquelle nous allons définir les cas d’utilisation.
Et nous allons finir par une étude conceptuelle, cette phase a pour objectif de déduire la
spécification de l’architecture du système.
3.2 identification des acteurs

Tout au long de ce rapport, nous allons présenter l’acteur suivant :
; L’utilisateur : c’est l’ingénieur radio de l’opérateur qui est le bénéficiaire de l’utilisation
de notre application.
28
Chapitre 3. Planification et Conception
3.3 Besoins fonctionnels et non fonctionnels
3.3.1 Besoins fonctionnels
Notre Application doit permettre à l’utilisateur les fonctionnalités suivantes :
÷ Performance Monitoring : Supervision de la qualité de service via les deux mé-

thodes KPI OSS et Drive Test.
÷ Audit capacity : Supervision des KPI de capacité.
÷ Audit throughput : Supervision du changement du trafic par rapport au temps.
÷ Géolocalisation : Représentation des cellules et des paramètres des sites sectorielles
ainsi que les marqueurs du Drive Test.
÷ Dashboard : Représentation graphique des valeurs des KPI radio sous forme de graphe.
÷ Drive Test Benchmarking : Comparaison des valeurs des Drive Test d’un opérateur
ou de deux opérateurs différents.
÷ Gestion des formules KPI : Création / suppression des formules KPI personnalisées
selon les besoins de l’utilisateur.
3.3.2 Besoins Non-fonctionnels
÷ Ergonomie sobre et efficace : L’interface de l’application doit faciliter au maximum

l’utilisation à l’aide d’une présentation claire et intuitive qui s’observe grâce a une séparation
des fonctionnalités dans un menu de coté qui définit les taches une par une pour l’utilisateur.
÷ Formulaire de téléchargement simple : L’utilisateur doit être capable de télécharger
les différents fichier de paramètres (CSV) dont il a besoin dans certaine fonctionnalités sans
aucune difficulté.
÷ Représentation claire : La représentation des dashboard, des diagrammes, des statis-
tiques, des sites, des secteurs, et des drives test doivent être bien claire, lisible et interprétable
pour l’utilisateur.
÷ Le Besoin de sécurité : L’application doit garantir à l’utilisateur connecté l’intégrité
et la confidentialité de ses données par conséquent la sécurité du système est assurée par
l’authentification avec un Login et un mot de passe.
29
÷ La Performance : L’application doit fournir toutes les informations et réaliser les fonc-
tionnalités d’une manière optimale.
÷ La flexibilité : Une personnalisation et une ouverture sur d’autres fonctionnalités futures
comme la création et la planification des réseaux sera un atout majeure dont on pensera dé-
velopper et ajouter à notre application .
÷ L’intégrité Le système doit savoir comment faire la capture des différentes erreurs
d’entrée-sortie exemple lors d’un upload de fichier de type inadéquat et doit générer dans les
cas pareils des messages pour l’utilisateur sans oublier l’intégration des informations dans
les tables de la base des données SQL.
÷ La portabilité L’application doit s’exécuter sans problème sur tous types de navigateurs
internet.
3.4 architecture 3-tiers[8]

L’architecture rationnel du système est scindée en trois niveaux ou couches : couche de
présentation, couche de traitement et couche d’accès aux données.
Il est question d’un modèle rationnel d’architecture applicative dont l’objectif est la modéli-
sation d’une application afin d’avoir un empilement composé de trois couches logicielles dont
la mission est de :
Présenter les données : cela veut dire l’affichage, la restitution sur le post de travail,
et la conciliation avec l’usager.
Traiter les données : cela veut dire la mise en œuvre de l’ensemble des règles de gestion
et de la logique applicative.
L’accès au données persistantes cela veut dire les données conservées définitivement.
30
L’architecture trois tiers a pour but d’apporter une réponse aux questions suivantes :
u L’allègement du poste de travail,

u La prise en compte de l’hétérogénéité des architectures (serveurs, consommateurs, lan-
gages, etc.),
u Contrôle de l’intégrité et la validité des données avant de les transmettre dans la couche
d’accès aux données,
u La rupture du lien entre application et données.
u Une bonne répartition de la charge entre différents serveurs d’applications.
Ce schéma 3.1 donne une vision globale sur l’architecture 3-tiers.
Figure 3.1: Architecture 3-tiers
31
La couche de présentation :
C’est la section visible et interactive du programme pour les usagers, c’est une interface
homme-machine à travers une application graphique ou textuelle.
Elle relaie les requêtes de l’utilisateur pour la couche de traitement, et en retour lui dévoile
les informations renvoyées par les traitements de cette couche. Ce qui donne naissance à un
assemblage de services applicatifs offerts par la couche inférieure.
La couche de traitement des données :

C’est la partie opérationnelle du programme, celle qui implémente la logique du travail.
En fonction des requêtes issues de la couche supérieure, le rôle de la couche traitement est
de décrire les opérations appliquées sur les données et de proposer des services applicatifs à
la couche présentation. Ces services sont proposées si le cas se présente en s’appuyant sur
les données systèmes disponibles via la couche accès au données.
La couche d’accès aux données : Cette couche est la responsable de la gestion d’accès
aux données propres à l’application. Elle est aussi capable d’accéder aux données gérées par
une autre application.
Dans l’architecture 3-tier, si les données d’une vue seront modifiés, toutes les vues concer-
nées par cette modification doivent être mises à jour, d’où la nécessité d’utiliser le modèle
MVC. Dans le modèle MVC, il est généralement admis que la vue puisse consulter directe-
ment le modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement
passer par le contrôleur pour effectuer une modification (écriture).
32
3.5 Modèle architectural MVC[9]

Après avoir cité les besoins et les utilisateurs et l’architecture physique, nous pouvons
par la suite identifier l’architecture logique de notre système.
Ce schéma 3.2 donne une vision globale sur l’architecture MVC.
Figure 3.2: Architecture MVC
Dans le cas de notre application le MVC est présenté comme :

Le modèle : il encapsule les données de l’application.
La vue : elle est responsable du rendu des données du modèle.Dans notre cas, la vue repré-
sente l’application Web développée.
Le Contrôleur : il est responsable du traitement des demandes des utilisateurs et de la
construction d’un modèle approprié et le transmet à la vue pour le rendu.
Le modèle est indépendant de la vue et du contrôleur cependant il peut leur envoyer des
messages. La lecture des données du modèle et la réception des messages sont assurées par
la vue et cette dépendance permet au modèle d’être utilisé par plusieurs vues à la fois. Les
aspects de la gestion des entrées/sorties ont des interdépendances faibles. Le contrôleur est
responsable de la gestion des entrées et la vue se charge de la gestion des sorties . La vue
est dépendante du modèle. Elle interroge celui-ci pour en afficher une représentation. Pour
33
afficher une présentation, la vue, qui dépend du modèle, interroge celui-ci. Répondants aux
actions utilisateurs effectuées sur la vue le contrôleur modifie les données du modèle et se
trouve donc dépendant de la vue et du modèle.
Flux de traitement
Lorsqu’un client envoie une requête à l’application : La requête envoyée depuis la vue est
analysée par le contrôleur.
Le contrôleur demande au modèle approprié d’effectuer les traitements et notifie à la vue
que la requête est traitée.
La vue notifiée fait une requête au modèle pour se mettre à jour (par exemple affiche le
résultat du traitement via le modèle).
L’architecture trois niveaux (3-tier) est un modèle en couches, c’est-à-dire que chaque couche
communique seulement avec ses couches adjacentes (supérieures et inférieures) et le flux de
contrôle traverse le système de haut en bas. Les couches supérieures contrôlent les couches in-
férieures, c’est-à-dire que les couches supérieures sont toujours sources d’interaction (clients)
alors que les couches inférieures ne font que répondre à des requêtes (serveurs).
Dans le modèle MVC, il est généralement admis que la vue puisse consulter directement le
modèle (lecture) sans passer par le contrôleur. Par contre, elle doit nécessairement passer
par le contrôleur pour effectuer une modification (écriture). Ici, le flux de contrôle est inversé
par rapport au modèle en couches, le contrôleur peut alors envoyer des requêtes à toutes les
vues de manière qu’elles se mettent à jour.
3.6 La modélisation UML

La modélisation consiste à créer une représentation virtuelle d’une réalité de telle façon
à faire ressortir les points auxquels on s’intéresse.
Dans le cadre de notre projet on a utilisé la méthodologie UML pour la modélisation des
différents diagrammes.
En regardant les objectifs fixés pour la réalisation du projet, nous remarquons que nous
somme face à une application modulaire et qui devra rester ouverte pour les améliorations
futures. De ce fait, il est très important d’utiliser un langage universel pour la modélisation
34
afin de clarifier la conception et de faciliter les échanges. Notre choix est porté sur le langage
UML puisqu’il convient pour toutes les méthodes objet et se prête bien à la représentation
de l’architecture du système.
3.6.1 Présentation d’UML[10]
UML : UML (Unified Modeling Language) est un langage de modélisation unifié

permet de modéliser une application logicielle d’une façon standard dans le cadre de concep-
tion orienté objet.
UML permet de couvrir le cycle de vie d’un logiciel depuis la spécification des besoins jus-
qu’au codage en offrant plusieurs moyens de description et de modélisation des acteurs et
d’utilisation système, du comportement des objets, des composants d’implémentation et de
leurs relations, de la structure matérielle et de la distribution des objets et des composants
indépendamment des techniques d’implémentation et peut être mis à jour selon les besoins.
3.6.2 Les avantages d’UML
3 Universel.
3 Adopté par les grandes entreprises.
3 Notation unifié.
3 Facile à comprendre.
3 Adopté par plusieurs processus de développement.
3 Limite les risques d’erreur.
3 N’est pas limité au domaine informatique.
3.7 Analyse
Après avoir analysé les différents besoins et détaillé l’architecture logique et l’architecture
physique de notre application qui sont la base sur laquelle nous allons réaliser la phase
d’analyse et la phase de conception du système .
35
3.7.1 Diagramme de cas d’utilisation général[11]
Le diagramme de cas d’utilisation a pour but de donner une vue globale sur les interfaces
de l’application.
La figure suivante 3.3 présente le diagramme de cas d’utilisation global, ce diagramme donne
une vue générale sur les fonctionnalités offertes et les relations entre elles.
Figure 3.3: Diagramme de cas d’utilisation général.
36
Description Textuelle
Après authentification, l’utilisateur peut :

å Télécharger les fichiers (csv) des KPI afin de les analysés.
å Superviser la performance du réseau via les méthodes KPI OSS et/ou Drive Test.
å Gérer la liste des formules (KPI).
å Analyser le post-processing Drive Test.
å Comparer les drives Test de deux opérateurs.
å Géolocaliser les sites.
å Auditer le trafic .
å Auditer la capacité .
3.7.2 Diagramme de cas d’utilisation raffiné du suivi de la perfor-

mance du réseau
Le diagramme ci-dessous (figure 3.4) détaille la tâche du suivi de la performance du ré-

seau.
Figure 3.4: Diagramme de cas d’utilisation raffiné du suivi de la performance du réseau.
37
Table 3.1: Description du cas suivre la performance
Description Textuelle
Þ Après l’authentification, l’utilisateur peut surveiller la qualité du réseau en utilisant

les compteurs OMC ou bien les Drive tests.
Þ Afin de suivre la qualité du réseau en utilisant les compteurs OMC, l’utilisateur doit
remplir un formulaire pour bien spécifier le cadre à surveiller.
Þ Si L’utilisateur choisi de suivre la performance du réseau avec les drive test, il doit spécifier
le paramètre qu’il veut visualiser sur la carte géographique.
Le tableau ci-dessus 3.1 décrit le diagramme de cas d’utilisation raffiné du suivi de la
performance via la méthode KPI OMC.
38
3.8 Conception
Cette phase aboutira à la conception et la représentation des diagrammes de séquence,
de classes et d’activités en se basant sur le langage de modélisation UML.
3.8.1 Diagramme de séquences «Ajouter Formule»
Ce diagramme de séquences (figure 3.5) décrit la tâche de création d’une formule.
Figure 3.5: Diagramme de séquences « Ajouter une formule».
39
Description textuelle
Pour créer une nouvelle formule, l’utilisateur demande d’ajouter une formule. Il devra
choisir un nom de formule et composer sa formule en utilisant les compteurs afficher dans
l’interface.
La nouvelle formule passe par la phase de traitement pour arriver à être ajoutée dans la base
de données. Le système vérifie si la formule existe déjà en cherchant le nom dans la table
formule ainsi que le contenu de la formule elle même c’est à dire que une telle formule ne
peut pas être ajoutée avec des différents noms .
3.8.2 Diagramme de classes
Le diagramme de classes est une représentation de l’architecture utilisée pour présenter

les classes et les interfaces du système ainsi que les différentes relations entre celles-ci.
Une classe décrit les capacités, le type et le comportement d’un ensemble d’objets. Les
éléments de cet ensemble sont les instances de la classe.
Figure 3.6: Diagramme de classe.
40
3.8.3 Diagramme d’activités
Ce diagramme d’activité 3.7 décrit la tâche «Télécharger un fichier CSV» .
Figure 3.7: Diagramme d’activité «Télécharger un fichier»
41
Ce diagramme décrit la phase de télèchargement d’un fichier, cette action passe par
l’étape d’analyse de l’extension du fichier.
Alors si le test retourne «oui extension = .csv »,le système insérera le contenu du fichier dans
la base des données, sinon le système affichera un message d’erreur.
3.9 Conclusion
La phase d’analyse et de conception sert à présenter les différentes étapes de conception de
l’application. Par conséquent, elle nous permet d’aboutir immédiatement à l’implémentation
avec une vue plus en plus claire des aspects fonctionnels de l’application.
Nous entamerons maintenant la mise en œuvre de la solution retenue dans le chapitre suivant.
Notre application est à présent bien définie de point de vue fonctionnalités et structure.
42
Réalisation : Eagle Vision Network Monitoring
4
4.1 Introduction
Dans ce chapitre, nous allons commencer par une description de l’environnement de tra-
vail et les différentes configurations réalisées et nous terminons par l’illustration des différents
scénarios d’utilisation de l’application réalisée.
4.2 Environnement de travail

Au cours de ce projet, nous avons utilisé des outils de base qui ont servi à la mise en place
de l’application. Dans ce qui suit, nous détaillons les environnements matériels et logiciels
adoptés durant ce projet.
4.2.1 Environnement matériel
On implémente notre application sur nos ordinateurs qui ont les caractéristiques sui-
vantes :
d Modèle : Assus.
d Processeur : Intel(R) Core(TM) i5-6198DU CPU 2.30GHz 2.40GHz.
43
Chapitre 4. Réalisation : Eagle Vision Network Monitoring
d Mémoire RAM : 8.00 Go.

d Système d’exploitation : Windows 10.
d Type du système : Système d’exploitation 64 bits.
d Modèle : DELL INSPIRON.

d Processeur : Intel(R) Core(TM) i5-2430M CPU 2,40 GHz x 2.
d Mémoire RAM : 4 Go.
d Systéme d’exploitation : Windows 7.
d Type du système : Système d’exploitation 64 bits.
4.2.2 Environnement logiciel
Dans cette partie nous allons présenter les logiciels et les technologies que nous avons
choisis de travailler avec tout au long de notre projet :
Edraw utiliser pour créer les diagrammes de réseau.
StarUML est un logiciel de modélisation UML, cédé comme open source par son éditeur, à
la fin de son exploitation commerciale, sous une licence modifiée de GNU GPL.
44
¨ Système de gestion de base de données
]Mysql [12] est un système de gestion de base de données (SGBD). Il fait partie des logi-
ciels de gestion de base de données les plus utilisés au monde, autant par le grand public
(applications web principalement) que par des professionnels, en concurrence avec Oracle et
Microsoft SQL Server.
MySQL est un serveur de base de données relationnelle SQL développé dans un souci de
performances élevées en lecture, ce qui signifie qu’il est davantage orienté vers le service de
données déjà en place que vers celui de mises à jour fréquentes et fortement sécurisées.
¨ Serveur d’application
]WampServer [13] est une plate-forme de développement Web sous Windows pour des ap-
plications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une
base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement les
bases de données.
¨ Choix du langage de programmation
Dans cette partie, nous allons comparer point par point, les caractéristiques des trois
langages les plus utilisés afin de faire le bon choix :
45
]PHP est un langage largement utilisé pour le développement des sites WEB. Ce langage
bénéficie d’une grande communauté de développeurs ainsi que d’un grand nombre de fonc-
tionnalités disponibles.
Points forts
; Il est gratuit ,
; Il ne nécessite pas beaucoup de code pour obtenir un résultat,
; L’hébergement du PHP est supporté presque partout,
; Beaucoup de documentation.
Points faibles
— Les failles de sécurité se sont révéles très nombreuses au fil des années.
— Certains professionnels qualifient ce langage d’amateur .
ü CHOIX DU LANGAGE PHP
Pour plusieurs raisons, nous allons adopter Le langage PHP pour développer notre ap-
plication WEB.
Tout d’abord, PHP est un langage OpenSource gratuit et n’exige pas une licence d’utilisa-
tion.
Un des facteurs qui nous a poussé à utiliser PHP est l’existence d’une communauté de dé-
veloppeurs très active. Cette communauté nous dispose des milliers de librairies PHP de
grande qualité accompagnées de milliers de tutoriel d’utilisation qui nous facilite le travail
ainsi qu’une vaste quantité de documentation qui réduisent notre temps d’exécution.
4.3 Travail réalisé

Dans cette partie, nous allons présenter les cas d’utilisations, sous forme d’un guide
d’utilisation.
46
4.3.1 Menu de l’application
En se connectant (voir figure A.1), l’utilisateur sera capable d’accéder aux différents
services présentés dans cette figure 4.1 ci-dessous.
Figure 4.1: Menu de l’application
47
fSurveillance de la performance du réseau via KPI OMC ou DT.

f Drive Test Benchmarking :
f Benchmarking entre deux opérateurs :
f Géolocalisation des sites .
f Gestion des formules .
f Audit de la capacité .
f Audit du trafic .
4.3.2 Tableau de Bord de l’application
La première interface après l’authentification, c’est le dashboard UMTS (figure 4.2 ci-
dessous), qui représente les importantes KPIs du réseau mobile UMTS capturés des trois
dernières semaines.
Figure 4.2: Dashboard UMTS
De même pour les réseaux GSM (voir Annexe figure A.2) et LTE (Annexe A.3).
L’utilisateur peut également modifier la date de suivi afin d’avoir une idée sur la métamor-
phose du réseau.
48
Afin de gérer un rapport détaillé l’ingénieur peut imprimer le résultat sous forme d’un ta-
bleau (voir annexe figure A.4).
4.3.3 Interface Visualisation des formules
Comme on a mentionné au cours de la présentation de notre projet, parmi les valeurs

ajoutées de notre application, c’est la phase de personnalisation des formules qui évidemment
diffère d’un fournisseur à un autre et d’un opérateur à un autre.
Cette figure 4.3, présente l’interface "Show Formula".
Figure 4.3: Visualisation des formules.
49
Pour simplifier les tâches, les compteurs sont ajoutés aux formules et chaque formule
reflète un indicateur de performance spécifique. Donc pour ajouter une formule (voir figure
A.5), il suffit de sélectionner les compteurs de la liste affichée dans l’interface.
Pour vérifier si une formule est bien ajoutée dans la base, il suffit de consulter l’interface
"Show Formula" (figure A.6).
L’ingénieur peut ainsi supprimer une formule (figure A.7).
4.3.4 Importer un fichier
Afin de générer des rapports d’analyse et statistique, que ce soit dans la phase de l’analyse
Post-processing ou la phase de Benchmarking Drive Test, l’utilisateur a besoin d’importer
les fichiers de traces capturés au niveau de l’interface radio (Drive test).
En premier lieu, il doit sélectionner la technologie (Figure ci-dessous A.9).
En second lieu, il doit sélectionner un fichier au format CSV ou xlsx ( Annexe figure A.10.)
L’ingénieur peut importer :
3 Fichier LOG DT,
3 Fichier Log DT un opérateur,
3 Fichier Log DT deux opérateur,
3 Fichiers de représentation des sites,
3 fichiers des traitement des interférences des fréquences.
3 Fichier des compteurs OMC.
4.3.5 Interface Supervision des performances
Comme on a mentionné dans le deuxième chapitre, le suivi de la performance du réseau

via notre application se fait en utilisant le post-processing drive test ou bien via les comp-
teurs OMC.
4.3.5.1 KPI OMC
Notre ingénieur radio, est invité à remplir le formulaire (voir figure A.12) afin de parti-
culariser le suivi du comportement du réseau.
50
Une fois l’ingénieur valide son choix, l’interface suivante (figure 4.4) s’affiche.
Figure 4.4: Visualisation du KPI par rapport au temps.
51
Dans cette exemple (figure ci-dessous 4.5), pour bien analysé le comportement du réseau,
l’utilisateur visualise le taux de coupures d’appel par rapport au trafic afin d’avoir une idée
plus au moins claire sur le comportement du réseau.
Figure 4.5: Analyse de deux KPIs par rapport au temps.
4.3.5.2 Drive Test
L’analyse du Drive Test(figure A.13) est l’une des fonctionnalités les plus importantes
développées dans notre application.
Cette fonctionnalité permet à l’ingénieur de visualiser les marqueurs des valeurs capturées
du Drive Test. Selon l’appartenance de ces valeurs aux intervalles définis et ce à partir du
fichier LOG généré.
Choisir la clé indicatrice de performance qui diffère selon la technologie par exemple :
ß Pour la technologie GSM : L’affichage est généré selon le choix de l’utilisateur :
Les clé indicatrices de performance RXLeveL ou RXQUAL Le code BSIC ou la chaine
BCCH.(voir Annexe figure A.14).
52
ßPour la technologie UMTS :

L’affichage est généré selon le choix de l’utilisateur,
RSCP, PSC, Ec/N0, SC, Throughput 3G.
Figure 4.6: Post-processing Drive Test 3G.
53
ßPour la technologie LTE :

L’affichage est généré selon le choix de l’utilisateur :
RSRP , RSRQ , SINR, PCI ou throughput 4G (Voir annexe figure A.15).
Après avoir importé les fichiers de traces capturés par un Drive Test et spécifiés les seuils(v1,v2,v3),
le système affichera un graphe (figure ci-dessous 4.7), qui permettra à l’utilisateur d’analyser
et de déterminer le nombre des marqueurs selon leurs appartenances aux intervalles qu’il a
définis lui-même. Il peut aussi imprimer ou télécharger le graphe sous forme d’une image.
Figure 4.7: Affichage Drive Test.
4.3.6 Interface Benchmarking Drive Test
À ce niveau, on offre à l’utilisateur la possibilité de comparer les performances techniques

d’un seul opérateur ou bien de deux opérateurs différents.
Sachant que toutes les fonctionnalités citées dans la partie Drive Test sont applicables sur
cette partie, l’ingénieur peut réaliser un Drive Test Benchmarking pour un seul opérateur
54
tout en choisissant la technologie et l’intervalle du temps à surveiller.
La valeur ajoutée du "Benchmarking un opérateur" qu’il permet à l’ingénieur de :

¨ représenter les marqueurs des deux drive test générés par les fichiers LOG téléchargés par
le même opérateur, l’un à coté de l’autre sur la même carte Google Map pour assurer la
comparaison claire des valeurs (voir Annexe figure A.16).
¨ générer deux graphes de statistiques associées à chaque Drive TEST (figure 4.8).
Figure 4.8: Chart Benchmarking Drive Test.
55
4.3.7 Interface Benchmarking Drive Test de deux opérateurs
Avant de commencer le Benchmarking Drive Test pour deux opérateurs, il faut sélection-
ner les noms des deux opérateurs, la technologie et l’intervalle du temps à surveiller (figure
A.23).
La valeur ajoutée du drive test Benchmarking deux opérateurs c’est de représenter les valeurs
des marqueurs des deux DT sur la même carte pour assurer la comparaison des valeurs des
deux DT.(figure 4.9).
Figure 4.9: Statistiques Benchmarking deux opérateurs.
La figure suivante 4.10 présente les deux graphes des statistiques associées à chaque
opérateur.
Figure 4.10: Statistiques Benchmarking deux opérateurs.
56
4.3.8 Géolocalisation sites
Dans cette partie nous présentons quelques captures d’écrans décrivant les différentes
fonctionnalités du système de géolocalisation pour les différentes technologies GSM, UMTS,
LTE.
Le système de géolocalisation permet à l’utilisateur de :
« Visualiser les sites sur la Map en détaillant leurs propriétés (Azimuts, Nom de cellule, Sc,
Latitude longitude,etc).
Figure 4.11: Géolocalisation des sites.
57
« Modifier l’affichage des secteurs selon la sélection de la clé indicatrice de performance

(Exemple Voir figure A.17 et figure A.18).
« Faisant l’analyse des interférences des fréquences l’utilisateur peut :
;Choisir la bande de fréquences 900 ou bien 1800 MHZ (Annexe figure A.19).
;Choisir la valeur de fréquence qu’on va traiter (Annexe figure A.20).
;Distinguer la valeur de fréquence choisie et la fréquence qui la précède pour chaque secteur
représenté sur la MAP, comme le montre la figure A.21.
4.3.9 Interface Audit de la capacité du réseau UMTS
L’interface suivante (figure 4.12), permet à l’utilisateur d’auditer les paramètres de ca-
pacité du réseau.
Figure 4.12: Audit de la capacité.
58
En UMTS, l’interférence sur la liaison montante peut varier en fonction de plusieurs fac-
teurs :
« Le nombre d’utilisateurs dans la cellule,
« Le service, les types de connexion,
« Les conditions radio, etc.
Si RTWP autour de -95 dBm, cela indique que la cellule a des interférences de liaison
montante.
Si la valeur est d’environ -85 dBm, la situation est laide, avec de fortes perturbations sur
la liaison montante.
Habituellement, nous avons des mesures élevées, faibles et moyennes de RTWP. Cependant,
les valeurs maximales et minimales ne sont recommandées qu’à titre d’aide auxiliaire ou de
référence, car elles peuvent avoir été provoquées par un pic d’accès.
Figure 4.13: RTWP analyse.
59
4.3.10 Interface Audit du trafic réseau UMTS
L’audit de la capacité n’est pas assez suffisant pour avoir une idée plus exacte sur la
dégradation ou l’amélioration du réseau, du coup, on a pensé à ajouter une phase d’audit
du trafic via l’interface suivante (figure 4.14).
Figure 4.14: Audit du trafic.
60
Pour plus de détails, l’ingénieur peut sélectionner un RNC afin d’avoir une analyse spé-
cifique (figure A.22).
Il peut également visualiser les dix meilleures cellules et les dix mauvaises cellules comme le
montre la figure 4.15 ci-dessous, lié à un tel RNC choisi.
Figure 4.15: Analyse détaillée du trafic.
4.4 Conclusion
Dans ce chapitre, nous avons pu présenter les choix technologiques choisissent pour la
réalisation de l’application. Cependant, nous devons mettre en évidence, que la réalisation
n’était et ne sera jamais l’étape finale du processus de développement d’un bon logiciel. Il faut
continuer à suivre et superviser l’application par sa mise en exploitation par les utilisateurs,
dans le but de détecter les éventuels bugs et anomalies et de les rectifier pour assurer la
stabilité et la fiabilité du système.
61
Conclusions et Perspectives
Au terme de ce rapport, nous pouvons conclure que ce stage de fin d’études nous a donné
l’occasion de confronter l’acquis théorique à l’environnement pratique. En outre, ce stage
nous a permis de nous familiariser à certaines responsabilités, en plus d’une consolidation de
nos connaissances théoriques et pratiques.
C’est là que réside la valeur d’un tel projet de fin d’études qui combine les exigences de la vie
professionnelle aux côtés bénéfiques de l’enseignement pratique que nous avons eu à l’ULT.
Au début de notre stage, nous avons consacré du temps pour l’étude et recenser les fonc-
tionnalités de notre application. L’étude analytique menée dans les détails nous a permis de
prévoir puis contourner les problèmes rencontrés.
Et tout au long du développement, nous avons concentré sur les nouvelles technologies
utilisées et les techniques de programmation appliquées.
En plus, au cours de l’élaboration du projet, nous avons rencontré plusieurs difficultés au
niveau de la réalisation. Tout de même, nous avons réussi à les surpasser pour présenter en
fin de compte une application opérationnelle.
Nous avons également eu la chance de côtoyer de près le travail d’ingénieur au cours

de ce stage et eu l’opportunité de participer activement à leurs côtés aux travaux en cours
notamment ceux relevant du domaine pratique de la supervision des équipements du réseau
mobile.
Comme perspective, nous espérons voir notre application évoluer par une étape d’accès
direct avec le centre OMC afin d’extraire les paramètres radio en temps réel et de rendre
notre application plus intéressante.
Enfin, nous espérons que le travail que nous avons effectué a été à la hauteur de la confiance
qui nous a été donnée.
62
A
Annexe
Interface authentification
Figure A.1: Interface de connexion
63
Annexe A. Annexe
Dashboard 2G
Figure A.2: Dashboard 2G.
Dashboard 4G
Figure A.3: Dashboard 4G.
64
Annexe A. Annexe
Tableau rapport dashboard
Figure A.4: Tableau à imprimer
Ajouter Formule
Figure A.5: Ajouter formule.
65
Annexe A. Annexe
Formule ajoutée
Figure A.6: Formule ajoutée avec succès.
Sélectionner une formule à supprimer
Figure A.7: Sélectionner Formule.
66
Annexe A. Annexe
Formule Supprimée avec succés
Figure A.8: Formule supprimée
Importer un fichier
Figure A.9: Importer un fichier.
67
Annexe A. Annexe
Figure A.10: Sélectionner un fichier.
Figure A.11: Fichier importé avec succés.
68
Annexe A. Annexe
Formulaire KPI OMC
Figure A.12: Formulaire.
Exemple d’affichage de DT
Figure A.13: Affichage Drive Test.
69
Annexe A. Annexe
Analyse Post-processing 2G
Figure A.14: Post-processing Drive Test 2G.
Analyse Post-processing 4G
Figure A.15: Post-processing Drive Test 4G.
70
Annexe A. Annexe
Benchmarking Drive Test
Figure A.16: Benchmarking Drive Test.
HandOver SuccessRate
Figure A.17: HandOver Success Rate UMTS.
71
Annexe A. Annexe
Call Drop Rate
Figure A.18: Call Drop Rate UMTS.
72
Annexe A. Annexe
Analyse de fréquence
Figure A.19: Analyse de fréquence.
Figure A.20: Sélection de la bande de fréquence.
73
Annexe A. Annexe
Figure A.21: Valeur de la fréquence.
Distribution du trafic par RNC
Figure A.22: Distribution du trafic.
74
Annexe A. Annexe
Schedule Drive Test Benchmarking
Figure A.23: Schedule .
75
Bibliographie
[1] https ://www.astellia.com/fr/produits/
[2] https ://www.astellia.com/products/nova-geo/
[3] http ://www.sunvizion.com/products/network-performance-monitoring
[4] https ://fr.scribd.com/doc/229942486/Nemo-Outdoor-7-20-Manual
[5] https ://fr.scribd.com/document/173302896/Atoll-Forsk-Description
[6] https ://fr.wikipedia.org/wiki/Two_Tracks_Unified_Process
[7] http ://www.telecomhall.com/what-is-rtwp.aspx
[8] https ://fr.wikipedia.org/wiki/Architecture_trois_tiers
[9] https ://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur
[10] https ://fr.wikipedia.org/wiki/UML_(informatique)
[11] https ://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation
76
Bibliographie
[12] http ://www.conseil-webmaster.com/developpeur-web-nord.php
[13] http ://www.wampserver.com/
77

Langue

PFE 2019 Finale1

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

PFE 2019 Finale1

Transféré par

Droits d'auteur :

Remerciements

Avant de commencer la présentation de ce travail, nous profitons de l’occasion pour re-

1 Présentation générale et étude de l’existant 1

2.3.3 Les indicateurs clés de performance . . . . . . . . . . . . . . . . . . . 20

4 Réalisation : Eagle Vision Network Monitoring 43

4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 43

1.1 Organigramme Telcotec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Schéma général du processus de l’optimisation. . . . . . . . . . . . . . . . . . 16

3.1 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Menu de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.13 RTWP analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.1 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

1.1 Comparaison entre les méthodologies de travail . . . . . . . . . . . . . . . . 9

2.1 Indicateurs clés de performance de capacité . . . . . . . . . . . . . . . . . . . 17

3.1 Description du cas suivre la performance . . . . . . . . . . . . . . . . . . . . 38

* GSM Global System for Mobile Communications.

* UMTS Universal Mobile Telecommunication System.

* LTE Long Term Evolution.

* WCDMA Wideband Code Division Multiple Access

* LTE-A Long Term Evolution Advanced.

* RUP Rational Unified Process.

* 2TUP Two Tracks Unified Process.

* QOS Quality Of Service.

* KPI Key Performance Indicator.

* OMC Operation and Maintenance Center

* OSS Operations Support System

* RTWP Received Total Wideband Power.

* PCH Physical CHannel

* BTS BTS Base Transceiver Station

* RSCP Received Signal Code Power

* RSRP Reference Signal Received Power

* RSRQ Reference Signal Received Quality

* RSSI Received Signal Strength Indicator

* RRC Radio Resource Control

* RAB Radio Access Bearers

* ERAB EPS Radio Access Bearer

* UTRAN UMTS Terrestrial Radio Access Network

* eUTRAN Evolved UMTS Terrestrial Radio Access Network

* CSV Comma Separated Value

* xlsx Excel spreadsheet

* UML Unified Modeling Language

* SINR Signal to Interference Noise Ratio

* PHP HyperText Preprocessor

* SGBD Système de gestion de base de données

* WAMP Windows Apache MySQL PHP

Notre rapport sera organisé de la manière suivante :

Dans le premier chapitre, nous commençons par la présentation du cadre et du contexte

Au cours du quatrième chapitre nous présenterons l’environnement de développement ma-

1.2 Présentation de l’organisme d’accueil

nombreuses missions d’audit, d’étude, d’optimisation et de conseil de formation dans leurs

1.2.2 Les différents division

L’organigramme de la société TELCOTEC est représenté par la figure suivante.

Figure 1.1: Organigramme Telcotec

1.3 Cadre du projet

1.4 Étude de l’existant

1.4.1 Astellia [1]

C’est une solution de monitoring, d’analytique et de troubleshooting en temps réel d’Astellia

1.4.1.1 Points forts

â Amélioration de l’efficacité opérationnelle,

1.4.1.2 Points faibles

1.4.2 SunVizion [3]

1.4.2.1 Points forts

â Surveillance en temps réel,

1.4.2.2 Points faibles

â Pas de personnalisation (Formules KPI),