Audit et Gestion de la configuration radio 3G.pdf

Résumé

Imen Romdhani 1

Cycle de formation des ingénieurs en Télécommunications

Option :

Réseaux et Services Mobiles (RSM)

Rapport de Projet de fin d’études

Thème :

Conception et développement d’un outil d’automatisation de

l’audit et la gestion de la configuration radio du réseau 3G

Réalisé par :

Imen ROMDHANI

Encadrant (s) :

M. Kais AMEUR

Mme. Malek BEN YOUSSEF

Travail proposé et réalisé en collaboration avec

Année universitaire : 2012/2013

Résumé

Imen Romdhani i

Résumé

e présent rapport est le compte rendu du travail effectué au sein des locaux de Tunisie

Télécom dans le cadre du projet intitulé « Conception et développement d’un outil

d’automatisation de l’audit et la gestion de la configuration radio du réseau 3G ».

Ce projet a été réalisé en vue d'obtenir le diplôme national d’Ingénieur en

Télécommunications délivré par l’Ecole Supérieure des Communications de Tunis

(SUP’COM).

Le travail présenté par ce document a été effectué parmi l’équipe Optimisation Radio.

Plusieurs tâches accomplies au long de ce projet de fin d’études relèvent de l’ingénierie

Radio et permettent, par conséquent, de développer un bon potentiel d’initiation à ce

métier.

Dans le but d’améliorer le processus d’audit de la configuration radio du réseau 3G, favoriser

la gestion des KPI et la détection des anomalies dans le réseau ainsi que de rapporter la

traçabilité de changement de la configuration des cellules sur une période de temps, nous

nous sommes menés à concevoir et à développer un outil permettant de répondre à ces

besoins.

Mots Clés : automatisation, développer, audit, gestion, configuration, 3G, KPI, anomalies,

rapporter la traçabilité …

L

Imen Romdhani ii

Remerciements

C’est avec mon enthousiasme le plus vif et le plus sincère que je voudrais rendre mérite à tous

ceux qui m’ont aidé, à leurs manières, à bien mener ce projet de fin d’études.

Je tiens tout spécialement à exprimer mon plus grand respect et ma gratitude à mes

encadreurs, avec qui j'ai eu l'honneur de travailler, M. Kais AMEUR, chef SuDivision

Optimisation Radio à Tunisie Télécom, et à Mme. Malek BEN YOUSSEF, maître assistant à

l'école supérieure des communications de Tunis (SUP'COM), pour leur confiance en moi,

leur aide considérable ainsi que les précieux conseils qu'ils n'ont cessé de me prodiguer tout

au long de ce projet.

Aussi, je ne manquerais pas cette occasion pour remercier toute l’équipe Optimisation Radio,

pour l’ambiance agréable de travail, leurs encouragements, leurs aides et leurs conseils qui

m’ont aidé à bien mener à terme ce travail.

Je souhaite aussi remercier tous les enseignants de SUP'COM grâce à qui j'ai eu la chance

de suivre des cours de haut niveau pendant les trois ans de mon cycle ingénieur.

Enfin, je souhaiterais également remercier tous les membres du jury de bien vouloir évaluer

mon travail.

Table des matières

Imen Romdhani iv

Table des matières

Dédicace ............................................................................................. Erreur ! Signet non défini.

Remerciements ........................................................................................................................... ii

Table des matières .................................................................................................................... iv

Liste des figures ......................................................................................................................... vii

Liste des tableaux .......................................................................................................................ix

Liste des acronymes .................................................................................................................. viii

Introduction générale ................................................................................................................ 1

Chapitre 1: Cadre Général Du Stage ......................................................................................... 3

Introduction ............................................................................................................................ 3

1.1. Présentation du réseau de troisième génération (UMTS) .......................................... 3

1.1.1. Objectifs de l’UMTS .............................................................................................. 4

1.1.2. Architecture de l’UMTS ........................................................................................ 5

1.1.2.1. Equipement utilisateur ................................................................................. 6

1.1.2.2. Le réseau d’accès (UTRAN) ........................................................................... 6

1.1.2.3. le réseau cœur (CN) ...................................................................................... 7

1.2. Processus de l’optimisation 3G ................................................................................... 8

1.2.1. Cycle de vie du réseau 3G .................................................................................... 8

1.2.2. Optimisation du réseau 3G .................................................................................. 9

1.2.3. Les relations de voisinage en 3G ....................................................................... 10

1.2.4. Les indicateurs clés de performance en 3G ....................................................... 12

1.2.4.1. Les compteurs OMC-R ................................................................................ 12

Table des matières

Imen Romdhani v

1.2.4.2. KPI (Key Performance Indicators) ............................................................... 12

1.2.4.3. Processus d’analyse et d’optimisation basé sur les KPI .............................. 14

1.3. Cadre du projet .......................................................................................................... 15

1.3.1. Introduction ........................................................................................................ 15

1.3.2. Problématique .................................................................................................... 16

1.3.3. Solution envisagée ............................................................................................. 16

Conclusion ............................................................................................................................ 17

Chapitre 2: Analyse Et Spécification Des Besoins .................................................................. 18

Introduction .......................................................................................................................... 18

2.1. Etude de l’existant et apport du projet ..................................................................... 18

2.1.1. Etude de l’existant .............................................................................................. 18

2.1.2. Critique de l’existant .......................................................................................... 20

2.1.3. Objectifs du projet ............................................................................................. 20

2.2. Méthodologie adoptée .............................................................................................. 21

2.3. Spécification des besoins ........................................................................................... 22

2.3.1. Les besoins fonctionnels .................................................................................... 22

2.3.2. Les besoins non fonctionnels ............................................................................. 23

2.4. Analyse des besoins ................................................................................................... 24

2.4.1. Identification des acteurs ................................................................................... 24

2.4.2. Diagramme des cas d’utilisation global.............................................................. 25

2.4.3. Cas d’utilisation « Gérer la configuration radio du réseau » ............................. 26

2.4.3.1. Diagramme des cas d’utilisation ................................................................. 26

2.4.3.2. Description des cas d’utilisation ................................................................. 26

2.4.4. Cas d’utilisation « Vérifier un OT » ..................................................................... 30

2.4.5. Cas d’utilisation « Rapporter la traçabilité d’une cellule » ................................ 31

Table des matières

Imen Romdhani vi

2.4.6. Cas d’utilisation « Afficher les éléments du réseau sur une interface

cartographique avec les principaux KPI » ......................................................................... 32

Conclusion ............................................................................................................................ 33

Chapitre 3: Conception De L’Outil « 3G Parser » ................................................................... 34

Introduction .......................................................................................................................... 34

3.1. Conception architecturale ......................................................................................... 34

3.1.1. Architecture logicielle de l’application « Configuration Parsing » ..................... 35

3.1.2. Architecture de l’application web « 3G Network Map » ................................... 36

3.2. Conception détaillée .................................................................................................. 37

3.2.1. Modélisation statique ........................................................................................ 37

3.2.1.1. Diagramme de paquetage .......................................................................... 37

3.2.1.2. Diagrammes de classes ............................................................................... 39

3.2.2. Modélisation dynamique ................................................................................... 47

Conclusion ............................................................................................................................ 53

Chapitre 4: Réalisation, Tests Et Validation........................................................................... 54

Introduction .......................................................................................................................... 54

4.1. Environnement matériel et logiciel ........................................................................... 54

4.1.1. Environnement matériel .................................................................................... 54

4.1.2. Environnement logiciel ....................................................................................... 55

4.1.2.1. L’API SAX ..................................................................................................... 55

4.1.2.2. Apache POI 3.9 ............................................................................................ 56

4.1.2.3. Google Maps API V3 .................................................................................... 57

4.1.2.4. JasperReports .............................................................................................. 57

4.2. Interfaces graphiques de l’application ...................................................................... 58

4.2.1. Authentification ................................................................................................. 59

Table des matières

Imen Romdhani vii

4.2.2. Accueil ................................................................................................................ 59

4.2.3. Module d’analyse de la configuration radio du réseau 3G ................................ 60

4.2.3.1. Afficher les paramètres de configuration du réseau sur des tableaux....... 61

4.2.3.2. Exporter les tableaux de configuration au format Excel ............................ 63

4.2.3.3. Comparer la configuration d’une cellule entre dates ................................. 64

4.2.3.4. Comparaison de configuration entre deux cellules .................................... 66

4.2.3.5. Détection des Missing Neighbors ............................................................... 68

4.2.3.6. Vérification des paramètres par rapport à des valeurs de références ....... 69

4.2.3.7. Vérification d’un ordre de travail (OT) ........................................................ 70

4.2.3.8. Reporting de la traçabilité de configuration d’une cellule ......................... 72

4.2.4. Module d’affichage des éléments du réseau sur une interface

cartographique.................................................................................................................73

4.3. Etude de cas ............................................................................................................... 74

Conclusion ............................................................................................................................ 77

Conclusion générale ............................................................................................................. 78

Références ............................................................................................................................. 80

Annexe A : OSS ...................................................................................................................... 82

Annexe B : Outils de développement .................................................................................... 83

Liste des tableaux

Imen Romdhani vii

Liste des figures

Figure 1. 1 : Architecture globale du réseau UMTS. .................................................................. 5

Figure 1. 2 : Architecture du réseau d’accès. ............................................................................. 6

Figure 1. 3 : Architecture du réseau cœur de l’UMTS. ............................................................... 8

Figure 1. 4 : Cycle de vie d’un site 3G. ....................................................................................... 9

Figure 1. 5 : Exemple de planification des relations de voisinage pour un secteur. ................ 10

Figure 1. 6 : Organigramme du processus d’analyse et d’optimisation................................... 15

Figure 2. 1: Représentation du modèle en V...........................................................................22

Figure 2. 2: Diagramme des cas d’utilisation global. ................................................................ 25

Figure 2. 3: Cas d’utilisation « Gérer la configuration radio du réseau ». ............................... 26

Figure 3. 1 : Architecture du modèle MVC.............................................................................. 35

Figure 3. 2 : Architecture de l’application « 3G Network Map ». ............................................ 36

Figure 3. 3 : Diagramme de packages. ..................................................................................... 38

Figure 3. 4 : Diagramme de classes du package « parsing ». ................................................... 40

Figure 3. 5 : Diagramme de classes du package « Export To Excel ». ...................................... 42

Figure 3. 6 : Diagramme de classes du package « Export To DataBase ». ............................... 43

Figure 3. 7 : Diagramme de classes du package « Parameter_Check ». .................................. 44

Figure 3. 8 : Diagramme de classes du package « Verif_OT ».................................................. 45

Figure 3. 9 : Diagramme de classes du package « Reporting ». ............................................... 46

Figure 3. 10 : Diagramme de séquence du scénario « Exporter la configuration à la base de

données ». ................................................................................................................................ 48

Figure 3. 11 : Diagramme de séquences du scénario « Détecter la différence de configuration

entre deux RNC »...................................................................................................................... 49

Figure 3. 12 : Diagramme de séquences du scénario « Vérifier un OT». ................................. 50

Figure 3. 13 :Diagramme de séquence du scénario « Rapporter la traçabilité d’une cellule ».

.................................................................................................................................................. 51

Figure 3. 14 : Diagramme de séquences du scénario « Afficher les éléments du réseau et

leurs paramètres sur une interface cartographique ». ............................................................ 52

Liste des tableaux

Imen Romdhani viii

Figure 4. 1 : La démarche du reporting....................................................................................58

Figure 4. 2 : Interface d’authentification. ................................................................................ 59

Figure 4. 3 : Interface d’accueil. ............................................................................................... 60

Figure 4. 4 : Interface d’audit de la configuration radio. ......................................................... 61

Figure 4. 5 : Importer le fichier de configuration format XML. ................................................ 62

Figure 4. 6 : Affichage des tableaux de configuration. ............................................................. 62

Figure 4. 7 : Choix du tableau de configuration à exporter au format Excel. .......................... 63

Figure 4. 8 : Résultat de l’export au format Excel. ................................................................... 64

Figure 4. 9 : Demande de comparaison de la configuration d’une cellule entre deux dates. . 64

Figure 4. 10 : Choix de la cellule et des fichiers à comparer. ................................................... 65

Figure 4. 11 : Résultat de la comparaison de la configuration d’une cellule entre ................. 66

Figure 4. 12 : Sélectionner deux fichiers de configuration. ..................................................... 67

Figure 4. 13 : Choisir deux cellules à comparer........................................................................ 67

Figure 4. 14 : Résultat de la comparaison entre deux cellules. ............................................... 68

Figure 4. 15 : Détection des missing neighbors. ...................................................................... 69

Figure 4. 16 : Résultat du check des paramètres du réseau. ................................................... 70

Figure 4. 17 : Choix du type de l’OT. ........................................................................................ 70

Figure 4. 18 : Résultat de la vérification d’un OT. .................................................................... 71

Figure 4. 19 : Choisir les paramètres du reporting. .................................................................. 72

Figure 4. 20 : Rapport sur la traçabilité de configuration de la cellule « UHM002W ». .......... 73

Figure 4. 21 : Interface cartographique de l’application « 3G Network Map ». ...................... 74

Figure 4. 22 : Détection d’un problème au niveau d’une cellule. ............................................ 75

Figure 4. 23 : Optimisation de la QoS d’une cellule. ................................................................ 76

Figure 4. 24 : Evolution du KPI « CS Drop rate » de la cellule « UHM004Z ». .......................... 76

Liste des tableaux

Imen Romdhani ix

Liste des tableaux

Tableau 1. 1 : Porteuses UMTS-2100 utilisées par Tunisie Télécom. ........................................ 4

Tableau 1. 2 : Indicateurs clés de performance. ...................................................................... 13

Tableau 1. 3 : Les valeurs seuils des KPI. .................................................................................. 14

Tableau 2. 1 : Description du cas d’utilisation « Afficher les paramètres de configuration du

réseau sur des tableaux »........................................................................................................27

Tableau 2. 2 : Description du cas d’utilisation « Détecter les Missing Neighbors ». ............... 28

Tableau 2. 3 : Description du cas d’utilisation « Détecter la différence de configuration d’un

RNC/ une cellule entre deux dates ». ....................................................................................... 29

Tableau 2. 4 : Description du cas d’utilisation « Vérifier un OT». ............................................ 30

Tableau 2. 5 : Description du cas d’utilisation: « Rapporter la traçabilité d’une cellule ». .... 32

Tableau 2. 6 : Description du cas d’utilisation: « Afficher les éléments du réseau sur une carte

avec les principaux KPI ». ......................................................................................................... 33

Liste des acronymes

Imen Romdhani viii

Liste des acronymes

-C-

CDMA : Code Division Multiple Access

CN : Core Network

CS : Channel Switching

CSSR : Call Setup Success Rate

-F-

FTP : File Transfer Protocol

-G-

GPRS : General Packet Radio Service

GSM : Global System for Mobile Communications

-H-

HSPA : High Speed Packet Access

-K-

KPI : key Performance Indicator

-L-

LAC : Local Area Code

-M-

ME : Mobile Equipement

MSC : Mobile Switching Center

Liste des acronymes

Imen Romdhani ix

-O-

OMC : Operations and Maintenance Center

OMC-R : Operations and Maintenance Center-Radio

OSS : Operations Support Systems

OT : Ordre de Travail

-P-

PS : Packet Switching

-Q-

QoS : Quality of Service

-R-

RNC : Radio Network Controller

RNO : Radio Network Optimiser

-S-

SGSN : Serving GPRS Support Node

-U-

UE : User Equipement

UMSC : UMTS Mobile Switching Center

UMTS : Universal Mobile Telecommunications System

UTRAN : Universal Terrestrial Radio Access Network

-W-

W-CDMA : Wideband Code Division Multiple Access

Introduction générale

Imen Romdhani 1


ans un contexte très concurrentiel, tant sur les marchés du mobile que du fixe et de

l'accès à Internet, tout opérateur se doit de se distinguer de ses concurrents par la

qualité des services qu'il offre à ses clients actuels et qu'il veille à fidéliser. Il doit aussi se

différencier par l'attractivité des offres proposées aux clients potentiels qu'il souhaite

ajouter à son portefeuille client.

Pour un opérateur de service radio mobile, il est indispensable de veiller au bon

fonctionnement de son réseau afin de garantir à ses abonnées une qualité de service

satisfaisante. Pour ce faire, un opérateur met à disposition de ses ingénieurs radio une

panoplie d'outils qui leur donnent la possibilité de suivre en temps réel les performances du

réseau, de détecter les éventuelles anomalies et d'effectuer les modifications nécessaires

pour y remédier. L'ensemble de ces opérations relève du domaine de l'ingénierie radio et

tout particulièrement celui de l'optimisation.

L'optimisation radio a donc pour but de relever le défi d'offrir une qualité de service

satisfaisante à une clientèle de plus en plus exigeante sur un réseau évolutif dont la charge

ne cesse de croitre.

Ce processus est fastidieux et complexe vu le nombre de paramètres et d'outils à manipuler

lors de la résolution des problèmes radio ayant lieu sur le réseau. Ceci est d'autant plus

problématique du fait que les activités d'optimisation sont des activités quotidiennes pour

un ingénieur radio.

C’est dans ce contexte que s’inscrit notre projet de fin d’études qui consiste à concevoir et à

développer un outil permettant l’automatisation de l’audit et la gestion de la configuration

radio du réseau 3G de Tunisie Télécom.

D


Imen Romdhani 2

Le présent rapport synthétise le travail que nous avons effectué dans cette perspective. Il est

divisé en quatre chapitres :

Dans un premier chapitre, nous commencerons par introduire les concepts théoriques

relatifs au projet. Pour cela, nous aborderons des généralités sur le réseau UMTS (objectifs

et architecture). Nous présenterons le processus d’optimisation du réseau 3G ainsi que

quelques techniques d’évaluation des performances du réseau. Enfin, nous décrirons la

problématique de notre projet, jusqu’à arriver aux solutions proposées.

Dans le deuxième chapitre, nous allons évoquer la méthodologie du travail. Ensuite nous

détaillerons les différents besoins fonctionnels et non fonctionnels que devra satisfaire notre

outil. Pour cela, nous aurons recours aux diagrammes de cas d’utilisation UML.

Le troisième chapitre sera consacré à la partie conception du système à travers une

présentation des architectures utilisées, du diagramme de package, des diagrammes de

classes et des diagrammes de séquences.

Dans le quatrième et dernier chapitre, nous décrirons l’environnement de travail et nous

terminerons par la présentation du travail effectué.

Imen Romdhani 3

Cadre Général Du Stage 1

Introduction

a réalisation de ce projet a nécessité une étude approfondie de certaines notions

théoriques que nous jugeons important de les connaître pour le bon déroulement de

ce travail. Ce chapitre prétend présenter ces différentes notions afin de bien les assimiler.

En premier lieu, le réseau de troisième génération sera présenté. Par la suite, nous nous

concentrerons sur le processus de l’optimisation du réseau, l’audit et la gestion de la

configuration 3G, la notion du voisinage et les indicateurs clés de performance. Finalement,

nous donnerons un aperçu sur la problématique de notre projet et la solution envisagée

dans le cadre de ce stage.

1.1. Présentation du réseau de troisième génération

(UMTS)

L’UMTS (Universal Mobile Telecommunications System) est la norme de télécommunications

de troisième génération basée sur la technologie W-CDMA. Elle a été développée à partir de

l’année 2004 avec la Release 99 (R99). En effet, l’UMTS introduit une nouvelle technique

d'accès multiple : le W-CDMA, dite à étalement de spectre permettant d'utiliser le spectre de

fréquences de manière plus efficace que dans le cas du réseau GSM et ses évolutions, d'où

l'augmentation de la capacité sur l'interface radio [1].

L

Chapitre 1. Cadre général du stage

Imen Romdhani 4

Les réseaux 3G utilisent des bandes de fréquences différentes des réseaux précédents, à

savoir les bandes 1885-2025 MHz et 2110-2200 MHz. Les spécifications techniques de cette

norme sont développées au sein de l’organisme 3GPP (3rd Generation Partnership Project).

Tunisie Télécom a opté, lors la mise en place de son réseau 3G, pour l'exploitation de la

bande centrée sur la fréquence 2100 MHz de la manière suivante (Tableau 1.1) :

Porteuse Bande Uplink(MHz) Bande Downlink(MHz)

FDD1 1920,1-1925,0 2110,1-2115,0

FDD2 1925,1-1930,0 2115,1-2120,0

FDD3 1930,1-1935,0 2120,1-2125,0

Tableau 1. 1 : Porteuses UMTS-2100 utilisées par Tunisie Télécom.

1.1.1. Objectifs de l’UMTS

Pour répondre aux besoins des utilisateurs, les objectifs suivants ont été fixés, entre

autres, pour l'UMTS lors de la phase de recherche et de normalisation de ce standard :

Compatibilité de l'UMTS avec le GSM : en termes de services offerts aux usagers.

Support du multimédia : voix, visiophonie, transfert de fichiers ou navigation sur le

Web, etc.

Débits supportés : en tant que successeur du GSM, l'UMTS devait proposer une

gamme de débits supérieure à celle offerte par le réseau de 2ème génération. Il a été

décidé que l'UMTS serait conçu de manière à assurer les débits suivants [2]:

- 144 kbit/s en environnement rural extérieur.

- 384 kbit/s en environnement urbain extérieur.

- 2 Mbit/s pour des faibles distances à l'intérieur d'un bâtiment couvert (c'est à

dire à mobilité réduite).

Classes de services : Dans la couche physique de l'UTRAN (Universal Terrestrial Radio

Access Network), réseau d'accès de l'UMTS, sont prévues plusieurs méthodes de protection


Imen Romdhani 5

des données contre les erreurs dues à la transmission sur l'interface radio. L'UTRAN choisit

ces méthodes selon la qualité du service requise pour chaque classe. En effet, les classes de

services sont définies selon leurs exigence en terme de :

- Délai de transfert de l’information.

- Variation de délai.

- Tolérance aux erreurs.

Roaming : Un autre objectif indéniable qui consiste à offrir un service de mobilité

universelle (international Roaming), dépassant les limitations dues à la multiplicité des

systèmes et des réseaux.

1.1.2. Architecture de l’UMTS

Le réseau UMTS se divise en deux domaines : le domaine d’équipement utilisateur

(UE : User Equipment) et le domaine d’infrastructure.

Le domaine d’infrastructure, de son côté, comporte deux parties : le réseau d'accès radio

UTRAN et le réseau cœur (CN : Core Network).

La figure 1.1 suivante nous montre l’architecture globale du réseau UMTS [3] :

Figure 1. 1 : Architecture globale du réseau UMTS.


Imen Romdhani 6

1.1.2.1. Equipement utilisateur

Un utilisateur UMTS doit être équipé d'un UE (User Equipment) qui se compose du

Mobile Equipment (ME) correspondant au combiné téléphonique et la carte USIM (UMTS

Subscriber Identity Module).

Le rôle de l'USIM est semblable à celui de la carte SIM en GSM. Elle enregistre les identités

de l'abonné (ex. IMSI, TMSI, P-TMSI), les données de souscription, la clé de sécurité (Ki) et les

algorithmes d'authentification et de génération de clé de chiffrement. L'UE peut se rattacher

simultanément aux domaines circuit (MSC : Mobile Switching Center) et paquet (SGSN :

Serving GPRS Support Node) et peut donc disposer simultanément d’un service GPRS

(General Packet Radio Service) et d’une communication téléphonique.

1.1.2.2. Le réseau d’accès (UTRAN)

Le réseau d’accès UTRAN est composé de plusieurs éléments : une ou plusieurs

stations de base (NodeB), des contrôleurs radio RNC (Radio Network Controller) et des

interfaces de communication entre ces différents éléments. Ceci est illustré par la figure 1.2

suivante :

Figure 1. 2 : Architecture du réseau d’accès.


Imen Romdhani 7

a. NodeB

C’est l’équivalent de la BTS dans le réseau GSM. Mais contrairement à une BTS, le

NodeB intègre un récepteur CDMA qui convertit les signaux de l'interface Uu (Interface Air)

en flux de données acheminés au RNC sur l'interface Iub. Dans l'autre sens, le transmetteur

CDMA convertit les flux de données reçus du RNC pour assurer leur transmission sur

l'interface Air. En outre, le NodeB travaille au niveau de la couche physique du modèle OSI

(codage et décodage) et peut gérer une ou plusieurs cellules.

b. RNC (Radio Network Controller)

Le RNC est l’équipement qui contrôle les ressources radio de l'UTRAN et gère le

protocole RRC (Radio Ressource Control) définissant les procédures et les messages entre le

mobile et l'UTRAN. Il est en liaison avec le réseau cœur pour une transmission en mode

paquet à travers l'interface lu-PS et en mode circuit à travers l'interface lu-CS. Il permet

également de router les communications entre le NodeB et le réseau cœur de l’UMTS.

Un RNC travaille au niveau des couches 2 et 3 du modèle OSI (contrôle de puissance,

allocation de codes) et constitue alors le point d’accès pour l’ensemble des services vis-à-vis

du réseau cœur.

1.1.2.3. le réseau cœur (CN)

Le réseau Cœur (core network) représente la partie du système chargée de la gestion

des appels. Il permet aux abonnées de communiquer à l’intérieur d’un même réseau

de téléphonie mobile comme il assure l’interconnexion de ce dernier avec des réseaux

externes, fixes ou mobiles. Il fournit enfin les logiciels d’application qui permettent, tout

en garantissant la sécurité des échanges, de maintenir la communication même lorsque

l’utilisateur est itinérant.

Le réseau cœur de l’UMTS est composé principalement de trois parties dont deux domaines:

- Le domaine CS (Circuit Switched) qui est utilisé pour la téléphonie.

- Le domaine PS (Packet Switched) qui permet la commutation de paquets.

- Les éléments qui sont communs aux domaines CS et PS.


Imen Romdhani 8

En effet, ces deux domaines permettent à l’équipement usager de pouvoir gérer

simultanément une communication paquets et circuits.

L’architecture du réseau cœur de l’UMTS est donnée dans la figure 1.3 :

Figure 1. 3 : Architecture du réseau cœur de l’UMTS.

1.2. Processus de l’optimisation 3G

1.2.1. Cycle de vie du réseau 3G

Le cycle de vie du réseau 3G passe principalement par trois étapes [4] :

La première phase est le déploiement radio qui consiste à rajouter le système UMTS au

réseau GSM, et ce, après avoir fait des études théoriques par l’ingénierie radio afin de

permettre la coexistence des deux systèmes et atteindre les objectifs fixés pour le réseau

3G.

La deuxième phase est la mise en service du réseau UMTS. La figure 1.4 comprend

toutes les étapes qui suivent le déploiement d’un site UMTS et précèdent la phase

d’optimisation.


Imen Romdhani 9

Figure 1. 4 : Cycle de vie d’un site 3G.

La troisième phase est l’optimisation du réseau. Elle sera explicitée dans la partie

suivante.

1.2.2. Optimisation du réseau 3G

La vie du réseau ne se résume pas au déploiement de nouveaux sites UMTS. Elle inclut

aussi des opérations quotidiennes sur le réseau, qui risquent d’en altérer la qualité 3G. Voici

un exemple d’opérations sur le réseau UMTS :

- Mise en service d’un NodeB lors du déploiement d’un nouveau site.

- Un site est en panne et est hors service(HS) : il faut lancer une intervention

immédiate.

- Problèmes lors de l’intégration du site, cross feeders inversés par exemple.

- Mutation de NodeB (avec et sans changement de LAC).

- Changement de configuration d’un RNC, d’un NodeB ou d’une cellule.

- Modification de certains paramètres radio 3G : fréquence, plan de codes, puissances.

- Mise en service d’un RNC, d’un UMSC (UMTS Mobile Switching Center) ou SGSN et

mutation de l’ancien vers le nouveau.

- Un problème de voisinage (Missing Neighbors) pour certaines cellules.

Par la suite, chaque problème au niveau des éléments du réseau peut engendrer l’arrêt du

fonctionnement de plusieurs services. D’où, toute panne au niveau de ces éléments

présente un impact désastreux.


Imen Romdhani 10

Il faut donc, par prévention, mettre l’accent sur certains aspects et paramètres du réseau

ayant une grande importance et assurer un contrôle continu de ces derniers.

1.2.3. Les relations de voisinage en 3G

Chaque réseau cellulaire vit de sa capacité à pouvoir transférer la connexion entre un

téléphone mobile et le réseau, d’une cellule à une autre. Dans un réseau GSM, deux cellules

seulement (Source Cell et Target Cell) participent à cette action alors que dans les réseaux

UMTS, ce sont des groupes de cellules administrés dans des «Active Set» (jeux de cellules

actives). Afin de pouvoir transférer une communication existante à une autre cellule, les

cellules UMTS proches d’une station de base doivent être identifiées. Pour cela, des «listes

de voisinage» sont stockées dans toutes les stations de base avec les informations de

voisinage. Elles sont généralement établies par les opérateurs du réseau à l’aide d’outils de

planification dont les résultats sont basés sur des simulations. Ces listes sont ensuite

confrontées aux conditions réelles du réseau et optimisées en conséquence [5].

Figure 1. 5 : Exemple de planification des relations de voisinage pour un secteur.


Imen Romdhani 11

a. Règles lors de la déclaration des relations de voisinage

Les relations entre cellules 3G/3G intra fréquences :

- sont réciproques entre la Cellule Source et la Cellule Destinataire.

- les cellules 3G des deux autres secteurs 3G du même site doivent être déclarées

voisines entre elles.

Un problème de missing neighbor peut être la cause de :

- Un accès échoué ainsi qu’un Handover échoué : peut tenter d'accéder à un mauvais

code d'embrouillage.

- Une coupure d’appel : UE non conscient d'un code d’embrouillage fort, une forte

interférence.

- Un mauvais débit des données.

- Une mauvaise qualité de la voix, etc.

D’où l’intérêt d’une intervention de l’ingénieur d’optimisation radio lors de la détection de

l’absence d’une relation réciproque (ce qu’on appelle One Way Relation) ou un voisinage

incorrect.

b. Limitation du nombre de voisines par cellule

En mode connecté, après chaque mise à jour de l’Active set (entrée ou sortie d’une cellule),

un mesurement control avec 32 emplacements est envoyé par le RNC. On y trouve la liste

des voisines des cellules qui sont présentes dans l’active set. Si leur nombre est trop

important, certaines voisines vont être oubliées. On peut ainsi « passer à coté » d’une

voisine présentant un ECNO (Ec/No) de bonne qualité. C’est pourquoi il est recommandé de

limiter le nombre de voisines déclarées par cellule. On doit donc, pour chaque cellule, limiter

son nombre de relations de voisinage :

- Nombre de voisines 3G/3G (intra fréquence) <12 recommandé, (Limitation

constructeur à 31).

- Nombre de voisines 3G/3G (inter fréquence) <12 recommandé, (Limitation

constructeur à 31).


Imen Romdhani 12

- Nombre de voisines 3G/2G <12 recommandé, (Limitation constructeur à 32).

1.2.4. Les indicateurs clés de performance en 3G

1.2.4.1. Les compteurs OMC-R

L’une des principales fonctions de l’OMC-R (Operation and Maintenance Center–

Radio) est la gestion de la performance du réseau. Les mesures de performance sont basées

sur la collection des compteurs calculés par les entités du réseau à travers l’interface ltf-R

reliant l’OMC-R et le RNC et l’interface ltf-B entre OMC-R et NodeB. Ces mesures sont

principalement utilisées pour quatre types de besoins [6] :

- L’optimisation et la planification efficace du réseau.

- Les statistiques.

- L’investigation détaillée d’un problème passé.

- L’analyse en temps réel.

Les mesures des compteurs au niveau de l’OMC (remontées par les NodeB à l’OMC-R) sont

faites sur un intervalle de temps précis et sont liées à un évènement survenu dans le réseau.

Elles servent aux calculs des indicateurs clés de performance (KPI : Key Performance

Indicator) du réseau par combinaison de ces compteurs selon des formules bien

déterminées. L’analyse de ces indicateurs est très essentielle pour la supervision de la

qualité de service.

Le RNO (Radio Network Optimiser) est la partie de l’OMC-R permettant à l’opérateur de

surveiller la QoS (Quality of Service) et détecter les problèmes du réseau. Il fournit un

rapport de QoS pour permettre son analyse comme il permet de visualiser la configuration

radio du réseau. A partir des compteurs OMC-R, le RNO permet d’obtenir les différents KPI.

1.2.4.2. KPI (Key Performance Indicators)

A toute phase du cycle de vie du réseau, l'analyse de la QoS suit un processus de drill-

down. Au sommet, il y a un nombre réduit de critères de QoS qui résument

l'accomplissement de la QoS à l’utilisateur final. Ce sont ces critères qui sont appelés KPI.


Imen Romdhani 13

Ces indicateurs clé de performance évaluent la performance d’un service suivant : le volume

du trafic dans le réseau, l'accessibilité au réseau, le maintien de l'appel, la qualité du service

End-user et le comportement du Soft et Hard Handover.

Dans le RNO, ces KPI sont compilés soit par RNC soit par zone cellulaire. Au moyen de Drive

Tests, ces indicateurs sont compilés sur campagnes d'appels répétitifs, dans la région du

service.

Le tableau 1.2 qui suit présente les KPI auxquels nous nous sommes intéressés lors de

l'étude effectuée dans le cadre de ce projet [7] :

Indicateur Nom Complet Description

hs AVG throughput HSPA average throughput Moyenne des débits HSPA /cellule

CS CSSR Circuit Switching call setup success rate

Taux de réussite d’établissement d’appel en mode circuit (CS)

PS CSSR Packet Switching call setup success rate

Taux de réussite d’établissement de connexion en mode paquet (PS)

CS Drop rate Circuit Switching Drop Rate

Taux total de coupure d’appels en mode circuit

PS Drop rate Packet Switching Drop Rate

Taux total de coupure de connexion en mode paquet

Tableau 1. 2 : Indicateurs clés de performance.

En effet, si un des KPI dépasse les seuils fixés par l’opérateur, l’équipe responsable de

supervision du réseau constate qu’un problème est survenu au niveau de la fonctionnalité

qu’assure cet indicateur. Généralement, ce problème peut être du à un problème de

couverture, d’interférence, d’insuffisance de capacité ou d’un mauvais paramétrage du

réseau, etc.

Par exemple, si on détecte un taux de succès de l’établissement d’appels inférieur à 98%, on

constate alors qu’on a un problème d’accès au réseau causé par la capacité, l’interférence ou

aussi un problème de paramétrage du réseau.

Le tableau 1.3 nous montre les seuils de quelques KPI utilisés par Tunisie Télécom :


Imen Romdhani 14

Indicateur Seuil

Taux de perte des sessions 5%

Taux de retransmission des sessions 5%

Taux d’établissement des sessions 95%

Taux de coupures sessions RNC 2%

Taux des sessions réussies 95%

Taux de coupure sessions radio 2%

Taux de coupure d’appels (call drop) 1%

Taux d’établissement d’appels avec succès (CSSR) 98%

Taux d’échec du handover 2%

Tableau 1. 3 : Les valeurs seuils des KPI.

1.2.4.3. Processus d’analyse et d’optimisation basé sur les KPI

Une fois les différents indicateurs sont obtenus, on commence la phase d’analyse de

ceux-ci et on déclenche le processus de détection des anomalies. Cette étape consiste à faire

une synthèse des différentes sources d’informations et faire passer cette synthèse aux bons

intervenants pour d'éventuelles actions telles que la maintenance, l’ingénierie et

l’optimisation. L’organigramme suivant nous présente les différentes étapes de ce

processus.


Imen Romdhani 15

Figure 1. 6 : Organigramme du processus d’analyse et d’optimisation.

Dans ce qui suit, nous allons donner un aperçu sur le cadre du projet. Pour ce faire, nous

allons commencer par introduire la problématique qui nous a menées à mettre en place ce

projet. Ensuite, nous décrirons la solution que nous avons envisagée.

1.3. Cadre du projet

1.3.1. Introduction

Le trafic de données dans les réseaux mobiles et fixes connait actuellement un

développement vertigineux. Ce qui fait de la QoS un aspect presque primordial pour les

opérateurs téléphoniques. Cette QoS est assurée par le suivi continu des paramètres du


Imen Romdhani 16

réseau pour détecter les incohérences de configuration et lutter contre le

dysfonctionnement des éléments du réseau.

1.3.2. Problématique

Afin d’assurer le bon fonctionnement et garantir une stabilité des services et par la

suite la satisfaction des clients, l’équipe Optimisation Radio de Tunisie Télécom assure un

contrôle continu des différents paramètres de configuration radio du réseau 3G et des

différents indicateurs clés de performance. En effet, l’ingénieur radio a comme activité la

vérification du bon fonctionnement des éléments du réseau en assurant l’audit et la gestion

de la configuration de ces éléments et le lancement d’un OT (ordre de travail) s’il y a

détection d’une anomalie ou un besoin d’effectuer un changement de certains paramètres.

Ici, le facteur temps est primordial. En effet, plus tôt on détecte une anomalie, plus tôt on

peut lancer une intervention et par conséquent éviter les problèmes qui peuvent être

survenus.

Afin d’automatiser cette tâche et de lui ajouter un aspect préventif, il est nécessaire de

déployer de nouveaux outils de gestion de la configuration des éléments du réseau et

surtout de l’état des cellules.

1.3.3. Solution envisagée

Le travail demandé dans le cadre de ce projet de fin d’études consiste à étudier

l’architecture du réseau UMTS de Tunisie Télécom, envisager les différents paramètres de

chaque élément du réseau qui doit être configuré, les différents aspects du réseau qui sont

pris en compte par les ingénieurs d’optimisation afin d’assurer une bonne QoS et permettre

son optimisation, concevoir et développer un outil qui permet l’automatisation de l’audit et

la gestion de la configuration radio du réseau.

Cet outil doit assurer :


Imen Romdhani 17

Le parsing des fichiers de configuration type XML issue de l’OSS (Operations support

system) Ericssson et mise à jour dans une base de données SQL.

Affichage convivial des paramètres de configuration réseau sur des tableaux

structurés.

Détection des différences de configuration entre deux RNC.

Détection des différences de configuration entre deux Cellules.

Détection des différences de configuration d'un RNC entre deux dates.

Détection des différences de configuration d'une cellule entre deux dates.

Détection des différences de configuration des RNC/NodeB/Cellule selon un référentiel

de valeurs recommandées.

Export de la configuration réseau en format Excel.

Detection des missing Neighbors "One way relation".

Vérification de l'exécution des OT.

Reporting de la traçabilité des changements de configuration des cellules.

Affichage des éléments du réseau et leurs paramètres sur une

interface cartographique (Google Maps/Bing Map).

Affichage des KPI de capacité et détection des goulots d'étranglements au niveau de

chaque cellule sur l’interface géographique.

Détection des incohérences sur la configuration et des dysfonctionnements des

éléments du réseau.

Conclusion

Les notions de base du réseau de troisième génération sur lesquels se base notre

projet telle que l’architecture du réseau et le processus d’optimisation ont été couvertes par

ce chapitre. Ces informations sont très utiles pour bien mener la suite de notre projet.

Ensuite, nous avons décrit notre problématique et précisé les objectifs à atteindre.

Une étude de l’existant s'avère indispensable pour dégager les principales fonctionnalités

que nous devons assurer. Ce sera l'objet du chapitre suivant.

Imen Romdhani 18

Analyse Et Spécification Des

Besoins

Introduction

près avoir introduit le réseau 3G, donné un aperçu sur le travail de l’équipe

d’optimisation radio et les différents paramètres qui entrent en jeu pour accomplir

leur mission, ce chapitre permet de donner une vue claire des différents besoins escomptés

de notre projet.

Etant la première dans le cycle de vie d’un projet, cette phase est déterminante pour bien

comprendre les défis mis en jeu. D’abord, nous donnerons une étude de l’existant, ensuite

nous présenterons le travail qui nous a été demandé lors de ce stage. Enfin, nous allons faire

une spécification et analyse détaillée des besoins des futurs utilisateurs du système à

concevoir.

2.1. Etude de l’existant et apport du projet

2.1.1. Etude de l’existant

Une étude de l’existant s’avère essentielle puisqu’elle fournit une base de référence

pour la suite du projet comme elle sert à approfondir l’analyse des dimensions innovantes

de notre travail.

A

2

Chapitre 2. Analyse et spécification des besoins

Imen Romdhani 19

La gestion et l’audit de la configuration radio du réseau 3G font partie des tâches

quotidiennes de l’équipe Radio au sein de Tunisie Télécom. En effet, les ingénieurs de cette

équipe doivent contrôler et assurer le bon fonctionnement du réseau à travers la vérification

et le suivi continu de la configuration des RNC, des NodeB, des antennes, du voisinage des

cellules, etc.

En cas de détection d’anomalie ou dégradation de la QoS, les ingénieurs doivent trouver les

solutions convenables pour chaque problème et envoyer un ordre de travail (OT) à l’équipe

support afin de s’occuper du problème.

D’abord, l’ingénieur commence par télécharger la configuration radio de l’OSS en utilisant le

client ftp, FileZilla. Cette configuration est sous la forme d’un fichier XML assez volumineux

(100, 150, 200 Mo..) comptant des milliers de lignes qui contiennent la configuration d’un

RNC à un moment donné. Par la suite, cette configuration doit être analysée et interprétée

afin de pouvoir intervenir et corriger les aberrations. L’ingénieur Radio doit donc vérifier la

configuration de certains paramètres par rapport aux valeurs recommandées par le

constructeur, à celle téléchargée dans une date précédente. Il doit aussi comparer la

configuration des différents éléments du réseau entre eux, détecter s’il y a un problème de

voisinage pour certaines cellules (ce qu’on appelle One_Way_Relation), etc. (Pour plus de

détails sur l’OSS, voir Annexe A).

Actuellement, pour ce faire, tout le travail se fait manuellement. En effet, après avoir

téléchargé la configuration en format XML, l’ingénieur ouvre ce fichier avec un éditeur de

code source (ex. Notepad++) et fait l’analyse en parcourant les milliers de lignes qu’il

contient.

Afin d’examiner les différents KPI d’une cellule, il faut importer le rapport des KPI de l’OSS.

Ce rapport contient la correspondance entre le nom de la cellule, ses coordonnées et ses

principaux KPI.


Imen Romdhani 20

2.1.2. Critique de l’existant

L’étude de l’existant nous a permis de dégager un certain nombre de lacunes :

Le premier problème, c’est la grande taille du fichier XML. De ce fait, l’analyse de tout le

fichier est une tâche assez complexe et l’ingénieur qui fait l’audit de la configuration peut

négliger des problèmes qui peuvent engendrer l’arrêt du fonctionnement de quelques

services. Parfois, l’équipe d’optimisation ne se rend compte d’un défaut dans la

configuration radio qu’après la réception de plaintes des abonnés. Ce qui peut mettre en

cause l’image de marque de l’opérateur.

Un autre problème est la lenteur de la procédure d’audit qui doit être appliquée sur un

grand nombre de paramètres. En effet, on peut passer des heures, voire toute une journée

pour analyser une seule configuration. Ceci peut provoquer un retard lors de la détection

des problèmes et dans ce cas les conséquences peuvent être graves.

Le troisième problème est l’absence d’un outil qui permet de faciliter la tâche d’audit,

économiser du temps et ajouter une grande efficacité au processus de la recherche des

erreurs de configuration. Au fait, ce type d’outils est propre au fournisseur donc payant.

Le quatrième problème est l’absence d’une base de données pour stocker les résultats de

l’analyse des configurations. Donc, pour faire la comparaison entre deux dates, l’ingénieur

est obligé, soit d’aller chercher le fichier XML téléchargé de l’OSS en une date antérieure et

qui peut être endommagé, soit de solliciter l’OSS une deuxième fois, re-télécharger et ré-

analyser le même fichier de configuration.

Le cinquième problème, concernant les KPI, est l’absence d’une interface cartographique qui

rassemble les cellules et leurs paramètres clés de performance afin de faciliter la localisation

du problème.

Afin de remédier à toutes ces lacunes, on nous a confié le développement d’un outil dont la

description fait l’objet des parties suivantes.

2.1.3. Objectifs du projet


Imen Romdhani 21

L’objectif de notre projet est le développement d’un outil qui permet l’automatisation

d’audit et de gestion de la configuration radio du réseau 3G de Tunisie Télécom. Cet outil va

permettre aux ingénieurs d’optimisation radio un gain en temps et une efficacité au niveau

du processus de sauvegarde, de restauration et de stockage des fichiers de configuration, de

la représentation des indicateurs clés de performance associés aux cellules ainsi que la

gestion des modifications de ces indicateurs.

Mais avant de commencer le travail, nous devons tout d’abord choisir une méthodologie de

travail à suivre.

2.2. Méthodologie adoptée

Un modèle de développement logiciel désigne toutes les étapes du développement, de

sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des

jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la

conformité de l’application avec les besoins exprimés, et la vérification du processus de

développement. L'origine de ce découpage provient du constat que les erreurs ont un coût

d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le

cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du

logiciel, les délais de sa réalisation et les coûts associés [8].

A ce fait nous adoptons le modèle de cycle de vie en V qui part du principe que les

procédures de vérification de la conformité du logiciel aux spécifications doivent être

élaborées dès les phases de conception. La figure 2.1 résume les différentes étapes du cycle

en V.


Imen Romdhani 22

Figure 2. 1: Représentation du modèle en V.

Ce modèle repose sur une étroite interdépendance des étapes soumises à une validation

avant la prochaine étape et une vérification anticipatoire du produit final. L'énorme intérêt

du cycle en V est qu'il soit un excellent support à la formalisation de notre relation avec le

futur utilisateur. Il nous oblige à réfléchir aux différents aspects de sa demande.

2.3. Spécification des besoins

Notre application est supposée satisfaire les besoins fonctionnels qui seront exécutés

par le système et les besoins non fonctionnels qui perfectionnent la qualité logicielle du

système.

2.3.1. Les besoins fonctionnels

Les besoins fonctionnels répondent aux points précis du cahier des charges, et sont

donc requis par notre utilisateur final et lui sont indispensables. En d’autres termes, ce sont

les besoins obligatoires ou encore les fonctionnalités de l’application.

A cet égard, notre outil que nous avons nommé 3G Parser doit répondre aux besoins

fonctionnels suivants :


Imen Romdhani 23

Analyse des fichiers de configuration de type XML issus de l’OSS Ericsson ainsi que

l’affichage du résultat dans des tableaux structurés.

Export des tableaux de configuration vers une base de données MySQL.

Détection des différences de configuration entre deux RNC/Cellules.

Comparaison de la configuration d'un RNC ou d’une cellule entre deux dates.

Check des valeurs de certains paramètres par rapport à des valeurs recommandées par

Ericsson.

Export de la configuration du réseau en format Excel.

Detection des missing Neighbors (One way relation).

Vérification de l’exécution des OT.

Reporting de la traçabilité des changements de configurations des cellules.

Import de la configuration physique des cellules (Azimuths, X/Y, Tilts Mec., HBA,

Feeders Length, antenna, etc) ainsi que des principaux KPI de la base de données et

affichage des éléments du réseau et leurs paramètres sur une interface

cartographique (Google Maps/Bing Map).

Le dernier besoin fonctionnel de notre projet, qui sert à afficher les éléments du réseau sur

une interface cartographique, consiste à développer une application web permettant de

placer les différentes cellules du réseau Tunisie Télécom sur une carte. Elle permet

également d’afficher un tableau pour chaque cellule contenant les informations qui lui sont

propres telles que le Cell_ID, l’Azimuth, le nom du site auquel elle appartient ainsi que les

principaux KPI. D’autre part, cette application permet, grâce aux différentes couleurs que

peuvent prendre les marqueurs situés sur la carte, de détecter s’il y a une anomalie au

niveau d’une cellule et par la suite aiguiller l’utilisateur vers les éléments qu’il doit analyser.

Les informations propres à chaque cellule sont obtenues directement et dynamiquement de

la base de données.

2.3.2. Les besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du

système mais plutôt identifient des contraintes internes et externes du système.


Imen Romdhani 24

Les principaux besoins non fonctionnels de notre application se résument dans les points

suivants :

L’évolutivité : Le code doit être clair pour permettre de futures évolutions ou

améliorations. Nous avons utilisé le modèle MVC (Model-View-Controller) qui impose

la séparation des couches donc la facilité d’amélioration et d’entretien à l’avenir. Nous

allons aborder cela dans le chapitre architecture et conception de l’application.

L’ergonomie : l’application offre des interfaces conviviales et faciles à utiliser et à

interpréter. Nous allons aborder cela dans le chapitre réalisation.

La sécurité : l’application doit respecter la confidentialité des données, ceci en limitant

les droits d’accès à notre outil.

2.4. Analyse des besoins

Suite à la spécification des besoins faite dans la partie précédente et ayant établi les

objectifs du projet, nous devons en premier lieu les traduire sur le diagramme des cas

d’utilisation. Ce dernier permet d’exprimer le besoin des clients d’un système qui ne sont

pas généralement informaticiens. C’est un moyen qui leur permet d’exprimer leurs attentes

et de pouvoir les négocier. Le diagramme cas d’utilisation a donc une vision orientée

utilisateur [9].

2.4.1. Identification des acteurs

Un acteur représente une personne, un matériel ou un logiciel qui interagit

directement avec le système en question. Pour la réalisation des fonctionnalités de notre

système, nous avons un seul acteur qui est l’ingénieur de l’équipe «optimisation radio » qui

va solliciter régulièrement notre outil afin de bénéficier de ses fonctionnalités.


Imen Romdhani 25

2.4.2. Diagramme des cas d’utilisation global

Pour illustrer les fonctionnalités offertes par notre système, nous avons opté pour le

diagramme des cas d’utilisation. Ce diagramme donne une vue sur les fonctionnalités de

notre système ainsi que les acteurs qui l’utilisent. Nous présenterons en premier lieu le

diagramme des cas d’utilisation global de l’application et nous passerons par la suite à la

description détaillée des principaux cas d’utilisation.

Le diagramme des cas d’utilisation global de notre outil 3G Parser est donné par la figure

2.2 suivante :

Figure 2. 2: Diagramme des cas d’utilisation global.


Imen Romdhani 26

Dans ce qui suit, nous allons détailler les différents cas d’utilisation utilisés dans ce

diagramme.

2.4.3. Cas d’utilisation « Gérer la configuration radio du réseau »

2.4.3.1. Diagramme des cas d’utilisation

Figure 2. 3: Cas d’utilisation « Gérer la configuration radio du réseau ».

2.4.3.2. Description des cas d’utilisation

a. Cas d’utilisation « Afficher les paramètres de configuration du réseau sur des

tableaux »

Ce cas permet à l’utilisateur de voir la configuration des différents paramètres du

réseau répartie sur des tables de manière simple et claire. Ceci lui permet par la suite de

faire l’export des tables qu’il choisit vers la base de données ou au format Excel et de


Imen Romdhani 27

comparer la configuration entre deux dates comme il peut comparer les valeurs prises par

certains paramètres avec des valeurs de référence.

Une description détaillée du déroulement de cette opération est illustrée dans le tableau 2.1

suivant :

Sommaire

Titre : Afficher les paramètres de configuration du réseau sur des tableaux

But : Permettre à l’utilisateur de voir la configuration du réseau de manière

structurée sous forme de tableaux.

Description

Pré-condition(s) :

Lancer l’outil 3G Parser.

S’authentifier.

Choisir l’option « Configuration_Parsing » dans la page d’accueil.

Ouvrir le fichier XML téléchargé auparavant de l’OSS.

Scénario:

L’utilisateur lance l’outil et ouvre le fichier à analyser.

L’outil analyse le fichier et remplit les tables.

Il affiche à l’utilisateur les tables résultantes du processus de parsing.

L’utilisateur parcourt les tables selon son besoin.

Cas d’échec L’utilisateur ne possède pas les droits d’accès à l’outil : Déclenchement

de l’exception *exception 1].

Le fichier XML n’est pas conforme aux normes d’Ericsson :

Déclenchement de l’exception *exception 2].

Exception(s)

[Exception 1]: Un message d’erreur «Your login attempt was not successful,

try again. Caused: Invalid username or password» s’affiche à l’utilisateur.

[Exception 2] : Un message d’erreur «the selected file is not a valid Ericsson

file » est affiché à l’utilisateur.

Tableau 2. 1 : Description du cas d’utilisation « Afficher les paramètres de configuration du réseau sur des tableaux ».


Imen Romdhani 28

b. Cas d’utilisation « Détecter les missing neighbors»

Ce cas d’utilisation permet à l’ingénieur de contrôler le voisinage de chaque cellule et

de détecter s’il y a un voisinage caché (ce qu’on appelle One Way Relation). En effet, les

relations de voisinage doivent être réciproques entre la Cellule source et la Cellule

destinataire.

Une description détaillée du déroulement de cette opération est répertoriée dans le tableau

2.2 suivant :

Sommaire Titre : Détecter les Missing Neighbors.

But : Contrôler les relations de voisinage de chaque cellule.

Description

Pré-condition(s) :

Parsing du fichier XML.

Scénario:

L’utilisateur lance sa demande pour détecter les relations de voisinage

en cliquant sur « One_Way_Relation » dans la barre des outils.

Après un traitement sur la table qui contient les relations de voisinage,

préparée lors du parsing, une fenêtre s’affiche à l’utilisateur comprenant

les relations de voisinage qui manquent pour toutes les cellules.

L’utilisateur peut exporter cette table au format Excel.

Si tous les voisinages sont bien vérifiés et il n’y a aucune relation qui

manque, un message « No Missing Neighbors » s’affiche à l’utilisateur.

Cas d’échec

Exception(s)

Tableau 2. 2 : Description du cas d’utilisation « Détecter les Missing Neighbors ».

c. Cas d’utilisation « Détecter la différence de configuration d’un RNC/une cellule entre

deux dates »

Ce cas d’utilisation permet à l’utilisateur de comparer la configuration des éléments du

réseau entre deux dates différentes. Ceci lui permet, s’il y a un changement de la valeur d’un


Imen Romdhani 29

paramètre, de prendre des décisions selon le degré de priorité de ce dernier.

Dans ce qui suit, nous allons traiter le cas de détection de la différence de configuration

d’une cellule, le même principe peut être appliqué à un RNC.

Une description détaillée du déroulement de cette opération est présentée dans le tableau

2.3 suivant :

Sommaire

Titre : Détecter la différence de configuration d’un RNC/une cellule entre

deux dates.

But : Comparer la configuration d’une cellule ou d’un RNC entre deux dates

différentes afin de détecter s’il y a un problème.

Description

Pré-condition(s) :

Parsing du fichier xml.

Export de la configuration résultante du parsing vers la base de

données.

Scénario:

L’utilisateur lance la demande de comparaison en cliquant sur

«Compare between two dates » dans la barre des outils.

Une fenêtre s’affiche à l’utilisateur pour choisir la cellule à traiter ainsi

que les deux fichiers de configuration à comparer.

L’utilisateur confirme son choix.

le serveur de l’application envoie des requêtes à la base de données, il

fait des traitements sur le résultat de ces requêtes et affiche à

l’utilisateur une table qui contient les noms des paramètres qui ont

changé de valeurs entre les deux dates ainsi que l’ancienne et la

nouvelle valeur qu’ils ont prises.

L’utilisateur peut faire l’export de cette table au format Excel.

Cas d’échec

Exception(s)

Tableau 2. 3 : Description du cas d’utilisation « Détecter la différence de configuration d’un

RNC/ une cellule entre deux dates ».


Imen Romdhani 30

2.4.4. Cas d’utilisation « Vérifier un OT »

Après avoir analysé la configuration d’un RNC à une date bien déterminée et en cas de

détection d’un problème au niveau d’un ou de plusieurs paramètres, l’ingénieur prépare un

ordre de travail sous la forme d’un fichier Excel et le transfère à l’équipe support. Après, il a

besoin de vérifier si cet ordre de travail a été bien accompli. Pour ce faire, il analyse la

configuration du même RNC à une date récente et vérifie les nouvelles valeurs des

paramètres qui ont occasionné le problème par rapport à celles de l’OT.

Une description détaillée du déroulement de cette opération est répertoriée dans le tableau

2.4 suivant :

Sommaire

Titre : Vérifier un OT.

But : Vérifier si un ordre de travail est bien accompli.

Description

Pré-condition(s) :

Parsing du fichier XML.

Scénario:

L’utilisateur lance la demande de vérification d’un OT en cliquant sur

«Verif_OT» dans la barre des outils.

Une fenêtre s’affiche à l’utilisateur pour choisir si c’est un OT pour un

RNC ou pour des cellules.

L’utilisateur confirme son choix.

Un filechooser s’affiche à l’utilisateur pour importer le fichier Excel

comportant l’ordre du travail.

Après un traitement, une table s’affiche à l’utilisateur contenant les

noms des paramètres, les valeurs demandées dans l’OT et les valeurs

trouvées dans le fichier de configuration.


Cas d’échec

Le fichier de l’OT n’a pas l’extension xls : Déclenchement du traitement

de l’exception [Exception 3].

Exception(s) [Exception 3] : Un message d’erreur «Please select only Excel file with xls

extension » est affiché à l’utilisateur.

Tableau 2. 4 : Description du cas d’utilisation « Vérifier un OT».


Imen Romdhani 31

2.4.5. Cas d’utilisation « Rapporter la traçabilité d’une cellule »

Ce cas d’utilisation permet à l’utilisateur d’avoir un rapport sur la traçabilité d’une

cellule durant les 30 derniers jours. Ceci lui permet de visualiser l’état de la cellule sur une

longue période et par la suite conclure l’effet des changements effectués au niveau de la

configuration des paramètres de cette dernière durant cette période sur la qualité du

réseau.

Une description détaillée du déroulement de cette opération est illustrée dans le tableau 2.5

suivant :

Sommaire Titre : Rapporter la traçabilité d’une cellule.

But : Avoir un rapport sur l’état d’une cellule durant une période de 30

jours.

Description

Pré-condition(s) :


S’authentifier.

Scénario :

L’utilisateur ouvre l’outil 3G Parser.

Il entre ses données d’authentification.

Il lance sa demande pour faire le reporting en cliquant sur « Reporting»

dans la barre des outils.

Une fenêtre s’affiche à l’utilisateur comprenant les différents noms de

fichiers de configuration enregistrés dans la base de données (Ces

fichiers font référence aux noms des RNC).

L’utilisateur choisit le RNC auquel appartient la cellule en question.

Une liste contenant toutes les cellules qui appartiennent à ce RNC

s’affiche à l’utilisateur.

L’utilisateur choisit une ou plusieurs cellules à reporter la traçabilité.

Après un traitement, l’outil affiche à l’utilisateur un tableau comprenant

les paramètres de la cellule et leurs valeurs durant les derniers 30 jours.



Imen Romdhani 32

Cas d’échec L’utilisateur ne possède pas les droits d’accès à l’outil : Déclenchement

de l’exception *exception 4].

Exception(s) [Exception 4] : Un message d’erreur «Your login attempt was not successful,

try again. Caused: Invalid username or password» s’affiche à l’utilisateur.

Tableau 2. 5 : Description du cas d’utilisation: « Rapporter la traçabilité d’une cellule ».

2.4.6. Cas d’utilisation « Afficher les éléments du réseau sur une

interface cartographique avec les principaux KPI »

Ce cas permet l’affichage dynamique des cellules du réseau Tunisie Télécom sur une

interface cartographique (Google maps). En outre, l’utilisateur peut examiner les

informations propres à chaque cellule ainsi que les principaux indicateurs clé de

performance grâce à un clic sur le marqueur pointant sur la cellule en question. Afin de

simplifier la détection des anomalies, nous avons envisagé différentes couleurs pour les

marqueurs qui changent suivant les valeurs des KPI. Ceci lui permet de décider sur la ou les

cellules qui demandent un audit de la configuration pour améliorer leur QoS.

Une description détaillée du déroulement de ce cas d’utilisation est présentée dans le

tableau 2.6 suivant :

Sommaire

Titre : Afficher les éléments du réseau sur une carte avec les principaux KPI.

But : Permettre à l’utilisateur de visualiser les éléments du réseau sur une

interface géographique (Google maps) accompagnés des principaux KPI.

Description

Pré-condition(s) :


S’authentifier.

Choisir l’option « 3G Network Map » dans la page d’accueil.

Scénario:

L’utilisateur lance l’outil 3G Parser.


Imen Romdhani 33

Il s’authentifie.

Il choisit de voir la carte qui présente les cellules dans la page d’accueil

qui s’affiche.

L’interface géographique Google maps s’affiche dans le navigateur par

défaut de l’utilisateur contenant des marqueurs pointant sur les

cellules du réseau Tunisie Télécom.

L’utilisateur détecte s’il y a un problème au niveau d’une cellule à partir

de la couleur du marqueur.

L’utilisateur clique sur le marqueur en question.

Un tableau s’affiche à l’utilisateur contenant les informations de la

cellule.

Cas d’échec

Exception(s)

Tableau 2. 6 : Description du cas d’utilisation: « Afficher les éléments du réseau sur une

carte avec les principaux KPI ».

Conclusion

Dans ce chapitre, nous avons fait une étude où nous avons décrit et critiqué l’existant

pour présenter l’apport de notre outil. Ensuite, nous avons complété cette étude par une

phase de spécification dans laquelle nous avons présenté les exigences et les besoins de

l’utilisateur. A la fin, nous avons fait une description détaillée des différents cas d’utilisation

de notre outil.

Dans le chapitre suivant, nous passerons à la phase de conception permettant d'aborder

l'aspect technique des besoins cités plus haut.

Imen Romdhani 34

Conception De L’Outil

« 3G Parser »

Introduction

près avoir fixé les besoins de notre projet, nous passons à l’étape de conception du

système. Dans ce chapitre, nous allons d’abord décrire les architectures sur lesquelles

notre système est basé. Ensuite, nous entamerons la conception détaillée. Pour ce faire,

nous présenterons la vue statique à travers le diagramme de packages et les diagrammes de

classes et la vue dynamique ayant recours aux diagrammes de séquences.

3.1. Conception architecturale

Les besoins issus de notre projet nous ont menés à développer deux applications. La

première consiste à développer une application java qui assure l’analyse du fichier de

configuration radio du réseau 3G et qui rassemble toutes les tâches d’audit. Pour cela nous

l’avons nommée « Configuration_Parsing ». La deuxième application repose sur le

développement d’une application web permettant l’affichage des éléments du réseau ainsi

que la gestion des KPI. Nous l’avons intitulée « 3G Network Map ».

Nous détaillerons dans ce qui suit les architectures adoptées pour nos deux applications.

A

3

Chapitre 3. Conception de l’outil «3G Parser»

Imen Romdhani 35

3.1.1. Architecture logicielle de l’application « Configuration

Parsing »

Pour l’architecture logicielle de l’application dénommée « Configuration_Parsing »,

nous avons opté pour le modèle de conception MVC (Model View Controller) vu qu’il répond

le plus à nos besoins. Il s’agit d’un concept puissant qui intervient dans la réalisation d’une

application. Son principal intérêt est la séparation des données (modèle), de l’affichage (vue)

et des actions (contrôleur) [10].

La figure 3.1 nous montre les trois parties fondamentales du modèle MVC.

Figure 3. 1 : Architecture du modèle MVC.

Le modèle : il représente les règles et les données métiers. Les traitements en relation

avec le cœur du métier s’effectuent dans ce composant.

La vue : elle représente l’interface utilisateur. Elle ne fait aucun traitement et elle se

charge simplement et seulement d’afficher les résultats que le modèle lui fournit.


Imen Romdhani 36

Le contrôleur : il se contente d’intercepter les requêtes de l’utilisateur, d’appeler le

modèle ensuite de rediriger vers une vue adéquate. Il se charge de faire de la

redirection et de l’interception.

L’approche MVC apporte de réels avantages. En effet, la spécificité de ce modèle réside dans

la clarté et l’efficacité de la conception de l’application grâce à la séparation de la vue du

contrôleur et des données. Ce qui permet un gain de temps de maintenance et d’évolution.

En outre, ce modèle joue un rôle important dans la mesure où il offre une grande souplesse

pour organiser le développement de l’application entre différents développeurs

(indépendance des données, de l’affichage et des actions) ce qui permet une séparation de

compétences.

3.1.2. Architecture de l’application web « 3G Network Map »

Dans cette partie nous nous intéressons à l’architecture du module offrant un service

de géo-localisation ainsi qu’une gestion des KPI. Afin de mettre en place notre application,

nous avons adopté l’architecture donnée par la figure suivante [11] :

Figure 3. 2 : Architecture de l’application « 3G Network Map ».


Imen Romdhani 37

L’architecture de notre application, comme le montre la figure 3.2 ci-dessus, est composée

d’un serveur de base de données pour extraire les informations de chaque cellules, d’un

client équipé d’un navigateur web, d’un serveur web (apache) et d’un serveur Google Maps

que nous devons invoquer pour pouvoir charger la carte géographique avant de placer les

différentes cellules du réseau Tunisie Télécom.

Après avoir donné un aperçu sur les architectures adoptées pour le développement de notre

outil, nous allons découvrir dans ce qui suit sa conception détaillée.

3.2. Conception détaillée

Le but de cette section est de détailler la conception de notre projet en commençant

par la représentation statique du système et par la suite nous détaillerons quelques

scénarios en utilisant une représentation dynamique de nos modules.

3.2.1. Modélisation statique

Nous allons consacrer cette partie pour mettre en évidence l’architecture statique de

l’application « Configuration_Parsing ». Pour ce faire, nous présenterons d’abord le

diagramme de paquetage et ensuite les diagrammes de classes pour détailler les différents

rôles et associations entre les modules.

3.2.1.1. Diagramme de paquetage

Le diagramme de paquetage découpe notre application en plusieurs packages en

regroupant les classes qui ont une forte communication entre elles dans un conteneur

commun.

Nous avons choisi de subdiviser notre application en neuf principaux packages selon le type

de service fourni à l’utilisateur. Cette subdivision est illustrée par le diagramme de packages

suivant :


Imen Romdhani 38

Figure 3. 3 : Diagramme de packages.

La figure 3.3 montre l’existence de neuf packages décrits comme suit :

Package « Parsing » : inclut les fonctionnalités d’authentification, d’accueil, d’analyse

du fichier de configuration ainsi que l’affichage des paramètres de configuration sur

des tableaux.

Package « DataBase_Connexion » : contient la classe « DB_Connexion » permettant la

connexion à la base de données. Nous avons situé cette classe dans un package séparé

vu qu’elle sera utilisée par plusieurs autres packages.

Package « Export_To_Excel » : inclut toutes les fonctionnalités permettant l’export des

tableaux de configuration au format Excel.

Package « Export_To_DataBase » : inclut toutes les classes qui permettent d’exporter

les tableaux de configuration vers la base de données.


Imen Romdhani 39

Package « Display_Result » : contient la classe « Display_Result_view » qui permet

d’afficher à l’utilisateur le résultat de plusieurs processus tels que la comparaison, la

vérification des paramètres, etc. Nous avons opté pour la mise de cette classe dans un

package à part vu qu’elle sera appelée par plusieurs packages.

Package « Verif_OT » : inclut toutes les parties qui permettent la vérification d’un

ordre de travail.

Package « Parameter Check » : implémente toutes les fonctionnalités permettant la

vérification des paramètres de configuration par rapport à des valeurs recommandées

par le constructeur.

Package « Compare_Configuration » : comprend tous les composants permettant la

comparaison entre deux cellules ou deux RNC ainsi que la comparaison de la

configuration d’un RNC ou d’une cellule entre deux dates.

Package « Reporting » : inclut toutes les fonctionnalités permettant d’avoir un rapport

complet sur la traçabilité de configuration d’une cellule.

Cette présentation explique les différentes parties de notre application « Configuration

Parsing » mais elle n’explicite pas parfaitement les relations entre les différentes

composantes. Pour cette raison nous allons les détailler dans la partie suivante.

3.2.1.2. Diagrammes de classes

Nous passons dans cette partie à une analyse détaillée des différentes classes

contenues dans chaque package. A cette fin, nous allons utiliser les diagrammes de classes.

En effet, un diagramme de classes est une représentation statique des éléments qui

composent un système et des relations qui existent entre eux [12].

Dans ce qui suit nous allons aborder les principaux diagrammes de classes relatifs à nos

packages.


Imen Romdhani 40

a. Package « Parsing »

Une description détaillée du package « Parsing » est illustrée par le diagramme de

classes donné par la figure 3.4 qui suit.

Afin de mettre en évidence le modèle MVC au sein de chaque package, nous présentons les

classes de la partie view en rose, les classes du controller en bleu et celles de la partie model

en gris.

Figure 3. 4 : Diagramme de classes du package « parsing ».

Ce diagramme renferme toutes les classes ainsi que les diverses relations entre elles

permettant d’aboutir au fonctionnement du package « Parsing » :

Les classes « Accueil_Model » et « Acueil_Cont » ainsi que les deux interfaces

« Authentication_view » et « Aceuil_view » permettent d’afficher à l’utilisateur la

première page d’authentification aussi bien que la page d’accueil pour qu’il puisse

valider son choix.


Imen Romdhani 41

La classe « DB_Connexion » est appelée par la classe « Accueil_Model » pour pouvoir

accéder à la base de données et vérifier les coordonnées de l’utilisateur.

La classe « Open_Default_Browser_Model » contient les méthodes qui permettent

d’ouvrir le navigateur par défaut de l’utilisateur et de lancer l’application web « 3G

Network Map » afin de lui afficher l’interface cartographique contenant les cellules du

réseau Tunisie Télécom.

La classe « Parsing_Cont » est le contrôleur qui intercepte toutes les actions de

l’utilisateur sur l’interface « Parsing_View ». Cette dernière contient le menu principal

du module d’analyse et d’audit du fichier de configuration. Elle constitue l’interface

d’accueil de l’application « Configuration_Parsing ».

La classe « Parsing_Model » rassemble tous les traitements et les méthodes

nécessaires pour analyser le fichier de configuration et structurer le résultat sur des

tableaux.

b. Package « Export To Excel »

Grâce au développement de ce package, l’utilisateur aura la possibilité d’exporter tous

les tableaux de configuration au format Excel. Une description des éléments de ce package

est représentée par le diagramme de classes suivant :


Imen Romdhani 42

Figure 3. 5 : Diagramme de classes du package « Export To Excel ».

D’abord, la classe du contrôle « Parsing_cont » intercepte l’action de l’utilisateur sur

l’interface « Parsing_View ».

L’interface « Items_to_Export_Excel_view » et les deux classes « Export_Excel_cont » et

« Export_to_Excel_Model » sont employées respectivement pour l’affichage, le contrôle de

l’action de l’utilisateur et la réalisation des traitements nécessaires afin d’accomplir

l’opération de l’export.

c. Package « Export To DataBase »

La figure 3.6 qui suit représente le diagramme de classes du package « Export To

DataBase ».


Imen Romdhani 43

Figure 3. 6 : Diagramme de classes du package « Export To DataBase ».

Ce package renferme toutes les classes et les interfaces nécessaires permettant de remplir

les tables de la base de données avec les données des tableaux de la configuration analysée.

Et ce, après avoir intercepté l’action de l’utilisateur par la classe « Parsing_Cont » du package

« Parsing ».

En effet, L’interface « Export_DB_view » comprend la liste de tous les tableaux pour que

l’utilisateur choisisse un ou plusieurs à exporter. Son choix est capté par la classe

« Export_DB_Cont » qui fait appel à la classe « Export_DB_Model » afin d’effectuer les

traitements nécessaires. Cette dernière se sert de la classe « Insert_into_DB » pour se

connecter à la base de données et insérer les tableaux.


Imen Romdhani 44

d. Package « Parameter_Check »

Le diagramme de classes explicitant les objets du packages « Parameter_Check » est

donné par la figure 3.7 suivante :

Figure 3. 7 : Diagramme de classes du package « Parameter_Check ».

Ce Package contient toutes les clases nécessaires pour comparer les valeurs de certains

paramètres par rapport à des valeurs de référence.

La classe « Parameter_Check_Model » fait tout le traitement de comparaison et pour

ce faire elle fait appel à la classe « Recommended_Values_Model » qui contient les

valeurs de référence.

L’interface « Display_Result_view » permet d’afficher à l’utilisateur le résultat du

processus de vérification.

La classe « Parameter_Check_Cont » contrôle l’action de l’utilisateur sur l’interface

« Display_Result_view ».


Imen Romdhani 45

La classe « Export_Excel_Model » permet d’exporter le résultat affiché au format

Excel.

e. Package « Verif_OT »

Le diagramme de classes représenté par la figure 3.8 résume toutes les classes, les

interfaces et les relations nécessaires permettant d’achever le fonctionnement du package

« Verif_OT ».

Figure 3. 8 : Diagramme de classes du package « Verif_OT ».


Imen Romdhani 46

f. Package « Reporting »

Les classes et les interfaces contenues dans ce packages permettent la génération d’un

rapport sur l’état d’une cellule sur une période de trente jours en se basant sur les

configurations stockées dans la base de données. La figure 3.9 illustre le diagramme de

classes du package « Reporting ».

Figure 3. 9 : Diagramme de classes du package « Reporting ».

Après avoir terminé la description de l’aspect statique de notre projet, nous passons

maintenant à esquisser la vue dynamique de notre conception à travers les diagrammes de

séquences.


Imen Romdhani 47

3.2.2. Modélisation dynamique

Dans la partie précédente, nous avons exprimé les différentes composantes de notre

application en se basant sur la description des objets organisés dans un premier temps dans

un diagramme de package et ensuite dans des diagrammes de classes. Cette spécification

permet d’introduire les objets qui seront manipulés au cours de l’exécution de l’application.

Toutefois, elle ne peut pas décrire les étapes du traitement, ni la logique suivie par chaque

action. C’est pourquoi nous allons présenter dans cette partie l’aspect dynamique de notre

outil à travers la description de quelques scénarios. Nous allons employer pour cette fin les

diagrammes de séquences.

a. Scénario du cas d’utilisation « Exporter la configuration à la base de données »

Après avoir analysé le fichier XML contenant la configuration radio du réseau 3G,

l’utilisateur a intérêt à stocker cette configuration dans une base de données pour pouvoir la

récupérer dans une date postérieure. Une description détaillée du déroulement de cette

opération ainsi qu’une précision de l’ordre chronologique est donnée par la figure 3.10 :


Imen Romdhani 48

Figure 3. 10 : Diagramme de séquence du scénario « Exporter la configuration à la base de données ».

b. Scénario du cas d’utilisation « Détecter la différence de configuration entre deux

RNC »

L’ingénieur a besoin de comparer la configuration des paramètres du RNC qu’il est

entrain d’analyser avec celle analysée et stockée dans la base à une date précédente. Ceci

afin de détecter l’existence des anomalies qui peuvent affecter la QoS du réseau et

intervenir par la suite pour résoudre le problème. Le diagramme de séquences qui décrit les

étapes du déroulement de ce processus dans l’ordre chronologique est représenté par la

figure 3.11 suivante :


Imen Romdhani 49

Figure 3. 11 : Diagramme de séquences du scénario « Détecter la différence de configuration entre deux RNC ».

La même logique est suivie pour comparer la configuration de deux cellules aussi bien que

celle d’une cellule ou d’un RNC à deux dates.

c. Scénario du cas d’utilisation « Vérifier un OT »

Pour pouvoir vérifier un ordre de travail, l’utilisateur doit d’abord analyser le fichier de

configuration lié à l’OT. Ensuite il lance une demande de vérification à travers l’interface

d’accueil de l’application « Configuration_Parsing ». Le diagramme de séquences donné par

la figure 3.12 décrit les étapes du scénario de vérification d’un ordre de travail.


Imen Romdhani 50

Figure 3. 12 : Diagramme de séquences du scénario « Vérifier un OT».

d. Scénario du cas d’utilisation « Rapporter la traçabilité de configuration d’une cellule»

La tâche du reporting est considérée très importante vu que l’ingénieur a besoin

d’avoir un rapport complet sur la traçabilité du changement de configuration d’une cellule.

Par conséquent, il sera apte à dégager les causes de dégradation de la qualité de service de

cette cellule et suivre son comportement sur une période de temps. Pour aboutir à ce

résultat, un enchainement d’actions et de traitements doit être effectué. En effet, nous

avons commencé par créer un modèle du rapport que nous souhaitons générer et qui sera

exploitable par l’outil de reporting « JasperReports ». Pour ce faire, nous avons utilisé l’outil


Imen Romdhani 51

de design « iReport » qui génère un fichier ayant l’extension jrxml. Ce fichier sera appelé par

la suite par la classe « Generate_Report_Model » pour créer le rapport sous le format

indiqué par l’utilisateur au début du processus de reporting.

La figure 3.13 qui suit représente les différentes phases de cette opération.

Figure 3. 13: Diagramme de séquence du scénario « Rapporter la traçabilité d’une cellule ».

e. Scénario du cas d’utilisation « Afficher les éléments du réseau et leurs paramètres sur

une interface cartographique »

Après s’être authentifié, l’utilisateur peut demander l’affichage de l’interface

cartographique Google Maps afin de faire un check sur l’état des cellules. D’abord la

demande de l’utilisateur est interceptée par la classe « Accueil_cont » qui contrôle les

actions de l’utilisateur sur la page d’accueil de l’outil. Ensuite, « Accueil_cont » fait appel à la


Imen Romdhani 52

classe adéquate pour pouvoir lancer l’application web permettant l’affichage du résultat sur

le navigateur par défaut de l’utilisateur. Une description détaillée de l’enchainement des

étapes de cette opération est donnée par le diagramme de séquences suivant :

Figure 3. 14 : Diagramme de séquences du scénario « Afficher les éléments du réseau et leurs paramètres sur une interface cartographique ».

Dans un premier temps, pour pouvoir placer les cellules sur la carte, le serveur web sollicite

la base de données pour extraire les coordonnées des cellules se trouvant dans la table

« Cell_Info ». Après, quand l’utilisateur clique sur un marqueur de la carte, une deuxième

requête doit être envoyée à la base de données mais à ce stade une deuxième table doit

être impliquée. En effet, il faut récupérer les KPI de la cellule sélectionnée et ces derniers

sont situés dans la table « Cell_KPI ». Le résultat sera donc affiché à l’utilisateur sous forme


Imen Romdhani 53

d’un tableau comprenant les propriétés de la cellule, récupérées de la table « Cell_Info »,

ainsi que les principaux KPI.

Conclusion

Dans ce chapitre, nous avons répondu à toutes les questions concernant la manière de

réaliser le système à développer. Nous avons commencé par une conception architecturale

de notre outil. Par la suite nous avons détaillé la conception du système à travers quelques

diagrammes.

Dans le prochain chapitre, nous allons présenter l’environnement du développement

matériel et logiciel ainsi que la description et le test du travail réalisé.

Imen Romdhani 54

Réalisation, Tests

Et Validation

Introduction

ans ce chapitre qui forme la dernière étape du projet, nous allons décrire

l'environnement de travail logiciel et matériel permettant la réalisation de notre outil

« 3G Parser ». Par la suite, nous présenterons le travail réalisé et les résultats obtenus. Enfin,

pour illustrer, nous terminerons par une étude de cas

4.1. Environnement matériel et logiciel

4.1.1. Environnement matériel

Pour la réalisation de ce projet, le travail a été effectué sur un ordinateur portable

ayant les caractéristiques suivantes :

Processeur : Intel Core Duo CPU 2 GHZ.

Capacité du disque dur : 320 Go.

Capacité de la mémoire vive : 2Go.

OS : Windows XP professionnel.

D

4

Chapitre 4. Réalisation, tests et validation

Imen Romdhani 55

4.1.2. Environnement logiciel

Notre système a été mis en œuvre moyennant les outils logiciels suivants :

Conception de l’application : PowerAMC 15.1.

Langage de modélisation : UML.

Environnement de développement : Netbeans IDE 7.3.

Langage de développement de l’application « Configuration_Parsing » : JAVA

Système de gestion de la base de données : MySQL Server 5.5.21.

Outils de développement de l’application web « 3G Network Map » : PHP, JavaScript,

Html, AJAX.

Serveur Web : Apache.

API pour l’analyse du fichier XML : SAX (Simple API for XML).

API pour créer et personnaliser l’interface cartographique : Google Maps API V3.

Librairie pour manipuler des fichiers format Excel : Apache POI 3.9.

Outil de génération des rapports : JasperReports.

Outil de création de modèles de rapports utilisables par JasperReports : iReport.

Dans ce qui suit, nous allons présenter certains des outils employés dans le carde du projet.

Une description du reste est donnée en annexe. (Voir annexe B)

4.1.2.1. L’API SAX

D’abord, une API est une interface de programmation applicative (application

programming interface). Il s’agit d’un ensemble de fonctions qui sert de façade permettant à

un logiciel d’offrir des services à d'autres logiciels.

Simple API for XML ou SAX est une interface de programmation qui peut être utilisée par de

nombreux langages permettant la lecture et le traitement des documents XML. Elle est

basée sur un modèle événementiel, c'est-à-dire l'analyseur appelle automatiquement une

méthode lorsqu'un événement est détecté dans le fichier XML [13].


Imen Romdhani 56

Les 5 méthodes appelées par SAX en cas de détection d’un événement bien déterminé sont

les suivantes :

StartElement() : détection d'une balise de début.

EndElement() : détection d’une balise de fin.

Characters() : détection de données entre deux balises.

StartDocument() : début du traitement du document XML.

EndDocument() : fin du traitement du document XML.

Nous avons choisi de travailler avec l’API SAX pour bénéficier de ses avantages. En effet,

cette API est très adoptée pour des documents XML volumineux, ce qui est le cas des fichiers

que nous allons manipuler. Elle offre une lecture rapide et efficace ainsi qu’une économie de

la mémoire car SAX ne construit pas une représentation en mémoire de la structure en

arborescence des fichiers XML lus, comme il est le cas de l’API DOM (Document Object

Model).

4.1.2.2. Apache POI 3.9

POI est l'acronyme de Poor Obfuscation Implementation. C'est un projet open source

du groupe Apache, sous licence Apache V2, permettant d'exploiter des fichiers au format

Microsoft Office dans des applications Java mais sans utiliser Office.

Ce projet comprend plusieurs composants [14] :

HSSF (Horrible SpreadSheet Format) : pour la manipulation des fichiers Excel (XLS) en

lecture et écriture.

POIFS (Poor Obfuscation Implementation File System) : pour manipuler des fichiers

utilisant le format Microsoft OLE 2 Compound Document.

HWPF (Horrible Word Processor Format) : pour manipuler des fichiers Word en lecture

et certaines fonctionnalités en écriture.

HPSF (Horrible Slide Layout Format) : pour la manipulation des fichiers PowerPoint en

lecture et écriture pour certains fonctionnalités mais pas toutes.

HDGF : permet la lecture et uniquement l’extraction de texte des fichiers Visio.


Imen Romdhani 57

Afin de répondre à nos besoins, lecture et écriture des fichiers Excel, nous nous sommes

servis de l’API HSSF qui représente une solution riche en fonctionnalités et fiable pour la

manipulation de documents Excel en Java.

4.1.2.3. Google Maps API V3

Google Maps JavaScript API version 3 permet de créer et d'insérer dans une page web

une carte géographique. Grace à cette API, nous pouvons peaufiner tous les détails de

l’affichage tels que les zooms, les marqueurs, les titres et les contenus des info-bulles.

Cette version est déclarée officiellement active le 19 mai 2010. Elle remplace désormais la

version2. En effet, la nouvelle version est compatible avec plus de navigateurs, optimisée

pour les mobiles ainsi qu’elle ne demande plus l’acquisition de la clé API Google Maps

comme il est le cas de la version2.

Nous avons utilisé cette API pour créer l’interface géographique où nous allons placer les

cellules du réseau Tunise Télécom. Elle permet en plus de communiquer avec notre base de

données MySQL, moyennant le langage PHP, afin d’extraire les informations propres à

chaque cellule.

4.1.2.4. JasperReports

JasperReports est un outil (librairie) Open Source puissant utilisé pour la génération

d’états, entièrement écrit en Java et peut être embarqué dans une gamme très variée

d’applications Java. Il peut s’appuyer sur diverses sources de données pour produire des

rapports en vue de leur exportation vers plusieurs formats notamment Excel, PDF, HTML,

etc. Il coopère avec l’outil de création de modèle de rapports iReport.

En effet, iReport est un environnement de création WYSIWYG (What You See Is What You

Get) de modèles de documents pour JasperReports. Il permet de générer de manière assez

intuitive des fichiers .jrxml (fichiers XML) qui seraient compilés en fichiers .jasper

exploitables par JasperReports afin de produire des rapports au sein d'une application Java.

Le format du rapport généré dépend ensuite de JasperReports et du code utilisé [15].

La figure 4.1 représente le cycle de vie d’un rapport.


Imen Romdhani 58

Figure 4. 1 : La démarche du reporting.

La création d’un rapport avec JasperReports se déroule généralement en 4 étapes :

L’obtention d’un fichier modèle XML (à l’aide d’éditeurs graphiques comme iReport ou

OpenReports Designer).

La construction du rapport à partir du modèle.

Le remplissage des différents champs du rapport avec les données en provenance de

diverses sources (bases de données, classes Java, ...).

L’exportation du résultat vers plusieurs formats possibles (PDF, Excel, ...).

4.2. Interfaces graphiques de l’application

Dans cette partie, nous allons présenter les différentes fonctionnalités de notre outil.


Imen Romdhani 59

4.2.1. Authentification

La figure 4.2 qui suit représente la première interface vue au démarrage de l’outil.

L’utilisateur introduit un nom d’utilisateur et un mot de passe pour pouvoir accéder à

l’application. Le rôle de cette interface est de limiter l’accès à l’outil « 3G Parser ».

Figure 4. 2 : Interface d’authentification.

4.2.2. Accueil

A ce niveau, nous distinguons deux modules : l’affichage de la carte géographique,

« 3G Network Map », et l’analyse du fichier de configuration format XML, « Configuration

Parsing ». L’utilisateur doit donc confirmer son choix en appuyant sur l’un des boutons de

l’interface donnée par la figure 4.3 :


Imen Romdhani 60

Figure 4. 3 : Interface d’accueil.

4.2.3. Module d’analyse de la configuration radio du réseau 3G

A partir de la page d’accueil, l’utilisateur peut accéder au module d’analyse de la

configuration radio en cliquant sur « Configuration Parsing ».

C’est seulement à travers l’interface représentée par la figure 4.4 que l’utilisateur peut

accéder à toutes fonctionnalités offertes par l’application « Configuration Parsing ».


Imen Romdhani 61

Figure 4. 4 : Interface d’audit de la configuration radio.

4.2.3.1. Afficher les paramètres de configuration du réseau sur des tableaux

L’utilisateur commence par importer le fichier XML de configuration tel que présenté

par la figure 4.5 :


Imen Romdhani 62

Figure 4. 5 : Importer le fichier de configuration format XML.

Une fois le fichier XML est importé, le processus de parsing est déclenché automatiquement.

Le résultat sera visible sur des tableaux accessibles à partir de la liste située à gauche de

l’interface (figure 4.6).

Figure 4. 6 : Affichage des tableaux de configuration.


Imen Romdhani 63

4.2.3.2. Exporter les tableaux de configuration au format Excel

Afin de transférer le tableau de configuration d’un paramètre au format Excel,

l’utilisateur demande d’abord l’export à travers un clic sur « Export », après sur « To Excel »

dans la barre des outils. Par la suite, il sélectionne le tableau qu’il désire exporter. Les figures

4.7 et 4.8 illustrent le processus d’export au format Excel.

Figure 4. 7 : Choix du tableau de configuration à exporter au format Excel.

Lorsque l’utilisateur appuie sur le bouton « Export », une boite de dialogue s’affiche pour

qu’il choisisse l’emplacement du fichier qui va être crée sur son poste de travail.

On voit bien dans la figure 4.8 le fichier Excel résultant de l’opération d’export.


Imen Romdhani 64

Figure 4. 8 : Résultat de l’export au format Excel.

4.2.3.3. Comparer la configuration d’une cellule entre dates

Les figures qui suivent représentent les interfaces relatives à l’analyse comparative

entre deux configurations d’une cellule à deux dates différentes.

D’abord, il faut lancer une demande de comparaison. La démarche à suivre pour cette fin est

présentée par la figure 4.9 :

Figure 4. 9 : Demande de comparaison de la configuration d’une cellule entre deux

dates.


Imen Romdhani 65

Ensuite, une interface s’affiche à l’utilisateur, comme le montre la figure 4.10, pour

sélectionner deux fichiers qui doivent correspondre au même RNC mais comportant deux

configurations analysées dans deux dates différentes. Il choisit encore l’identifiant de la

cellule qu’il veut analyser.

Figure 4. 10 : Choix de la cellule et des fichiers à comparer.

Par la suite, une requête sera envoyée à la base de données pour récupérer tous les

paramètres de la cellule sélectionnée dans les deux dates désignées par l’utilisateur.

Enfin, on voit bien dans la figure 4.11, le résultat de cette opération qui sera présenté sous

forme d’un tableau à trois colonnes comprenant dans l’ordre le nom du paramètre qui a

changé de valeur, sa valeur dans la première date et celle dans la seconde date.


Imen Romdhani 66

Figure 4. 11 : Résultat de la comparaison de la configuration d’une cellule entre

deux dates.

Le bouton « Export_Excel » permet à l’utilisateur d’exporter le résultat au format Excel. En

effet, en se basant sur ce résultat, l’ingénieur peut rédiger un ordre de travail pour notifier

l’équipe support du changement de la configuration de cette cellule et appliquer les

corrections nécessaires.

Le scénario d’analyse comparative entre deux configurations d’un RNC est pareil à celle

d’une cellule.

4.2.3.4. Comparaison de configuration entre deux cellules

La figure 4.12 présente l’interface qui s’affiche à l’utilisateur s’il demande la

comparaison de configuration entre deux cellules.


Imen Romdhani 67

Figure 4. 12 : Sélectionner deux fichiers de configuration.

Après avoir sélectionné deux fichiers de configuration (deux RNC), les deux listes

correspondantes aux cellules de chaque RNC seront affichées (figure 4.13).

Figure 4. 13 : Choisir deux cellules à comparer.


Imen Romdhani 68

Finalement, le résultat sera affiché dans un tableau à trois colonnes qui peut être exporté au

format Excel en appuyant sur « Export_Excel ». La première colonne présente le nom du

paramètre qui n’a pas la même valeur dans les deux cellules. La seconde contient le nom de

la première cellule sélectionnée à partir de l’interface précédente et la dernière colonne

contient le nom de la deuxième cellule. Le tableau résultant est donné par la figure 4.14 :

Figure 4. 14 : Résultat de la comparaison entre deux cellules.

Le processus d’analyse comparative entre deux RNC est pareil à celui effectué entre deux

cellules.

4.2.3.5. Détection des Missing Neighbors

Cette fonctionnalité permet à l’ingénieur radio de vérifier le voisinage de toutes les

cellules d’un RNC à un moment donné. Pour ce faire, il clique sur « One Way Relation » dans

la barre des outils. Le résultat s’affiche à l’utilisateur sous forme d’un tableau à deux


Imen Romdhani 69

colonnes : Source cell et Terget Cell. Ce tableau représente les relations de voisinage qui

manquent et qui doivent être corrigées pour optimiser la QoS des cellules présentant des

One Way Relation. On voit bien le résultat d’un exemple de test dans la figure 4.15 :

Figure 4. 15 : Détection des missing neighbors.

4.2.3.6. Vérification des paramètres par rapport à des valeurs de références

Pour effectuer un check sur les paramètres du réseau, l’utilisateur doit cliquer sur

« Param_Check » dans la barre des outils. Le résultat sera affiché sous la forme d’un tableau

à trois colonnes contenant respectivement le nom du paramètre, la valeur recommandée

par le constructeur et la valeur trouvée dans la configuration qu’il est entrain d’analyser.

La figure 4.16 montre un exemple de résultat d’un check lancé par l’utilisateur.


Imen Romdhani 70

Figure 4. 16 : Résultat du check des paramètres du réseau.

4.2.3.7. Vérification d’un ordre de travail (OT)

La figure 4.17 présente la figure qui s’affiche à l’utilisateur s’il demande la vérification

d’un OT. Le type de l’OT : RNC ou Cellule, doit être spécifié au préalable.

Figure 4. 17 : Choix du type de l’OT.


Imen Romdhani 71

Ensuite, l’utilisateur ouvre le fichier contenant l’ordre du travail. Ce dernier doit être sous la

forme d’un fichier Excel ayant l’extension XLS. Dans le cas contraire, un message d’erreur

s’affiche à l’utilisateur pour vérifier le type du fichier qu’il cherche à importer.

Enfin, le résultat de l’analyse comparative entre les valeurs des paramètres spécifiées par

l’OT et celles se trouvant dans la configuration analysée sera affiché sous forme d’un

tableau. Dans le cas d’un OT type RNC, le tableau résultant contient quatre colonnes : le

nom du paramètre, le nom du RNC, la valeur demandée dans l’OT et la valeur trouvée dans

la configuration radio analysée. Si c’est un OT concernant des cellules, le tableau contiendra

dans ce cas cinq colonnes : le nom du paramètre, le nom du RNC auquel appartient la cellule,

l’identifiant de la cellule, la valeur demandée dans l’OT et la valeur trouvée.

On voit bien dans la figure 4.18 le résultat de vérification d’un exemple d’OT.

Figure 4. 18 : Résultat de la vérification d’un OT.


Imen Romdhani 72

4.2.3.8. Reporting de la traçabilité de configuration d’une cellule

La figure 4.19 représente l’interface qui s’affiche à l’utilisateur s’il veut récupérer un

rapport complet sur l’état d’une cellule dans les derniers 30 jours. Après avoir sélectionné

une cellule, il doit choisir le type du rapport qui va être généré ainsi que son format de

sortie.

Figure 4. 19 : Choisir les paramètres du reporting.

Un exemple de résultat de l’opération de reporting d’une cellule au format Excel est donné

par la figure 4.20 suivante :


Imen Romdhani 73

Figure 4. 20 : Rapport sur la traçabilité de configuration de la cellule « UHM002W ».

4.2.4. Module d’affichage des éléments du réseau sur une

interface cartographique

Ce module est accessible à partir de la première page d’accueil qui s’affiche à

l’utilisateur une fois l’accès est réussi. Après avoir cliqué sur le bouton « 3G Network Map »,

une interface géographique contenant les cellules de Tunisie Télécom s’affiche dans le

navigateur par défaut. Il peut détecter s’il existe un problème au niveau d’une ou de

plusieurs cellules à travers les couleurs des marqueurs. Par la suite il peut consulter les

informations relatives à cette cellule à travers le tableau qui s’affiche.

La figure 4.21 donne un aperçu sur l’interface géographique ainsi que le résultat qui s’affiche

à l’utilisateur quand il appuie sur un des marqueurs sur la carte.


Imen Romdhani 74

Figure 4. 21 : Interface cartographique de l’application « 3G Network Map ».

4.3. Etude de cas

Nous avons consulté la carte géographique et nous avons détecté la présence d’un

problème au niveau de la cellule ayant comme identifiant « UHM004Z » (figure 4.22).


Imen Romdhani 75

Figure 4. 22 : Détection d’un problème au niveau d’une cellule.

On voit bien le marqueur pointant sur cette cellule en rouge et la valeur du KPI «CS Drop

rate » est égale à « 1,2» alors qu’elle doit être inférieure ou égale à « 1» pour bien assurer

la QoS requise.

Nous avons fait l’analyse de la configuration de cette cellule moyennant l’application

« Configuration Parsing » et nous avons détecté un problème de missing neighbors.

Afin de remédier au problème, l’équipe Optimisation Radio a envoyé un OT à l’OSS où ils ont

ajouté les voisinages manquants à la liste des Active Set de la cellule « UHM004Z »

L’optimisation effectuée a permis de faire descendre la valeur du KPI de « 1,2 » à « 0,8 » qui

est une valeur acceptable et ne présente aucun problème (figure 4.23).

KPI>1


Imen Romdhani 76

Figure 4. 23 : Optimisation de la QoS d’une cellule.

Nous avons tracé la courbe de l’évolution du KPI « CS Drop rate » pour montrer l’impact de

l’optimisation que nous avons effectué au niveau des relations de voisinage. Cette courbe

est donnée par la figure 4.24 qui suit :

Figure 4. 24 : Evolution du KPI « CS Drop rate » de la cellule « UHM004Z ».

KPI = 0,8< 1


Imen Romdhani 77

Conclusion

Dans ce chapitre, nous avons présenté les aspects de réalisation de notre système à

travers une description de l’environnement de travail matériel et logiciel. Nous avons

également présenté les principales interfaces de l’application avec des imprimes écrans afin

d’illustrer le fonctionnement de notre outil. Enfin nous avons clos par une étude de cas afin

de donner une image réelle sur le travail réalisé.

Conclusion générale

Imen Romdhani 78


a gestion de la QoS dans les réseaux radio mobiles est un défi continuel pour un

opérateur de télécommunications qui compte sur l'expertise de son personnel, en

particulier les ingénieurs radio, afin d'offrir à ses abonnés une expérience utilisateur

satisfaisante apte à les fidéliser.

Le travail présenté dans ce rapport fait partie des activités d'optimisation quotidiennes

réalisées par l'équipe d'ingénieurs optimisation radio pour l'amélioration des performances

du réseau 3G. Il inclut une description de la méthodologie d'optimisation basée sur la

gestion et l’audit de la configuration radio du réseau 3G ainsi que la gestion des indicateurs

clé de performance pour détecter les anomalies radio et les corriger.

Au cours de ce travail nous avons pris conscience de la difficulté de la tâche d'un ingénieur

radio qui vient non seulement du caractère instable du réseau radio mais aussi du nombre

énorme de paramètres à manipuler. Nous avons alors proposé un outil capable

d’automatiser le travail d'audit de la configuration radio, de faciliter le suivi des KPI à partir

d’une carte géographique et de favoriser le contrôle de la réalisation d’un ordre de travail.

Afin de mener à bien cette mission, nous avons adopté un plan méthodologique dans notre

travail et cela en commençant dans un premier temps par une étude théorique sur le réseau

3G et le processus d’optimisation. Dans un deuxième temps, nous avons enchaîné avec

l’étude de l’existant afin d’approfondir l’analyse des dimensions innovantes de ce projet. Par

la suite, nous avons spécifié les besoins des futurs utilisateurs de ce produit et affiné ensuite

la conception qui en résultait pour arriver enfin à implémenter et tester la solution retenue.

Cet outil peut être amélioré par l'ajout d'une possibilité d’interagir directement avec l’OSS

pour importer le fichier de configuration. Ceci permet d’esquiver la tâche de l’import de ce

fichier avant de commencer le processus d’analyse.

L


Imen Romdhani 79

Pour conclure, l'apport le plus important de ce projet est qu'il présente un aperçu sur le

travail d'ingénierie radio et des défis continuels à relever pour garantir la meilleure

performance du réseau avec des conditions imprévisibles.

Références

Imen Romdhani 80

Références

[1] : Pierre Lescuyer, ”UMTS Les Origines L’Architecture La Norme”, Dunod, 2001.

[2] : Xavier Lagrange, ”Principes et évolutions de l'UMTS”, Hermès, 2005.

[3] : EFORT, ”Réseau d’Accès UMTS”, http://www.efort.com, consulté Mars 2013.

[4] : NEC France, ”Formation Ingénieur Optimisation 3G ”, Département Accès–Equipe

Optimisation, 2009.

[5] : Alcatel-Lucent, ”Successfully Deploying a 3G/UMTS Network — Some key techniques

for launching a 3G network on time with optimal performance”, 2008.

[6] : Alcatel University, ”OMC-R architecture and features”, Janvier 2009.

[7] : Huwaei Technologies, ”RAN12 document”, 2009.

[8] : http://jouonsy.free.fr/Projet/conception.htm, consulté Mai 2013.

[9] : http://objecteering_uml_modeler/diagrams/use_case_diagrams.htm, consulté Mai

2013.

[10] :http://blog.lecacheur.com/2004/12/09/mvc-mvc2-modele-vue-controlleur-model-

view-controller/, consulté Avril 2013.

[11] : Aron Lurie & Marty Lurie, ”DB2 and open source: Put yourself on the map with Google

Maps API”, IBM, 02 Mars 2006.

[12] : http://www.uml-sysml.org/diagrammes-uml-et-sysml/diagramme-uml/diagramme-de-

classe, Consulté juin 2013.

[13] : http://www.saxproject.org/, consulté Mars 2013.

http://www.efort.com/

http://jouonsy.free.fr/Projet/conception.htm

http://objecteering_uml_modeler/diagrams/use_case_diagrams.htm

http://blog.lecacheur.com/2004/12/09/mvc-mvc2-modele-vue-controlleur-model-view-controller/

http://blog.lecacheur.com/2004/12/09/mvc-mvc2-modele-vue-controlleur-model-view-controller/

http://www.uml-sysml.org/diagrammes-uml-et-sysml/diagramme-uml/diagramme-de-classe

http://www.uml-sysml.org/diagrammes-uml-et-sysml/diagramme-uml/diagramme-de-classe

http://www.saxproject.org/

Références

Imen Romdhani 81

[14] : http://poi.apache.org/, consulté Avril 2013.

[15] : Teodor Danciu & Lucian Chirita, ”The Definitive Guide to JasperReports”, DEFINITIVE

GUIDE, aot 2007.

[16] : http://www.ericsson.com/oss-bss, consulté juin 2013.

[17] : http://www.loukam.net/Support_Java.pdf, consulté Mars 2013.

[18] : http://telecharger.logiciel.net/poweramc/, consulté Mai 2013.

[19] : Jean-Marie Defrance, ”Premières applications Web 2.0 avec Ajax et PHP ”, Eyrolles,

2008.

http://poi.apache.org/

http://www.ericsson.com/oss-bss

http://www.loukam.net/Support_Java.pdf

http://telecharger.logiciel.net/poweramc/

Annexe

Imen Romdhani 82

Annexe A : OSS

L’OSS ou Operations Support Systems est l’ensemble de systèmes permettant à un

opérateur de maintenir et exploiter son réseau. Il assure la supervision et la gestion du

réseau. En effet, la supervision du réseau peut intervenir à de nombreux niveaux :

Exploitation et gestion de performance et Qualité de service.

administration commerciale (déclaration des abonnés, terminaux, facturation, etc).

La gestion de la sécurité.

L'installation et la configuration des composants réseau.

La gestion des erreurs réseaux.

Modification de paramétrage et réalisation de statistiques.

L’administration du réseau est effectuée moyennant les équipements suivants [16] :

1. TMN : Telecommunications Management Network

C’est un ensemble formé par les équipements de médiation, le système d’exploitation

et les réseaux de transport. Le management est réalisé par les OMC (Operations and

Maintenance Centre) qui assurent une supervision locale des équipements et transmettent

aux NMC (Network Management Center) les incidents majeurs survenus sur le réseau qui

permettent l’administration générale de l’ensemble du réseau par un contrôle centralisé.

2. EIR : Equipment Identity Register :

C’est une base de données annexe contenant les identités des terminaux. Elle peut

être consultée quand un abonné demande un service afin vérifier que le terminal utilisé est

autorisé à fonctionner sur le réseau.

3. AUC : Authentification Centre

Cette base de données permet l’authentification des demandes de services et le

chiffrement des communications à l'aide d’algorithmes.

http://fr.wikipedia.org/wiki/Qualit%C3%A9_de_service

Annexe

Imen Romdhani 83

Annexe B : Outils de développement

1. Langage de programmation JAVA

Java est un langage de programmation orienté objet qui a connu un énorme succès

depuis 1995. Nous avons choisi ce langage pour tirer profit de ses multiples avantages.

D’abord, java est un langage portable : c’est une bibliothèque d'exécution indépendante de

la plateforme. En théorie, il est possible d'utiliser le même code pour Windows 95/98/NT,

Solaris UNIX Macintosh, etc. D’autre part, les concepteurs de ce langage ont supprimé

l'allocation et la libération de mémoire manuelles. La mémoire dans java est allouée et

libérée automatiquement, à la différence du langage C++. Le développeur n'a jamais à se

préoccuper des pertes de mémoire. Un autre avantage indéniable du java est l’orienté objet,

c'est à dire qu'on ne va pas manipuler des fonctions et des procédures. En revanche, on crée

des objets qui vont s'échanger des messages. Le principal avantage est que l'on peut réaliser

une programmation modulaire : tous les objets peuvent être déclarés séparément. Ceci aide

à mieux organiser le code pour des futures évolutions et aussi bien que rendre certaines

parties réutilisables pour gagner en temps et en clarté [17].

2. MySQL Server

MySQL server est un système de gestion de base de données relationnel (SGBDR) libre. Il est

considéré comme l’un des plus utilisées SGBD. MySQL server a des avantages multiples :

Open source.

Performant : Il est classé parmi les SGBDR les plus rapides et les plus fiables.

Rapidité de mise en œuvre : Il est facile à utiliser grâce à ses fonctionnalités. pratiques

développées en coopération avec les utilisateurs.

Annexe

Imen Romdhani 84

3. Sybase PowerAMC 15

PowerAMC est un logiciel de conception proposant plusieurs techniques de

modélisation standard tel que la méthode Merise, la modélisation UML et autres

modélisations des processus de métiers consacrée aux non-informaticiens pour faciliter et

combler plus rapidement leurs besoins [18].

4. AJAX

AJAX (acronyme d'Asynchronous JavaScript and XML), autrement dit JavaScript et XML

Asynchrones, est un concept de programmation Web se servant de différentes technologies

telles que JavaScript et XML. Il permet de faire communiquer une page Web avec un serveur

Web sans avoir besoin de recharger la page.

On utilise AJAX pour de multiples raisons :

Temps de chargement réduit.

Utilisation de la bande passante réduite.

Un effet design épuré.

AJAX est donc une manière de développer des pages Web moyennant les technologies

suivantes [19] :

Javascript : un langage de script, en effet les fonctions Javascript sont invoquées si un

événement intervient sur la page.

DOM (Document Object Model) : c’est une API permettant d’accéder à des documents

structurés. Elle représente la structure de documents HTML et XML.

CSS (Cascading Style Sheets) : un langage de style permettant de séparer de façon

claire le contenu de la forme et de la présentation.

XmlhttpRequest : un objet Javascript qui permet l’envoie et la réception des requêtes

client-serveur en mode asynchrone.

Nous avons utilisé AJAX afin de mettre à jour notre page Web quand l’utilisateur demande

l’affichage des informations d’une cellule.

Documents

Audit et Gestion de la configuration radio 3G.pdf