Vous êtes sur la page 1sur 80

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom

A.KARKOURI & A.BOUCHOUKI PFE 2006


1

Table de matires





INTRODUCTION GENERALE.................................................................................................................................. 4
CHAPITRE 1. CONTEXTE GENERAL DU PROJET............................................................................. 6
1.1. ASPECTS GENERAUX DU GSM.............................................................................................................. 6
1.1.1. Architecture du rseau GSM.......................................................................................................... 6
1.1.2. Interfaces du rseau GSM.............................................................................................................. 8
1.1.3. Gestion de la mobilit dans GSM................................................................................................... 9
1.2. LOPTIMISATION DU RESEAU GSM..................................................................................................... 11
1.2.1. La qualit de service:................................................................................................................... 11
1.2.2. Notion dobjectif .......................................................................................................................... 14
1.2.3. Le cycle doptimisation ................................................................................................................ 15
CHAPITRE 2. ANALYSE ET CONCEPTION DU SYSTEME............................................................. 20
2.1. ETUDE DE LEXISTANT :...................................................................................................................... 20
2.1.1. Elaboration du Rapport hebdomadaire du service support:........................................................ 20
2.1.2. Plan dactions :............................................................................................................................ 24
2.1.3. Suivi des demandes de travaux : .................................................................................................. 24
2.1.4. Gestion de stock :......................................................................................................................... 24
2.2. SPECIFICATION DES BESOINS :............................................................................................................. 25
2.3. ANALYSE FONCTIONNELLE................................................................................................................. 25
2.3.1. Identification des acteurs du systme........................................................................................... 25
2.3.2. Langage de modlisation ............................................................................................................. 27
2.4. CONCEPTION DU SYSTEME.................................................................................................................. 35
2.4.1. Module KPI :................................................................................................................................ 35
2.4.2. Module Upgrade SCONG :.......................................................................................................... 36
2.4.3. Module Upgrade TCONG:........................................................................................................... 38
2.4.4. Module Rapport: .......................................................................................................................... 40
2.4.5. Module demande de travaux:....................................................................................................... 41
2.5. MATRICE DE CORRESPONDANCES CAS DUTILISATION/EXIGENCES..................................................... 42
CHAPITRE 3. MISE EN UVRE DU SYSTEME.................................................................................. 46
3.1. CONCEPTION ARCHITECTURALE DU SYSTEME..................................................................................... 46
3.1.1. Plate-forme J2EE:........................................................................................................................ 46
3.1.2. Conception architecturale du systme : ....................................................................................... 48
3.1.3. Solution en framework du systme :............................................................................................. 50
3.2. LENVIRONNEMENT DU DEVELOPPEMENT........................................................................................... 56
3.2.1. MySQL : ....................................................................................................................................... 56
3.2.2. Oracle : ........................................................................................................................................ 57
3.2.3. TomCat : ...................................................................................................................................... 57
3.2.4. Concurrent Versions System (CVS) : ........................................................................................... 57
3.2.5. Eclipse : ....................................................................................................................................... 58
3.2.6. API cewolf :.................................................................................................................................. 60
3.3. ARCHITECTURE DE LENVIRONNEMENT DU DEVELOPPEMENT............................................................. 61
3.4. MISE EN UVRE DE LA SOLUTION : ..................................................................................................... 63
Conclusion gnrale.................................................................................................................................... 68
Bibliographie............................................................................................................................................... 69
Liste des figures........................................................................................................................................... 70
Liste des tableaux ........................................................................................................................................ 72
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
2
ANNEXE 1. : LES COMPTEURS.............................................................................................................. 73
1.1 LES CANAUX DE SIGNALISATION : ....................................................................................................... 73
1.2 LES CANAUX DE TRAFIC TCH :........................................................................................................... 73
ANNEXE 2 : ANALYSE DES COUPURES DAPPELS ET DE LA CONGESTION ....................... 74
2.1 ANALYSE DES COUPURES DAPPELS :.................................................................................................. 74
a) Les coupures dappels sur SDDCH : ........................................................................................... 75
b) Les coupures dappel sur TCH : .................................................................................................. 76
2.2 LA CONGESTION :................................................................................................................................ 77
a) congestion sur SDCCH................................................................................................................ 78
b) Congestion sur TCH : .................................................................................................................. 79




















Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
3

Prsentation de MdiTelecom


MdiTelecom est le premier oprateur priv de tlcommunications vocation globale au
Maroc. Ce groupe est lissue du partenariat entre des entreprises marocaines, leaders de la
finance et de lindustrie, et de grandes multinationales du secteur de tlcommunications.
Forts dexpriences internationales, les groupes Telefonica et Protugal Telecom apportent
leur maitrise des nouvelles technologies des tlcommunications. Trois investisseurs maroains
les ont rejoints : le groupe BMCE (Banque marocaine du Commerce Extrieur) premier
acteur financier au Maroc, le groupe AFRIQUIA, leader dans le domaine de lnergie avec
une experience solide dans le domaine de la distribution et enfin la CDG (Caisse de Dpt et
de Gestion), premier investisseur institutionnel marocain.

Rpartition du capital de MdiTelecom
30,5%
8%
11%
20%
30,5%
Telefonica
Portugal Telecom
Groupe BMCE
Groupe Akwa
CDG

Figure 1 : Rpartition du capital de MdiTelecom

MdiTelecom sest associ les comptences de deux quipementiers de rfrence : le sudois
ERICSSON et lAllemand SIEMENS, deux groupes expriments et habitus cooprer en
matire de dploiement des rseaux GSM en Europe et notamment en Espagne.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
4


Introduction gnrale

Le souci de loprateur reste toujours daugmenter la qualit de service de son rseau
de manire remdier aux problmes de congestion du la croissance de la clientle.
Dans ce contexte plusieurs entits de Mditelecom sont charges daugmenter la
capacit du rseau et doptimiser lutilisation des ressources tout en assurant un niveau
acceptable de qualit de service. Le service support est lune de ces entits qui participe dans
les diffrentes oprations doptimisation en plus de son rle dans ldition des rapports
illustrant ltat du rseau et garantissant le suivi des actions.
Actuellement, le service support ne dispose pas doutil informatique qui lui facilite ses
fonctions. Conscient de ce problme, ce servie nous a confi, pendant notre stage, la tache de
trouver une solution pour son besoin.
Ce rapport se prsente, tant le travail que nous avons effectu au sein du dpartement
planification radio de Mditlecom, comme suivant : Aprs avoir introduit la problmatique
relative loptimisation du trafic, nous avons consacr le premier chapitre pour prsenter la
structure gnral du GSM ; Ce qui nous permettrait de comprendre la suite de notre travail.
Dans le chapitre 2 nous avons tent, autant que possible danalyser le besoin du service
support et dtablir un cahier de charge. Le chapitre 3 propose un plateforme architecturale
pour la solution adopte.


Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
5















Contexte gnral du projet










Chapitre I

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
6

Chapitre 1. Contexte gnral du projet
Ce premier chapitre vise cerner lenvironnement global du projet. Nous allons prsenter
dans un premier temps des aspects gnraux du GSM savoir larchitecture du rseau, les
interfaces et les diffrents canaux. Par la suite nous entamons dans une deuxime partie
loptimisation du rseau mobile et qui mettra laccent sur le processus et les actions
doptimisation..
1.1. Aspects gnraux du GSM
Le rseau GSM a pour premier rle de permettre des communications entre abonns mobiles
(GSM) et abonns du rseau tlphonique commut (RTCP - rseau fixe). Il se distingue par
un accs spcifique, la liaison radio, et sinterface avec le rseau RTCP.
1.1.1. Architecture du rseau GSM
En gnral, le systme de communication radio mobile est constitu de trois sous systmes
principaux :
Le sous systme radio (BSS, Base Station Sub-system) : qui permet la gestion des
ressources radio et les transmissions radiolectriques.
Le sous systme rseau (NSS, Network Sub-System) : qui comprend les fonctions
assurant ltablissement des appels et la gestion de la mobilit.
Le sous systme dexploitation et de maintenance (OSS, Operation Sub-System)
qui soccupe de la supervision du rseau.

Figure 2 : Architecture du rseaux GSM
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
7

a) Sous systme radio BSS :
Le sous systme radio est lensemble des constituants du rseau qui gre lchange et la
transmission des donnes. Le sous systme radio est principalement constitu de trois
lments : le mobile, la station de base et le contrleur de station.
La station mobile MS
Le terme station mobile dsigne un quipement terminal muni d'une carte SIM (Subscriber
Identity Mobile), qui permet d'accder aux services de tlcommunication d'un oprateur
GSM.
La station de base : BTS
La BTS est forme par un ensemble dmetteurs rcepteurs appels TRX. Elle offre une
couverture, un certain nombre de canaux de trafic dans une zone donne et ralise un
ensemble de mesures radio qui sont transmises au BSC.
Les fonctions de la BTS sont :
- Connexion radio avec La station mobile.
- Modulation / Dmodulation.
- Codage / Dcodage.
- Chiffrement.
- Gestion des canaux radio.
- Contrle et mesure de puissance.
- Correction derreur.
- Ralisation des rapports de mesures transmettre au BSC.
Le contrleur de station de base : BSC
Le contrleur de station de base BSC est lorgane intelligent du sous-systme radio. Le BSC
gre les ressources radio pour une ou plusieurs BTS, travers le monitorage de la connexion
entre la BTS et les MSC, et, aussi, il soccupe de lallocation des canaux radio, du codage, du
saut de frquences et du handover. Il permet plus prcisment :
La gestion et la configuration du canal radio: il doit choisir pour chaque appel la
cellule la mieux adapte et doit slectionner le canal radio.
La gestion du handover : il dcide, sur la base des relevs reus par la BTS, le moment
pour effectuer un handover.
Cest un commutateur qui ralise une concentration des circuits vers le MSC.
Cest un relais pour les alarmes et les statistiques issues des stations de base vers
lOMC-R.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
8
b) Sous systme rseau NSS :
Le sous-systme dacheminement ou le NSS inclut les quipements et les fonctions relatifs
ltablissement des appels, la gestion des utilisateurs, de la mobilit et de linterface avec le
rseau tlphonique commut.
Le NSS est la combinaison de trois entits :
Le MSC (Mobile-service Switching Center) appel aussi centre de commutation des
mobiles . Sa fonction essentielle rside au niveau de la coordination de
ltablissement de lappel entre les utilisateurs mobiles ou utilisateurs mobiles et
abonns au rseau tlphonique fixe.
Le HLR (Home Location Register) ou enregistreur de localisation nominal est une
base de donnes qui gre les abonns dun rseau GSM. Le HLR est la base de
donnes rfrence pour les paramtres relatifs aux abonns.
Le VLR (Visitor Location Register) appel aussi enregistreur de localisation
daccueil est une base de donnes qui mmorise, temporairement, les donnes
dabonnement des abonns prsents dans une zone de localisation gographique.
c) Le sous systme dexploitation et de maintenance : OSS
LOSS est le systme de gestion du rseau GSM. Il permet un contrle centralis et uniforme
de tous les lments du systme.
Selon la norme GSM, lOSS est structur de manire hirarchise et contient plusieurs centres
dexploitation et de maintenance (OMC) assurant le contrle des diffrents lments du
rseau.
Les centres OMC sont leur tour commands depuis un centre de gestion de rseau (NMC).
Ce dernier a donc pour tche ladministration gnrale de lensemble du rseau.
1.1.2. Interfaces du rseau GSM
Les interfaces travers lesquelles les diffrentes parties du rseau GSM arrivent
communiquer sont toutes spcifies par la norme.
La liste des interfaces dans le systme GSM est donne dans le tableau ci-dessous :
Nom Localisation Utilisation
Um MS BTS Interface radio
Abis BTS BSC Divers
A BSC MSC Divers
GMSC HLR Interrogation HLR pour appel entrant. C
SGMSC HLR Interrogation HLR pour message court entrant.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
9
VLR HLR Gestion des informations dabonns et de
localisation
D
VLR HLR Services supplmentaires.
MSC- SGMSC Transport des messages courts E
MSC MSC Excution du handover
G VLR VLR Gestion des informations dabonns
F MSC EIR Vrification de lidentit du terminal
B MSC VLR Divers
H HLR AUC Echange des donnes dauthentification.
Tableau 1 : les interfaces utilises dans le GSM
1.1.3. Gestion de la mobilit dans GSM
La diffrence principale entre les rseaux cellulaires et autres rseaux fixes classiques rsident
dans lintroduction de la mobilit. Ainsi, pour assurer cette caractristique, le systme GSM
dploie des procdures normalises et spcifiques lui permettant de rester en connexion avec
chacun de ses abonns et doffrir une qualit de communication estimable.
Il serait, donc, intressant dtudier les diffrentes tapes par lesquelles il faut passer pour
ltablissement dun appel.
Avant daborder ces diffrentes dmarches, il est ncessaire de donner un aperu sur une
notion qui reprsente la base de toute communication au sein du rseau GSM : Les canaux
logiques.
a) Canaux logiques :
Type de canal Canal logique Slot
possible
Multi
trame
Fonction
FCCH
Frquency Correction
Channel
0 51 Calage fin du mobile sur la frquence
porteuse
SCH
Synchronization Channel
0 51 Synchronisation du mobile avec la
cellule
Broadcast
Channel
Simplex
Non-ddis
BCCH
Broadcast Control Channel
0
2,4,6
51 Diffusion au mobile des informations de
la cellule
PCH
Paging Channel
0
2,4,6
51 Canal par lequel le mobile reoit les
appels en provenance du rseau
RACH
Random Access Channel
0
2,4,6
51 Canal par lequel le mobile accde au
rseau de faon alatoire pour rpondre
ou lancer un appel.
Common
Control Channel
Simplex
Non-ddis
AGCH
Access Grant Channel
0
2,4,6
51 Le rseau communique par ce canal pour
informer le mobile par o, quand et
comment il doit tablir une
communication
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
10
CBCH
Cell Broadcast Channel
0
1,2,3
51 Diffusion sur ce canal des messages
courts de type info routire, mto etc...
SDCCH
Stand-Alone Dedicated
Control Channel
0
1 7
51 Canal de signalisation, mise jour de
localisation
SACCH
Slow Associated Control
Channel
0
0 7
51
26
Canal de supervision d'une liaison,
control de la puissance, de la qualit,
remont de mesure.
Il peut tre associ soit un canal
SDCCH (multi-trame 51), soit un canal
TCH (multi-trame 26).
Dedicated
Control Channel
Duplex
Ddis
FACCH
Fast Associated Control
Channel
0 7 26 Canal de supervision d'une liaison, lors
d'une communication, il sert excuter
le Hand-Over, ce canal n'existe que par
le vol de slots du canal TCH
Traffic Channel

Duplex
Ddis
TCH
Traffic Channel
0 7 26 Canal supportant le trafic voix ou data
Tableau 2 : Canaux logiques du GSM
b) Etapes tablissement dappel
La figure ci-dessous illustre les diffrentes tapes ncessaires ltablissement dappel, dans
le cas dun appel arrivant une station mobile. Pour ce qui est de lautre sens de demande
dappel (appel originaire de la MS), les mmes tapes sont suivies, sauf que dans ce cas, la
procdure du paging naura pas lieu puisque la MS communique directement avec la BTS sur
laquelle elle est cale.
Ainsi, lappel ne peut tre tabli que si lopration de lallocation des canaux logiques
SDCCH et TCH russit. Dans ce sens, le processus doptimisation du rseau GSM est bas
sur le succs de cette opration.














Figure 3 : Etablissement dappel
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
11
c) La procdure du handover :
Le handover est le processus par lequel une communication tablie est maintenue alors que le
mobile se dplace travers le rseau cellulaire; elle implique que la communication puisse
passer d'un canal physique un autre canal physique avec le minimum d'interruption (en
moyenne < 100 ms pour une communication voix dans le GSM).
Il est vident qu'en cas de petites cellules, les handovers peuvent se multiplier et entraner une
charge grandissante pour le rseau.
Bien que le handover soit fondamentalement un transfert intercellulaire, il existe aussi un type
de handover intracellulaire impos par la qualit de service de la communication.

1.2. Loptimisation du rseau GSM
Loptimisation constitue, pour tout oprateur, un processus dterminant pour garantir le bon
fonctionnement de son rseau en terme de couverture, de capacit et de qualit de signal. En
effet, loptimisation permet dadapter la configuration du rseau aux changements frquents
que connaissent les zones couvertes en terme de rpartition de trafic de lenvironnement
radio.
1.2.1. La qualit de service:
Le dpartement qualit de MdiTelecom a dfini plusieurs indices appels indicateurs cls de
performance KPI (Key Performance Indicator) qui permettent de mesurer la qualit de service
offertes aux abonnes. Cette qualit, et par la suite les indicateurs ls de performance, a t
subdivise en trois catgories :
La qualit daccessibilit au service (Accessibility).
La qualit de maintenance de service (Retainability).
La qualit de service dintgrit (Integrity).












Figure 4 : Les catgories de la qualit de service

Qualit de service
Accessibilit du
service
Intgrit du service Maintenance du
service
Trafic
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
12

a) Laccessibilit au service :
Cest la possibilit pour lutilisateur dtablir un appel, donc daccder au rseau, quand il le
dsire. Pour mesurer la qualit de ce service, loprateur utilise les indicateurs suivants :
TCH_ASSIGNMENT SUCCESS RATE (TASR), reprsente le taux dallocation
des canaux de trafic TCH russies.
SDCCH Congestion Rate (SCONG), donne le pourcentage des assignements du
SDCCH refuss (Essai dtablissement dappel, Envoi dun message..) suite une
congestion au niveau du SDCCH
TCH Congestion Rate (TCONG), donne le pourcentage des demandes dun TCH
refuses car aucun TCH nest disponible (cela inclut tous les types de handovers).

a) TCH_ASSIGNMENT SUCCESS RATE (TASR):
TASR donne le taux de russite de lassignment dun canal TCH , quatre compteurs sont
disponible
Description des compteurs :
TASSSUC : Total Number of Successful Assignments, per Cell, per FR TCH .
TASSAT : Total Number of Assignment Attempts per Cell per FR TCH.
SINTHINT : Nombre de Handover SDCCH-TCH russi (Directed Retry) vers une
cellule qui appartient la mme BSC que la cellule d'origine.
SUINBHDO : Nombre de Handover SDCCH-TCH russi vers une cellule qui
appartient une autre BSC que la cellule d'origine. ce compteur est
donn par target cell d'o l'indice i qui indique la i_me voisine.
TASSATT
SUINBHDO SINTHINT TASSSUC
Tasr
i

=
+ +
=
32
1


b) SDCCH Congestion Rate (SCONG) :
S_CONG donne le pourcentage des assignements du SDCCH refuss (Essai dtablissement
dappel, Envoi dun message..) suite une congestion au niveau du SDCCH
Description des compteurs
ATSDCMBS : nombre de refus dassignement SDCCH
NATTSDPE : nombre dessai dassignement SDCCH.
NATTSDPE
ATSDCMBS
* 100 SCONG =

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
13

c) TCH Congestion Rate (TCONG) :
T_CONG donne le pourcentage des demandes dun TCH refuses car aucun TCH nest
disponible (cela inclut tous les types de handovers)
Description des compteurs:
ATCHSMBS : nombre de refus dassignement TCH.
ATTCHSEI : nombre dessai dassignement TCH.
.

=
=
=
2
1
2
1
ATTCHSEI
ATCHSMBS
* 100
j
i
TCONG

b) La maintenance du service :
Cest la possibilit de maintenir lappel jusqu sa fine normale, la maintenance du service est
value par les indicateurs suivants :
Handover Succes Rate (HSR), exprime le pourcentage des handovers russis.
Drop Call Rate (DCR), mesure le taux de coupure de connexions TCH.
a) Le DROP_CALL_RATE (DCR):
Le DCR mesure le pourcentage des MS qui ont eu des interruptions dappels anormales :
Elles ont russi tablir un appel (accs un TCH), mais suite un problme (Radio,
Transmission), il y a eu une coupure dappel.
Description des compteurs:
SUMIHOSUCC : internal incoming success Handover.
SUMEIHOSUCC : external incoming success Handover.
SUMEOHOSUCC : external outgoing success Handover.
SUMOHOSUCC : internal outgoing success Handover.
TNDROP : the number of abnormally terminated connections.



b) Le HANDOVER_SUCCESS_RATE (HSR):
Le HSR donne le pourcentage de succs du handover pour une cellule donne.
Description des compteurs:
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
14
SUMEOHOSUCC : external outgoing success Handover.
SUMOHOSUCC : internal outgoing success Handover.
SUMOHOATT : outgoing Handover attempts.
SUMEOHOATT : outgoing Handover attempts.


c) Lintgrit du service :
La notion dintgrit est lie la qualit de la voix. En ralit, il nexiste pas de mthode
permettant davoir la qualit de la voix dans tout le rseau. Par contre, les indicateurs suivants
peuvent offrir des informations intressantes dans ce sens. Ces deux indices ne font pas partit
de ceux trait par le rapport hebdomadaire donc on se restreint a les prsenter :
Call Succes Rate (CSR), reprsente le pourcentage des appels qui ont
russi la transition SDCC au TC, et qui ont eu une fin normale.
Intra Cell handover, donne le pourcentage des handover effectus dans la
meme cellule cause dune mauvaise qualit de signal.
d) Le trafic :
Le trafic en Erlang reprsente en une heure dobservation le nombre dheure de trafic
vhicul :
Trafic en Busy Hour (heure charg) cest lheure pendant la journe ou
on a le plus haut niveau du trafic.
%Half : le trafic vhicul en half rate.
1.2.2. Notion dobjectif
Mditel a galement divis le territoire en deux types de zones :
Golden Area : Zones rentables pour loprateur et gnrant un trafic important (villes,
zones touristiques, )
Autres zones ou les Non Golden Area, ils gnrent un trafic moins important et les
exigences de qualit seront donc moins fermes.
Mditel a galement fix pour les indicateurs de performance, des seuils ne pas franchir :


Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
15
Objectif
Indicateurs
GA NGA
DCR 1.5 1.5
TCONG 1.5 2
SCONG 0.3 0.5
HSR 95 94
TASR 99 97
CSR 99 97
Tableau 3 : Les objectifs qualits de Mditelecom

1.2.3. Le cycle doptimisation
Le cycle doptimisation ntant pas inscrit dans le cadre de notre projet on se contentera
prsenter le diagramme de la figure 5 qui rsume dune manire clair et simple ses diffrentes
tapes.
En examinant ce cycle on constate que les statistiques sont les cls de toute optimisation.
Cest pour cela quil faut s assurer non seulement de la pertinence des chiffres mais aussi de
leur disponibilit en permanence.



























Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
16












































Figure 5: Cycle d'optimisation
Problme de
capacit
Redimensionnement
Problme
Hardware
Maintenance
quipementier
Etapes ncessitant
un traitement
Lgende
Output
Input
Non
Oui
Oui
Non
-Rclamations des
abonnes
Collecte des donnes :
physiques, logiques, statistiques
Comparaison
Seuils fixs
par
loprateur
Problme
dtect ?
-Classement des cellules selon
leurs performances
-Dtection des cellules
critiques
Identification des problmes
dans les cellules tries
-Congestion des canaux
-Coupures dappel
-checs de Handover
Identification des causes :
-Interfrences
-Voisinage
-Trous de couverture
Elaboration dun plan daction :
-Ajustement des paramtres logiques
-modifications des paramtres physiques
Comparaison des
rsultats avec les
Problme
rsolu ?
Elaboration dun
rapport
Optimisation
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
17
a) Les statistiques
KPI, comme on la vu prcdemment, est la matire premire de toute dcision du fait quelle
reflte ltat du rseau et permet ainsi de suivre son fonctionnement. Son analyse conduit
identifier les diffrents problmes dont souffre le rseau et les causes qui ont gnr ce
dysfonctionnement.
Ceci dit, et dans la perspective dassurer le disponibilit de ces statistiques, Mditelecom
dispose dOPTIMA qui est un outil de gestion des performances du rseau en temps rel. Ce
systme de donnes permet :
La rcolte des donnes multi-fournisseurs. Ces donnes sont disponibles
immdiatement aprs leurs gnration par les diffrents lments du rseau.
Le traitement et le stockage des donnes dans une base de donnes
ORACLE facile interroger par des scripts SQL.
De fournir une reprsentation conviviale des indicateurs de performance.
b) Les actions
Une fois le problme est dtecte lingnieur doptimisation doit effectuer une action pour y
remdier. Cette action dpend bien videment de la severite du problme mais aussi de sa
nature.
a) UpGrade SDCCH
Un upgrade SDCCH est une action software qui consiste augmenter le nombre des canaux
SDCCH. Normalement cette action est la solution un problme de congestion au niveau de
la signalisation, cette congestion peut tre caus par :
o Usage excessif des SMS.
o Cellule sur le bord de la BSC et donc il y aura plusieurs contrles de Location Area
Update.
o Croissance en trafic.
b) UpGrade TCH
Un upgrade TCH est une action hardware qui consiste augmenter le nombre des TRX
accompagn dune autre action software de configuration. Lopration upgrade TCH peut
rsoudre des problmes de coupure dappels ou des problmes de congestion niveau trafic.
Ces diffrents problmes sont gnralement causs par une demande croissante en trafic ou
par une congestion sur les canaux TCH.
c) Les actions physique
Les actions physiques sont des interventions sur terrain qui visent le changement de lun des
paramtres de lantenne :
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
18

o Le type dantenne des stations de base choisi : Le type dantenne est choisi
selon le besoin en matire de couverture. Ainsi le choix repose sur des
caractristiques bien prcise : le gain, louverture 3dB, le type de la diversit,
le type de tiltage quelles supportent et la forme de leurs diagrammes de
rayonnement.
o La hauteur de lantenne : Le rayonnement de lantenne est, en gnral, modifi
par lenvironnement entourant lantenne : murs, btiments, corps,
obstaclesAinsi, il est recommand de dgager lantenne de ces contraintes en
jouant sur sa hauteur. Il est noter que la hauteur de lantenne est toujours
calcule par rapport au niveau du sol.
o Le tiltage de lantenne : Lnergie de lantenne est concentre dans un plan
horizontal partant du point central de lantenne. Cependant, lantenne doit tre
dgage de tout obstacle pouvant nuire la qualit de sa couverture. Pour ceci, il
est, souvent, recommand, dincliner lantenne de quelques degrs vers le bas
afin de limiter la couverture (down tilt). Dans dautres cas, le lobe principal de
lantenne doit tre remont de quelques degrs, afin quelle puisse couvrir des
zones lointaines (up tilt).
d) Actions lies au Handover
Le handover est peru comme une fonction cl dans un rseau GSM puisque cest une
contrainte directement lie la mobilit lune des principales features du GSM. Le tableau
suivant rsume les principaux problmes qui peuvent affecter les performances du handover
et les diverses solutions apportes. Lors de constats dun grand nombre dchec de handover
plusieurs actions sont envisager :
o Rsoudre le problme de la congestion si existe.
o Ajouter les voisins manquants et enlever les relations de voisinages non
ncessaires.
o Corriger la puissance en sortie de la BTS.
Conclusion :
Comme on a vu les indicateurs de performance sont des lments importants dans le mtier
radio et cest de ce point que vient limportance de notre projet. Ce projet quau cours duquel
on a pu raliser une application qui traite ces indicateurs. Or, avant de passer a la ralisation
de lapplication on doit voir la conception et lanalyse des diffrents modules du systme.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
19





















Analyse et conception du
systme




















Chapitre II

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
20


Chapitre 2. Analyse et conception du
systme

Le prsent chapitre est consacr ltude conceptuelle de notre projet. Comme tout plan
dtude nous commencerons par llaboration du cahier de charge ensuite nous allos voir de
prs les exigences du systme et enfin nous passerons la conception par UML.
2.1. Etude de lexistant :
Notre projet de fin dtude sinscrit dans le cadre du dveloppement du service support du
dpartement radio de Mditlecom. Il sagit dautomatiser les procs effectus auparavant par
des outils de bureautique et dutiliser des nouvelles technologies de linformation pour avoir
une solution web qui facilitera le travail de ce service.
On essaiera dans cette partie de prsenter les diffrentes taches du service support et leurs
mthodes de travail actuelles.
2.1.1. Elaboration du Rapport hebdomadaire du service support:
Lune des principales fonctionnalits de ce service est dlaborer un rapport de statistiques
qui rsume dans sa globalit les performances du rseau GSM, les projets radio, lanalyse et
plan daction, et en mme temps assure le suivi des oprations doptimisations.
Le rapport est un document PowerPoint hebdomadaire de 10 15 Mo, comportant
plusieurs lments qui permettent aux directeurs de critiquer lobjectif de la qualit du rseau.
Les paragraphes suivants dcrivent les diffrentes parties du rapport.
a) Ralisations radio de la semaine [n] :
Cette partie donne n rsum des ralisations effectus par le dpartement radio au cours de
la semaine.
Exemple de ralisations :
Traitement des rclamations du service zone sud.
Excution et planification des oprations upgrade/swap.
Changement de paramtre HO dans la rgion X.
b) Etat du rseau :
Cette deuxime partie illustre la situation actuelle du rseau GSM. Elle comporte en gnral
un pourcentage de couverture en population, plus le nombre de BTS intgrs dans tout le
rseau du territoire.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
21
Figure 6 : Evolution annuelle du trafic Air
P.S : Vu la confidentialit des chiffres ces derniers ne figurent pas sur lillustration.
Intgr dans cette partie du rapport, ce graphe montre lvolution moyenne du trafic de la
partie BSS du rseau GSM de Mditel. Il aide comparer le trafic des diffrentes annes, et
par consquent une bonne estimation des plans daction des vnements rencontrs au cours
de lanne.
c) Indicateurs de performence KPI :
La principale partie du rapport des statistiques est la dduction des indicateurs de
performances qui refltent en moyenne la sant du rseau, et permettent dobtenir des donnes
significatives pour un regard critique sur ltat du rseau. Suite lanalyse de ces KPIs, des
oprations doptimisations sont mises en action pour amliorer la qualit du rseau.
Ces indicateurs sont regroups par type sous forme de tableau. Voici la liste des groupements
de ces compteurs quon trouve dans cette partie du document des statistiques :
KPI : Tout le rseau.
KPI : Par Fournisseur.
KPI: Par zone.
KPI: Zone Sud.
KPI : Zone Nord.
KPI : Zone Centre.
Tableau 4 : KPI Golden Area

P.S : Vu la confidentialit des chiffres ces derniers ne figurent pas sur lillustration.
TRAFIC %HALF TCONG TASR DCR SCONG SDROP HSR %utilisation
TRX
GA xxx xxx xxx xxx xxx xxx xxx xxx xxx
NGA xxx xxx xxx xxx xxx xxx xxx xxx xxx
Zone xxx xxx xxx xxx xxx xxx xxx xxx xxx
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
22

d) KPI : Analyse et plan daction
KPI Cumul de lanne N :
Ce point du rapport dbute par une vue macroscopique des principaux indicateurs de
performance savoir trafic, SCONG, SDROP, TCONG et aussi DCR de tout le rseau GSM
de loprateur ( Tableau 5 ). A la base de ce global cumul, on peut comparer ces diffrents
indicateurs de qualit avec celles de lanne prcdente, et mettre en vidence ceux qui sont
hors objectif, ce qui va donner une priorit dexcution de certaines oprations doptimisation.
On trouve pour chaque indicateur sa moyenne et son volution au cours du temps, avec un
rsum de lanalyse faite par le service support, ainsi que les solutions doptimisation
adoptes.
KPI KPI N-1 Objectif rseau N : Wi Wi+1 cart
TRAFIC N N
SCONG X 0.50% X%
SDROP X% 2% X%
TCONG X% 1.3% X%
DCR X% 1.9% X%
Tableau 5 : Cumul KPI de lanne N
P.S : Vu la confidentialit des chiffres ces derniers ne figurent pas sur lillustration.
KPI : hebdomadaire Wn/Wn+1
Cet lment donne la diffrence entre les indicateurs des performances de la semaine(N) et
celles de la semaine(N+1) pour chaque constructeur et pour tout le rseau GSM [Tableau 6].
WN WN+1 KPI
Network
Objectif
Ericsson Siemens Network Ericsson Siemens Network
TRAFIC N n n n n N
SCONG 0.3 X% x% x% x% x% X%
SDROP 0.2% X% x% X% X% X% X%
TCONG 2.3% X% X% X% X% X% X%
DCR 1% X% X% X% X% x% X%
HSR 9% x% X% x% X% x% X%
Tableau 6 : KPI- WN/N+1
P.S : Vu la confidentialit des chiffres ces derniers ne figurent pas sur lillustration.

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
23
e) KPI: SCONG.
On prsente dans cette partie un rapport de lindicateur SCONG de tout le rseau GSM. Elle
comporte un rsum de la situation actuelle des BSCs qui ont eu un problme de SCONG
dans la semaine N-1 avec un suivi des actions mis en oeuvre pour loptimisation.
Elle comporte aussi lanalyse cellulaire des deux constructeurs par une rpartition des cellules
selon SCONG comme lillustr le schmas suivant :







Figure 7 : Rpartition des cellules selon SCONG

P.S : Vu la confidentialit des chiffres ces derniers ne figurent pas sur lillustration.
REMARQUE : Le traitement des autres indicateurs se fait de la mme manire que le
SCONG.
f) Cas critiques
Cet lment contient les diffrentes cellules qui ont eu un problme de disponibilit, et aussi
un suivi par semaine de ltat davancement des diffrentes actions. Le tableau suivant illustre
un exemple de ces cas:
CELL BSC %Dispo Wn %Dispo Wn+1 %Dispo Wn+2 Comment Wn+2
Cell X BSC X 41 42 35 New
Cell Y BSC Y 30 55 76 Rsolu
Tableau 7 : Cas critiques semaine n+2
P.S : Vu la confidentialit des noms ces derniers ne figurent pas sur lillustration.
g) Projet Master Radio :
Cet lment dcrit tous les projets qui sont sous la responsabilit du service support, ainsi que
leurs suivis et leurs plannings dexcution.
Projet Master Radio se constitue essentiellement des nouveaux projets mais aussi de certains
projets dj en cours dlaboration en vue de garantir un bon suivi.
Exemple : Wimax.
Rpartition des cellules selon SCONG
50% 50%
Dans l'objectif Hors Objectif
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
24
2.1.2. Plan dactions :
Un plan daction est un rsum des oprations doptimisation que le service support doit
piloter pour assurer une bonne qualit radio pendant des priodes spciales (par exemple : un
festival). Durant ces priodes, le trafic augmente, et par consquent les sites peuvent
engendrer une congestion importante. Lintrt du plan daction est dliminer le risque dune
mauvaise performance du rseau.
Llaboration des plans dactions par le service support se base sur lhistorique des plans des
annes prcdentes en plus dune analyse des diffrentes moyennes mensuelles des KPIs de
toute lanne. En effet, afin de justifier lajout dune cellule C dans le plan daction dt
2006, il est ncessaire de consulter les plans dt des annes prcdentes pour avoir une ide
sur le comportement de la cellule durant lt, en suite on analyse ces KPIs pour assurer sa
qualit radio.
Aprs la phase de la prparation du document plan daction , le service support suit
lexcution des oprations dcrites. Le rsum du suivi est peut tre demand tout moment
par les chefs de service pour la mise au point des actions planifies.
2.1.3. Suivi des demandes de travaux :
Une demande de travaux est une requte de la part du service zone qui reprsente une solution
doptimisation dans certains cas de problmes dans lune des cellules. Elle contient le type de
lopration effectuer, la date de sa planification, et ses spcificits techniques.
La tache de suivi des travaux est aussi assure par le service support qui doit laborer un
rsum de ltat de toutes ces demandes.
2.1.4. Gestion de stock :
Le service support possde un budget annuel et donc doit grer son stock selon ce que ce
budget lui permet.
Toute action doptimisation a besoin, bien videmment, de matriel (ex : TRX) . Lors dune
intervention ce matriel est rcupr par lentit intervenante auprs du stock mais avec une
autorisation du service support.

Les taches du service support sont actuellement gres laide des fichiers Excel dont la
manipulation est encombrante, ce qui cause le retard du traitement des problmes et donc
diminution de lefficacit du service..
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
25
2.2. Spcification des besoins :
A dfaut de raliser tous les besoins du service support, nous nous sommes intresss
quelques exigences. Ces diffrentes fonctionnalits reprsentent la premire brique du
document de spcification de cet outil. La facilit de la conception et limplmentation de ce
qui reste faire est assure par larchitecture logicielle globale du systme que nous avons
dcrit dans une autre occasion du document.
Nous rsumons la liste des exigences fonctionnelles du systme dans le tableau ci-dessous :
Module Numro de
lexigence
Description
1 Extraire KPI hebdomadaire,
mensuels, annuels dune zone du
rseau.
2 Pour chaque indicateur, il faut
slectionner ces mauvaises
cellules.
KPI
3 Pour chaque cellule, il faut
analyser ses indicateurs.
4 Ajout dune cellule dans un
traitement SCONG ou TCONG.
5 Suivi dune cellule.
Upgrade
SDCCH
&&
TCH
6 Changer ltat dune cellule.
7 Evolution du trafic, SCONG et
TCONG et leur cumul pour
SIEMENS et ERICSSON
8 Extraire pourcentage pour
chaque tat
Rapport
9 Les demandes de travaux
excuts
10 Ajout dune demande de travaux

11 Changer ltat dune demande de
travaux
Demande de
travaux
12 Extraire historique
Tableau 8 : Exigences du systme

2.3. Analyse fonctionnelle
2.3.1. Identification des acteurs du systme
Les utilisateurs de loutil sont caractriss par un profil qui dpend essentiellement de leur
statut et leur rle par rapport une opration doptimisation, ainsi ils sont caractriss par les
proprits suivantes :
Entit : un utilisateur appartient une et une seule entit qui reprsente un service.
[exemple : l ingnieur support est un membre de lentit support].
Disponibilit : chaque utilisateur vis--vis du systme peut tre actif ou non actif.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
26
En outre un utilisateur peut tre associ une ou plusieurs oprations doptimisation. Cette
association est qualifie par lun des deux rles suivants :
Responsable : toute personne du service support est responsable des actions et de leurs
suivis. Autrement dit; le service support est la seule entit qui peut commencer ou
terminer un processus doptimisation dune cellule.
Intervenant : toute personne qui participe dans lexcution dune opration
doptimisation dune cellule.
Ainsi on peut regrouper les intervenants selon le type daction effectuer :
Intervenant Upgrade SDCCH : ce profil regroupe les membres qui interviennent
pour lexcution dune action upgrade SDCCH.
Intervenant Upgrade TCH : ce profil regroupe les personnes qui participent
lexcution dun upgrade TCH.
La Figure 8 reprsente lensemble des utilisateurs de lapplication ainsi que leur hirarchie :
Intervenant
Upgrade SDCCH
Intervenant
Travaux
Intervenant
Activation
Intervenant Swap
ou Extension
User
Intervenant
Upgrade TCH
Intervenant
Upgrade

Figure 8 : Les acteurs du systme
Ces acteurs interviennent tout au long du cycle de loptimisation, chacun selon ses activits :

CORE_BSS Zone Support CER Magasinier ITX PMI Ericsson
Intervenant
Upgrade
SDCCH
+ + +
Intervenant
Upgrade
TCH
+ + + + + + +
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
27
Intervenant
Swap
+ + + + + + + +
Intervenant
Extension
+ + + + + + + +
Intervenant
Activation
+ + +
Intervenant
Travaux
+ + +
Tableau 9 : Les intervenants par action


2.3.2. Langage de modlisation
Aujourdhui, l'Unified Modeling Language (UML) constitue le standard industriel de
modlisation objet. Il reprsente une notation standardise qui facilite la conception des
logiciels, en amont du travail de programmation proprement dit ("codage"). La socit
Rational a coordonn la cration et l'volution du langage, aujourd'hui devenu l'une des
principales mthodes de conception de systmes.
UML se dfinit comme un langage de modlisation graphique et textuel destin comprendre
et dcrire des besoins, spcifier et documenter des systmes, esquisser des architectures
logicielles, concevoir des solutions et communiquer des points de vue. Il unifie la fois les
notations et les concepts orients objet. Il ne sagit pas dune simple notation graphique, car
les concepts transmis par un diagramme ont une smantique prcise et sont porteurs de sens
au mme titre que les mots dun langage.
UML dfinit neuf diagrammes pour reprsenter les diffrents points de vue de la
modlisation. Ils permettent de visualiser et de manipuler les lments de la modlisation.
Pour cette partie, nous avons utilis les diagrammes suivants :
Les diagrammes dactivits : reprsentation du comportement dune opration en
terme daction.
Les diagrammes des cas dutilisation : reprsentation des fonctions du systme du
point de vue de lutilisateur.
Les diagrammes de classes : reprsentation de la structure statique en terme de classes
et de relations.
Aprs cet aperu sur le langage de modlisation UML, nous commencerons la phase
danalyse par une description des diffrents processus dopration doptimisation en utilisant
le diagramme dactivits.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
28
2.3.3. Processus de traitement :
a) Upgrade SCONG
Au cours de ce prsent paragraphe, nous allons dcrire les tapes du processus dun traitement
SCONG pour les cellules qui ont connu une congestion de signalisation. En gnral, ce type
dopration comporte quatre tapes :
Etape 1 : Analyse des statistiques de la semaine (n)
Aprs une visualisation des diffrents indicateurs de performance dune semaine n pour
lensemble des cellules, il faut slectionner celles qui ont un mauvais SCONG.
Selon le rsultat de lanalyse de cet indicateur, lentit support dtermine la liste des cellules
qui vont subir un upgrade SDCCH.
Etape 2 : Cration dun Job Request [JR]:
Une fois les mauvaises cellules sont dfinies, un mail doit tre envoy OMC_R sous une
forme bien spcifique pour donner lordre de changer la configuration actuelle par une
nouvelle afin de diminuer le taux de SCONG dtect.
Etape 3 : Accus de rception :
Lorsque lentit Core_BSS reoit le JR, il excute les scripts de modifications sur les BSCs, et
envoi un accus de rception du JR au demandeur.
Etape 4 : Vrification daction :
La vrification des statistiques vient aprs un ou deux jours du changement des configurations
des cellules concernes. Si on trouve que la congestion de signalisation est rsolue ; on arrte
le processus si non on laisse leurs traitements pour la semaine suivante.


Analyse des
statistiques
Cration JR
Accus de
rception
Vrification de
l'action
Figure 9 : diagramme dactivit dUpgrade SCONG

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
29

b) Traitement TCONG
La phase danalyse des KPIs pour lensemble des cellules permet la slection de celles qui ont
un mauvais indicateur TCONG [indicateur TCONG est suprieur au seuil]. Les actions de
traitement de ce problme se rsument en quatre grandes oprations : Upgrade, Swap,
Extension, Activation.
Ainsi, Dans ce paragraphe nous dcrivons les diffrents processus pour chacune des taches :
1- Action Upgrade TCH normal:
Dans cette action, lentit support envoie une demande (mail) lentit transmission ITX, ou
il spcifie les diffrentes cellules congestionnes avec leurs anciennes et nouvelles
configurations [exemple : cellule X 1/1/1 1/2/2].
ITX valide ces nouvelles configurations pour continuer lexcution du processus, si non,
laction dupgrade est mise en attente.
Aprs la validation de ITX, lentit support demande le matriel auprs du magasinier
[ensemble de cartes TRX par exemple] .En cas de rupture de stock, laction sarrte jusqu' la
disponibilit du matriel.
Et lorsque la rponse du magasinier est positive, il contacte CTM pour rcuprer le matriel et
le transporter au CER qui se charge de linstallation physique des sites.
Lentit CER confirme larrive du matriel en spcifiant la date darrive et la date de
planification dinstallation.
Lentit support envoie une demande des donnes radio lentit Zone, qui se charge de la
planification radio. Suite sa rponse, lentit support cre un JR pour garantir la
coordination entre lentit CORE_BSS et CER, qui valident le JR.
Lentit support teste le trafic des cellules concernes pour confirmer la fin du processus de
lopration dupgrade. Dans le cas o elle dtecte un problme, il le mentionne CORE_BSS
et CER pour le vrifier.








Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
30
Prparation des
KPIs
Ajout des cellules
mauvais TCONG
Ajout des cellules qui vont
subir d'un Upgrade
Support envoi d'une
demande ITX
Support envoie demande au
magasinier
Contacter CTM pour
transporter matril
CER met au courant Support de l'arrive du matriel
&& planification de l'installation.
Support envoie la zone une
demande des donnes radio
Support cre et
envoie un JR
Support teste lecomportement des
cellules traites.
Fin de l'action
Upgrade
Action upgrade
temporise
Action upgrade
temporise
Action upgrade
temporise
Action upgrade
temporise
Support informe CER et CORE_BSS pour la
rsolution du problme.
ITX a rpondu
Oui
Non
Oui
Oui
Oui
Oui
Oui
Non
Non
Non
Non
Non
magasinier a
rpondu
matril est
arriv
donnes recues
JR valid
dtction de pb
Figure : diagramme d'activit d'Upgrade Normale

Figure 10 : diagramme dactivit dupgrade TCH
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
31
2- Action Swap / Extension :

Cette action consiste de changer compltement la station de base. Elle est envisage
lorsquon veut effectuer un upgrade pour un site et que sa configuration actuelle ne supporte
aucune extension. Pour Extension, Elle reprsente lajout dun RBR (bloc contenant des
TRXs) au site pour augmenter le nombre de TRXs sans changer la station de base.
Pour cela, lentit support demande du matriel au magasinier qui rpond la requte selon
ltat du stock.
Dans le cas ou le stock peut satisfaire le besoin, lingnieur support envoie une demande
lentit PMI qui se charge de linstallation physique des sites dans ce type daction. De son
cot, le responsable du PMI contacte le sous-traitant pour lexcution de lopration.
Lentit support a besoin des informations radio [frquence planifie par exemple] qui vont
servir la configuration logique du site. Pour les avoir, il fait une demande lentit Zone.
Une fois, lingnieur support reoit la rponse, il la transmet au PMI qui la retransmettra son
tour soit lentit CORE_BSS qui se charge du mise jour des BSCs dans le cas dune
cellule traite par Siemens, soit aux responsables de Ericsson qui soccupe eux-mmes de
linstallation des nouveaux sites et de leurs configurations.
Une fois laction Swap est termine, lentit PMI alerte le responsable support, qui doit tester
lefficacit de lopration et dinformer PMI sil y a un problme.














Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
32
P reparat i on
des KP Is
A j out de c el l ul es
mau vai s TCO NG
Aj out des c el l ul es qui vont
s ubi r Swap ou ex t ens io n
S upport envoi
deman de au I TX
S upport envoi une
demande au magas i ni er
Ac t i on
t empori s e
Envoi d'une
demande au P MI
S ous -t rai t ant
pl ani fi e ac t i on
Fi n de
l 'ac t i on
JR c re et envoy
pour ac t i on
Ac t i on
t emp ori s e
t rans mi s s i on
as s ure
S t oc k s uffi s ant
A c t i on
t em poris e
A c t i on
t em poris e
S ous -t rai t ant
pl ani fi e ac t i on
JR val i de
A c t i on
t empori s e
Sup port t est e l e
c ompo rt emen t des
s it es
Ac t i on
t empori s e
Support aj out e l e s i t e c eux qui
s ont s ous obs ervat i on
S upport i nforme P MI qu'i l y
a de s pr obl mes
S upport envoi e une demande
de donnes l a z one
S upport t rans mi t l es
donnes au P MI
Ret rans mi s s i on des
donnes au CORE _BS S
Ret rans mi s s i on de s
donnes E ri c s s on
Ty pe c el l ul e
t rai t e
S upport
re c oi t l es
donnes



Figure 11 : diagramme dactivit dune action Swap/Extension
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
33
3 - Action Activation :
Dans certain cas dupgrade, le nombre de TRX activ dune station de base est infrieur ce
quelle peut supporter, donc il faut juste activ le fonctionnement du reste pour rsoudre le
problme de congestion du trafic.
Cette opration est assure par lentit CORE_BSS aprs une demande de la part dun
ingnieur support accompagne des informations radio qui vont servir au responsable du
CORE_BSS accomplir sa tache convenablement.
Une fois laction est excute, le CORE_BSS informe lentit support pour vrifier le trafic
du site. Dans le cas dun problme dtect, lingnieur support avise lentit CORE_BSS pour
le rsoudre.



Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
34
Prparation
des KPIs
Ajout des cellules
mauvais TCONG
Ajout des cellules qui
vont subir une activati on
Support envoie une demande
des donnes radio
Support cre et envoie un
JR au CORE_BSS
Support reoi t
lesdonnes
Support teste le trafic
aprs activation
JR valid
Fin de l'action
Activation
La cellule est ajoute
lorsqu'elle dpasse un
seuil de TCONG
Support a besoin des
donnes radio pour l a
configuration
Aprs la rcepti on
des donnes, JR
est cre.
Activation d'upgead
t emporise
Activation d'upgead
temporise
Support dtect e un
probl me
Activation d'upgead
temporise






Figure 12 : diagramme dactivit dune action Activation
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
35
2.4. Conception du systme
2.4.1. Module KPI :
Tout utilisateur du systme peut visualiser et analyser les indicateurs de performances du
rseau pour une semaine n ou pour un mois. A la base de lvolution dun indicateur,
lutilisateur peut juger que la cellule est congestionne ou seulement a connu un simple peak.
Authentification
Extraire KPIs mensuels
include
Extraire KPIs hebdomadaires
include
Analyser KPI d'une cellule
include
include
User

Figure 13 : Use case du module KPI

Use Case Extraire KPIs mensuels :
Lutilisateur sauthentifie par un login et un mot de passe.
Lutilisateur choisit le mois traiter.
Lutilisateur demande la visualisation des KPIs pour le mois spcifi. [La vue est
limite par un certain nombre de lignes par pages pour faciliter lanalyse].
Lutilisateur peut slectionner les cellules les plus congestionnes dans le rseau
pendant le mois choisi.
Use Case Extraire KPIs hebdomadaires :
Lutilisateur sauthentifie par un login et un mot de passe.
Lutilisateur choisit la semaine traite et un certain nombre de cellules ou tout le
rseau laide dun filtre qui contient le numro de la semaine, location, technologie,
numro BSC.
Lutilisateur demande la visualisation des KPIs pour la configuration dtermine.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
36
Lutilisateur peut slectionner les mauvaises cellules dans le rseau pour la semaine
spcifie dans le filtre.
Use Case Analyser KPI dune cellule:
Lutilisateur sauthentifie par un login et un mot de passe.
Lutiliser choisit la cellule et lindicateur analyser.
Lutilisateur demande lvolution de ce KPI de la cellule spcifie pendant 3 mois.
Diagramme de classe du module KPI :
Cell
name
BSC
Location
Zone
classe
Technology
ErlangB
TCH
TRX
TWO
ONE
HALF
AvgWeekly
week
TCONG_N
TASR_N
DCR_N
SCONG_N
SDROP_N
HSR_N
TONG_D
TASR_D
DCR_D
SONG_D
SDROP_D
HSR_D
TRAFIC_FULL
TRAFIC_HALF
Disponibility
1 1 1 1 1
1..*
1
1..*

Figure 13 : Diagramme de classe du module KPI

2.4.2. Module Upgrade SCONG :
Aprs une slection des cellules qui ont un mauvais SCONG, lingnieur support est amen
faire lanalyse de ces cellules, qui consiste dcouvrir lvolution de cet indicateur pendant
une longue dure. En fonction de cette volution, il peut dcider si une cellule doit subir un
upgrade SDCCH ou non.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
37
Intervenant
Upgrade SDCCH
Changer l'tat d'une cellule
Visualiser historique des tats
d'une cellule
Analyse SCONG de toutes les
cellules
Mise jour liste mauvais SCONG
include
include
Support

Figure 14 : Use case du module upgrade SCONG
Use Case Mise jour liste mauvais SCONG
Lingnieur support sauthentifie par un login et un mot de passe.
Lingnieur support slectionne les cellules qui ont un SCONG hors objectif en se
basant sur les KPIs hebdomadaires.
Lingnieur support analyse cet indicateur partir de son volution.
Selon lanalyse, lingnieur support peut ajouter une cellule la liste des mauvaises
qui vont subir un upgrade SDCCH.
Use Case Changer ltat dune cellule :
Lintervenant Upgrade SDCCH sauthentifie par un login et un mot de passe.
Lintervenant Upgrade SDCCH choisie la cellule parmi celles qui sont incluses dans
un processus upgrade SDCCH.
Lintervenant Upgrade SDCCH modifie ltat courant de la cellule par un autre avec
un commentaire justifiant le choix.
Lingnieur support peut aussi changer ltat dune cellule avec la slection de son Job
Request et son objectif.
Lingnieur support est parmi les membres des participants dans ce type dupgrade, et
lui le seul qui a le droit de terminer le processus dune cellule.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
38
Use Case Suivi dun Upgrade SDCCH.
Lintervenant Upgrade SDCCH sauthentifie par un login et un mot de passe.
Lintervenant Upgrade SDCCH choisie la cellule parmi celles qui sont incluses dans
un processus upgrade SDCCH.
Lintervenant Upgrade SDCCH demande lhistorique des diffrents tats de la cellule
slectionne tri par date de modification dtat.
Diagramme de classe du module Upgrade SDCCH.
Entite
name
departement
direction
CellStateTCH
state
desription
action
JobRequest
name
date_entree
state
type
Cell
name
BSC
Location
Zone
classe
Technology
Objectif
name
description
date
User
nom
prenom
login
pass
tel
1..*
1
1..*
1
CellStateHistorySDCCH
date_entree
description
0..*
1
0..*
1
0..* 1 0..* 1
0..*
1
0..*
1
0..*
1
0..*
1
1
0..*
1
0..*

Figure 14 : Diagramme de classe du module Upgrade SDCCH.
2.4.3. Module Upgrade TCONG:
Lingnieur support analyse lindicateur de TCONG lors dune dtection dune congestion de
trafic.A la base de cette analyse, les cellules congestionnes peut subir dun upgrade TCH.
Use Case Mise jour de la liste mauvais TCONG
Lingnieur support sauthentifie par un login et un mot de passe.
A la base des KPIs hebdomadaires gnrs dans le module KPI, Lingnieur support
peut slectionner les cellules qui ont un mauvais TCONG.
Lingnieur support analyse cet indicateur partir de son volution durant une dure
de 3 4 mois.
En fonction du rsultat de lanalyse, lingnieur support peut juger quune cellule doit
subir dun upgrade TCH.
Use Case Ajouter cellule dans liste dune action
Lingnieur support sauthentifie par un login et un mot de passe.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
39
Pour chaque cellule de la liste qui subit un upgrade TCH, Lingnieur support doit
dcider quel est le type dupgrade choisir, en se basant sur init config, target config,
le type de la station de base.
Use Case Changer ltat dune cellule :
Lintervenant Upgrade TCH sauthentifie par un login et un mot de passe.
Lintervenant Upgrade TCH choisit la cellule parmi celles qui sont incluses dans un
processus upgrade TCH.
Lintervenant Upgrade TCH modifie ltat courant de la cellule par un autre avec un
commentaire justifiant le choix.
Lingnieur support peut aussi changer ltat dune cellule avec la slection de son Job
Request et son objectif.
Lingnieur support est parmi les membres des participants dans ce type dupgrade, et
lui le seul qui a le droit de terminer le processus dune cellule.
Use Case Suivi dun Upgrade TCH.
Lintervenant Upgrade TCH sauthentifie par un login et un mot de passe.
Lintervenant Upgrade TCH choisie la cellule parmi celles qui sont incluses dans un
processus upgrade TCH.
Lintervenant Upgrade TCH demande lhistorique des diffrents tats de la cellule
slectionne tri par date de modification dtat.
Lintervenant Upgrade TCH trie la liste de lhistorique par tat, user pour avoir.

Diagramme de classe du module Upgrade TCONG :

JobRequest
name
date_entree
state
type
Cell
name
BSC
Location
Zone
classe
Technology
Objectif
name
description
date
User
nom
prenom
login
pass
tel
CellStateHistoryTCH
date_entree
description
initConfig
targetConfig
0..* 1 0..* 1
0..*
1
0..*
1
0..*
1
0..*
1
1
0..*
1
0..*
Entite
name
departement
direction
1..* 1 1..* 1
CellStateTCH
state
desription
action
0..*
1
0..*
1
0..*
1
0..*
1
Figure 14 : Diagramme de classe du module Upgrade TCONG
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
40
2.4.4. Module Rapport:
Les chefs du service support demande tout moment des rapports rsumant ltat du rseau
plus des graphes qui montrent en moyenne le nombre des demandes que chaque entit na pas
pu y rpondre. Le rsultat de ce module peut nous donner une ide sur les causes du retard de
lexcution de certaines oprations doptimisation.
Cumul KPIs
Evolution KPI
Rpartition KPI
Rpartition DT
Support

Figure 15 : use case du module rapport
Use Case Cumul KPIs:
Lutilisateur sauthentifie par un login et un mot de passe.
Lutilisateur demande le cumul des KPIs [TRAFIC, SCONG, SDROP, TCONG,
HSR] de tout le rseau pour lanne courante et pour lanne prcdente.
Lutilisateur demande un rsum du KPI pour chacun de ces indicateurs du cot
SIEMENS et ERICSSON.
Use Case Evolution KPI:
Lutilisateur sauthentifie par un login et un mot de passe.
Lutilisateur demande lvolution du trafic
Lutilisateur demande lvolution de chacun des KPIs pour les deux constructeurs et
lvolution du taux global.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
41
Lutilisateur demande lvolution du cumul de chacun des KPIs pour les deux
constructeurs et lvolution cumul global.
Use Case Rpartition KPI :
Lutilisateur sauthentifie par un login et un mot de passe.
Lutilisateur demande un hors objectif
Lutilisateur demande une rpartition par tat des diffrents cas mis en processus
dupgrade SDCCH et aussi TCH.
2.4.5. Module demande de travaux:
Lingnieur radio dcide dans certains problmes, dffectuer des actions (Travaux) sur les
sites sans faire un upgrade. Il demande les travaux au service support qui se charge de suivi de
lopration.
Il y a quatre grands types des demandes de travaux :
Action sur antenne : cette action est purement hardware et peut tre un changement
de type dantenne, dazimut, de position, dhauteur, de support ou/et de tilt.
Ajout de secteur
Swap.
Dsintgration : surtout pour les micros.
R allocation du site.
S'authentifier
Ajouter Demande de travaux
include
Changer l'tat d'une demande
include
Afficher les demandes en cours
include
include
Historique des demandes de
travaux
Intervenant Demande
de Travaux
include
Figure 16 : Use case demande travaux
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
42
Use Case Ajout de demande de travaux :
Lintervenant travaux de travaux sauthentifie par un login et un mot de passe.
Il saisit par la suite les diffrentes informations concernant une demande de travaux
savoir le cot et les dlais dexcution.
Il valide les donnes.
Use Case Consulter les demandes de travaux en cours et changer leur tat :
Lintervenant demande de travaux sauthentifie par un login et un mot de passe.
il passe par la suite une page ou il pourra visualiser lhistorique des demandes de
travaux en cours dexcution.
Use Case Consulter lhistorique des demandes de travaux excutes :
Lintervenant demande de travaux sauthentifie par un login et un mot de passe.
Par la suite il pourra avoir lhistorique de toutes les demandes de travaux de lanne en
cours qui sont excut
Diagramme de classe du module demande de travaux :

Entite
name
departement
direction
User
nom
prenom
login
pass
tel
1..*
1
1..*
1
Demande_travaux
type
comment
dtetat
dt
name
desc
Cell
name
BSC
Location
Zone
classe
Technology
dt_history
date_ent
date_exe
comment
cout
1
0..*
1
0..*
1
0..*
1
0..*
0..*
1
0..*
1
0..*
1
0..*
1
Objectif
name
description
date
1
0..*
1
0..*

Figure 17 : Diagramme de classe du module demande de travaux


2.5. Matrice de correspondances cas dutilisation/exigences
La matrice de correspondance cas dutilisation/exigence permet de mapper les cas
dutilisation aux besoins fonctionnels quils reprsentent. Cette matrice de correspondance
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
43
permet dune part, de vrifier que tous les besoins fonctionnels sont pris en compte dans les
cas dutilisation et permet dautre part de faciliter la modification des cas dutilisation.
Pour construire la matrice, nous avons utilis un tableau qui contient lensemble des besoins
identifis partir du cahier des charges et un autre tableau qui contient lensemble des cas
dutilisation que nous avons dgag. La matrice contient deux colonnes, qui associent les
identifiants des besoins [Tableau 8] ceux des cas dutilisation correspondants.
A lensemble des besoins, correspond la liste suivante (Tableau) des cas dutilisation que nous
avons dgags :
Numro du use case Nom du Use Case
1 Extraire KPIs mensuels
2 Extraire KPIs hebdomadaires
3 Analyser KPI dune cellule
4 Mise jour liste mauvais SCONG
5 Changer ltat dune cellule
6 Suivi dun Upgrade SDCCH
7 Mise jour de la liste mauvais TCONG
8 Ajouter cellule dans liste dune action
9 Suivi dun Upgrade TCH
10 Cumul KPIs
11 Evolution KPI
12 Rpartition KPI
13

Ajout de demande de travaux
14 Changer ltat des cellules noires
15 Consulter les demandes excutes
Tableau 10 : Liste des cas dutilisation
La correspondance entre les deux tableaux et donc entre les cas dutilisation et les besoins se
trouve dans la matrice du Tableau suivant :
Exigence Use Case
1 1,2
2 4,7
3 3
4 4, 7,8
5 6,9
6 5
7 10,11
8 12
Tableau 11 : Matrice de correspondance exigence/cas dutilisation
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
44

Co Co Co Conclusion nclusion nclusion nclusion
A partir du besoin du Dpartement Planification Radio, on a pu la fin de ce chapitre dresser
larchitecture gnrale de notre systme qui fait appel la programmation, la gestion de la
base de donne, et la ralisation des interfaces homme machine.

















Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
45











Mise en uvre du systme



Chapitre III

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
46

Chapitre 3. Mise en uvre du systme


Nous avons consacr ce troisime chapitre la partie technique du projet, dans laquelle nous
prsenterons notre proposition de larchitecture du systme.
Par la suite, nous dcrivons lenvironnement du dveloppement et quelques crans
dutilisation de lapplication.
3.1. Conception architecturale du systme
Llaboration dune application nest gnralement pas une mince affaire. En effet, de
nombreux composants doivent tres utiliss et linterconnexion entre ces composants est trs
souvent difficile mettre en place.
Le dveloppement dune application doit toujours prendre en compte les futures volutions
probables (changement de base de donnes, changement de la logique mtier). Ainsi, pour
faciliter lvolution dune application, il est convenable dutiliser des composants gnriques
sous forme dune architecture modulaire.
Dans ce contexte, nous avons propos une solution architecturale du systme, base sur la
plate-forme J2EE qui rpond aux spcifications fonctionnelles prsentes dans le chapitre
prcdant.
3.1.1. Plate-forme J2EE:
Avant de prsenter la structure de larchitecture du systme, nous commenons par une
description des bases de la plate-forme J2EE qui comporte sa technologie et son architecture.
a) Architecture multi tiers :
Malgr les avantages quoffre larchitecture Client/Serveur, elle pose beaucoup de
problmes :
Il doit y avoir un dploiement des applications du ct client.
Il y a une lourdeur des applications clientes, car une part des traitements est excute
au ct client.
Le concept de larchitecture multi-tiers est apparu pour remdier ces problmes et aux
problmes de la maintenance et de la rutilisation dune application. Les applications bases
sur ce type darchitecture sont divises en plusieurs niveaux logiques, chacun deux comporte
un ensemble dinterfaces bien dfini, savoir la couche client, la couche mtier et la couche
daccs aux donnes.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
47
La couche client, dite couche prsentation, reprsente linterface client qui permet de faire
appel aux services offerts par la couche mtier. Une fois les traitements sont raliss par la
couche mtier, le rsultat sera ensuite envoyer la couche prsentation afin dafficher les
rsultats.
La sparation de la logique applicative de linterface utilisateur accentue considrablement la
souplesse de conception dune application. En effet, il est dsormais possible de crer et de
diffuser plusieurs interfaces utilisateurs sans modifier la logique applicative.
Enfin, le troisime niveau contient les donnes ncessaires lapplication. Il peut sagir de
toute source de donnes prsente sous nimporte quelle forme : base de donnes
relationnelle, ensemble de documents XML ou autres.
La figure suivante illustre les trois niveaux dcrits ci-dessus.

Figure 18 : Architecture Multi Tiers
b) Technologie J2EE
La technologie Java 2 Entreprise Edition (J2EE) dfinit la norme de dveloppement des
applications dentreprise distribues et multi tiers. Elle permet de simplifier les applications
d'entreprise en les basant sur des composants modulaires normaliss, tout en fournissant un
ensemble complet de services et en grant automatiquement un grand nombre de dtails sur
le comportement des applications.
Elle est compose de plusieurs technologies qui sont regroupes en trois catgories :
composant, service et communication.
Technologie de type composant
Les technologies de type composant sont utilises pour crer des composants logiciels dune
application notamment linterface utilisateur et la logique mtier. Elles permettent de
dvelopper des modules rutilisables qui peuvent tre intgrs dans dautres applications.
Technologie de type service
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
48
Etant donn que la plupart des applications ont besoin daccder aux systmes dinformation
dentreprise, la plate-forme J2EE offre un ensemble de services tels que laccs aux bases de
donnes (JDBC) et le service nommage (JNDI).
Technologie de type communication
La plate-forme J2EE fournit un ensemble de technologies permettant la communication entre
clients et serveurs, et entre les objets qui collaborent dans les diffrents serveurs, telles que les
connecteurs aux systmes dinformation existants et linvocation des mthodes distantes
travers RMI.
c) Architecture J2EE :
Cest une architecture promue par SUN MICROSYSTEMS qui dfinit et fournit un modle
de programmation multi niveaux bas sur des composants framework.
Avec ce modle, des applications lgres peuvent interagir facilement avec le systme
d'information et les composants, quant eux, implmentent la logique sur des serveurs
d'applications.
Larchitecture J2EE consiste en trois parties :
Components : les composants prenant en charge la prsentation et la logique mtier.
Containers : fournit un contexte aux composants.
Connectors : fournit laccs aux sources de donnes de lentreprise.
3.1.2. Conception architecturale du systme :
Aprs cet aperu sur larchitecture J2EE, nous prsentons dans ce paragraphe les diffrents
niveaux de lapplication que nous avons adopts pour limplmentation du systme.
Notre solution architecturale du systme est compose de 5 niveaux dont nous dtaillerons
par la suite
.














Couche prsentation
(Interface entre user et application)
Framework Struts
Couche physique
(Base de donnes relationnelle)
SGBD MySQL
Couche services
(Implmentation des scnarios de traitement)

Beans + Packages
Couche Mapping
(Description
Couche DAO
(Description des
Framework Hibernate
Figure 19 : Architecture applicative du systme

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
49


Couche prsentation
La couche prsentation reprsente linterface entre lutilisateur et le systme. Elle se charge
principalement de la restitution des donnes lutilisateur, et de la traduction de ses actions en
vnements mtier avec un feedback de la russite ou de lchec des oprations dclenches.
Couche services
Cette couche contient les services offerts par le systme aux utilisateurs. Elle reprsente
limplmentation des scnarios dcrits dans les spcifications fonctionnelles du systme. Elle
fait appel, dans sa prise en charge de la logique mtier, la couche lui fournissant le service
daccs et de manipulations de donnes DAO.
Couche DAO [data access object]
La couche daccs aux donnes fournit un service de manipulation des entits de la couche
physique, elle doit prendre en charge toutes les interactions entre lapplication et la base de
donnes. Si une telle couche nexistait pas, on serait obligs de rcrire les mmes lignes de
code diffrents endroits de lapplication.
Aussi cette couche est labore dans le but de faire abstraction de la couche mapping
Objet/Relationnel, elle est donc la seule contenir du code appelant les classes figurant dans
les bibliothques du mapping. De cette faon lorsquon aura changer le contenu de la
couche de mapping, on aura qu redfinir les mthodes permettant les diffrentes oprations
de consultation et de manipulation des donnes selon les fonctionnalits offertes par la couche
mapping.
Couche mapping
La couche de mapping contient les classes mappes sur les tables existant matrialisant le
modle relationnel ceci dans le but dadopter une approche objet dans laccs et la
manipulation de donnes stockes dans une base de donnes relationnelle. Une telle approche
pargnerait dans la phase du dveloppement de tout code SQL, et mettra la disposition de
son utilisateur tous les atouts du monde objet tout en manipulant une base de donnes
relationnelle.
Couche physique
Cette couche comporte le schma de la base de donnes du systme. Elle peut utiliser lun
des systme de gestion de base de donnes pour sa reprsentation physique par exemple :
MySQL ou Oracle.


Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
50
3.1.3. Solution en framework du systme :
a) Framework de la couche web :
Pour cette couche, nous avons utilis le framework struts pour son implmentation grce
ses avantages que nous citerons par la suite. Mais de lister ces avantages, nous prsenterons
le design pattern MVC2 qui est la base du framework struts.
Design Pattern MVC2
Un Design Pattern donne un nom, isole et identifie les principes fondamentaux d'une structure
gnrale, pour en faire un moyen utile l'laboration d'une conception oriente objet
rutilisable. Ce type de Patterns, galement appels Patterns de conception orients objet, sont
les Patterns les plus utiliss.
Trois catgories des Design Patterns sont dfinies: les patterns de cration, les patterns
structuraux et les patterns de comportement.
Le modle MVC est un type de Design Patterns de la catgorie Patterns structuraux . Il est
simple mais en mme temps trs utile, il permet essentiellement de concevoir une application
en utilisant les trois niveaux suivants :
MODEL : cest le noyau de lapplication. Il maintient ltat et les donnes que
lapplication reprsente. Quand des changements significatifs apparatront dans le
modle, les vues aussi seront changes
CONTROLLER : il dfinit le comportement de lapplication et gre linteraction avec
lutilisateur. Il fait appel au modle des composants pour rpondre aux requtes de
lutilisateur
VIEW : linterface utilisateur qui est la reprsentation visuelle du modle .










Figure 20 : architecture MVC

NAVIGATEUR
BD,
fichiers
Servlet
Classes
Mtiers
Application Web

Vue
Contr

Modle
JSPs
Servlet
JSPs
Servlet
JSPs
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
51
Cette architecture qui spare le contrle des actions utilisateurs, la couche mtier et la couche
de prsentation favorise le dveloppement et la maintenance d'une application. Malgr cet
apport, il prsente un inconvnient majeur : la multiplication des points d'entre (pages JSP et
servlet) dans l'application. La mise en place de services comme la scurit,
l'internationalisation, ou la personnalisation devient alors complexe avec cette architecture.
Le modle MVC 2 propose de palier cet inconvnient en utilisant un seul point dentre
pour chaque application. Ainsi, une application contient un seul contrleur frontal sous la
forme d'un servlet d'entre unique. Le modle ci dessus devient ainsi comme suit :












Figure 21 : architecture MVC2

C'est sur ce modle que plusieurs Frameworks sont conus afin d'aider les dveloppeurs
construire la couche de prsentation de leurs applications web. Dans la communaut java,
c'est le projet Jakarta Struts qui fait rfrence
Prsentation du framework struts : Struts est un Framework MVC2 utilis pour
dvelopper des applications WEB. Il sagit donc dun squelette dapplication sappuyant sur
le modle vue contrleur et fournissant des outils supplmentaires pour aider le dveloppeur
raliser ses applications. On distingue donc un contrleur principal qui aiguille les requtes
reues du client vers des sous contrleurs qui vont alors effectuer le traitement correspondant.
Les trois composants de Struts sont :
- Le modle : Struts ne fournit aucune implmentation pour le modle. Le
dveloppeur doit donc dfinir lui-mme le(s) modle(s). En revanche, cela permet
dappliquer la couche Struts nimporte quel projet dj existant.
NAVIGATEUR
BD,
fichiers
Servlet
Frontal
unique
Classes
Mtiers
Application Web

Vue
Contrleur

Modle
JSPs
JSPs
JSPs
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
52
- Les vues : dans Struts, ce sont principalement des pages JSP. Pour cela, Struts
fournit plusieurs bibliothques de taglibs permettant de raliser les pages JSP
rapidement.
- Le contrleur : Struts implmente un contrleur principal (reprsent par la classe
ActionServlet) et des sous contrleurs (correspondant aux classes Action).
Le schma ci-dessous reprsente la structure de Struts et son fonctionnement.
Figure 22 : structure du framework Struts
On retrouve sur ce schma les lments principaux de Struts, savoir :
- ActionServlet : cest le contrleur principal. Il joue le rle de servlet et reoit donc les
requtes du client quil renvoie ensuite vers les sous contrleurs.
- Action : il sagit des sous contrleurs. Ils effectuent le traitement correspondant une
requte prcise.
- ActionForm : ce sont des containers pour les pages JSP. Ils peuvent tre utiliss par
les Action lors du traitement.
- Le fichier de configuration Struts-config.xml : Cest le composant principal de
struts puisquil permet de faire le lien entre tous les composants prcdents.
Cycle de vie dune opration :
Sur le schma ci dessus, le client envoie une requte lActionServlet.
Grce au fichier de configuration Struts-config.xml, lActionServlet aiguille la
requte vers lAction approprie.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
53
LAction ralise alors le traitement adquat. Si besoin, cette Action utilise les
ActionForm ncessaires et effectue les oprations utiles sur le modle.
Laction renvoie ensuite le rsultat du traitement (russite, chec).
A partir de cette valeur, lActionForm est alors capable de dterminer le rsultat
renvoyer au client (redirection vers une autre page JSP).
Le Framework Struts permet un apport concret pour la structuration des dveloppements des
applications web. Le dcoupage suivant le pattern MVC2 de la couche prsentation permet de
mieux grer la logique de dialogue avec l'utilisateur. Le dveloppement est mieux cadr et
finalement plus efficace car :
- comme dans l'utilisation de tout Framework objet correctement ralis, le code est plus
homogne.
- dvelopper correctement la couche de prsentation d'une application web avec Struts
demande moins de comptences;
- le travail des dveloppeurs expriments en charge de la logique mtier de l'application est
compltement indpendant.

Le choix de struts :

Le tableau suivant rsume une comparaison entre plusieurs frameworks MVC2 :


FRAMWORK

VERSION

URL

PUISSANCE

COMPLEXITE
Barracuda PR2 http://barracuda.enhydra.org/ +++ +++
Hammock 1.0 http://www.oop.com/TechnologiesHammock.jsp +++ +++
Tapestry 0.2.9 http://sourceforge.net/projects/tapestry ++ +++
Webwork 0.95 http://sourceforge.net/projects/webwork/ + +
Struts 1.1 http://jakarta.apache.org/struts +++ ++
Tableau 11 : Comparaison de quelques frameworks en terme de puissance et de complexit

Ainsi, latout principal qui fait la force de Struts est la complexit rduite par rapport aux
autres Frameworks de mme degr de puissance.
Le manque d'expertise technique sur les technologies web de Java n'est plus un frein pour
aboutir une application robuste, volutive et maintenable : on peut utiliser Struts pour la
couche de prsentation avec un niveau d'expertise minime
b) Framework de la couche persistance :
La persistance objet
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
54
Dans le modle relationnel, les donnes sont persistantes : une fois que la structure du schma
relationnel a t dfinie, les donnes qui y sont ajoutes restent accessibles durablement, tant
quelles ne sont pas explicitement supprimes. La dure de vie des donnes est donc
totalement indpendante du cycle de vie des sessions applicatives qui les manipulent.
Pour apporter ce caractre de durabilit des donnes au modle objet, il convient donc de
trouver un moyen de prolonger lexistence des objets au-del de lexistence dune session
applicative. Pour dsigner cette capacit des objets survivre en dehors du contexte
dexcution applicatif, on parle de persistance objet.
La problmatique de la persistance objet consiste donc laborer et mettre en uvre les
mcanismes permettant de sauvegarder de faon fiable et durable ltat des objets manipuls
par une application.
Techniquement, il existe plusieurs approches pour implmenter la persistance objet. La plus
adopte est le mapping objet/relationnel. Cette technique vise dfinir et utiliser un schma
en base de donnes relationnelle pour assurer la persistance de ltat des objets. Elle consiste
dfinir prcisment la structure dune ou plusieurs tables qui seront utilises pour sauvegarder
les diffrents attributs dun objet.
Il est galement ncessaire dimplmenter la logique de persistance qui va permettre aux
applications deffectuer la sauvegarde et la restauration de ltat des objets manipuls. Cest le
rle de la couche de persistance (ou moteur de persistance). Le moteur de persistance expose
une API aux applications pour la cration, la mise jour, et la recherche dobjets sur le
support de persistance. A ce niveau, il est convenable dassocier un outil de projection des
objets sur le support de persistance : le rle de cet outil est de fournir le moyen de dfinir les
rgles de transformation entre la reprsentation des objets en mmoire et la reprsentation de
ces objets sur le support de persistance, avec la cration des structures de donnes ncessaires.
La persistance objet est donc une problmatique trs complexe, qui ncessite la mise en
uvre doutils spcifiques et sophistiqus.
Parmi ces outils, on trouve hibernate qui reprsente la solution la plus mature sur le march.
Prsentation du Hibernate :
Hibernate est un framework qui assure les fonctionnalits de la couche persistance savoir
linterface avec la couche service et le mapping objet/relationnel. IL est un projet
professionnel, open source faisant partie de la suite de produits de JEMS (JBoss Entreprise
Middleware System).
Voici comment se prsente globalement larchitecture dHibernate :

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
55














Figure 23 : Architecture dHibernate
La configuration de Hibernate est assez facile, il contient deux types de fichiers drivs xml
savoir Hibernate.cfg.xml qui reprsente le fichier de configuration contenant les droits daccs
(le nom du user et le mot de passe), l url de la base de donnes, le driver utilis, et lensemble
des ressources mappes. Le fichier ci-dessous est une illustration du relat.

Figure 24 : structure du fichier hibernate.cfg.xml
Le deuxime fichier est une reprsentation xml des attributs dune table dj choisi de la base
de donnes. On met laccent sur le fait que Hibernate fait le mapping aussi au niveau des type
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
56
de valeur (exemple Varchar devient String, Blob devient un tableau de byte). Voici un
exemple de fichier hbm quon a cre.


Figure 25 : structure interne du fichier reprsentant une table
Une panoplie de classes est disponible lors de limplantation de ce framework permettant un
accs facile et organis via des transactions.
Ce type d'outil optimise le temps de dveloppement du programmeur et permet de raliser des
applications plus homognes, plus facilement migrables aussi (il suffit juste de toucher
hibernate.cfg.xml).
Le framework est trs puissant et finalement peu complexe grce ses plug-ins. Hibernate est
capable de grer finement les jointures entre les tables, la gnration des cls primaires, la
conversion de types. De mme, Hibernate fournit un langage de requte efficace, le HQL.
Cest grce ses divers avantages, nous avons choisi ce framework pour limplmentation de
cette couche persistance.

3.2. Lenvironnement du dveloppement
La plate-forme J2EE ncessite un ensemble doutils qui facilitent la phase du dveloppement.
Les outils choisis par les dveloppeurs dpendent essentiellement de la solution architecturale
du systme et aussi des frameworks adopts. Ainsi, nous prsentons dans cette partie les outils
choisis pour russir le codage de lapplication.
3.2.1. MySQL :
MySQL est un vritable serveur de base de donnes multi-utilisateur et multi-thread
permettant lhbergement des bases donnes de lapplication. Il est le plus utilis dans le
monde informatique. Son architecture logicielle le rend rapide et facile utiliser.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
57
MySQL est caractris par sa rapidit, sa robustesse et sa facilit dadministration, ainsi que
sa portabilit sur plusieurs plates-formes. Ce qui nous a encourag de faire confiance ce
type de SGBD pour la mise en place notre base de donne.
3.2.2. Oracle :
Oracle est un SGBD (systme de gestion de bases de donnes) dit par la socit du mme
nom, leader mondial des bases de donnes.
Oracle est un SGBD permettant d'assurer :
La dfinition et la manipulation des donnes
La cohrence des donnes
La confidentialit des donnes
L'intgrit des donnes
La sauvegarde et la restauration des donnes
La gestion des accs concurrents
Le choix de Oracle comme un deuxime SGBD est impos puisquon est besoin de tracer
lvolution des indicateurs pendant une longue dure et cette information qui ne peut tre
extraite que du serveur Optima utilisant Oracle.
3.2.3. TomCat :
Le serveur Tomcat est un serveur Open Source qui agit comme un conteneur de servlet J2EE.
Il fait partie du projet Jakarta, au sein de la fondation Apache. Tomcat implmente les
spcifications des servlets et des JSP de Sun Microsystems. Comme Tomcat inclut un serveur
HTTP interne, il est aussi considr comme un serveur HTTP.
Tomcat est un serveur web qui supporte servlet et JSP. C'est le compilateur jasper qui compile
les pages JSP pour en faire des servlet. Tomcat a t crit en langage Java, il peut donc
s'excuter via la JVM (machine virtuelle java) sur n'importe quel systme d'exploitation.
Tomcat utilise le serveur de conteneur Catalina.
3.2.4. Concurrent Versions System (CVS) :
CVS est un outil d'aide au dveloppement de logiciels. Il permet une gestion efficace et riche
des diffrentes versions pour un projet logiciel. Cela passe notamment par la mise en place
d'un suivi, et par consquent d'un historique, pour l'ensemble des fichiers appartenant au
projet.
L'un des autres points forts de CVS est de permettre et de favoriser un dveloppement en
quipe. En effet, il permet un stockage centralis (CVS fonctionne en mode client/serveur)
du code source sur un serveur et gre les accs concurrents sur les fichiers de dveloppement.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
58
Ce qui distingue CVS d'autres outils de dveloppement collaboratif est la possibilit pour les
dveloppeurs d'accder en mme temps un mme fichier pour le modifier, avec une prise en
charge des modifications lorsque celles-ci ne gnrent pas de conflits.
Enfin, comme tout outil de gestion de configuration, CVS s'intgre au processus qualit et
permet non seulement d'introduire des rgles pour une quipe, mais galement de conserver
un historique complet de ce qui a t fait.
Durant la phase du dveloppement de lapplication, nous avons utiliss CVSNT 2.5 comme
serveur CVS qui fonctionne seulement sur Windows NT.

Figure 25 : CVSNT
3.2.5. Eclipse :
Eclipse est un Environnement de dveloppement Intgr (IDE) dvelopp par IBM, dont le
but est de fournir une plate-forme modulaire. Il permet de dvelopper les applications se
basant sur lArchitecture J2EE. Cet EDI permet le dploiement des applications dans les
serveurs dapplications. Eclipse est compos de plusieurs plug-in , chaque plug-in permet
lajout dune fonctionnalit Eclipse (Exemple le plug-in Lomboz permet Eclipse de
supporter les fichiers JSP ).
Plug-in Struts :
Pour utiliser le framework struts, nous avons choisi le plug-in Easy Struts pour faciliter la
mise en uvre de struts avec eclipse.Ce plug-in trs intressant et pratique.
Easy Struts permet notamment de faciliter la ralisation de certaines tches et la cration des
lments suivants :
"Add Easy Struts support" : permet d'ajouter les lments ncessaire l'utilisation de
Struts dans l'application (fichier .jar, .tld, ...) et cr les fichiers de configuration.
"Easy Form" : crer une JSP avec une classe de type ActionForm associe et ajoute la
dfinition de ce bean dans le fichier de configuration
"Easy Action" : crer une classe de type Action et ajoute la definition du mapping de
cette classe dans le fichier de configuration
"Easy Action associated with a form" : crer une JSP avec une classe de type
ActionForm associe, ajoute la dfinition de ce bean dans le fichier de configuration et
cr une classe de type Action et ajoute la definition du mapping de cette classe dans
le fichier de configuration
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
59
"Easy Forward" : crer des renvois ddis une Action ou globaux
"Easy Exception" : crer des handler pour les exceptions.
"Easy Message resources" : crer des fichiers de ressources pour localiser l'application
"Easy Datasource" : permet de dfinir une source de donnes qui sera utilise dans
l'application.

Figure 27 : Liste des taches assistes par Easy Struts


Plug-in struts-layout:
Struts-layout est un ensemble de tags dstin etre utiliser sur des page jsp avec une
application se basant sur le framework struts. Le but est de facilit le dveloppement de ces
pages dynamiques par les dveloppeurs et de permettre son utilisation par les non-
programmeurs Java. Ces libraires sont souvent utilis pour laffichage des tableaux puisquils
contiennent des fonctionnalits puissante dans ce sens (tri, pagination, ...)
Plug-in hibernate:
Le plug-in Hibernate Synchronizer permet la gnration de code utilisant le framework
Hibernate. Il permet aussi de re-gnrer ce code lorsqu'un fichier de mapping est modifi.
Aprs lintegration de Hibernate Synchronizer dans Eclipse. Ce dernier fournit deux vues
pour la configuration de hibernate.
Hibernate Configuration File : [fichier.cfg.xml] pour le fichier de configuration da la base de
donnes.
Hibernate Configuration File : [table.hbm] pour le mapping avec la table nomme
nom_table
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
60

Figure 28 : assistant du plug-in hibernate

Plug-in CVS :
Pour le client CVS, nous avons utilis le plugin-CVS sur lIDE Eclipse dj intgr dans la
version du Eclipse lomboz. Ce plug-in nous a facilit la synchronisation du code avec le
serveur CVS.
La figure ci-dessous montre une des vues CVS fournies par Eclipse Lomboz, qui montre le
ajout dun chemin du rfrentiel dans la vue.


Figure 29 : Rfrentiel CVS

3.2.6. API cewolf :
LAPI Cewolf est un ensemble de tags utiliser dans une Servlet/JSP dans un contexte
dapplication web pour faciliter la ralisation des graphes complexes de tout type (e.g. line,
pie, barres, plots, etc.). En effet cet API offre beaucoup de fonctionnalits qui permet de grer
et bien raliser ses graphes : couleurs, chelles, lgendes, etc... tout en gardant une jsp sans
aucun code java.
Lors dtablissement dun graphe limage est gard uniquement sur session et donc on aura
aucun fichier cre au niveau du serveur.

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
61
3.3. Architecture de lenvironnement du dveloppement
Lors du dveloppement, nous disposons de trois machines et un serveur de dploiement. Dans
chaque machine, on utilise un IDE et une instance de serveur web TomCat pour le test local.
Le serveur de dploiement contient un serveur MySQL, serveur CVS et aussi une instance du
TomCat pour la mise en production des diffrentes versions de lapplication.

Figure 30 : Architecture de lenvironnement

3.3.1. La ralisation des modules :

a) Interface homme-machine : IHM
Aprs linstallation de lenvironnement du travail, nous avons entam la phase du
dveloppement des modules exigs.
Vu que notre solution est une application web, il a t convenable de dfinir une forme
gnrique de interface homme-machine (IHM).
Nous avons pu concevoir une forme des pages JSP grace la notion de template introduite par
le framework struts. Cette mthode permet de rduire le code redondant dans une application
web.
Template (ou en francais modle) est une page JSP qui utilise une bibliothque dtiquettes
personnaliss JSP pour dcrire laspect graphique de la page. Le contenu est insr dans le
template lors de l'excution. Ainsi une ou plusieurs pages peuvent utiliser le mme modle
assurant l'uniformit de la prsentation. Voici le modle que nous avons choisi pour organiser
la prsentation des pages Web.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
62
Header.jsp
Content.jsp
Footer.jsp
Figure 31 : Template JSP

b) Larborescence de lapplication
Pour bien organiser laffichage des rsultats des modules nous avons adopts une structure de
lapplication qui facilite son utilisation.
Voici larborescence selon laquelle laspect graphique de loutil est organis :
KPI
Suivi KPI Demande Travaux Rapport
Suivi Upgrade
Suivi Swap
Suivi Extension
Suivi Activations
Suivi TCONG
Suivi SCONG
Cumul KPI
SCONG
TCONG
Evolution
Rpartition
Evolution
Rpartition
Rpartition DT
KPI Hedomadaire
KPI Mensuel
Acceuil
Figure 32 : arborescence de lapplication

Elle se compose de 4 modules :
KPI : module des KPIs contenant lextraction des indicateurs
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
63
Suivi KPI : ce module suit les oprations doptimisations Upgrade SDCCH et Upgrade
TCH.
Demande Travaux : ce module permet lajout et le suivi des demande de travaux.
Rapport : ce module se charge des interfaces du rapport des statistiques.

3.4. Mise en uvre de la solution :
a) Authentification :
Chaque utilisateur appartient une entit spcifique qui se caractrise par un profil. Cela
justifie lobligation de lauthentification avant daccs au menu de lapplication.
Ladministrateur est le responsable de la cration des comptes.


Figure 33 : page dauthentification


b) Menu de lapplication :
Aprs authentification, lutilisateur accde lapplication avec un profil bien spcifique. Cette
page ci-dessous reprsente une illustration de larborescence dcrite auparavant. Cette
dernire se constitue de 4 grandes rubriques :
KPI : pour extraction des indicateurs et leurs analyses,
suivi KPI : pour le suivi des oprations doptimisations dans le cas dune congestion
de signalisation et de trafic.
Demande de travaux : pour lajout et le suivi des demandes de travaux.
Rapport : pour reprsenter les modules du rapport.

Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
64

Figure 34 : page daccueil
c) KPIs hebdomadaires :
Parmi les fonctionnalits assures par lapplication, cest lextraction des KPIs hebdomadaires
[figure 35 ]. Ces KPIs rsument ltat du rseau pour chaque zone et pour chaque
technologie.
Dans cette page, On trouve lhistorique des KPIs quon peut consulter partir du changement
de la valeur du champ semaine.

Figure 35 : KPI hebdomadaire
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
65

d) KPIs cellulaires :
Pour lextraction des KPIs, nous avons mis la disposition de lutilisateur un filtre.
Lutilit de ce filtre est de faciliter la fonction de lextraction des KPIs .En effet; un ingnieur
support de la zone Ericsson a besoin seulement des indicateurs de cette zone.


Figure 36 : Filtre assurant la pertinence des rsultat

Aprs la configuration du filtre, lutilisateur peut extraire les KPIs pour les analyser. La page
ci-dessous illustre les KPIs de la zone SIEMENS de la semaine 22. Les cellules hors objectif
en signalisation ont la couleur orange dans la colonne SONG. Lindicateur SCONG dans le
menu du tableau des KPIs sert trier les cellules affiches par cet indicateur, ce qui permet
visualiser les cellules les plus congestionnes en signalisation. La pagination en bas de la page
a pour rle de limiter le nombre de cellules visualises. Le filtre de la figure est ajout dans
cette page des KPIs pour faciliter lanalyse.


Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
66

Figure 37 : KPIs zone SIEMENS

Pour Analyser un indicateur dune cellule, il suffit de cliquer sur sa valeur pour visualiser son
volution. La figure montre un cas dun indicateur pour une cellule X.
Lorsque lingnieur support juge quune cellule X est congestionne en signalisation, il peut
lajouter dans la liste des cellules noires en cliquant sur la colonne S.

Figure 38 : analyse dcr dune cellule XX
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
67
Une fois la cellule est ajoute dans la liste des cellules hors objectif en signalisation, elle
devient visible dans la page de suivi SCONG. Dans cette page nous trouvons la liste des
cellules avec leurs derniers tats.
Au niveau de cette page mme, lutilisateur peut visualiser lhistorique des tats dune cellule.
La colonne update permet la mise jour de ltat dune cellule.


Figure 39 : suivi Scong


Conclusion :

Dans ce chapitre, nous avons dcrit notre solution architecturale du systme avec le choix des
technologies adoptes pour la phase de limplmentation ainsi que la mise en uvre des
diffrents modules raliss









Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
68





Conclusion gnrale




Ce stage nous a permis dintgrer lquipe du service support et de nous confronter a
la difficult du terrain de lingnieur radio.
Aprs avoir analyser lexistant informatique nous avons russi proposer une solution
pour contourner un certain nombre de difficults. En particulier, nous avons informatiser les
sorties KPI, nous avons aussi prsenter des modules pour lanalyse des indicateurs de
performance, le suivi des oprations doptimisation, les demandes de travaux ainsi que le
reporting hebdomadaire.
Par consquent nous estimons que ce travail a permis dapporter une contribution
rpondant aux besoins prioritaires du service support notamment lextraction des KPIs qui
reprsentent des lments cls dans le mtier radio.
Pour apprhender davantage les lments de la solution propose, il serait trs utile de
dvelopper les autres modules de larchitecture en particulier la gestion du stock et lanalyse
du drop call.


Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
69

Bibliographie





[1] J.Gabay : Merise et UML pour la modlisation des systmes dinformation Dunod
2001.
[2] Site offiiciel de sun Microsystme : www.java.sun.com
[3] M.Dahchour : Language de modulation Unifi UML . Cours INE 3 l INPT.
[4] L.Massrour : Optimisation du rseau GSM, traitement des statistiques, quipement
siemens Centre de documentation l INPT Juin 2003
[5] Site officiel dhibernate www.hibernate.org
[6] Site officiel dEclipse : http://www.eclipse.org
[7] Document interne de meditel : Les indicateurs de QoS du rseu GSM.
[8] Documentation sur Java: http://java.developpez.com/cours/

[9] Plugins pour eclipse : http://eclipse-plugins.2y.net











Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
70


Liste des figures



Figure 1 : Rpartition du capital de MdiTelecom 3
Figure 2 : Architecture du rseaux GSM6
Figure 3 : Etablissement dappel...10
Figure 4 : Les catgories de la qualit de service.11
Figure 5: Cycle d'optimisation..16
Figure 6 : Evolution annuelle du trafic Air...21
Figure 7 : Rpartition des cellules selon SCONG23
Figure 8 : Les acteurs du systme 26
Figure 9 : diagramme dactivit dUpgrade SCONG...28
Figure 10 : diagramme dactivit dupgrade TCH31
Figure 11 : diagramme dactivit dupgrade TCH33
Figure 12 : diagramme dactivit dune action Activation...35
Figure 13 : Diagramme de classe du module KPI36
Figure 15 : use case du module rapport38
Figure 16 : use case du module demande de travaux39
Figure 17 : Diagramme de classe du module demande de travaux..40
Figure 18 : Architecture Multi Tiers41
Figure 19 : Architecture applicative du systme.42
Figure 20 : architecture MVC.43
Figure 21 : architecture MVC2....48
Figure 22 : structure du framework Struts...49
Figure 23 : Architecture dHibernate...51
Figure 24 : structure du fichier hibernate.cfg.xml52
Figure 25 : structure interne du fichier reprsentant une table.53
Figure 26 : CVSNT..56
Figure 27 : Liste des taches assistes par Easy Struts.56
Figure 28 : assistant du plug-in hibernate57
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
71
Figure 29 : Rfrentiel CVS59
Figure 30 : Architecture de lenvironnement...60
Figure 31 : Template JSP.61
Figure 32 : arborescence de lapplication61
Figure 33 : page dauthentification..62
Figure 34 : page daccueil63
Figure 35 : KPI hebdomadaire.63
Figure 36 : Filtre assurant la pertinence des rsultat66
Figure 37 : KPIs zone SIEMENS67
Figure 38 : analyse dcr dune cellule XX67
Figure 39 : suivi Scong68






















Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
72


Liste des tableaux




Tableau 1 : les interfaces utilises dans le GSM8
Tableau 2 : Canaux logiques du GSM9
Tableau 3 : Les objectifs qualits de Mditelecom...15
Tableau 4 : KPI Golden Area....................................................................................................21
Tableau 5 : Cumul KPI de lanne N22
Tableau 6 : KPI- WN/N+122
Tableau 7 : Cas critiques semaine n+2.23
Tableau 8 : Exigence du systme .25
Tableau 9 : Les intervenants par action26
Tableau 10 : Liste des cas dutilisation.44
Tableau 11 : Matrice de correspondance exigence/cas dutilisation.44
Tableau 12 : Comparaison de quelques frameworks en terme de puissance et de complexit.54














Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
73

Annexe 1. Les compteurs

1.1 les canaux de signalisation :

CNRELCONG Nombre de canaux SDCCH librs cause dune congestion des
ressources radio.
CNDROP Nombre de coupures de connexions anormales.
CMSESTAB Nombre de tentatives dtablissement russies sur canaux TCH.
CDISQA Nombre de coupures de connexions dues une mauvaise qualit de
signal en Uplink ou en Downlink.
CDISTA Nombre de coupures de connexions dues un TA (Timing Advance)
excessif.
CDISSS Nombre de coupure de connexions dues un faible niveau de signal

Compteurs de coupures du canal SDCCH

1.2 les canaux de trafic TCH :

TNDROP Nombre de coupures de connexions anormales.
TMSESTB Nombre de tentatives dtablissement russies sur canaux TCH.
TFQABL Nombre de coupures de connexions dues une mauvaise qualit de signal
dans les deux sens (Uplink et Downlink).
TFQADL Nombre de coupures de connexions dues une mauvaise qualit de signal
en Downlink.
TFQALUL Nombre de coupures de connexions dues une mauvaise qualit de signal
en Uplink.
TFDISSUL Nombre de coupures de connexions dues un faible niveau de signal en
UL.
TFDISSDL Nombre de coupures de connexions dues un faible niveau de signal en
DL.
TFDISSBL Nombre de coupures de connexions dues un faible niveau de signal dans
les deux sens.
TFDISTA Nombre de coupures de connexions dues un TA (Timing Advance)
excessif.
TFSUDLOS Nombre de connexions perdues dune manire soudaine.
CONERRCNT Identifie un IT qui souffre de coupures dappel plus que la moyenne.
Tableau : Compteurs de coupures du canal TCH



Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
74

Annexe 2 : Analyse des coupures dappels et
de la congestion
2.1 Analyse des coupures dappels :
Lanalyse des coupures dappels consiste :
Vrification des coupures dappels par cellule et choisir les cellules avec un taux de
coupures dappels lev.
Examen des raisons des coupures dappels pour les cellules choisies
Contrle du rapport de handovers perdus dus aux coupures dappels.
La raison est de dterminer si le taux de coupures dappels est reli aux performances de
Handovers. Il faut contrler galement quelles relations de voisinages prsentent le plus de
coupures dappels par rapport la moyenne.
Contrle des coupures dappels par TS pour trouver les quipements dfectueux ou
trouver l'interfrence ainsi que le contrle du registre d'erreurs de la BTS.
D'autres activits pourront tre faites comme:
Les essais de Drive Tests et les survey.
La vrification du plan de frquence, la couverture et les plots dinterfrences.
La vrification des puissances de sortie et des configurations de paramtre des cellules
Lorganigramme de la figure 1.4 illustrant cette analyse est dcrit ci dessous :















Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
75






















Figure : Organigramme danalyse des coupures dappels

a) Les coupures dappels sur SDDCH :

Contrler les raisons de
coupures dappels par cellules
Contrler le taux de coupures
dappels par cellules
Contrler le rapport de
Handover perdus par rapport au
total de coupures dappels
Contrler les coupures
dappels par TS de base
Contrler le registre derreur de
la BTS
Contrler les performances
&paramtres de handover
Plusieurs coupures
dappels au Handover
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
76
Tableau : Causes ventuelles et solutions des coupures dappels sur SDCCH
b) Les coupures dappel sur TCH :
En plus des causes vues auparavant, on peut citer :

Les causes probables Plus de dtails Les actions entreprendre Les solutions
Faible niveau de signal en
uplink ou en downlink
Un affaiblissement de
signal rapide peut se
produire si le mobile
- Vrifier les plots de
couverture.
- vrifier la puissance
- Ajouter un rpteur pour
amliorer la couverture
dans un tunnel par
Les causes
probables
Dtails sur les causes Les actions entreprendre Les solutions

Faible niveau de
signal en uplink ou
en downlink
Une pauvre couverture
peut tre synonyme
dun manque de
sites,dune puissance
dmission de la BTS
insuffisante, pas de
couverture indoor,
quipement en panne
- Vrifier les plots de
couverture.
- vrifier la puissance
dmission de la BTS et du
MS.
- Effectuer des drives tests.
- Vrifier le journal
derreur de la BTS.
- Ajouter de nouveaux sites pour
amliorer la couverture
-Jouer sur le Tilt et la hauteur de
lantenne
- Augmenter la puissance
dmission de la BTS.
- Remplacer les quipements
dfectueux.


Mauvaise qualit de
signal en Uplink ou
en Downlink.



Elle est gnralement
due des interfrences

- Effectuer des drives tests.
-Vrifier le C/I et le C/A.
- Vrifier le plan de
frquence utilis.
- Vrifier le tilt dantennes.
-Revoire le plan de frquence et
la dfinition des voisines
-Limiter la couverture des
cellules en jouant sur le tilt
dantennes ou sur le paramtre
TALIM.
- Activer les fonctionnalits
DTX et le saut de frquences.
Un trs grand
Timing Advance.

Le Timing Advance
donne un ordre de
grandeur sur la distance
BTS-MS

- Vrifier si le paramtre
TALIM est infrieur 63.
-Verifier la dfinition des
voisines
-Si la fonctionnalit Extended
Range nest pas utilise, mettre
le TALIM la valeur 63.
-Limiter la porte du site en
jouant sur le Tilt ,puissance
dmission et la hauteur
Congestion sur les
canaux TCH.
Il y a coupure si aucun
canal TCH nest
disponible dans la
cellule qui sert la
connexion lors de la
phase dallocation dun
canal TCH.


- Vrifier la congestion des
canaux TCH.
- Ajouter de nouveaux sites ou
des TRX(upgread)
- Activer la fonctionnalit
Assignment to Worse Cell .
Expiration de la
batterie au niveau
de la MS.
Si la batterie de la MS
se dcharge au cours de
la phase
dtablissement
dappel, la coupure sera
enregistre en tant que
Dropped call due to
low signal strength .

- Vrifier si le contrle de
puissance au niveau de la
MS est utilis.
- Vrifier si le DTX uplink
est utilis.
-Activer les fonctionnalits
DTX uplink et Dynamic Ms
power control .
-Activer le contrle de puissance
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
77
entre dans un tunnel, un
garage, un ascenseur
Une mauvaise
couverture indoor peut
engendrer des coupures
dappels.
dmission de la BTS et du
MS.
- Effectuer des drive tests
et des sites surveys.
- Vrifier sil sagit dun
site omni.
- Vrifier la configuration
dantennes et leurs types.
-Vrifier linstallation
dantennes.
exemple.
- Utiliser des antennes
haut gain pour les BTS.
- Amliorer lindoor.
- Ajouter un nouveau site
sil y a de grands trous de
couverture.
Manque de Best Server

Vrifier les plots de
couverture.
- Amliorer la couverture.
Configuration errone des
paramtres relatifs au
contrle de puissance (au
niveau de la MS et de la
BTS).
Si la batterie de la MS
se dcharge au cours de
la phase
dtablissement
dappel, la coupure sera
enregistre en tant que
Dropped call due to
low signal strength .
Vrifier les valeurs des
diffrents paramtres de
contrle de puissance.

Corriger les valeurs
errones et les mettre aux
valeurs recommandes.





Problmes relatifs au
Handover.
- Manque de relation de
voisinnage.
- Congestion des
cellules voisines.
- Mauvais usage de la
fonctionnalit Bad
Quality Urgency
Handover .
- Vrifier les valeurs des
paramtres relatifs au
Handover
- Vrifier les relations de
voisinage.
- Vrifier les valeurs des
paramtres QLIMDL et
QLIMUL.
- Redfinir les relations de
voisinage et ajouter les
voisins manquants.
- Corriger les valeurs des
paramtres.
Tableau : Causes ventuelles et solutions des coupures dappels sur TCH
2.2 La congestion :
La congestion en trafic est lun des problmes majeurs dont souffre un rseau mobile. Une
congestion importante dtriore les performances du rseau et doit donc tre minimise.
Afin de rsoudre le problme de la congestion, il sagit tout dabord didentifier sa nature selon est ce
quil sagit dune congestion court terme ou long terme.
- A court terme : les vnements occasionnel tels que les rencontres sportives, les
confrences, les foires etc. peuvent induire un trafic lev. Il faudra donc laborer des
solutions temporaires.
- A long terme : sil sagit dune expansion long terme du rseau, sa capacit doit aussi
augmenter suivant la demande.
Il existe deux types de congestion, congestion TCH et congestion SDCCH. Une congestion sur les
canaux SDCCH et sur les canaux TCH ne peut tre rsolue que par laugmentation de la capacit
physique en ajoutant des TRXs et ventuellement des nouveaux sites (Macro ou Micro).
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
78
a) congestion sur SDCCH

Les causes probables Commentaire Les actions
entreprendre
Les solutions
Demande croissante en
trafic
Un trafic lev peut
tre reli un
vnement
occasionnel ou bien
une croissance long
terme.
- Vrifier sil sagit
dune demande de trafic
court terme.
- Vrifier si le mode
SDCCH combin est
utilis.
Augmenter le nombre de
canaux SDCCH soit en
ajoutant de nouveaux TRX, soit
en utilisant le SDCCH en mode
non combin
Lusage des SMS
Lusage excessif des
SMS augmente le
trafic sur les canaux
SDCCH et peut
engendrer une
congestion si le
SDCCH nest pas
dimensionn
correctement.
- Vrifier lactivit des
SMSs.

Redimensionner les canaux
SDCCH en tenant compte de
lusage des SMSs.
IMSI Attach/Detttach Si pendant une
priode de temps
donne plusieurs
abonns teints leurs
MS ou lallume

-Vrifier lactivit de
cette option
Redimensionner les canaux
SDCCH en tenant compte de
lusage de cette option.
Location Area Update Si une cellule se
trouve au bord dune
BSC
-Vrifier lemplacement
de la cellule
Redimensionner les canaux
SDCCH en tenant compte de
cette contrainte
Congestion des canaux
TCH
Une congestion sur
TCH peut amener le
mobile rester plus
longtemps sur le
SDCCH avant de se
voir allouer un IT sur
TCH.
- Vrifier sil y a
congestion TCH.
- vrifier le temps moyen
de signalisation sur
canaux SDCCH
SDCCH Mean Holding
Time .

- Augmenter la capacit en
TCH.
- Utiliser les fonctionnalits de
distribution de trafic telles que
le Cell Loading Sharing et l
Assingnment to Worse Cell
.
Dure moyenne de
signalisation
importante
Si la dure moyenne
de signalisation est
longue, elle gnre
une haute charge en
trafic.
Vrifier si la valeur du
Mean Holding time est
infrieure 7 secondes.
Mettre le paramtre TASSREQ
sa valeur par dfaut.
TASSREQ = 7 s.
Tableau : Causes ventuelles et solutions de la congestion SDCCH
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
79
b) Congestion sur TCH :
Tableau : Causes ventuelles et solutions de la congestion TCH









Les causes
probables
Commentaire Les actions entreprendre Les solutions
Demande
croissante en
trafic
Un trafic lev peut
tre reli un
vnement
occasionnel ou bien
une croissance long
terme.
- Vrifier sil sagit dun
vnement occasionnel.
- Vrifier le
dimensionnement des
canaux SDCCH.
- Vrifier si les
fonctionnalits de
distribution de trafic (HCS,
CLS, AWC) sont utilises
- Augmenter la capacit en
TCH en ajoutant de nouveaux
TRXs.
- Utiliser HCS, CLS et AWC.
-Essayer de faire du Load
Balancing
Dfaut
dinstallation ou
panne
dquipement
Des erreurs
dinstallation ou des
pannes
dquipements
peuvent induire une
congestion.
- Vrifier la disponibilit des
canaux TCH et regarder si
certains ont t bloqus
manuellement ou
automatiquement.
- Changer les quipements
dfectueux.
- Activer tous canaux
disponibles.
Position
dantenne trs
leve
Une position
dantenne trs leve
est synonyme dune
large zone de service
et prend donc
beaucoup de trafic.
- Vrifier la position de
lantenne.
- Vrifier le type dantenne.
-Rduire la hauteur des
antennes sil ny a aucun risque
de trou de couverture.
-Tilter lantenne ou changer
son type peut aussi rduire la
zone de couverture de la
cellule.
Faible activit du
Handover.
Trs peu de
Handover peut
conduire une
congestion si le
mobile est forc de
rester une longue
dure dans la cellule.
- Vrifier la congestion des
cellules voisines.
- Vrifier la dfinition des
voisins (un manque de
voisin peut causer des
problmes de Handover).
- Ajouter les relations de
voisinages manquantes.
- Corriger les paramtres de
Handover tel que lOffset.
Congestion des
cellules voisines
- Revoir les relations de
voisinages.
- Vrifier si AWC est activ.
Si cest le cas, vrifier la
valeur du paramtre
AWOFFSET.
- Ajouter de nouvelles relations
de voisinage.
Etude et dveloppement dun outil danalyse et de suivi des oprations doptimisation du rseau GSM Meditelecom



A.KARKOURI & A.BOUCHOUKI PFE 2006
80