PFE SAIDI Emna

RAPPORT DE PROJET DE FIN DETUDES
Filire
Ingnieurs en Tlcommunications
Option
Ingnierie des rseaux des tlcommunications
DEVELOPPEMENT DUN OUTIL DE GESTION DES ELEMENTS RESEAU

Elabor par :
Emna SADI
Encadr par :
Mme. Malek Ben Youssef M. Montasser Derbel
Anne universitaire : 2004/2005
A ma mre et mon pre, Que ce travail soit pour eux le tmoignage de ma reconnaissance et de mon affection.
A mon frre et mon fianc, Quils trouvent ici le tmoignage de toute mon affection et de mon dvouement.
A mes oncles et mes tantes. A mes cousins et cousines. A mes amis.
Remerciements
Jexprime mes vifs remerciements Monsieur Adel Brahem chef du service NSS de la direction technique de TUNISIANA pour mavoir si bien accueillie et permis de faire ce stage. Mes remerciements sadressent galement, tout le personnel du service Network SubSystem de TUNISIANA qui ma apport une aide prcieuse chaque fois que jen ai formul le besoin en particulier Monsieur Montasser Derbel auquel jexprime toute ma reconnaissance et mes respects.
Je tiens galement adresser mes remerciements et ma gratitude Mme Malek Ben Youssef pour sa disponibilit, son soutien, son aide prcieuse et ses conseils judicieux tout au long de ce projet. Je suis particulirement reconnaissante lcole SUPrieure des COMmunications de Tunis ( SUPCOM ) pour mavoir offert lopportunit dacqurir cette exprience qui, sans doute, me sera dun grand apport dans ma vie professionnelle. Merci
Sadi Emna
Sommaire
Sommaire
SOMMAIRE .........................................................................................................................................................1 LISTE DES FIGURES ........................................................................................................................................3 INTRODUCTION GENERALE .......................................................................................................................4 CHAPITRE 1. PRESENTATION DU CADRE DE TRAVAIL ET DU SUJET .......................................6 INTRODUCTION...................................................................................................................................................6 1. PRESENTATION DE LORGANISME D ACCUEIL ..............................................................................................6
1.1. Prsentation gnrale de TUNISIANA .................................................................. 6 1.2. Organisation de TUNISIANA ................................................................................ 7

2. PRESENTATION DU SUJET ...............................................................................................................................9 CONCLUSION ......................................................................................................................................................9 CHAPITRE 2 ETUDE THEORIQUE ET ETAT DE LART....................................................................10 INTRODUCTION.................................................................................................................................................10 1. LE RESEAU GSM..........................................................................................................................................10
1.1. Le sous-systme radio ........................................................................................... 11 1.2. Le sous-systme rseau ......................................................................................... 12 1.3. Le rseau de gestion de tlcommunications....................................................... 14
2. LE SOUS-SYSTEME RESEAU DE TUNISIANA.............................................................................................15
2.1. Architecture du MSC de TUNISIANA ................................................................ 15 2.1.1. Signalling System Network Control (SSNC) ............................................... 17 2.1.2. Coordination Processor (CP) ......................................................................... 19 2.1.3. Message Buffer (MB).................................................................................... 19 2.1.4. Switch Commander (SC) ............................................................................... 21 2.1.5. Line Trunk Group (LTG)............................................................................... 21 2.1.6. Switching Network (SN)................................................................................ 23 2.2. Interconnexion entre n uds du rseau ................................................................. 25
CONCLUSION ....................................................................................................................................................26 CHAPITRE 3. SPECIFICATION...................................................................................................................27 INTRODUCTION.................................................................................................................................................27 1. ETUDE DE LEXISTANT .................................................................................................................................27
1.1. Prsentation de lexistant....................................................................................... 27 1.2. Limites de lexistant .............................................................................................. 29

2. SPECIFICATION DES BESOINS .......................................................................................................................30 3. TRADUCTION DES BESOINS EN DIAGRAMMES DES CAS DUTILISATION .....................................................31
3.1. Objectifs des cas dutilisation ............................................................................... 31 3.2. Diagrammes des cas dutilisation ......................................................................... 32
CONCLUSION ....................................................................................................................................................34 CHAPITRE 4. CONCEPTION........................................................................................................................35 INTRODUCTION.................................................................................................................................................35 1. CONCEPTION DE LA BASE DE DONNEES .......................................................................................................35
Projet de fin dtudes
Sommaire 1.1. Le modle conceptuel des donnes (MCD) ......................................................... 35 1.1.1. Dfinition des lments de base du modle E/A .......................................... 35 1.1.2. Schma entit-association .............................................................................. 36 1.2. Le modle logique des donnes (MLD) ............................................................... 40
2. ARCHITECTURE DE LAPPLICATION .............................................................................................................43
2.1. Prsentation du langage de modlisation UML ................................................... 43 2.2. Architecture de lapplication................................................................................. 44 2.3. Module de configuration de la base de donnes .................................................. 45 2.3.1. La classe TablePage ....................................................................................... 46 2.3.2. La classe CatalogPage................................................................................... 47 2.3.3. La classe Connection...................................................................................... 48 2.3.4. Le diagramme de classe du module de configuration de la base................. 49 2.4. Le module dinterrogation de la base de donnes................................................ 50 2.4.1. Prsentation du systme de recherche dinformation................................... 50 2.4.2. Principe de la recherche ..................................................................................... 51 2.4.3. Le diagramme de classes du module dinterrogation de la base ................. 53 2.5. Le module dauthentification ................................................................................ 57
CONCLUSION ....................................................................................................................................................58 CHAPITRE 5. REALISATION.......................................................................................................................59 INTRODUCTION.................................................................................................................................................59 1. LES TECHNIQUES UTILISEES.........................................................................................................................59
1.1. Le serveur dapplications ...................................................................................... 60 1.2. Le serveur de base donnes................................................................................... 60 1.3. Choix du langage de programmation.................................................................... 61
2. ENVIRONNEMENT DE DEVELOPPEMENT ......................................................................................................62
2.1. Environnement matriel ........................................................................................ 62 2.2. Environnement logiciel ......................................................................................... 63

3. ETAPES DE LA REALISATION ........................................................................................................................63
2.1 Cration de la base.................................................................................................. 63 2.2 Dveloppement de loutil ....................................................................................... 63

3. CAPTURES DECRAN .....................................................................................................................................63
3.1 Lauthentification.................................................................................................... 63 3.2. Interface principale ................................................................................................ 64 3.3. Insertion dans la base............................................................................................. 65 3.4. Interface de consultation de table ......................................................................... 66 3.5. Interface de requte manuelle ............................................................................... 68 3.6. Interface du moteur de recherche.......................................................................... 68
CONCLUSION ....................................................................................................................................................70 CONCLUSION GENERALE ..........................................................................................................................71 LES ANNEXES ..................................................................................................................................................72 ANNEXE A. STATISTIQUES SUR LE GSM ..............................................................................................72 ANNEXE B. LA SIGNALISATION SS7 .......................................................................................................74 ANNEXE C. LE LANGAGE DE MODELISATION UML........................................................................75 GLOSSAIRE.......................................................................................................................................................78 BIBLIOGRAPHIE.............................................................................................................................................80
Liste des Figures
Liste des figures

Figure 1 . Organigramme de TUNISIANA...........................................................................................................7 Figure 2 . Organigramme de la direction technique. ..........................................................................................8 Figure 3 . Le rseau GSM....................................................................................................................................11 Figure 4 . Dcomposition de la zone de couverture en cellules. ......................................................................11 Figure 5 . Vue d ensemble de l environnement D900. .....................................................................................16 Figure 6 . Vue d ensemble sur l quipement du SSNC......................................................................................17 Figure 7 . Hardware du MB de type D (MBD). .................................................................................................20 Figure 8 . Les fonctions du LTG. ........................................................................................................................21 Figure 9 . Structure interne d un LTG................................................................................................................23 Figure 10 . Structure du SN D et connexion avec les autres n uds du MSC. .................................................25 Figure 11 . Exemple d interrogation de l tat des LIC du SSNC. ...................................................................28 Figure 12 . Interrogation du LTG sur l tat d un DIU.....................................................................................28 Figure 13 . Cration d un DIU et affichage de son tat....................................................................................29 Figure 14 . Diagramme de cas d utilisation de l application. ........................................................................33 Figure 15 . Diagramme de cas d utilisation de la cration d un DIU. ............................................................34 Figure 16 . Schma E/A de la base de donnes (1)............................................................................................38 Figure 17 . Schma E/A de la base de donnes (2)............................................................................................39 Figure 18 . Schma relationnel des tables (1)....................................................................................................41 Figure 19 . Schma relationnel des tables (2)....................................................................................................42 Figure 20 . Vue d'ensemble de l'architecture de l'application..........................................................................45 Figure 21 : La classe TablePage. .......................................................................................................................46 Figure 22 . La classe CatalogPage.....................................................................................................................47 Figure 23 : La classe connection........................................................................................................................48 Figure 24 . Diagramme de classes du module de configuration de la base de donnes.................................49 Figure 25 . Structure du systme de recherche. .................................................................................................51 Figure 26 . Les tapes de recherche dans la base............................................................................................53 Figure 27 . Paquetages du module d'interrogation de la base. ........................................................................54 Figure 28 . Diagramme de classes du paquetage DB_Query...........................................................................55 Figure 29 . Diagramme de classes du module de configuration de la base. ..................................................57 Figure 30 . Processus d'authentification............................................................................................................58 Figure 31 . Architecture de l'application trois niveaux..................................................................................59 Figure 32 . Ecran d'authentification...................................................................................................................64 Figure 33 . Interface principale. .........................................................................................................................64 Figure 34 . Interface d'insertion. ........................................................................................................................66 Figure 35 . Interface de consultation..................................................................................................................67 Figure 36 . Rsultat de l'affichage. .....................................................................................................................67 Figure 37 . Interface de requte manuelle. ........................................................................................................68 Figure 38 . Interface de saisie des mots cls......................................................................................................69 Figure 39 . Affichage des tables correspondant la recherche. ......................................................................69 Figure 40 . Spcification des critres d'affichage..............................................................................................70 Figure 41 . Rsultat de la recherche...................................................................................................................70
Introduction gnrale
Introduction gnrale
Il ne fait dsormais plus aucun doute que les tlcommunications sont la rvolution la plus importante et la plus innovante qui a marqu la vie de lhumanit moderne au cours de ce dernier sicle. En effet, loin dtre un phmre phnomne de mode, ou une tendance passagre, cette avance technologique a fondamentalement chang la vie de lHomme. LHomme sest vu raliser son rve dantan : rduire les distances physiques qui le sparent des autres en communiquant avec eux. Ainsi, de lingnieur qui voit son travail sensiblement facilit au patient qui discute avec son mdecin, personne ne peut plus se passer de son tlphone portable. Quoique les services tlphoniques existent depuis longtemps, un regain de popularit apparat alors avec les services associs aux tlphones portables. La notion de GSM (Global System for Mobile Communications) devient rapidement lindispensable de monsieur tout le monde et vient alors le souci des oprateurs tlphoniques doffrir des services qui satisfont aux besoins de leurs clients. Lvolution des services du GSM suscite de plus en plus lintrt des utilisateurs dont le nombre ne cesse de crotre (Voir Annexe A Statistiques sur le GSM). Du fait de cette expansion les oprateurs voient le nombre de leurs quipements GSM augmenter ce qui rend leur gestion de plus en plus difficile voire mme parfois impossible vu le temps quelle prend. Cependant, une entreprise ne pourra atteindre une efficacit oprationnelle optimale que si elle arrive minimiser ses charges et optimiser ses ressources. Lun des moyens doptimisation qui soffrent aux oprateurs tlphoniques est lutilisation doutils ou applications qui rendraient facile la gestion des quipements constituant leurs rseaux, entre autres les quipements tlcoms du c ur de rseau GSM dont la gestion est le sujet de ce projet.
Introduction gnrale Cest dans cet ordre dides que sinscrit ce projet de fin dtudes que jai eu loccasion daccomplir au sein de lentreprise TUNISIANA de Orascom Telecom Tunisie. Le travail raliser consiste donc concevoir et mettre en gestion des lments du rseau de GSM de Tunisiana . Le prsent rapport se dcompose en cinq chapitres. Dans ce qui suit, on prsentera le contenu de chaque chapitre. Le premier chapitre, qui sintitule prsentation du cadre de travail et du sujet, on y prsentera lenvironnement du stage ainsi que le sujet traiter. Le second chapitre sera consacr la prsentation de quelques notions de base dont la matrise est indispensable pour la comprhension du sujet. Le troisime chapitre sera rserv ltude de lexistant ainsi que ses limites, et voquera la spcification des besoins fonctionnels et non fonctionnels. Le quatrime chapitre sintressera la phase la plus importante celle de conception de loutil de gestion des lments du rseau. Enfin le dernier chapitre concerne limplmentation, les tests et la validation de loutil propos. uvre un outil de
Chapitre 1. Prsentation du cadre de travail et du sujet
Introduction
Avant de traiter le sujet du prsent mmoire de fin dtudes, il convient de prsenter lenvironnement dans lequel il a t men bien. En effet, cest de lenvironnement que dpend, en grande partie, lefficacit et la qualit dun travail. Jai effectu mon projet de fin dtudes au sein de lentreprise TUNISIANA premier oprateur priv de tlcommunications en Tunisie.
1. Prsentation de lorganisme daccueil

1.1. Prsentation gnrale de TUNISIANA
En mai 2002, la deuxime licence tunisienne de tlphonie mobile a t attribue Orascom Telecom Tunisie [1]. Cette licence, qui a cot 454 millions de dollars, a marqu la naissance du premier oprateur de tlcommunications priv en Tunisie : TUNISIANA. Cest une socit tunisienne anonyme au capital de 330 millions de dinars dont le principal actionnaire est Watanya Telecom qui dtient la moiti des actions, associe Orascom Tunisia Holding (35% des actions) et Carthage Consortium (15% des actions). Grce des performances techniques, Tunisiana a ralis son lancement commercial le 27 dcembre 2002, et, six mois plus tard, couvrait dj 60% de la population.
Chapitre 1. Prsentation du cadre de travail et du sujet Son action se nourrit de quatre valeurs fondatrices : orientation client, professionnalisme, transparence et innovation, et s'inscrit dans sa vision stratgique : fournir le meilleur, pour une satisfaction totale et durable de ses clients, et dans le cadre de partenariats solides . Acteur essentiel du secteur des nouvelles technologies, TUNISIANA s'appuie sur les progrs rapides de la technique pour dvelopper des services adapts, innovants et de qualit.
1.2. Organisation de TUNISIANA

Afin dassurer une bonne prestation de services ses clients et un bon fonctionnement de son rseau de transmission GSM, TUNISIANA est base sur linteraction de plusieurs directions et dpartements complmentaires comme le montre la figure ci-dessous (Figure1):
Direction Gnrale (DG)
Chef Financier Officier
Conseillre Juridique
Direction Administrative et Financire (DAF)
Direction Qualit et Programme (DQP)
Direction Marketing (DM)
Direction des Vente (DV)
Direction Service Client (DSC)
Direction Technique (DT)
Direction des Systmes Information (DSI)
Direction des Ressources Humaines (DRH)
Figure 1 . Organigramme de TUNISIANA.
Ce projet a t ralis la direction technique qui est compose de 3 dpartements comme lindique la figure suivante :
DIRECTEUR TECHNIQUE
DEPARTEMENT ARCHITECTURE ET DEPLOIEMENT
DEPARTEMENT INGENIERIE ET DEVELOPPEMENT
DEPARTEMENT OPERATION & MAINTENANCE
Figure 2 . Organigramme de la direction technique.
Dpartement Architecture et dploiement

o Planification et optimisation du rseau radio; o Recherche et acquisition des sites relais ; o Construction des sites; o Livraison des quipements sur sites.
Dpartement Opration et maintenance

o Supervision du rseau 24h/24 ; o Maintenance du rseau ; o Suivi de la qualit de service (QOS) ; o Support aux dpartements fonctionnels.
Dpartement Ingnierie et Dveloppement
Cest au sein de ce dpartement que ce projet a t ralis. Ses principales fonctions sont : o La conception du rseau de commutation; o La conception et limplmentation des services valeurs ajoutes (SAV); o LArchitecture et linterconnexion avec les rseaux fixes et mobiles de loprateur historique et des oprateurs partenaires.
Chapitre 1. Prsentation du cadre de travail et du sujet 2. Prsentation du sujet Ce projet de fin dtudes porte sur la ralisation dun outil de gestion des lments du rseau GSM de TUNISIANA. En effet, le nombre sans cesse croissant des quipements constituant le rseau GSM de TUNISIANA rend leur gestion de plus en plus difficile, do la ncessit de dvelopper un outil permettant une gestion plus efficace et offrant une visibilit dtaille de tous les composants du rseau.
Conclusion
Aprs avoir prsent le cadre de ce projet de fin dtudes ainsi que le sujet traiter, il est utile dtudier les notions thoriques principales pour bien comprendre le projet.
Chapitre 2. Etude thorique et tat de lart
Chapitre 2 Etude thorique et tat de lart

Introduction
La ralisation de ce projet a ncessit une tude approfondie sur certaines notions qui touchent non seulement au cadre gnral du projet, mais aussi sa ralisation. Pour bien assimiler ces diffrentes notions, cette section sera consacre en premier lieu la prsentation brve du rseau GSM. On dtaillera ensuite larchitecture du c ur du rseau (Network SubSystem ou NSS) ainsi que ses diffrents composants.
1. Le rseau GSM
Un rseau GSM, comme dcrit dans la figure 1, se compose de huit lments distincts jouant chacun un rle bien dfini lors de la transmission des informations (parole ou donnes) : une station de base Base Tranceiver Station (BTS) , un contrleur de station Base Station Controller (BSC) , un centre de commutation Mobile Services Switching Center (MSC) , un enregistreur de localisation nominal Home Location Register (HLR) , un centre dauthentification Authentication Center (AUC) , un enregistreur de localisation des visiteurs Visitor Location Regiter (VLR) , un enregistreur didentification dquipement Equipment Identity Register (EIR) et un centre dexploitation et de maintenance Operation and Maintenance Center (OMC) [2].
10
Figure 3 . Le rseau GSM. Comme dcrit dans la figure 4, le principe de fonctionnement dun rseau GSM consiste diviser la zone que lon veut couvrir en zones gographiques appeles cellules. Ensuite, on affecte chaque cellule une station de base relie une tour hertzienne.
BTS
Cellule A
BTS
Station Mobile
Cellule B
Figure 4 . Dcomposition de la zone de couverture en cellules. L'architecture de base du systme GSM se prsente sous la forme d'une structure hirarchise, compose des lments cits ci-dessus et rpartis en trois segments.
1.1. Le sous-systme radio

Le sous-systme radio appel galement Base Station Subsystem (BSS) regroupe les quipements assurant toutes les fonctions de gestion des aspects radio savoir les BTS et les BSC.
11
La station de base BTS assure la couverture radiolectrique dune cellule du rseau. Elle fournit un point dentre aux abonns prsents dans sa cellule pour recevoir ou transmettre des appels. Une station de base gre simultanment huit communications grce au multiplexage temporel AMRT (Accs Multiple Rpartition dans le Temps).
Le contrleur de station de base BSC gre une ou plusieurs stations et remplit diffrentes missions pour les fonctions de communication et dexploitation. Pour le trafic abonn venant des stations de base, cest un concentrateur, pour le trafic issu du commutateur, cest un aiguilleur vers la station du bon destinataire. Le contrleur est aussi le relais pour les alarmes et les statistiques issues des stations de base.
1.2. Le sous-systme rseau

Le sous-systme rseau, galement appel Network SubSystem (NSS) , regroupe les sous-systmes qui assurent des fonctions du niveau rseau (routage, interconnexion) savoir le MSC, le HLR et VLR. Le HLR ou enregistreur de localisation nominal est la base de donnes qui gre les abonns d'un oprateur donn. Il mmorise les caractristiques suivantes[3]: o Lidentit internationale de l'abonn utilise par le rseau (IMSI) ; o Le numro d'annuaire de l'abonn (MSISDN ou numro d'appel) ; o Le profil de l'abonnement (services supplmentaires autoriss, autorisation d'appel international). D'autre part, le HLR est une base de donnes de localisation. Il mmorise pour chaque abonn le numro du VLR o il est enregistr, mme dans le cas o l'abonn se connecte sur un oprateur tranger. Cette localisation est effectue partir des informations mises par le terminal et reue par
12
Chapitre 2. Etude thorique et tat de lart les BTS travers le rseau. L'implantation du HLR peut tre centralise ou dcentralise. Dans le premier cas, un HLR peut grer plusieurs centaines de milliers d'abonns et il constitue une machine spcifique. Dans le deuxime cas, il peut tre intgr dans les MSC et les donnes d'un abonn sont alors physiquement stockes sur le MSC o l'utilisateur communique prfrentiellement. Les changes de signalisation sont ainsi minimiss. Dans tous les cas d'implantation, chaque abonn est associ un HLR unique, de faon indpendante de la localisation momentane de cet abonn. Le rseau identifie le HLR partir du numro d'appel. Le commutateur de services mobiles (MSC-VLR) : le MSC gre l'tablissement des communications entre un mobile et un autre MSC, la transmission des messages courts (SMS) et l'excution d'un handover entre deux BSC diffrentes. Il dialogue avec le VLR pour grer la mobilit des usagers : vrification des caractristiques des abonns visiteurs lors d'un appel dpart, transfert des informations de localisation... On distingue deux types d'appels au niveau d'un MSC : o Un appel de mobile mobile: dans ce cas, le MSC tablit une liaison avec un autre MSC. o Un appel du mobile au rseau tlphonique fixe: Il doit alors possder une fonction passerelle, GMSC (Gateway MSC), qui est active au dbut de chaque appel d'un abonn mobile vers un abonn fixe. Le MSC est en gnral coupl avec le VLR (Visitor Location Register), ou enregistreur de localisation visiteur. C'est une base de donnes qui mmorise les informations aux abonns prsents dans la zone gographique du MSC. Les donnes mmorises par le VLR sont
13
Chapitre 2. Etude thorique et tat de lart similaires aux donnes du HLR, mais concernent seulement les abonns mobiles prsents dans la zone considre. Le VLR a une information de localisation plus prcise que le HLR. La sparation matrielle entre VLR et MSC propose par la norme n'est que rarement respecte. Certains constructeurs intgrent le VLR dans le MSC. Les dialogues ncessaires pour l'tablissement d'appel sont alors simplifis. D'autres tablissent un dcoupage diffrent entre MSC et VLR en utilisant l'approche rseau intelligent, cest le cas de TUNISIANA.
1.3. Le rseau de gestion de tlcommunications

Le rseau de gestion de tlcommunications, galement appel Telecommunication Management Network (TMN) , regroupe les sous-systmes qui assurent des fonctions de scurisation, de supervision et de maintenance. Ce segment est constitu de lOMC, du EIR et du AUC : Le centre dexploitation et de maintenance OMC est lentit de gestion et dexploitation du rseau. Elle regroupe la gestion administrative des abonns et la gestion technique des quipements. La gestion administrative et commerciale du rseau sintresse aux abonnements en terme de cration, de modification, de suppression et de facturation, ce qui suppose une interaction avec la base de donnes HLR . La gestion technique veille garantir la disponibilit et la bonne configuration matrielle des quipements du rseau. Ses axes de travail sont la supervision des alarmes mises par les quipements, la suppression des disfonctionnements, la gestion des versions
logicielles, de la performance et de la scurit. Lenregistreur didentification dquipement EIR stocke des informations sur lappareil mobile. Il contient la liste noire des appareils mobiles. Un code didentification dquipement appel
14
Chapitre 2. Etude thorique et tat de lart International Mobile Equipement Identity (IMEI) est donn et inscrit sur chaque GSM, ce code peut servir bloquer lappareil. Le centre dauthentification AUC est une base de donnes qui stocke des informations confidentielles. Il contrle les droits dusages possds par chaque abonn sur les services du rseau. Ce contrle est important la fois pour loprateur (contestation de facture) et pour labonn (fraude). Vu la complexit des fonctions du niveau rseau que ralise le NSS, ce soussystme est, de loin, la partie la plus difficile grer dans le rseau GSM. Afin de mieux comprendre la gestion de ses quipements, on se propose de se focaliser dans ce qui suit sur la constitution interne des quipements du NSS, en particulier le MSC.
2. Le sous-systme rseau de TUNISIANA

En plus de larchitecture standard GSM, il est indispensable tout oprateur de tlphonie mobile de se munir dune architecture supplmentaire permettant la gestion des lments constitutifs du rseau GSM. Ces architectures diffrent selon le constructeur dquipements. Dans cette perspective, TUNISIANA sest munie du matriel fourni par lquipementier allemand SIEMENS pour son c ur de rseau GSM. La mise en place d'un rseau GSM permet tout oprateur de proposer des services de type voix ses clients en donnant l'accs la mobilit tout en conservant un interfaage avec le rseau fixe RTC (Rseau Tlphonique Commut) existant. Toutes ces tches reposent essentiellement sur les quipements du c ur du rseau et en particulier sur le MSC. Dans ce qui suit on va prsenter larchitecture du MSC existant TUNISIANA, ses quipements internes ainsi que ceux permettant son interconnexion avec les autres n uds du rseau.
2.1. Architecture du MSC de TUNISIANA

Lensemble des quipements SIEMENS qui constituent le MSC forme ce que lon appelle lenvironnement D900 prsent dans la figure 5 [4].
15
Trunks and SS7 Links

High Speed SS7 Links
LTG LTG SN SSNC: Signaling System Network Control LTG: Line Trunk Group Switching Network Message Buffer Coordination Processor Switch Commander
PCM30s only with SS7 links
SN: SC SSNC MB CP: MB:
SC: CP
Figure 5 . Vue densemble de lenvironnement D900. Comme lindique la figure 5, lenvironnement D900 est constitu : Dun rseau de contrle de la signalisation du systme ou Signalling System Network Control (SSNC) ; Dun ensemble de processeurs constituant le processeur de coordination ou Coordination Processor (CP) ; Dune unit de stockage dsigne par le Message Buffer (MB) ; Dune unit de commande du MSC appele Switch Commander (SC) ; Dunits permettant les entres-sorties des lignes de trafic et de signalisation appeles Line Trunk Group (LTG). Et enfin dun rseau de commutation ou Switching Network (SN) ;
Dans ce qui suit on se propose de dtailler chaque lment du D900.
16
2.1.1. Signalling System Network Control (SSNC)

Le rseau de contrle de la signalisation du systme ou SSNC est la composante de signalisation SS7 de lenvironnement D900 (Voir Annexe B. La signalisation SS7). Cet quipement peut tre utilis en tant que point de transfert de la signalisation (Signalling Transfert Point STP) et dans ce cas il est spar du MSC do le type de ce dernier standalone. Il peut aussi tre associ au rseau et le MSC sera alors de type associated.
LTG LTG
SS7 Links (64kb/s) High Speed Links (2Mb/s)
SSNC LIC
ATM Switching Network:
LIC
SN
MP
SC
MB
MP
X.2 5
CP
Figure 6 . Vue densemble sur lquipement du SSNC. Le SSNC soccupe de lchange des messages entres les diffrents n uds de signalisation afin dtablir, de contrler et de grer les connexions entre ces n uds et dadministrer le rseau de signalisation[4]. Les processeurs des n uds du rseau (MSC ou
17
Chapitre 2. Etude thorique et tat de lart GMSC) passent les messages quils veulent transmettre au SSNC avec les adresses de destination et le SSNC se charge de crer les messages au format SS7 et de les envoyer sur les liens de signalisation appropris la bonne destination. Le SSNC peut tre utilis comme tant un : Signalling End Point (SEP) il reprsente lorigine ou la destination des messages de signalisation ; Signalling Transfer Point (STP) ou point de transfert de signalisation sil reoit les messages de signalisation partir dun SEP et les transfre un STP ou un SEP ; Une combinaison de STP et SEP.
Quand il reoit un message, le SSNC vrifie si ce message est destin son propre ud (SEP) ou bien sil doit le transfrer un autre n ud (STP) sur des liens de signalisation sortants. Comme on le voit dans la figure 7, le SSNC est compos de trois entits : Les cartes Line Interface Card (LIC) qui constituent une interface entre les units du SSNC et le rseau SS7. Elles ont pour principal rle de convertir les liens de signalisation synchrones entrant dbits de 64 Kbps (pour les liaisons MIC) et 2 Mbps (pour les liaisons haut dbit) des liens de signalisation asynchrones 207 Mbps et inversement. Le rseau de commutation ATM appel ATM Switching Network (ASN) qui effectue la commutation des liens provenant des cartes LIC. Les Main Processors (MP) ou processeurs principaux qui peuvent tre au plus au nombre de 50 et qui sont relis lASN. Un MP effectue entre autres des fonctions de traitement de messages signalisation. Selon leurs utilisations, on distingue deux sortes de MP : le stand-alone (MP:SA) et le Application software Processing (MP:AP). Le SSNC est reli un processeur de coordination travers des liaisons sortantes du ASN un dbit de 207 Mbps.
18
2.1.2. Coordination Processor (CP)

Coordination processor ou processeur de coordination est llment en charge du contrle de toutes les units du D900. Il effectue trois tches principales : Le traitement des appels : routage, administration du trafic de donnes, slection de chemin travers le rseau de commutation, Lopration et la maintenance : communication avec lOMC ; La dtection et la correction d erreurs.
Le CP est constitu de plusieurs sous units dont on cite : Les processeurs de base Base Processor (BAP) pour les tches de maintenance et de traitement des appels ; Les processeurs servant dinterface avec le SSNC ATM Bridge Processor (AMP) ; Les processeurs dappels Call Processor (CAP) utiliss seulement pour le traitement des appels ; Les mmoires communes tous ces processeurs Common Memory (CMY).
2.1.3. Message Buffer (MB)

Dans le cas de Tunisiana il sagit dun message buffer de type D dsign par MBD. Le message buffer est lunit de lenvironnement D900 qui soccupe de la gestion de diffrents types dinterfaces entre SSNC, CP, les Line Trunk Group (ensemble de liens de trafic et de signalisation) et le rseau de commutation SN (Switching Network). Ainsi, il se charge de la commutation des informations travers ces interfaces. Le MB est constitu de quatre modules : Le MBD pour le traitement des interfaces HDLC[*] avec les LTG et le SN, appel MBDH ;
HDLC ou High-Level Data Link Control est un protocole de couche liaison de donnes synchrone orient-binaire dvelopp par l organisme de normalisation international ISO
[*]
19
Chapitre 2. Etude thorique et tat de lart Le MBD pour la connexion avec le SSNC travers les liens ATM, appel MBDA; Le MBD pour la connexion avec le CP, appel MBDC; Le MBD qui reoit la frquence de lhorloge depuis le gnrateur dhorloge CG (Clock Generator) et il est appel MBDCG. La figure 7 illustre ceci :
Line Trunk Group (LTG) And Switching Network (SN)
LTG and SN
MBDH
SSNC
ATM207
MBDA
MBDC
MBDCG
CP
Figure 7 . Hardware du MB de type D (MBD).
(International Standard Organisation). Il indique une mthode d'encapsulation des donnes sur des liaisons synchrones en srie l'aide de caractres de trame et de sommes de contrle.
20
2.1.4. Switch Commander (SC)

Switch Commander est un ordinateur ou un ensemble dordinateurs qui ont pour tche de communiquer avec les quipements du rseau et de commander les oprations dimport de mesure de performance.
2.1.5. Line Trunk Group (LTG)

Le LTG est une carte hardware qui supporte des Trunk Group. Un Trunk Group reprsente un ensemble de liens appels Trunk responsables de lacheminement du trafic entre les n uds quils interconnectent. Les LTG forment l'interface entre le MSC (plus prcisment le rseau de commutation SN), d'un ct, et le BSC et les autres quipements du rseau mobile (PLMN), de l'autre ct. La figure suivante illustre les fonctions du LTG :
LTG
Primary Digital Carrier 0 PDC 0 PDC 1 PDC 2 PDC 3
Effectue des fonctions de contrle dcentraliss qui rduisent les tches du CP tel que la gnration de son de signalisation audible pour l utilisateur. Fournit une interface entre le SN et les autres n uds du rseau mobile.
SN0
8Mbit/s SDC
SN1
Figure 8 . Les fonctions du LTG.
Les liaisons PDC sont des liaisons 64 Kbps. Elles sont multiplexes en liaisons SDC (Secondary Digital Carrier) de 8 Mbps. Chacun de ces SDC 8 Mbps possde 127 times slots. Les time slot transportent les informations de signalisation et les donnes utilisateur un dbit de 64 Kbps. Le time slot numro zro est rserv pour les messages internes entre LTG, CP et SSNC.
21
Chapitre 2. Etude thorique et tat de lart Selon que lon les utilise pour connecter le MSC un rseau fixe ou un n ud du rseau de signalisation SS7 de type STP ou SEP, Il existe plusieurs types de LTG qui dpendent de lenvironnement de travail D900 ou autres tel que le EWSD. Tous ces LTG ont pratiquement la mme composition interne en units physiques et logiques. Ils se composent de : Une unit dinterfaage avec le rseau de commutation SN appele Link Interface Unit (LIU) ; Un processeur qui contrle le fonctionnement interne du LTG appel Group Processor (GP); Un gnrateur dhorloge, le Group Clock Generator (GCG); Lunit logique de signalisation du LTG appele Signalling Unit (SU) qui est reprsente physiquement par : o Un Code Receiver (CR) : module hardware qui reoit et dtecte les signaux multifrquences ; o Un Tone Generator (TOG) ou gnrateur de tonalit. Lunit logique du LTG appele Line/Trunk Unit (LTU) qui contient diffrents modules tels que : o Digital Interface Unit (DIU) : unit dinterface numrique utilise par le LTG pour connecter les PDC vhiculant les liaisons MIC ; o Conference Unit (COU) : cest lunit logique qui permet les confrences multiparti entre diffrents abonns la fois ; o Digital Echo Compensator (DEC) : cette unit permet la compensation des dlais des connexions entre rseaux fixes et rseaux mobiles ; o Operationally Controlled Annoucement Equipment
(OCANEQ) : cette unit est responsable des annoncements
22
Chapitre 2. Etude thorique et tat de lart standard ou individuels. Par exemple quand le crdit dun abonn a expir, il est prvenu grce ce type dannoncement. Et enfin, le Group Switch (GS) qui fait la commutation entre les LTU et les SU. La figure 9 illustre la composition des LTG :
2Mbps
TOG CR
8Mbps
Signalling Unit (SU)
Link Interface Unit (LIU)
Group Switch (GS)
Line Trunk Unit (LTU)
Liens SDC 8Mbps vers SN0 et SN1
DIU DEC COU OCANEQ CR
Line Trunk Unit (LTU)
Group Processor
Group Clock Generator
Figure 9 . Structure interne dun LTG.
2.1.6. Switching Network (SN)

Le SN est un rseau de commutation qui a pour rle de : Faire la connexion entre les LTG (connexion non permanente);
23
Chapitre 2. Etude thorique et tat de lart Faire lchange interne de messages entre les LTG, le SSNC et le CP via des canaux de messages fixes appels MCH (Message Channel) ; Vhiculer les messages de signalisation se trouvant sur les canaux de signalisations des liens MIC connectant les LTG et le SSNC. Le SN est dupliqu (on trouve le SN 0 et le SN 1) de telle sorte que si lun des deux SN tombe en panne cest lautre qui le remplace. En effet, pour les connexions de trafic seul un des deux SN est actif, lautre tant en mode de veille. Ainsi, tous les appels sont tout le temps connects aux LTG via les deux SN mais cest seulement le SN actif qui reoit les informations utilisateur parvenues travers les liaisons MIC. La structure interne dun SN dpend de son type, sil est de type B ou D. Un SN de type B est constitu des sous units suivantes : Time Stage Group (TSG) : cet lment effectue la commutation temporelle des liens SDC partir de ou allant vers les LTG et le MB. Space Stage Group (SSG) : cet lment interconnecte les TSG entre eux.
Le SN de type D, ou SN D par abus de langage, reprend les fonctions assures par le SN B mais permet de grer des ressources plus importantes en termes de nombre de LTG en plus de sa compatibilit avec tout type de LTG.
24

SDC:LTG 8 Mb/s
LTG N/M/P
SNMUX A
electr.
SDC:LTG 8 Mb/s
LTG N/M/P
S N M A T
SNMUX B
LTG P
LTG P
S N O P T
opt.
16*SDC:LTG 184 Mb/s
SN0 SN1 SDC:MBD-S1 SDC:MBD-S3 SDC:MBDH
SSNC
MBD CP
Figure 10 . Structure du SN D et connexion avec les autres n uds du MSC. Comme le montre la figure 10 [4], le SN D est constitu des sous units suivantes : Le Switching Network Multiplexer (SNMUX) : SNMUXA pour les liaisons lectriques et SNMUXB pour les liaisons optiques. Le SNMUX se charge de multiplexer les donnes venant de ou allant vers les LTG ; Le Switching Network Matrix (SNMAT) qui se charge de multiplexer les donnes des connexions entre SNMUX A et SNMUX B.
2.2. Interconnexion entre n uds du rseau

Pour le routage dun appel dun mobile un autre, il est ncessaire dinterconnecter les diffrents noeuds du rseau entre eux. Au sein du centre de commutation de TUNISIANA, linterconnexion se fait grce lquipement Digital Frame Distribution (DDF).
25
Chapitre 2. Etude thorique et tat de lart On distingue autant de DDF que de type de n ud dans le rseau. Ainsi, TUNISIANA utilise : Les DDF Transmission pour linterconnexion entre ses diffrents MSC si ces derniers ne co-existent pas dans le mme lieu par exemple pour interconnecter le MSC de Charguia celui de Mannouba; Les DDF BSS pour linterconnexion entre MSC et BSS ; Le DDF interco TT pour linterconnexion entre TUNISIANA et le rseau fixe et/ou mobile de Tunisie Telecom ; Ainsi que dautres DDF pour linterconnexion avec le rseau intelligent (IN) et le centre de service des messages courts (SMSC).
Conclusion
Tout au long de ce chapitre, on a introduit des notions thoriques sur larchitecture de lenvironnement D900 et sur ses quipements. Ces notions nous seront utiles pour la conception de notre base de donnes et le dveloppement de notre outil mais tout dabord il est ncessaire de dfinir les besoins de cet outil et son utilit par rapport larchitecture existante.
26
Chapitre 3. Spcification
Introduction
La spcification est la premire tape dans un projet. Cest une tape dterminante et qui se construit mesure que la problmatique est pose. Il est alors primordial de bien comprendre le sujet afin de cerner les problmes potentiels dun point de vue conceptuel, organisationnel et technique. Nous commencerons dans la premire partie par une tude de larchitecture existante pour en extraire dans une deuxime partie, les nouvelles orientations en terme de besoins. Finalement, une analyse dtaille sera ralise en utilisant les diagrammes de cas dutilisation.
1. Etude de lexistant
1.1. Prsentation de lexistant
Pour accder aux donnes relatives la gestion des ressources du c ur du rseau GSM, les utilisateurs du service NSS de TUNISIANA ont recours directement au Switch Commander qui se situe la salle de supervision des commutateurs au rez-de-chausse. Le Switch Commander leur affiche ltat de chaque lment du rseau ainsi que les disponibilits des ses ressources et leur permet de modifier ces donnes. Cette tche est dautant plus difficile que le nombre des lments du rseau ne cesse daugmenter dun jour lautre et leurs tats changent plusieurs fois dans une mme journe. Comme cas dutilisation du switch commander on cite : Le diagnostic sur ltat oprationnel des cartes LIC (Line Interface Card) comme le montre la figure suivante :
27
Figure 11 . Exemple dinterrogation de ltat des LIC du SSNC. Laffichage de la configuration actuelle dun DIU : le LTG auquel il appartient, la nature des liens sur ce DIU (signalisation ou trafic), son tat oprationnel, (voir figure 12) :
Figure 12 . Interrogation du LTG sur ltat dun DIU. La cration dun DIU sur un LTU appartenant un certain LTG (Voir figure 13) :
28
MSC2/D2MMPK1V9502-I21/003 15:54:54 4284 CA REMOTE#2 99-01-27 3098/00007
CRLTU:LTG=0-22,LTU=0,TYPE=D30,APPLIC=CCSCCS; EXEC D END JOB 4284
MSC2/D2MMPK1V9502-I21/003 16:03:43 4359 CA REMOTE#2 DISPLTU:LTG=0-22;
99-01-27 3102/01017
LTG LTU TYPE APPLIC MODVAR -----+----+-----+-------+--------------------------------------0-22 0 D30 CCSCCS 0-1 & 1-1 & 2-1 & 3-1 & 4-1 & 5-1 & 6-1 END JOB 4359
Figure 13 . Cration dun DIU et affichage de son tat.
1.2. Limites de lexistant

Vu la multitude et la diversit des informations ncessaires pour les besoins des utilisateurs du service NSS, le switch commander ne fournit pas la solution idale cause des problmes suivants :
On ne peut pas runir des informations concernant deux ou plusieurs quipements la fois. En effet, pour connatre, par exemple, la fois ltat oprationnel dun LTG et la configuration actuelle de ses LTU, il est ncessaire dexcuter les commandes statLTG (tat du LTG) et
dispLTU (affiche LTU) sparment de telle sorte quon obtient en rsultat les tats des LTG spcifis et les configurations des LTU demands sans avoir de correspondance entre les deux. Dans ce cas, il faudrait alors imprimer les deux rsultats et faire la correspondance manuellement ;
Laffichage dun rsultat est statique et pas trs lisible sous le format .txt. En effet, en excutant une commande depuis le switch commander, on ne peut pas contrler laffichage des informations de telle sorte que lon a parfois des informations affiches qui ne sont pas ncessaires mais qui, affiches, encombrent notre cran et rendent la lecture plus difficile. Les
29
Chapitre 3. Spcification employs qui travaillent la salle de supervision ont mme recours des crans de taille suprieure la moyenne (19 au lieu de 17) pour la consultation des donnes depuis le switch commander;
Il nest pas possible daccder distance au switch commander. En effet, il faudra se dplacer depuis le service NSS jusqu la salle de supervision autant de fois que ncessaire pour excuter des commandes ce qui constitue une perte de temps donc un inconvnient majeur de nos jours;
La manipulation du switch commander ncessite une connaissance parfaite des commandes utiliser ce qui nest pas le cas de tous les utilisateurs do la ncessit de leur offrir une formation adquate.
2. Spcification des besoins

Lapplication consiste donc regrouper les divers lments du c ur du rseau pour permettre leur affichage dans une structure claire et souple et pour pouvoir traiter les informations relatives ces lments et qui sont stockes dans la base de donnes de lapplication. Loutil doit donc disposer de plusieurs fonctionnalits qui doivent satisfaire toutes les tches cites, savoir :
Permettre les oprations dinsertion, de suppression et de mise jour dune faon aise des donnes relatives larchitecture matrielle des quipements du c ur du rseau. En effet lun des apports majeur de cette application cest sa capacit modliser les quipements du c ur du rseau sous une structure logique tout en respectant les spcificits techniques de chaque lment. Mais en raison de la complexit des spcificits techniques de ces quipements, il est indispensable, lors de la gestion de la configuration rseau, dintroduire des routines permettant linsertion et la suppression multiple des informations. Aussi la structure de lapplication doit assurer une facilit de navigation entre les lments en vue dune exploitation facile des informations.
Offrir lutilisateur la possibilit de faire des recherches complexes avec de simples manipulations graphiques sans quil ait connaissance dun
30
Chapitre 3. Spcification langage de manipulation de donnes. En ralit les utilisateurs de lapplication ne sont pas tous des connaisseurs du langage de base de donnes. Ceci impose que loutil doit fournir les moyens de crer des requtes dimport denregistrements sans que les utilisateurs aient recours la manipulation dun langage spcifique. Ceci est possible en offrant des outils graphiques dimport des informations voulues et en traduisant les choix graphiques vers le langage de manipulation de donnes adquat.
Dans le cas o les besoins des utilisateurs en terme de recherche dinformations ne sont pas satisfaits par lapplication, loutil doit fournir une interface de saisie de requtes conformment un langage de manipulation de donnes. En effet, en raison de la complexit que peut atteindre les requtes dimport, leur modlisation graphique peut dans certains cas tre impossible. Pour cela le seul moyen cest doffrir une interface de saisie directe des requtes conformment la base de donnes choisie.
Contrler
les
accs
lapplication
moyennant
une
procdure
dauthentification base sur un nom dutilisateur et un mot de passe et partageant les utilisateurs en des groupes ayant chacun des privilges conformes ses besoins.
3. Traduction des besoins en diagrammes des cas dutilisation

3.1. Objectifs des cas dutilisation
Un cas d'utilisation modlise un dialogue entre un acteur et le systme. C'est la reprsentation d'une fonctionnalit offerte par le systme. L'ensemble des cas d'utilisation forme toutes les faons possibles d'utilisation du systme. Les principaux objectifs des cas dutilisation sont :
Permettre de structurer les besoins des utilisateurs et les objectifs correspondants dun systme.
Centrer lexpression des exigences du systme sur ses utilisateurs. 31

Se limiter aux proccupations relles des utilisateurs : ils ne prsentent pas de solutions dimplmentation et ne forment pas un inventaire fonctionnel du systme.
Identifier les utilisateurs du systme (acteurs) et leurs interactions avec le systme.
3.2. Diagrammes des cas dutilisation

Vu le nombre important des actions du modle des cas dutilisation du systme et pour des raisons de simplification de la reprsentation, le modle va tre divis en diagrammes prsentant quelques unes des diverses fonctionnalits offertes par notre outil. Le schma qui suit reprsente une vue gnrale sur les diffrents cas dutilisation de notre application et ce suivant la mthodologie UML que lon a adopt (Voir Annexe C. Le langage de modlisation UML).
32
Figure 14 . Diagramme de cas dutilisation de lapplication. Les oprations dajout dans la base de donnes des diffrents lments du rseau figurent parmi les fonctionnalits principales que lapplication doit offrir. Pour assurer son volutivit, le systme doit galement offrir la possibilit de supprimer, ou de mettre jour lune des informations de la base de donnes tout en respectant les contraintes qui seront dfinies sur les donnes de la base. Ces diffrentes oprations ncessitent lidentification de lutilisateur. Lutilisateur peut dfinir les oprations dsires de deux manires : Il peut faire une saisie manuelle textuelle de sa requte en langage de manipulation de donnes. Il peut construire sa requte par lintermdiaire de linterface fournie par lapplication.
33
Chapitre 3. Spcification Seuls les utilisateurs connects avec un compte administrateur ont le droit de supprimer des tables de la base. Exemple de cas dutilisation : La cration dun DIU La figure 15 illustre une vue statique de la cration dun DIU.
Figure 15 . Diagramme de cas dutilisation de la cration dun DIU. Vu son emplacement physique dans le MSC, la cration dun DIU, ncessite dabord la prsence dun NE, dun TSG, dun LTG et dun LTU dans la base afin de respecter les contraintes de cls trangres dans cette dernire.
Conclusion
Dans le prsent chapitre nous avons prsent la spcification de notre application qui comprend une tude de lexistant et une spcification des besoins ainsi que les cas dutilisation de lapplication. Pour illustrer la concrtisation de la spcification, le chapitre suivant prsente la conception des diffrentes fonctionnalits de notre application.
34
Chapitre 4. Conception
Introduction
On sintresse dans ce chapitre la prsentation de la conception des diffrentes parties de notre projet menant la ralisation de notre application. Ainsi, en premier lieu, nous prsentons la conception de la base de donnes. Ensuite, nous abordons la conception des fonctionnalits de lapplication en donnant pour chacune delles, selon la mthodologie UML son diagramme de classes (Voir Annexe C. Le langage de modlisation UML).
1. Conception de la base de donnes

La conception de notre base de donnes est constitue de deux tapes : La premire tape est la modlisation de la problmatique traiter dun point de vue conceptuel et indpendamment du logiciel utilis. Le modle labor est alors appel Modle Conceptuel des Donnes (MCD) et est dcrit par le schma Entit-Association.
La deuxime tape traite de la construction de ce modle afin de le rendre directement exploitable par lapplication utiliser. Il sagit l du Modle Logique des Donnes (MLD) .
1.1. Le modle conceptuel des donnes (MCD)

On se propose dans ce qui suit de dfinir quelques lments de base du modle Entit-Association (appel aussi modle E/A) afin de mieux prsenter son schma par la suite.
1.1.1. Dfinition des lments de base du modle E/A

Le modle E/A est constitu de deux lments de base :
35
Chapitre 4. Conception Les entits qui sont des regroupements d'informations et qui possdent des attributs (caractristiques) ; Les associations qui sont les liens logiques entre les entits et qui sont quantifies par des cardinalits (nombre minimal et nombre maximal de fois ou on a recours une entit).
1.1.2. Schma entit-association

Notre base de donnes est compose des entits suivantes : NE : qui fait rfrence Network Element (lment du rseau). Cette entit contient entre autres des informations concernant le nom, le numro et le type dun lment du rseau ainsi que des informations sur la version de son software. TSG : elle contient les numros des TSG et des SSG. SNMUX : elle informe sur le type du SNMUX que contient le rseau de commutation de type D. CP : cette entit sert spcifier la configuration du processeur de coordination pour chaque lment du rseau. LTG : cest une entit qui fournit les informations concernant chaque LTG tels que son emplacement physique, le TSG auquel il est interconnect et les fonctionnalits quil supporte. LTU : cette entit nous informe sur le LTU et son application. DIU : cette entit sert identifier le DIU et le Trunk Group travers lequel il est connect au reste des lments du rseau. DEC : cette entit indique lemplacement physique et logique du module DEC ainsi que sa version. COU : cette entit sert prciser ltat du module COU. CR : Comme lentit prcdente cette entit indique ltat du module CR.
36
Chapitre 4. Conception OCANEQ : fournit des informations concernant lemplacement physique et logique du module OCANEQ ainsi que son tat oprationnel. TGRP : cette entit sert prciser lorigine et la destination du Trunk Group. PORT : cette entit sert identifier le port et le DIU auquel est reli ce port ainsi que le Trunk Group des liaisons entrantes au LTG en question. DDF_MSC : cette entit sert prciser les caractristiques de linterface dinterconnexion entre les diffrents MSC. DDF_BSS : cette entit sert prciser les caractristiques de linterface dinterconnexion entre MSC et BSS. DDF_INTERCO_TT : cette entit sert prciser les caractristiques de linterface dinterconnexion entre loprateur TUNISIANA et loprateur Tunisie Telecom. DDF_TRANSMISSION : cette entit fournit les informations concernant linterface dinterconnexion entre MSC spars par une distance physique. DDF_OTHERS : cette entit fournit les informations concernant linterface dinterconnexion entre MSC et les autres lments du rseau tels que le rseau intelligent ou IN (Intelligent Network) et le SMSC. Le schma suivant reprsente le modle conceptuel de la base de donnes :
37
Figure 16 . Schma E/A de la base de donnes (1).
38
LTU
Figure 17 . Schma E/A de la base de donnes (2).
39
1.2. Le modle logique des donnes (MLD)

Il sagit du passage dun concept de haut niveau (MCD) vers un concept de bas niveau (MLD). Le schma conceptuel prcdent nous permet de gnrer le modle logique suivant :
40
DIU
Figure 18 . Schma relationnel des tables (1).
41
LTU
Figure 19 . Schma relationnel des tables (2). Aprs avoir prsent les deux modles conceptuel et logique de notre base de donnes, il ne reste plus qu utiliser cette base pour la conception et la mise en uvre de notre application.
42
2. Architecture de lapplication
Afin de maximiser le degr de flexibilit du systme, on a opt pour une dmarche de modlisation et de conception modulaire ou objet. Le caractre abstrait du modle doit notamment permettre de faciliter la comprhension du systme. Il rduit sa complexit, permet de le reprsenter et de reproduire ses comportements. Concrtement, ce modle rduit la ralit, dans le but de rendre son utilisation simple. Ainsi, dans une premire partie, on sintressera la prsentation du langage de modlisation utilis, ensuite on dtaillera les diffrents modules constituant notre application savoir le module de configuration de la base de donnes, le module dinterrogation de la base de donnes ainsi que le module dauthentification. On procdera la prsentation de chacun de ces modules avec leurs diffrents diagrammes de classes.
2.1. Prsentation du langage de modlisation UML

UML ou Unified Modeling Language, que l'on peut traduire par "langage de modlisation unifi, est une notation permettant de modliser un problme de faon standard. Ce langage est n de la fusion de plusieurs mthodes existant auparavant savoir la mthode Object Modeling Language (OMT) de lanalyste Rumbaugh, la mthode BOOCH'93 de lanalyste Booch et la mthode Object Oriented Software Engineering (OOSE) de Jacobson [5]. Le langage UML est un langage qui s'appuie sur un mtamodle, un modle de plus haut niveau qui dfinit les lments d'UML (les concepts utilisables) et leurs smantiques (leurs significations et leurs modes d'utilisation)[6]. Le mtamodle permet de se placer un niveau d'abstraction suprieur car il est tudi pour tre plus gnrique que le modle qu'il permet de construire. Le mta-modle d'UML en fait un langage formel qui prsente plusieurs avantages qui ont motiv notre choix. Parmi ces avantages on cite :
43

Un langage sans ambiguts. Un langage universel pouvant servir de support pour tout langage orient objet.
Un moyen de dfinir la structure d'un programme. Une reprsentation visuelle permettant la communication entre les acteurs d'un mme projet.
Une notation graphique simple, comprhensible mme par des non informaticiens.
2.2. Architecture de lapplication

Notre application se compose essentiellement de trois modules qui interagissent entre eux et qui, ventuellement, font appel la base de donnes pour des oprations dimport de donnes ou mme de mise jour.
44
Application
Base de donnes
Module de configuration Serveur de base de donnes
Module dinterrogation
Module d authentification
Accs lapplication
Figure 20 . Vue d'ensemble de l'architecture de l'application.
2.3. Module de configuration de la base de donnes

Lapplication dvelopper doit pouvoir permettre lutilisateur de pouvoir configurer la base de donnes ce qui implique les oprations dinsertion, de suppression et de mise jour des enregistrements de la base et ce afin de pouvoir redimensionner les ressources du c ur de rseau selon les besoins. Comme exemple, on cite lopration dajout dun lien de signalisation sur un LTG x-x appartenant au trunk group ou TGRP identifi par le nom XXXX sur le MSC 03. La conception du module de configuration de la base de donnes se base sur lutilisation de plusieurs classes dont on cite les plus importantes savoir : La classe TablePage ; 45
Chapitre 4. Conception La classe CatalogPage; Et la classe Connection.
2.3.1. La classe TablePage

Il sagit de la classe la plus importante de ce module puisquelle soccupe des oprations dinsertion, de suppression et de mise jour des enregistrements de la base grce ses mthodes. Cette classe permet aussi de procder lexport des donns sous un format autre que le format HTML (Hyper Text Markup Language : langage utilis pour la gnration de pages web).
Figure 21 : La classe TablePage. Comme le montre la figure prcdente, cette classe utilise plusieurs mthodes ; On cite les principales savoir : GoInsertUpdate () : pour insrer ou mettre jour un enregistrement dans la base. Delete () : pour supprimer un enregistrement de la base. Export () : pour lexport des donnes.
46
Chapitre 4. Conception RowId () : qui retourne le numro dune colonne dun tableau. Cette mthode est extrmement utile pour laffichage par cellule. TableName() : elle retourne le nom de la table. Cette mthode est extrmement utile pour laffichage dynamique des tables de la base. SqlQuery () : qui prsente la plateforme de chaque requte SQL.
2.3.2. La classe CatalogPage

Cette classe est trs utile pour la navigation sur notre site. En effet sert crer et maintenir facilement une structure de navigation simple et pratique pour le site. Elle est galement trs utile pour personnaliser toutes formes de messages derreurs ou de message interactif avec lutilisateur.
Figure 22 . La classe CatalogPage. Les mthodes les plus importantes de cette classe sont : Pfoot () : pour laffichage statique du bas des pages. PHead () : pour laffichage des enttes des pages. Paging () : pour maintenir la structure de page et tablir les liens vers les autres interfaces. CheckErrors() : pour vrifier les erreurs. ErrMsg () : pour personnaliser et rcuprer les messages derreur qui peuvent se produire si par exemple un utilisateur tente de supprimer un enregistrement dans la base et qui est utilis par dautres tables.
47
Chapitre 4. Conception JsAlert () : pour la gestion des alertes concernant les utilisateurs (exemple si un champ de formulaire est vide un message est gnr pour informer lutilisateur de limportance de remplir ce champ). Le message est crit dans le langage Java Script.
2.3.3. La classe Connection

Les utilisateurs potentiels de notre application sont partags en groupes ayant chacun des privilges conformes ses besoins. Selon ces privilges la connexion la base se fait en utilisant des noms dutilisateurs et des mots de passe personnels. Cette classe sert rcuprer les informations ncessaires pour lauthentification des utilisateurs et les envoyer la base de donnes pour leur vrification.
Figure 23 : La classe connection. La classe connection possde comme attributs le nom dutilisateur, son mot de passe, le nom de la base de donnes ainsi que le nom de la connexion. Elle utilise galement : La mthode Connect() pour tablir la connexion la base en fonction des paramtres cits dessus ; La mthode Disconnect() pour la dconnexion ; La mthode ResetConnection() pour tablir une nouvelle connexion dans le cas o lutilisateur sest dconnect ou quil na pas pu se connecter la premire fois pour des raisons dauthentification.
48
2.3.4. Le diagramme de classe du module de configuration de la base

La figure suivante reprsente le diagramme de classes de ce module :
Connection -username -password -dbid -conn +Connect() +Disconnect() +ResetConnection()
Paging -pageN -itemN -rowperpage -defaultlastpage +Paging() +CalcPaging() +PageCount() +PageN() +ItemCout() +ItemN() +RowPerPage() +DefaultLastPage() leftMenuPage +Page() +Connection() +ResetConnetion() +PHead() +Login() +Logout()
Table +ListOfTables() +Fields() +BrowseSelect() +SqlInsertRows() +SqlCreateRows() +SqlCreateIndexe)() +SqlCreateTable() +IsViews() +GetNumRows() +Load()
Column -field -type -nullable -default +Column()
TablePage -sqlquery -rowid -tablename -selectfield -selectwhere -selectfieldscond -selectordercol -selectorder -exporttable -exporttype -exportdisplay -exportasfile -exportcompleteins +TablePage() +Load() +GoSql() +GoInsertUpdate() +Delete() +Empty() +Drop() +Select() +Export() +State() +SqlQuery() +RowId() +TableName() +SelectOrderCol()
CatalogPage Page +Page() +PHead() +PFoot() +PagingNavig() +PHead() +PFoot() +CheckErrors() +AfterSaveAction() +State() +Save() +Delete() +ErrMsg() +JsAlert() +RowperPage() +Paging()
Sql +SqlQuery()
Figure 24 . Diagramme de classes du module de configuration de la base de donnes.
49
2.4. Le module dinterrogation de la base de donnes

Une information peut tre disponible mais inaccessible tant donne la diversification des donnes et les masses volumineuses de dtails qui augmentent chaque jour. Par consquent, une personne qui cherche une information, doit avoir sa disposition des outils puissants qui permettent laccs aux donnes dsires dans des dlais raisonnables. Dans ce qui suit, nous allons dcrire la mthode adopte pour faire une recherche pousse dans notre base de donnes impliquant plusieurs tables. On prsentera ensuite le diagramme de classes utilis pour ce module.
2.4.1. Prsentation du systme de recherche dinformation

Un systme de recherche dinformation a pour objectif la manipulation dun ensemble denregistrements afin den extraire des informations utiles. Pour atteindre cet objectif, ce systme doit tablir une fonction de correspondance entre les mots cls taps par lutilisateur et les tables de la base concernes. La fonction essentielle dun tel systme est la recherche qui permet de visualiser toutes les tables rpondant un critre de recherche. La figure ci dessous illustre cette fonction :
50
Base de donnes
Recherche
Critres de recherche
Rsultat de la recherche
Figure 25 . Structure du systme de recherche.
2.4.2. Principe de la recherche

Pour raliser la fonction de recherche par mots cls, nous avons cr une table dans la base de donnes appele MOTS. La table MOTS est constitue de trois champs : Le champ Table qui contient la liste des noms des tables de la base ; Le champ Champ dans lequel figurent les champs de chaque table ; Et le troisime champ intitul Mots cls et qui contient la liste des mots cls ventuellement taps par lutilisateur et qui sont dduits des rflexions des utilisateurs de lapplication en leur voquant les champs des diffrentes tables. Linterrogation de la base sappuie sur cette table et suit les tapes suivantes : 1. Lutilisateur fait la saisie de ses critres de recherche ou mots cls. Une requte est alors formule partir de ces mots cls et envoye vers la base;
51
Chapitre 4. Conception 2. Phase de consultation du champ Mots cls de la table MOTS pour vrifier la prsence des mots cls taps. Sil ny a pas de concordance un message est alors affich pour le signaler. Si le ou les mots taps figurent dans le champ Mots cls la table alors on dtermine les noms des tables correspondantes. 3. Phase daffichage du formulaire de saisie qui comprend les tables, leurs diffrents champs avec le type de donnes saisir ainsi que les valeurs de ces champs qui sont chargs dynamiquement depuis la base. Dans cette tape, on donne aussi lutilisateur la possibilit de slectionner les informations quil veut afficher avant denvoyer sa requte. 4. Une fois le formulaire rempli, lutilisateur envoie sa requte vers le serveur qui lexcute et lui renvoie le rsultat sous format de table HTML. Le schma suivant illustre les tapes de cette recherche :
52
Figure 26 . Les tapes de recherche dans la base.
2.4.3. Le diagramme de classes du module dinterrogation de la base

Vu la complexit de ce module on a opt pour son dveloppement pour lutilisation de paquetages (ensemble de classes runies par fonctionnalit) qui soccupent de ses deux principales tches savoir lchange de requtes entre le serveur et la base de donnes dune part (paquetage DB_Query) et laffichage des informations sous format HTML (paquetage HTML) dautre part.
53
Chapitre 4. Conception Figure 27 . Paquetages du module d'interrogation de la base.

2.4.3.1. Le paquetage DB_Query
Ce paquetage fait appel trois classes qui sont : La classe Connection : Il sagit de la classe principale et laquelle font appel les autres classes DB et SQL. Cest la classe utilise dans le module de configuration de la base. La classe DB : Cette classe constitue une interface pour l'accs la base de donnes. Elle utilise entre autres les mthodes suivantes : o AffectedRows () : trouve le nombre de lignes affectes. o Commit () : enregistrer la transaction courante. o Execute () : excute une requte SQL prpare. o ExecuteMultiple () : excute une requte prpare SQL pour chaque lment d'un tableau. o GetCol () : rcupre le contenu dune colonne. o ListOftables : retourne la liste des tables de la base. La classe SQL : Cette classe est utilise pour lexcution des requtes SQL. Les mthodes de cette classe sont : o Insert () : insrer un enregistrement dans la base de donnes. o Update () : mettre jour des enregistrements. o Delete () : supprimer partir dune table. o Query () : envoyer une requte SQL. o OrderBy () : ajouter un ordre suivant des conditions. o GroupBy () : grouper suivant des conditions. o TableName () : retourne le nom dune table. o Keys () : retourne les cls dune table. o CheckErrors () : retourne un message derreur pour chaque type derreur.
54
Chapitre 4. Conception Lensemble de ces classes avec leurs mthodes forment le diagramme de classes du module de recherche que voici :
Figure 28 . Diagramme de classes du paquetage DB_Query.

2.4.3.2. Le paquetage HTML
Le paquetage HTML sert faciliter les oprations daffichage et de manipulation des donnes sous forme de formulaires. Il utilise plusieurs classes dont on cite : Classe HTML_Common : Cette classe fournit les fonctionnalits communes pour les autres classes. Elle utilise la mthode AnalyzeSourceCode () qui analyse le code source de chaque classe. Classe HTML_Javascript : Cette classe permet de gnrer les diffrents messages crits en langage JavaScript. Elle sert rendre laffichage interactif. Exemple : le changement de couleur dune ligne de tableau quand on elle est slectionne. Les mthodes de cette classe sont : o GetOnclickJs () : retourne le message java script pour lvnement onclick o SetJsWarnings () : initialise les messages derreurs java script. Classe HTML_TABLE : Cette classe sert HTML. Elle utilise les mthodes suivantes : crer des tableaux en format
55
Chapitre 4. Conception o AddCol (): ajoute une colonne. o AddRow () : ajoute une ligne. o GetCellContents () : retourne le contenu dune cellule. o GetColCount (): retourne le nombre de colonnes. o GetRowCount (): retourne le nombre de lignes. o SetColType (): affecte un type une colonne. o SetHeaderContents () : personnaliser lentte des cellules. o UpdateCellAttributes () : permet la mise jour des attributs des cellules. Classe HTML_Form : cest la classe quon utilise pour gnrer et grer les formulaires HTML. Les mthodes de cette classe sont: o ErrorMessage () : retourne un message derreur pour chaque type derreur. o IsError () : indique lexistence dune erreur. o Freeze () : fige un lment du formulaire. o Unfreeze () : opration inverse de freeze. o SetType () : initialise le type dlment. Classe HTML_Form_Element : Cest la classe de base pour les lments de formulaires. Elle hrite de la classe HTML_Form. On utilise cette classe pour ajouter un lment dans la page HTML. Elle se sert de la mthode ElementType() pour connatre la nature de llment ajouter au formulaire. De cette classe hritent les classes HTML_Form_Select utilise pour laffichage des listes droulantes et HTML_Form_Input utilise pour laffichage des zones de texte, les cases cocher, les boutons, On se contente dans ce qui suit de reprsenter le diagramme de classes du module de configuration en omettant de citer leurs diffrentes mthodes :
56
Figure 29 . Diagramme de classes du module de configuration de la base. Dans la figure 29, les traits discontinus indique une relation dhritage entre les classes (voir annexe C. Le langage de modlisation unifi UML), tandis que les relations trait simple indiquent une relation de type 1-1.
2.5. Le module dauthentification

Pour accder la base de donnes depuis lapplication, lutilisateur doit entrer son nom dutilisateur et son mot de passe : il sagit de la phase dauthentification.
57
Chapitre 4. Conception Pour raliser cette tape, on a dress une liste de tous les utilisateurs potentiels de notre application en leur donnant chacun un nom dutilisateur et un mot de passe. Ce dernier peut tre personnalis. Ensuite, on a cre une table dans notre base de donnes pour y stocker ces informations. Ainsi, chaque accs la base, ces donnes sont vrifies.
Oui
Non
Figure 30 . Processus d'authentification. La phase de vrification des donnes se fait grce la classe connection utilise dans les deux modules prcdents que lon a dj explicit dans la conception du module de configuration de la base (Voir la section 2.2.3. La classe connection).
Conclusion
Dans ce chapitre, on a prsent la conception de notre base de donnes et sur laquelle repose notre application. Ensuite on a dtaill larchitecture de notre application avec ses diffrents modules : le module de configuration de la base de donnes, le module dinterrogation de la base de donnes et le module dauthentification. A ce stade l, il ne reste plus qu implmenter lapplication.
58
Chapitre 5. Ralisation
Introduction
Aprs avoir tudi lexistant, exprim les besoins, procd une tude thorique et enfin spcifi et conu le systme raliser, il ne reste plus qu limplmenter. Ainsi, dans ce chapitre on prsentera les techniques utilises pour la ralisation de notre application, lenvironnement de dveloppement ainsi que les tapes de la ralisation.
1. Les techniques utilises

Comme pour toute application utilisant les bases de donnes, nous devons choisir la technique la plus adapte notre application pour pouvoir en bnficier au maximum et viter les inconvnients pouvant provenir des autres techniques. Notre application prsente une architecture trois niveaux comme le montre la figure suivante [6]:
Niveau 1 Requte http, fichiers, SQL,

Envoi des requtes
Niveau 2
Niveau 3
Requte SQL
Client
Envoi des reponses
Serveur applications
Serveur et base de donnes
Figure 31 . Architecture de l'application trois niveaux.

59
Chapitre 5. Ralisation Ainsi, on a besoin pour limplmentation de lapplication de : Un serveur dapplications ; Un serveur de base de donnes ; Un langage de programmation.
1.1. Le serveur dapplications

On a choisi comme serveur dapplications le serveur Apache pour les nombreux avantages quil a et dont on cite les plus importants : La performance : Apache possde sur le plan de la performance une excellence rputation. En effet, il permet deffectuer plusieurs contrles visant augmenter la performance du systme dont on peut mentionner : o Contrle des processus Apache sous Unix ou Windows. o Limitation de la bande passante. La scurit : le serveur Apache offre plusieurs moyens pour scuriser laccs aux ressources tels que : o Authentification des utilisateurs. o Scurisation des requtes par le protocole Secure Socket Layer (SSL) .
1.2. Le serveur de base donnes

Notre choix pour les serveurs de donnes sest port sur ORACLE. Ce choix est justifi dune part parce que lentreprise, dans laquelle ce projet a t ralis, possde une licence de ce produit qui est payant et dautre part parce que ORACLE prsente de nombreux avantages. En effet, ORACLE est incontestablement l'un des systmes de gestion les plus performants existant au march. Il est multi plateformes : les premires versions d'ORACLE tournaient sur des systmes Unix, et depuis, l'diteur a dvelopp
60
Chapitre 5. Ralisation des versions pour des plateformes de type Windows NT-2000-XP, et plus rcemment Linux [7]. Dans ses versions actuelles tel que ORACLE 8i, ORACLE est un systme rserv aux grandes entits car il ncessite de fortes contraintes de disponibilit. Oracle n'est pas consacr optimiser des petites bases de donnes. En effet, sur de petits volumes de traitements et avec peu d'utilisateurs, le serveur MySQL offre des performances quasi comparables Oracle. Par contre, ds que le volume de donnes devient trs important et qu'il y a un grand nombre d'utilisateurs, les carts de performance sont trs visibles et tournent l'avantage d'Oracle.
1.3. Choix du langage de programmation

Une premire analyse des possibilits de dveloppement montre une trs grande gamme de choix pour les langages de programmation dont nous pouvons citer : CGI ou Common Gateway Interface : cest un moyen simple et ancien pour la cration des sites web dynamiques. Linconvnient des CGI est labsence de contexte, du fait que le programmeur doit trouver seul les moyens techniques pour grer les sessions, ce qui constitue une norme charge de travail. ASP : Cest la technologie Active Server Pages qui a t labor par Microsoft dans le but de concevoir des applications Internet totalement dynamiques. Les scripts ASP peuvent effectuer de nombreuses tches comme accder des bases de donnes, gnrer un contenu HTML, grer des dossiers et autres fichiers directement sur le serveur hte, etc. Nanmoins, l'ASP est incapable de fonctionner sur des plateformes diffrentes de celles de Microsoft, c'est--dire les serveurs web de Microsoft Internet Information Server (IIS) de Windows NT ou 2000 ou encore sur le PWS (Personal Web Server) de Windows 95, 98, Millenium et XP. Le JSP ou Java Server Pages est un langage de script semblable ASP il a plusieurs avantages tels que la robustesse et la portabilit mais, lutilisation de ce composant peut introduire une lourdeur dexcution, de plus son dboguage
61
Chapitre 5. Ralisation (correction derreurs dans le code de programmation) est difficile par rapport celui du ASP. Le PHP ou Personal Home Page est un langage qui a t cr en 1994 par Rasmus Lerdorf pour les besoins des pages Web personnelles. C'est un langage incrust au HTML (c'est--dire qu'il s'crit en milieu du code HTML) et interprt (dans sa version 3) ou compil (dans sa version 4) du ct serveur. Il est extensible grce de nombreux modules qui multiplient ses fonctionnalits et son code source est ouvert. Comme il supporte tous les standards du Web et qu'il est gratuit, il s'est trs rpandu sur le web. Notre choix sest port sur PHP car il prsente les avantages suivants [6]:
La gratuit et la disponibilit du code source (PHP est distribu sous licence GNU GPL) ;
La simplicit d'criture de scripts ; La possibilit d'inclure le script PHP au sein d'une page HTML; La simplicit d'interfaage avec des bases de donnes (de nombreux Systme de Gestion de Base de Donnes (SGBD) sont supports tel que ORACLE) ;
L'intgration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.).
2. Environnement de dveloppement
2.1. Environnement matriel
Ce projet a t effectu dans lentreprise TUNISIANA. Nous avons bnfici des rcentes acquisitions matrielles de cette entreprise. Nous avons utilis pour les besoins de ce projet un micro-ordinateur dot de la configuration suivante : Intel Pentium IV 2.4 GHz, 512 RAM, Disque dur 80 Go. Ecran 17. Connexion au rseau Local de TUNISIANA.
62
2.2. Environnement logiciel

Pour les besoins de notre projet, nous travaillons avec lenvironnement Windows XP comme systme dexploitation, ORACLE 8i comme serveur de base de donnes et le logiciel EasyPHP qui regroupe le serveur Apache et le langage PHP.
3. Etapes de la ralisation
2.1 Cration de la base
La premire tche ralise lors du dveloppement de loutil de gestion des lments du c ur du rseau tait limplmentation de la base de donne sous ORACLE qui recueille les rsultats de tous les traitements effectus par le systme dvelopp. Ainsi, cette base devrait respecter le schma conu auparavant et les contraintes prvues.
2.2 Dveloppement de loutil

La deuxime tape dans la phase de ralisation concerne la cration des interfaces utiles pour le systme, lintgration des donnes lies la base et enfin, lcriture du code en PHP pour obtenir un systme fonctionnel.
3. Captures dcran
Cette partie est consacre la prsentation de quelques captures dcran du systme dvelopp au cours de ce stage.
3.1 Lauthentification
Chaque utilisateur doit sauthentifier avant de pouvoir accder son module. La figure suivante illustre les champs ncessaires remplir pour se connecter au serveur de donnes.
63
Figure 32 . Ecran d'authentification.
3.2. Interface principale

En cas de succs de lauthentification, lutilisateur pourra bnficier des services de lapplication moyennant une interface principale montre par la figure suivante :
Figure 33 . Interface principale.
64
Chapitre 5. Ralisation Linterface principale prsente lutilisateur les diffrentes tables de la base, elle prsente la majorit des fonctionnalits de lapplication. Lutilisateur a accs ces tables soit : Pour insrer un enregistrement, en cliquant sur le lien Insert. Pour supprimer un enregistrement, en cliquant sur le lien Empty Pour supprimer une table, en cliquant sur le lien Drop. Pour consulter la structure de la base, en cliquant sur le lien Structure. Pour rechercher des enregistrements dans la base, en cliquant sur le lien Select. Pour afficher une table en cliquant sur le lien Browse.
3.3. Insertion dans la base

Aprs avoir choisi la table dsire et en cliquant sur le lien insert de linterface prcdente, interface dinsertion saffiche lutilisateur. Il pourra alors remplir les champs indiqus pour ajouter un lment (Voir figure 34). Il est noter que linterface de suppression des enregistrements de la base est similaire cette interface une seule diffrence prs cest que lutilisateur doit choisir la valeur de lenregistrement supprimer et non pas la remplir.
65
Figure 34 . Interface d'insertion.
3.4. Interface de consultation de table

La figure 35 prsente linterface de consultation de la base. Lutilisateur doit spcifier les champs quil dsire afficher, il a le choix entre afficher le rsultat dans un ordre ascendant ou descendant.
66
Figure 35 . Interface de consultation. Les paramtres quon a spcifi (afficher les champs NE_ID, TSG_ID, LTG_ID et LTG_TYPE pour NE_ID=1111) donnent le rsultat suivant :
Figure 36 . Rsultat de l'affichage.
67
3.5. Interface de requte manuelle

Dans le cas o il est impossible de gnrer dynamiquement une requte, lutilisateur a recours une interface o il peut entrer manuellement ses propres requtes. Lutilisateur peut aussi importer un fichier dj crit et lexcuter.
Figure 37 . Interface de requte manuelle.
3.6. Interface du moteur de recherche

Le moteur de recherche offre lutilisateur la possibilit de faire des recherches complexes. La figure 38, reprsente la premire interface de ce moteur, o lutilisateur est amen introduire les mots cls sujets de la recherche quil dsire effectuer. Les figures 39, 40 et 41, illustrent les tapes de cette recherche :
68
Figure 38 . Interface de saisie des mots cls. La figure 39 prsente linterface permettant dafficher les tables correspondantes aux critres de la recherche.
Figure 39 . Affichage des tables correspondant la recherche. Une fois la table dsire choisie (LTG dans cet exemple), une liste des champs de cette table saffiche lutilisateur il ne lui reste plus qu spcifier les champs quil dsire afficher grce des cases cocher.
69
Figure 40 . Spcification des critres d'affichage.
Figure 41 . Rsultat de la recherche.
Conclusion
Dans le prsent chapitre nous avons prsent une tude de lensemble des outils choisis pour la ralisation de notre application. Nous avons galement prsent les tapes de la ralisation de notre projet ainsi que quelques captures dcran de lapplication ralise.
70
Conclusion gnrale
Conclusion gnrale
Au terme de ce rapport, on peut conclure que ce stage de fin dtudes ma donn une occasion opportune me permettant de confronter l'acquis thorique l'environnement pratique. En effet, ce stage m'a permis de prendre certaines responsabilits, et de montrer de plus en plus mes connaissances thoriques et pratiques. Cest l que rside la valeur dun tel projet de fin dtudes qui joint les exigences de la vie professionnelle aux cots bnfiques de lenseignement pratique que jai eu lEcole Suprieure des
Communications de Tunis. On a donc conu et dvelopp tout au long de quatre mois de stage un outil informatique de gestion des lments du c ur du rseau qui permet lentreprise une gestion plus efficace et une visibilit dtaille de tous les composants du c ur de son rseau GSM. Dun point de vue technique, ce projet ma permis de madapter avec lenvironnement des tlcommunications ainsi que les quipements constituant le centre de commutation des services mobiles qui joue un rle trs important et principal dans le fonctionnement du rseau GSM. Ce travail peut tre sans doute amlior en ajoutant dautres fonctionnalits qui enrichissent le systme et automatisent quelques tches comme la cration automatique des lments constituants un n ud du rseau suite la spcification de la nature du matriel utilis. En plus, il peut tre tendu par une analyse statistique, par des reprsentations graphiques relatives aux statistiques ou aux requtes personnalises, par des diagrammes de type histogramme, etc.
71
Annexe A. Statistiques sur le GSM
Les annexes Annexe A. Statistiques sur le GSM

"Les communications GSM dominent toujours le secteur des tlcommunications mobiles", a soulign dans un communiqu la GSM Association (GSMA). Selon les chiffres publis par la GSMA et lEMC World Cellular Database [7]: Le nombre d'abonns au GSM norme europenne de tlphonie mobile pour la transmission de la voix et des messages courts, aurait dcupl depuis 1997. Ces 12 derniers mois, la croissance des communications GSM au niveau mondial sest poursuivie avec plus de 160 millions de nouveaux clients. A la fin de lanne 2003, le nombre dabonns au GSM devrait atteindre le seuil du milliard, figure A.1. Alors qu la fin de lanne 2002, le nombre de clients a t estim 787 millions d'individus rpartis dans 190 pays.
Figure A. 1 Rpartition des abonns GSM. "Une personne sur sept utilise dsormais des services GSM dans le monde. La croissance se poursuit, ces communications reprsentant dsormais 72% du march mondial des tlcommunications numriques sans fil", a soulign Craig EHRLICH, Vice-prsident de la GSMA et Directeur gnral de l'oprateur hongkongais SUNDAY Communications.
72
Annexe A. Statistiques sur le GSM Huit oprateurs de tlcommunications numriques mobiles sur dix ayant choisi leur technologie de nouvelle gnration, ont opt pour les plates-formes GSM GPRS et W-CDMA et y ont investi des milliards de dollars. L'Association estime que plus de 140 rseaux GPRS ont t dploys commercialement dans le monde, 40 autres seraient actuellement en construction. Grce eux, les clients peuvent bnficier de services tels que le multimdia mobile (MMS - mobile multimdia services). Regroupement international (Vodafone, Orange, T-Mobile, NTT DoCoMo, China Mobile, Singtel Optus, Telefonica, AT&T Wireless, etc.), la GSM Association reprsente les intrts de plus de 660 oprateurs de tlphonie mobile de seconde et de troisime gnration, fabricants et quipementiers tlcoms.
73
Annexe B. La signalisation SS7
Annexe B. La signalisation SS7

Le systme de signalisation numro 7 (SS7 ou C7, CCITT no7 ou CCS7) est un composant critique des systmes modernes de tlcommunications. SS7 est un protocole de transmission qui fournit la signalisation et la commande pour diffrents services et possibilits de rseau. Tandis que lInternet, les donnes sans fil, et la technologie relative ont attir lattention des millions, beaucoup ngligent ou ne se rendent pas compte de limportance de SS7. Chaque appel dans chaque rseau dpend de SS7. SS7 est une norme globale pour des tlcommunications dfinies par le secteur international dtalonnage de tlcommunication des syndicats de tlcommunication (ITU)[9]. La norme dfinit les procdures et le protocole par lesquels des lments de rseau dans linformation commute publique dchange du rseau tlphonique (PSTN) au-dessus dun rseau de signalisation numrique pour effectuer linstallation de radio (cellulaire) et dappel de cble, le cheminement et la commande. SS7 a t conu pour amliorer lopration de rseau et pour fournir les services augments. La norme a t sortie pour des variations pays-spcifiques multiples, telles que les normes du American National Standards Institute (norme ANSI) et des technologies de Telcordia (autrefois Bell Communications Research, Bellcore) dans lAmrique du Nord, et lInstitut Europen pour les Normes de Tlcommunications (ETSI) en Europe. Le rseau SS7 et ces protocoles sont utiliss pour : Ltablissement, ladministration et larrt des appels ; Les services lis aux mobiles (roaming, authentification) ; Les services lis aux numros spciaux (numro vert) ; Des fonctions avances comme le transfert dappel, laffichage de lappelant, la confrence trois, etc ; Lamlioration et la scurisation des communications internationales.
74
Annexe C. Le langage de modlisation UML

1. Prsentation dUML
UML est un langage de modlisation dvelopp conjointement par Grady Booch, Yvar Jacobson et Jim Rumbaugh de Rational Software Corporation en 1994. Ce langage permet de modliser de manire claire et prcise la structure et le comportement dun systme indpendamment de toute mthode ou de tout langage de programmation. Pour la modlisation dun systme, UML dfinit neuf types de diagrammes[8] diviss en deux parties : une partie statique qui reprsente la structure du systme et une partie dynamique qui reprsente son comportement comme le montre le tableau suivant :
Statique (structure) Dynamique (comportement)
Diagramme de cas dutilisation Diagramme de classes Diagramme objet Diagramme de composants Diagramme de dploiement
Diagramme de collaboration Diagramme de squence Diagramme tat/transition Diagramme dactivits
Tableau 1. Les diagrammes d'UML. Nous allons prsenter dans ce qui suit le diagramme de classes que lon a utilis pour la conception des modules de notre application.
1.1. Le diagramme de classes

Les diagrammes de classes expriment de manire gnrale la structure statique dun systme, en termes de classes et de relations entre ces classes. Une classe permet de dcrire un ensemble dobjets (attributs et comportements), tandis quune relation ou une association permet de faire apparatre des liens entre ces objets. On peut donc dire : Un objet est une instance de classe ; Un lien est une instance de relation.
75
Annexe C. Le langage de modlisation UML Le diagramme de classes est un modle permettant de dcrire de manire abstraite et gnrale les liens entre objets.
2.1. Les classes

Une classe est une description dun ensemble dobjets partageant la mme smantique, ainsi que les mmes attributs, oprations et relations. Une classe dobjet est reprsente par un rectangle comprenant trois parties : nom de la classe, attributs et oprations (mthodes). Les listes des attributs et des oprations sont toutefois optionnelles, suivant le degr de dtail recherch dans un diagramme : ces parties peuvent tre vides ou mme absentes. Nom de la classe
Attributs Oprations Figure C. 2 Reprsentation graphique d'une classe.
2.2. Les associations

Une association reprsente une relation structurelle entre classes dobjets. La plupart des associations sont binaires, cest dire quelles connectent deux classes. On reprsente une association en traant une ligne entre les classes associes. Il existe plusieurs types dassociations tels que lassociation dagrgation, lassociation de composition ou encore celle dhritage que lon a utilis dans notre diagramme de classes. Le mcanisme dhritage permet une classe de rutiliser les attributs et les mthodes dautres classes. Cest un puissant outil de modlisation qui permet dlever les niveaux dabstraction des modles tout en augmentant la lisibilit des graphiques puisque les attributs redondants ne sont prsents quune seule fois.
76
3. Le diagramme de cas dutilisation

Les cas dutilisation sont une technique de description du systme tudi privilgiant le point de vue de lutilisateur. Les cas dutilisation dcrivent sous la forme dactions et de ractions, le comportement dun systme du point de vue dun utilisateur. Les cas dutilisation servent structurer les besoins des utilisateurs et les objectifs correspondants du systme.
3.1 Elments constitutifs du diagramme de cas dutilisation

Un diagramme de cas dutilisation est constitu de : Un acteur : cest une entit externe qui agit sur le systme. Le terme acteur ne dsigne pas seulement les utilisateurs humains mais galement les autres systmes. Un cas dutilisation : cest un ensemble dactions ralises par le systme en rponse une action dun acteur.
3.2 Relations entre les cas dutilisation

Parmi les types de relations standardises entre cas dutilisation dfinis par UML on cite : La relation dinclusion formalise par la notation include , en franais utilise . En effet, lors de la description des cas dutilisation, il apparat quil existe des sous-ensembles communs plusieurs cas dutilisation, il convient donc de factoriser ces fonctionnalits en crant de nouveaux cas dutilisation qui seront utiliss par les cas dutilisation qui les avaient en commun. La relation dextension formalise par la notation extend , en franais tend . Elle permet d'tendre les interactions et donc les fonctions dcrites par les interactions.
77
Glossaire
Glossaire A
AMP : ATM Bridge Processor. ASN : ATM Switching Network. AUC : Authentication Center.
G
GCG : Group Clock Generator. GP : Group Processor. GS : Group Switch. GSM : Global systems for mobile.
B
BAP : Base Processor. BSC : Base Station Controller. BSS : Base Station Subsystem. BTS : Base Transceiver Station.
H
HLR : Home Location Register.
L
LIC : Line Interface Card. LIU : Link Interface Unit. LTG : Line Trunk Group. LTU : Line/Trunk Unit.
C
CAP : Call Processor. CG : Clock Generator. CMY : Common Memory. COU : Conference Unit. CP : Call Processing. CP : Coordination Processor. CR : Code Receiver.
M
MB : Message Buffer. MP : Main Processors.
D
DIU : Digital Interface Unit. DDF : Digital Frame Distribution. DEC : Digital Echo Compensator.
MSC : Mobile-Services Switching Center.
78
Glossaire SDC : Secondary Digital Carrier.
N
NSS : Network SubSystem.
SEP : Signalling End Point. SN : Switching Network. SNMAT : Switching Network Matrix. SNMUX : Switching Network Multiplexer. SSG : Space Stage Group. SSNC : Signalling System Network Control. STP : Signalling Transfert Point. SU : Signalling Unit.
O
OCANEQ : Operationally Controlled Annoucement Equipment. OMC : Operation and Maintenance Center.
P
PDC : Primary Digital Carrier. PLMN : public land mobile network.
T
TGRP : Trunk Group. TSG : Time Stage Group.
S
SC : Switch Commander.
V
VLR : Visitor Location Register.
79
Bibliographie
Bibliographie
[1] Site web du rseau local de TUNISIANA appel OPTINET, 2005.
[2] A. Charbonnier, C. Hartmann, R. Thomas- Les architectures des rseaux mobiles-
mmento technique N 9 du Conseil scientifique de France Tlcom, 10 juin 1997. [3] X. Lagrange, P. Godlewski, S. Tabbane Rseaux GSM-DCS des principes la norme Editions HERMES 1997. [4]
Document
de
formation
SIEMENS PLMN
MN2512EU10MN_0001
et
MN2512EU10MN_0002 2005. [5] Frdric Brouard Petit guide d'analyse des donnes l'aide de la mthode MERISE du site www.developpez.com 2005. [6] CommentCaMarche.net Introduction la notation UML Encyclopdie informatique libre version 2.0.4 2005. [7] URL : http://didier.deleglise.free.fr [8] URL : http://www.gsmworld.com/news/statistics/index.shtml$
[9] Le rseau smaphore numro 7 : Principe, architecture et protocoles. URL : www.efort.com
80
Rsum
Le prsent travail entre dans le cadre du projet de fin dtudes pour lobtention du diplme national dingnieur en tlcommunications.
Il sagit de la ralisation dun outil de gestion des lments du rseau GSM de
TUNISIANA permettant une gestion efficace et offrant une visibilit dtaille des composants les plus importants du c ur du rseau GSM. Il offre ainsi une solution la gestion des quipements du sous-systme rseau devenue difficile vu leur nombre sans cesse croissant. Mots cls : Rseau GSM, quipements MSC, conception de bases de donnes,
Abstract
The present work is carried out as an end of studies project to obtain the national diploma of Telecommunications Engineer. In fact, it deals with realizing a GSM network elements management tool for TUNISIANAs GSM network which would enable an efficient management and a detailed view for the most important components of the GSM core network. Therefore, it offers a solution to the management of the hardware core network equipment which was made difficult because of their increasing number. Keywords : GSM network, MSC equipments, database design,

PFE SAIDI Emna

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PFE SAIDI Emna

Enviado por

Direitos autorais:

Formatos disponíveis

RAPPORT DE PROJET DE FIN DETUDES

Ingnierie des rseaux des tlcommunications

DEVELOPPEMENT DUN OUTIL DE GESTION DES ELEMENTS RESEAU

Mme. Malek Ben Youssef M. Montasser Derbel

Anne universitaire : 2004/2005

A mes oncles et mes tantes. A mes cousins et cousines. A mes amis.

1.1. Prsentation gnrale de TUNISIANA .................................................................. 6 1.2. Organisation de TUNISIANA ................................................................................ 7

1.1. Prsentation de lexistant....................................................................................... 27 1.2. Limites de lexistant .............................................................................................. 29

Projet de fin dtudes

Anne universitaire : 2004/2005

2.1. Environnement matriel ........................................................................................ 62 2.2. Environnement logiciel ......................................................................................... 63

2.1 Cration de la base.................................................................................................. 63 2.2 Dveloppement de loutil ....................................................................................... 63

Projet de fin dtudes

Anne universitaire : 2004/2005

Liste des Figures

Liste des figures

Projet de fin dtudes

Anne universitaire : 2004/2005

Projet de fin dtudes

Anne universitaire : 2004/2005

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 1. Prsentation du cadre de travail et du sujet

Chapitre 1. Prsentation du cadre de travail et du sujet

1. Prsentation de lorganisme daccueil

Projet de fin dtudes

Anne universitaire : 2004/2005

1.2. Organisation de TUNISIANA

Direction Gnrale (DG)

Chef Financier Officier

Direction Administrative et Financire (DAF)

Direction Qualit et Programme (DQP)

Direction Marketing (DM)

Direction des Vente (DV)

Direction Service Client (DSC)

Direction Technique (DT)

Direction des Systmes Information (DSI)

Direction des Ressources Humaines (DRH)

Figure 1 . Organigramme de TUNISIANA.

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 1. Prsentation du cadre de travail et du sujet

DEPARTEMENT ARCHITECTURE ET DEPLOIEMENT

DEPARTEMENT INGENIERIE ET DEVELOPPEMENT

DEPARTEMENT OPERATION & MAINTENANCE

Figure 2 . Organigramme de la direction technique.

Dpartement Architecture et dploiement

Dpartement Opration et maintenance

Dpartement Ingnierie et Dveloppement

Projet de fin dtudes

Anne universitaire : 2004/2005

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

Chapitre 2 Etude thorique et tat de lart

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

1.1. Le sous-systme radio

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

1.2. Le sous-systme rseau