Vous êtes sur la page 1sur 96
Résumé
Résumé

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

Malek BEN YOUSSEF Travail proposé et réalisé en collaboration avec Année universitaire : 2012/2013 Imen Romdhani

Année universitaire : 2012/2013

Imen Romdhani 1
Imen Romdhani
1

Résumé

Résumé

Résumé Résumé Imen Romdhani i
Résumé Résumé Imen Romdhani i

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

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

 

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

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

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

Liste des figures

Figure 1. 1 : Architecture globale du réseau

5

6

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

8

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

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

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

48

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

données

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

52

leurs paramètres sur une interface cartographique »

Liste des tableaux

Figure 4. 1 : La démarche du reporting

58

Figure 4. 2 : Interface

59

Figure 4. 3 : Interface

60

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

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

63

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

64

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

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

67

Figure 4. 13 : Choisir deux cellules à comparer

67

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

68

Figure 4. 15 : Détection des missing

69

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

70

Figure 4. 17 : Choix du type de

70

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

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

75

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

76

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

76

Liste des tableaux

Liste des tableaux

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

4

Tableau 1. 2 : Indicateurs clés de

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

33

avec les principaux KPI

Liste des acronymes

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

-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

Introduction générale

D 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.

Introduction générale

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é.

Cadre Général Du Stage

1

Cadre Général Du Stage 1 Introduction L a réalisation de ce projet a nécessité une étude

Introduction

L 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].

Chapitre 1. Cadre général du stage

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

Chapitre 1. Cadre général du stage

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] :

nous montre l’architecture globale du réseau UMTS [3] : Figure 1. 1 : Architecture globale du

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

Chapitre 1. Cadre général du stage

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 :

éléments. Ceci est illustré par la figure 1.2 suivante : Figure 1. 2 : Architecture du

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

Chapitre 1. Cadre général du stage

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

aux abonnées de communiquer à l’intérieur d’un même réseau 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

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

lorsque

des appels. Il permet de téléphonie mobile

échanges, de maintenir

la

communication

même

- 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.

Chapitre 1. Cadre général du stage

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 :

réseau cœur de l’UMTS est donnée dans la figure 1.3 : Figure 1. 3 : Architecture

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.

Chapitre 1. Cadre général du stage

Chapitre 1. Cadre général du stage Figure 1. 4 : Cycle de vie d’un s ite

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 dun 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.

Chapitre 1. Cadre général du stage

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].

réelles du réseau et optimisées en conséquence [5]. Figure 1. 5 : Exemple de planification des

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

Chapitre 1. Cadre général du stage

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).

Chapitre 1. Cadre général du stage

- 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 CenterRadio) 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.

Chapitre 1. Cadre général du stage

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 :

Chapitre 1. Cadre général du stage

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.

Chapitre 1. Cadre général du stage

Chapitre 1. Cadre général du stage Figure 1. 6 : Organigramme du processus d’analyse et d’optimisation.

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

Chapitre 1. Cadre général du stage

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 :

Chapitre 1. Cadre général du stage

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.

2

Analyse Et Spécification Des Besoins

2 Analyse Et Spécification Des Besoins Introduction A près avoir introduit le réseau 3G, donné un

Introduction

A 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.

Chapitre 2. Analyse et spécification des besoins

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

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

(100, 150, 200 Mo

)

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.

Chapitre 2. Analyse et spécification des besoins

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

Chapitre 2. Analyse et spécification des besoins

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.

Chapitre 2. Analyse et spécification des besoins

Chapitre 2. An a lyse et spécification des besoins Figure 2. 1: Représentation du modèle en

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 :

Chapitre 2. Analyse et spécification des besoins

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.

Chapitre 2. Analyse et spécification des besoins

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.

Chapitre 2. Analyse et spécification des besoins

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 :

outil 3G Parser est donné par la figure 2.2 suivante : Figure 2. 2: Diagramme des

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

Chapitre 2. Analyse et spécification des besoins

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

du réseau » 2.4.3.1. Diagramme des cas d’utilisation Figure 2. 3: Cas d’utilisation « Gérer la

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

Chapitre 2. Analyse et spécification des besoins

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 :

 

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

Sommaire

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

structurée sous forme de tableaux.

 

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.

Description

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 1]: Un message d’erreur «Your login attempt was not successful,

Exception(s)

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 ».

Chapitre 2. Analyse et spécification des besoins

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.

 

Pré-condition(s) :

Parsing du fichier XML.

Scénario:

Description

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

Chapitre 2. Analyse et spécification des besoins

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.

 

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.

Description

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 ».

Chapitre 2. Analyse et spécification des besoins

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.

 

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.

Description

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.

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

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».

Chapitre 2. Analyse et spécification des besoins

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.

 

Pré-condition(s) :

Lancer l’outil 3G Parser.

Description

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.

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

Chapitre 2. Analyse et spécification des besoins

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.

 

Pré-condition(s) :

Lancer l’outil 3G Parser.

Description

S’authentifier.

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

 

Scénario:

L’utilisateur lance l’outil 3G Parser.

Chapitre 2. Analyse et spécification des besoins

 

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.

Conception De L’Outil « 3G Parser »

3

Conception De L ’Outil « 3G Parser » 3 Introduction A près avoir fixé les besoins

Introduction

A 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.

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

3.1.1.

Architecture Parsing »

logicielle

de

l’application

«

Configuration

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.

nous montre les trois parties fondamentales du modèle MVC. Figure 3. 1 : Architecture du modèle

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.

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

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] :

l’ar chitecture donnée par la figure suivante [11] : Figure 3. 2 : Architecture de l’application

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

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

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 :

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 3 : Diagramme de packages.

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.

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

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.

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

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.

du controller en bleu et celles de la partie model en gris. Figure 3. 4 :

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.

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

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 :

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 5 : Diagramme de classes

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 ».

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 6 : Diagramme de classes

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.

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

d. Package « Parameter_Check »

Le diagramme de classes explicitant les objets du packages « Parameter_Check » est donné par la figure 3.7 suivante :

Parameter_Check » est donné par la figure 3.7 suivante : Figure 3. 7 : Diagramme de

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 ».

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

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 ».

d’achever le fonctionnement du package « Verif_OT ». Figure 3. 8 : Diagramme de classes du

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

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

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 ».

illustre le diagramme de classes du package « Reporting ». Figure 3. 9 : Diagramme de

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.

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

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 :

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 10 : Diagramme de séquence

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 :

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 11 : Diagramme de séquences

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.

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

Cha pitre 3. Conception de l’outil «3G P arser» Figure 3. 12 : Diagramme de séquences

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

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

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.

représente les différentes phases de cette opération. Figure 3. 13: D iagramme de séquence du scénario

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

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

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 :

est donnée par le diagramme de séquences suivant : Figure 3. 14 : Diagramme de séquences

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

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

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é.

Réalisation, Tests Et Validation

4

Réalisation, Tests Et Validation 4 Introduction D ans ce chapitre qui forme la dernière étape du

Introduction

D 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.

Chapitre 4. Réalisation, tests et validation

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].

Chapitre 4. Réalisation, tests et validation

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.

Chapitre 4. Réalisation, tests et validation

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

l’affichage tels que les zooms, les marqueurs, les titres et les contenus des info-bulles.

. Grace à cette API, nous pouvons

peaufiner tous les détails de

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.

Chapitre 4. Réalisation, tests et validation

Chapitre 4. Réalisation, tests et validation Figure 4. 1 : La démarche du reporting. La création

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.

Chapitre 4. Réalisation, tests et validation

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 ».

est de limiter l’accès à l’outil « 3G Parser ». Figure 4. 2 : Interface d’authentification.

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 :

Chapitre 4. Réalisation, tests et validation

Chapitre 4. Réalisation, tests et validation Figure 4. 3 : Interface d’accueil. 4.2.3. Module d’analyse de

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 ».

Chapitre 4. Réalisation, tests et validation

Chapitre 4. Réalisation, tests et validation Figure 4. 4 : Interface d’audit de la configuration radio.

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 :

Chapitre 4. Réalisation, tests et validation

Chapitre 4. Réalisation, tests et validation Figure 4. 5 : Importer le fichier de configuration format

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).

la liste située à gauche de l’interface (figure 4.6). Figure 4. 6 : Affichage des tableaux

Figure 4. 6 : Affichage des tableaux de configuration.

Chapitre 4. Réalisation, tests et validation

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.

et 4.8 i llustrent le processus d’export au format Excel. Figure 4. 7 : Choix du

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.

Chapitre 4. Réalisation, tests et validation

Chapitre 4. Réalisation, tests et validation Figure 4. 8 : Résultat de l’export au format Excel.

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 :

à suivre pour cette fin est présentée par la figure 4.9 : Figure 4. 9 :

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

Chapitre 4. Réalisation, tests et validation

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.

encore l’identifiant de la cellule qu’il veut analyser. Figure 4. 10 : Choix de la cellule

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.