Vous êtes sur la page 1sur 84

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

Anne universitaire : 2004/2005

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

Projet de fin dtudes

Anne universitaire : 2004/2005

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

Projet de fin dtudes

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

Anne universitaire : 2004/2005

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

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

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.

Projet de fin dtudes

Anne universitaire : 2004/2005

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 :

Projet de fin dtudes

Anne universitaire : 2004/2005

Chapitre 1. Prsentation du cadre de travail et du sujet

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.

Projet de fin dtudes

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

Anne universitaire : 2004/2005

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

Projet de fin dtudes

10

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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.

Projet de fin dtudes

11

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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

Projet de fin dtudes

12

Anne universitaire : 2004/2005

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
Projet de fin dtudes

13

Anne universitaire : 2004/2005

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

Projet de fin dtudes

14

Anne universitaire : 2004/2005

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

Projet de fin dtudes

15

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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.

Projet de fin dtudes

16

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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

Projet de fin dtudes

17

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

18

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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

[*]

Projet de fin dtudes

19

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

20

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart

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.

Projet de fin dtudes

21

Anne universitaire : 2004/2005

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

Projet de fin dtudes

22

Anne universitaire : 2004/2005

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

Projet de fin dtudes

23

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

24

Anne universitaire : 2004/2005

Chapitre 2. Etude thorique et tat de lart


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

Projet de fin dtudes

25

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

26

Anne universitaire : 2004/2005

Chapitre 3. Spcification

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 :

Projet de fin dtudes

27

Anne universitaire : 2004/2005

Chapitre 3. Spcification

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

Projet de fin dtudes

28

Anne universitaire : 2004/2005

Chapitre 3. Spcification
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

Projet de fin dtudes

29

Anne universitaire : 2004/2005

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

Projet de fin dtudes

30

Anne universitaire : 2004/2005

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


Anne universitaire : 2004/2005

Projet de fin dtudes

Chapitre 3. Spcification

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

Projet de fin dtudes

32

Anne universitaire : 2004/2005

Chapitre 3. Spcification

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.

Projet de fin dtudes

33

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

34

Anne universitaire : 2004/2005

Chapitre 4. Conception

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 :

Projet de fin dtudes

35

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

36

Anne universitaire : 2004/2005

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 :

Projet de fin dtudes

37

Anne universitaire : 2004/2005

Chapitre 4. Conception

Figure 16 . Schma E/A de la base de donnes (1).

Projet de fin dtudes

38

Anne universitaire : 2004/2005

Chapitre 4. Conception

LTU

Figure 17 . Schma E/A de la base de donnes (2).

Projet de fin dtudes

39

Anne universitaire : 2004/2005

Chapitre 4. Conception

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 :

Projet de fin dtudes

40

Anne universitaire : 2004/2005

Chapitre 4. Conception

DIU

Figure 18 . Schma relationnel des tables (1).

Projet de fin dtudes

41

Anne universitaire : 2004/2005

Chapitre 4. Conception

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.

Projet de fin dtudes

42

Anne universitaire : 2004/2005

Chapitre 4. Conception

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 :

Projet de fin dtudes

43

Anne universitaire : 2004/2005

Chapitre 4. Conception

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.

Projet de fin dtudes

44

Anne universitaire : 2004/2005

Chapitre 4. Conception

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
Anne universitaire : 2004/2005

Projet de fin dtudes

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.

Projet de fin dtudes

46

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

47

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

48

Anne universitaire : 2004/2005

Chapitre 4. Conception

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.

Projet de fin dtudes

49

Anne universitaire : 2004/2005

Chapitre 4. Conception

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 :

Projet de fin dtudes

50

Anne universitaire : 2004/2005

Chapitre 4. Conception

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;

Projet de fin dtudes

51

Anne universitaire : 2004/2005

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 :

Projet de fin dtudes

52

Anne universitaire : 2004/2005

Chapitre 4. Conception

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.

Projet de fin dtudes

53

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

54

Anne universitaire : 2004/2005

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

Projet de fin dtudes

55

Anne universitaire : 2004/2005

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 :

Projet de fin dtudes

56

Anne universitaire : 2004/2005

Chapitre 4. Conception

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.

Projet de fin dtudes

57

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

58

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.


Projet de fin dtudes

59

Anne universitaire : 2004/2005

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

Projet de fin dtudes

60

Anne universitaire : 2004/2005

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

Projet de fin dtudes

61

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

62

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

63

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

64

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

65

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

66

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

67

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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 :

Projet de fin dtudes

68

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

69

Anne universitaire : 2004/2005

Chapitre 5. Ralisation

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.

Projet de fin dtudes

70

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

71

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

72

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

73

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

74

Anne universitaire : 2004/2005

Annexe C. Le langage de modlisation UML

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.

Projet de fin dtudes

75

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

76

Anne universitaire : 2004/2005

Annexe C. Le langage de modlisation UML

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.

Projet de fin dtudes

77

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

78

Anne universitaire : 2004/2005

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.

Projet de fin dtudes

79

Anne universitaire : 2004/2005

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

Projet de fin dtudes

80

Anne universitaire : 2004/2005

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,