Mmoire de fin dtudes Pour lobtention du diplme dIngnieur dEtat en Informatique Option : Systmes dinformation

Thme

CONCEPTION ET REALISATION DUN SYSTEME DE GETION DE LA SUPERVISION DU RESEAU GSM

Guellab Eloued Moustapha - Amari Mohamed Elamine

Encadr par : HIDOUCI W.K - Abdelmoumene Abdallah

Promotion : 2010/2011

Rsum
Notre projet consiste au dveloppement dun systme de gestion de la supervision pour une compagnie de tlcommunication ( Orascom telecom algerie) ; une socit consciente de la qualit, ralise l'importance d'avoir des outils efficaces de gestion du rseau pour assurer la disponibilit maximum de couverture et atteindre un statut stable du rseau, ce qui assure une qualit suprieure de service. Le rle principal de l'quipe de supervision est la surveillance du rseau et la dtection des anomalies pour rsoudre les dfauts avant que l'abonn ne commence prouver son impact. Mais pour atteindre ce but, il y a beaucoup de dfis relever. Tel le flou et le manque dinformation reprsentes dans les alarmes remontes par lO.M.C (opration and maintenance center) afin de prciser la nature du problme et son impact sur la couverture de rseau ce qui impose une difficult lors de la rsolution des problmes qui se base fortement sur lexprience et lintelligence de lingnieur de supervision qui varie dune personne a une autre. Dautant plus, il n'existe aucun mcanisme pour intgrer les bases de donnes, tout se fait par l'quipe de la supervision manuellement. Au cours de ce projet de fin d'tude, nous voulons atteindre l'objectif vis qui consiste la mise en place d'une application pour la supervision qui sera l'espace de travail des ingnieurs de la supervision et qui assure des fonctionnalits permettant aux superviseurs de grer au mieux les alarmes ressortissant des diffrentes stations de supervision et des diffrents lments du rseau ainsi que les taches relatives au gestion du rseaux tel que le Reporting et le suivi de la rsolutions des problmes signals au intervenant.

Table des matires

7.1

Table des matires

Table des matires

Table des matires

Table des figures :

Figure 1: figure reprsentant un motif lmentaire (a gauche) et un ensemble de motifs dans un rseau (a droite) . ................................................................................................................. 19 Figure 2: architecture du rseau GSM ................................................................................... 20 Figure 3: les informations gres par le HLR . ....................................................................... 23 Figure 4: interfaces GSM . ...................................................................................................... 27 Figure 5: structures des 5 types de burst dfinis par la norme GSM . .................................... 30 Figure 6: Le format d'un message court. ................................................................................. 32 Figure 7: figure montre un rseau de gestion de tlcommunications TMN ......................... 35 Figure 8: figure montre un centre d'opration et de maintenance .......................................... 36 Figure 9: schma reprsentant une architecture type de rseau d'entreprise........................... 44 Figure 10: les diffrant filial du groupe OT dans le monde. ................................................... 50 Figure 11: les diffrant centres de services et les siges dOTA ............................................ 53 Figure 12: organigramme dOTA ........................................................................................... 54 Figure 13: les taches de travail dans le centre de la supervision dOTA ................................ 64 Figure 14: le diagramme de contexte ...................................................................................... 72 Figure 15: diagramme du cas dutilisation authentification au systme ........................... 74 Figure 16: diagramme du cas dutilisation gestion des sites ............................................... 74 Figure 17: diagramme du cas dutilisation gestion des contacts ........................................ 76 Figure 18: diagramme du cas dutilisation gestion des societes partenaire ....................... 77 Figure 19: diagramme du cas dutilisation gestion des alarmes.......................................... 79 Figure 20: diagramme du cas dutilisation travaux programmes........................................ 80 Figure 21: diagramme du cas dutilisation traitement des alarmes ..................................... 81 Figure 22: diagramme du cas dutilisation alerte par sms................................................... 82 Figure 23: diagramme du cas dutilisation alerte par mail.................................................. 83 Figure 24: diagramme du cas dutilisation gestion des tt.................................................... 84 Figure 25: diagramme du cas dutilisation escalade........................................................... 86 Figure 26: diagramme du cas dutilisation gestion des rapports ........................................ 87 Figure 27: diagramme du cas dutilisation feedback .......................................................... 88 Figure 28: le package administration ................................................................................ 91 Figure 29: le package gestion des alertes .......................................................................... 92 Figure 30: le package gestion des ticket ............................................................................ 93 Figure 31: le package statistique et rapports ..................................................................... 94

Figure 32: diagramme de classe associe a la gestion dadministrateur................................... 95 Figure 33: diagramme de classe associe a la gestion des utilisateurs. .................................... 96 Figure 34: diagramme de classe associe a la gestion des travaux programmes. ..................... 96 Figure 35: diagramme de classe associe a la gestion des alertes. ........................................... 97 Figure 36: diagramme de classe associe a la gestion des tickets. ........................................... 98 Figure 37: diagramme de classe associe a la gestion des rapports.......................................... 99 Figure 38: diagramme de squence de lauthentification systme........................................ 103 Figure 39: diagramme de squence gestion des sites............................................................ 104 Figure 40: diagramme de squence traitements des alarmes................................................. 105 Figure 41: diagramme de squence de lalerte par SMS....................................................... 105 Figure 42: diagramme de squence gestion des TTS............................................................ 106 Figure 43: diagramme de squence des travaux programmes............................................... 107 Figure 44: diagramme de squence gestion des rapports...................................................... 108 Figure 45: diagramme de squence des feedback. ................................................................ 109 Figure 46: diagramme dactivits gestion des sites............................................................... 110 Figure 47: diagramme dactivits gestion des alertes. .......................................................... 111 Figure 48: diagramme dactivits publier rapports. .............................................................. 112 Figure 49: schma dtaille de la solution propose............................................................... 113

Table des tableaux :

Tableau 1: interfaces GSM .................................................................................................... 27 Tableau 2: les diffrentes filiales du groupe OT dans le monde et sa part de marche............ 51 Tableau 3: lhistorique dOTA................................................................................................ 52 Tableau 4: liste des cas dutilisation. ...................................................................................... 74 Tableau 5: description des classes. ....................................................................................... 102

Liste abrviations:
AUC BSC BSS BTS DCN DCS EIR GMSC GPRS GSM HLR HS IMEI IMSI MAP MSC MS NE NMC NMS NSC NSS OMC OSS OTA OTH PDH QoS RTC RTCP SDH Authentification Center Base Station Controller Base Station System Base Transmitter Station Data communication network Digital Cellular System L'enregistreur des identits des quipements. Gateway Mobile Service Switching Centre General packet radio service Global System for Mobile communication Home Location Registrer Hors service International Mobile station Equipment Identity. International Mobile Subscriber Identity. Management application protocol Mobile Service Switching Centre Mobile Station Network lment Network and Management Centre Network Management System Network Supervision center Network Switching Center opration and maintenance center Sous systme d'exploitation et de maintenance ORASCOM TELECOM ALGERIE. ORASCOM TELECOM HOLDING Plesiochronous digital hierarchy Quality of service Rseau Tlphonique Commut Rseaux Terrestres Commuts Publics Synchronous digital hierarchy

10

SM SMS SMSC Swap (SW) TCP TMN TT VLR

Short Message. Short Message Service. Short Messaging Service Center. Shkoder work ransmission control protocol Tlcommunications Management Network. Trouble ticketing Visitor Location Register

11

ntroduction gnrale

Introduction gnrale
De nos jours, toutes les entreprises commerciales, industriels ou de services utilisent des quipements lectroniques de grande importance indispensables pour la production des services. Lune des premires proccupations de ces entits est la prservation des quipements et de les garder oprationnels afin dassurer la continuit de la production et de service ; do la ncessit de surveillance et de contrle de ces quipements en permanence. Le problme qui se pose pour assurer cette continuit de service, Est-il de mettre une personne chaque quipement ? Et comment agir en cas de panne? Comment alerter lquipe de maintenance pour rgler ces pannes? Il est vident que cette solution nest pas applicable et est trs couteuse, particulirement l o il y a des quipements dans plusieurs units de service situes dans diffrentes localits. La solution la plus adquate est la mise en place dun systme de supervision qui fonctionne sous rseau qui assure le monitoring de tous les quipements. En effet, Un systme de supervision compos d'un ensemble dinterface client connects un serveur dont le rle principale est la gestion en temps rel des alarmes remontes par les diffrents quipements. Il peut aussi contenir dautres fonctionnalits telles que la notification de ces alarmes par email ou SMS, la gnration et lenvoi des rapports de ltat des quipements et de performances, tout en permettant de prvenir les problmes futurs. Cest dans ce contexte que sinscrit notre projet de fin dtude. En effet il nous a t demand lors de notre stage au centre national de la supervision dOTA qui est une socit de service de tlphonie mobile, afin de dvelopper un systme de gestion de la supervision. Lobjectif vis par le centre national de la supervision est d'assurer une disponibilit maximum de couverture et permettre un statut stable de ce rseau, ce qui assure une disponibilit permanente et de qualit suprieur de service. Pour raliser cela, il y a des dfis relever suite aux spcifications des systmes existants dont on peut citer : La supervision utilise pour chaque entit du rseau un NMS (Network management System) dont les fonctionnalits avec les diffrents sous-ensembles (BSS, NSS, Trans etc..) sont limites au listing des alarmes seulement, ces alarmes ne contiennent pas l'information suffisante pour prciser la nature du problme et de son impact.

Il n'y a pas de mcanisme disponible pour intgrer et interroger les Bases de donnes contenant les informations fiables de lensemble des acteurs des N.M.S actuels lquipe de supervision effectue cette tache manuellement. Le NMS courants ne peut pas analyser des alarmes ceci augmente encore le temps de rponse pour la rsolution de dfaut. Des efforts sont parfois gaspills pour analyser des alarmes. La rsolution des problmes se base fortement sur l'exprience et l'intelligence de l'ingnieur de supervision et qui varie d'une personne une autre. Ce facteur humain donne galement une diffrence dans la priode de rsolution du mme problme se reproduisant diffrentes heures. Le but de notre travail est de mise en place un systme de gestion de la supervision qui sera l'espace de travail des ingnieurs et l'interface avec les diffrentes bases de donnes. Elle Comporte : Un Module de notification qui envoie automatiquement les alarmes aux quipes de maintenance. Un Module qui informe les responsables hirarchiques sur les diffrents problmes persistant des sites importants. Un Module de Trouble Ticket pour suivre l'tat de site pendant la phase de maintenance. Un Module de Reporting qui fait l'tat quotidien de rseau national. Un Module d'valuation KPI qui mesure le taux de russite de dus quipes de maintenance. Un Module des statistiques qui affiche les diffrentes statistiques sur l'tat de rseau.

Organisation du document :
Ce document est organis en 3 sections : La premire section ltat de lart : Cette partie est consacre selon trois chapitres : Le premier, tant lintroduction gnrale de rseau GSM, o nous allons prendre connaissance du domaine GSM. Le deuxime chapitre contient une description de LOMC (opration & maintenance center), o nous effectuerons ltude de larchitecture dtaille et son fonctionnement. Le troisime chapitre o sera dcrites la supervision et dfinition de son fonctionnement La deuxime section tude de lexistant : Cette partie constitue dun seul chapitre, est ltude de lexistant. Celle-ci est base sur lanalyse de lancien systme et remarquer les dfaillances de fonctionnement de ce dernier, et connatre les nouveaux besoins pour crer un nouveau systme de gestion. La troisimes section conception et ralisation : Cette partie est constitue de deux chapitres. Le premier o nous utilisons le langage de modlisation UML pour dcrire la conception du systme propos, et ce, conformment aux objectifs viss pour la supervision du rseau GSM. Le deuxime o nous avons tudierons les outils de programmation et laffichage des rsultats du systme supervision de rseau GSM , et la scurisation des ses processus. On finalise notre mmoire par une conclusion gnrale et les perspectives. Ce document comporte aussi : Un annexe : qui fournit les complments de chacune des ses sections. Une bibliographie qui comprend toutes les rfrences des ouvrages et les ressources du web relatives notre tude.

re partie : Prsentation des concepts

hapitre 1: Introduction Rseau GSM

Chapitre 1: Introduction Rseau GSM

1. Introduction:
De nos jour, les tlcommunications son devenues un vritable enjeu conomique mais aussi une ncessit. En effet, elles permettent par exemple dtre inform de ce qui arrive dans le monde presque instantanment, mais aussi damliorer la scurit des individus en se rapprochant des secours. Nous assistons l'explosion, des systmes de tlphonie mobile bass sur la norme GSM/DCS (Digital Cellular System) dans le monde. Le succs instantan de ce type de service vient sans doute du fait qu'il est trs pratique de pouvoir tre joint n'importe o et n'importe quand. Les rseaux de type GSM sont des rseaux compltement autonomes. Ils sont interconnectables aux RTCP (Rseaux Terrestres Commuts Publics) et utilisent le format numrique pour la transmission des informations, qu'elles soient de type voix, donnes ou signalisation. Les quipements spcifiques constituant le squelette matriel d'un rseau GSM (BTS, BSC, MSC, VLR et HLR dtaills plus loin).

2. Historique
L'histoire de la tlphonie mobile (numrique) dbute rellement en 1982. En effet, cette date, le Groupe Spcial Mobile, appel GSM2, est cr par la Confrence Europenne des administrations des Postes et Tlcommunications (CEPT) afin d'laborer les normes de communications mobiles pour l'Europe. Les annes 80 voient le dveloppement du numrique tant au niveau de la transmission qu'au niveau du traitement des signaux, avec pour drivs des techniques de transmission fiables, grce un encodage particulier des signaux pralablement l'envoi dans un canal, et l'obtention de dbits de transmission raisonnables pour les signaux. Ainsi, en 1987, le groupe GSM fixe les choix technologiques relatifs l'usage des tlcommunications mobiles : transmission numrique, multiplexage temporel des canaux radio, chiffrement des informations ainsi qu'un nouveau codage de la parole. Il faut attendre 1991 pour que la premire communication exprimentale par GSM ait lieu. Au passage, le sigle GSM change de signification et devient Global System for Mobile communications. En Belgique, c'est en 1994 que le premier rseau GSM (proximus) est dploy ; Mobistar et Orange (rebaptis Base) viendront plus tard. Aujourd'hui, le nombre de numros attribus pour des communications GSM dpasse largement le nombre de numros ddis des lignes fixes et cette tendance se poursuit [PBFR 04].

3. Technologie GSM :
Le rseau GSM est adquat pour les communications tlphoniques de parole. En effet, il s'agit principalement d'un rseau commut, l'instar des lignes fixes et constitus de circuits, c'est--dire de ressources alloues pour la totalit de la dure de la conversation. Rien ne fut mis en place pour les services de transmission de donnes. Comme le rseau GSM ne convenait gure pour la transmission de donnes, les volutions rcentes ont vis accrotre la capacit des rseaux en termes de dbit mais largir les fonctionnalits en permettant par exemple l'tablissement de communications ne ncessitant pas l'tablissement pralable d'un circuit pour dpasser la borne des 14,4 [kb/s], dbit nominal d'un canal tlphonique chang en mode de transmission de donnes [PBFR 04].

4. Notion de rseau cellulaire:

Dans un rseau GSM, le territoire est dcoup en petites zones appeles cellules. Chaque cellule est quipe dune station de base fixe munie de ses antennes installes sur un point haut (chteau deau, cloch dglise, immeuble ...). Les cellules sont dessines hexagonales mais la porte relle des stations dpend de la configuration du territoire arros et du diagramme de rayonnement des antennes d'mission. Dans la pratique, les cellules se recouvrent donc partiellement. La taille limite des cellules permet de limiter la puissance dmission ncessaire pour la liaison et donc augmenter lautonomie des mobiles. Pour les pitons qui voluent moins vite qu'une voiture et au niveau du sol, on ajoute des sous-stations de petites dimensions sur un site peu lev et sur les murs des immeubles [PBFR 04].

Figure 1: figure reprsentant un motif lmentaire (a gauche) et un ensemble de motifs dans un rseau (a droite) [PBFR 04].

5. Architecture du rseau GSM

5.1 Structure gnral du GSM:
L'architecture d'un rseau GSM peut tre divise en trois sous-systmes : a) Le sous-systme radio (BSS) comprend essentiellement les stations de transmission de base (BTS) (Base Transmitter Station), et leurs contrleurs BSC (Base Station Controller) b) Le sous-systme Rseau (NSS) qui comprend l'ensemble des fonctions ncessaires l'tablissement des appels et la mobilit, il est essentiellement compos de MSC (Mobile Service Switching Centre), VLR (Visitor Location Register), HLR (Home Location Registrer). c) Le sous -systme dexploitation (OSS) dont (OMC) (opration and maintenance center) qui est le composant principal permet loprateur dadministrer et contrler son rseau

Figure 2: architecture du rseau GSM [PBFR 04].

5.2 Terminal dabonn (MS) :

La carte SIM : Cette carte identifie l'abonn sur le rseau. L'accs sera donc refus si la carte a t dclare perdue ou vole. Elle assure donc l'authentification de l'abonn ainsi que le cryptage de la voix. Le tlphone mobile : Il ne fonctionne que si la carte SIM a t insre et le code secret valid par l'abonn [GSM 99].

5.3 Sous systme radio BSS :

5.3.1 La Base Transceiver Station (BTS) La (BTS) est lquipement terminal du rseau vers les stations mobiles . Une BTS est un groupement dmetteurs et de rcepteurs fixes. Elle change des messages avec les stations mobiles prsentes dans la cellule quelle contrle. La BTS utilise des canaux radio diffrents selon le type dinformation changes, donnes utilisateur ou signalisation, et selon le sens de lchange (abonn rseau ou rseau abonn) [GSM 99].

5.3.2 Le contrleur de station de base (BSC): Le contrleur de station de base gre une ou plusieurs stations de base et communique avec elles par le biais de l'interface A-bis, le BSC agit comme un concentrateur puisqu'il transfre les communications provenant des diffrentes stations de base vers une sortie unique. Dans l'autre sens, le contrleur commute les donnes en les dirigeants vers la bonne station de base. Dans le mme temps, le BSC remplit le rle de relais pour les diffrents signaux d'alarme destins au centre d'exploitation et de maintenance. Il alimente aussi la base de donnes des stations de base. Enfin, une dernire fonctionnalit importante est la gestion des ressources radio pour la zone couverte par les diffrentes stations de base qui y sont connectes. En effet, le contrleur gre les transferts intercellulaires des utilisateurs dans sa zone de couverture, c'est--dire quand une station mobile passe d'une cellule dans une autre. Il doit alors communiquer avec la station de base qui va prendre en charge l'abonn et lui communiquer les informations ncessaires tout en avertissant la base de donnes locale VLR (Visitor Location Register) de la nouvelle localisation de l'abonn. C'est donc un maillon trs important de la chane de communication et il est, de plus, le seul quipement de ce sous systme tre directement grable (via l'interface X25 qui le relie au sous-systme d'exploitation et de maintenance) [PBFR 04].

5.4 Sous systme rseau (NSS) :

Le sous-systme rseau, appel Network Switching Center (NSS), joue un rle essentiel dans un rseau mobile. Alors que le sous-rseau radio gre l'accs radio, les lments du NSS prennent en charge toutes les fonctions de contrle et d'analyse d'informations contenues dans des bases de donnes ncessaires l'tablissement de connexions utilisant une ou plusieurs des fonctions suivantes : chiffrement, authentification ou roaming. Le NSS est constitu de [GSM 04]: 5.4.1 Le centre de commutation mobile (MSC) : Les MSC sont des commutateurs de mobiles gnralement associes aux bases de donnes VLR. Le MSC assure une interconnexion entre le rseau mobile et le rseau fixe public. Le MSC gre l'tablissement des communications entre un mobile et un autre MSC, la transmission des messages courts et l'excution du handover si le MSC concern est impliqu. (Le handover est un mcanisme grce auquel un mobile peut transfrer sa connexion d'une BTS vers une autre (handover inter BTS) ou sur la mme BTS d'un canal radio vers un autre (handover intra BTS). On parle de transfert automatique inter/intra cellule. Le commutateur est un nud important du rseau, il donne un accs vers les bases de donnes du rseau et vers le centre d'authentification qui vrifie les droits des abonnes. En connexion avec le VLR le MSC contribue la gestion de la mobilit des abonns ( la localisation des abonns sur le rseau) mais aussi la fourniture de toutes les tls services offerts par le rseau : voix, donnes, messageries ... Le MSC peut galement possder une fonction de passerelle, GMSC (Gateway MSC) qui est active au dbut de chaque appel d'un abonn fixe vers un abonn mobile. Un couple MSC / VLR gre gnralement une centaine de milliers d'abonns. Les commutateurs MSC sont souvent des commutateurs de transit des rseaux tlphoniques fixes sur lesquels ont t implants des fonctionnalits spcifiques au rseau GSM [AGSM 02]. 5.4.2 L'enregistreur de localisation nominale (HLR) : Il existe au moins un enregistreur de localisation (HLR) par rseau (PLMN).Il s'agit d'une base de donnes avec des informations essentielles pour les services de tlphonie mobile et avec un accs rapide de manire garantir un temps d'tablissement de connexion aussi court que possible. Le HLR contient:

toutes les informations relatives aux abonns : le type d'abonnement, la cl d'authentification Ki .cette cl est connue d'un seul HLR et d'une seule carte SIM., les services souscrits, le numro de l'abonn (IMSI), etc. ainsi qu'un certain nombre de donnes dynamiques telles que la position de l'abonn dans le rseau .en fait, son VLR. et l'tat de son terminal (allum, teint, en communication, libre, . . .). Les donnes dynamiques sont mises jour par le MSC. Cette base de donnes est souvent unique pour un rseau GSM et seules quelques personnes y ont accs directement [PBFR 04].

Figure 3: les informations gres par le HLR [AGSM 02]. Pour fait une mise jour aux donnes dynamiques le rseau commence par interroger le HLR pour prendre connaissance de la dernire localisation connue, de l'tat du terminal (On / Off) et de la date de ces donnes avant toute action. La mobilit constitue la diffrence essentielle entre le rseau filaire et le rseau de radiotlphonie. Ainsi sur le rseau mobile, l'oprateur doit interroger les diffrentes bases de donnes (HLR) afin de localiser un abonn [AGSM 02]. 5.4.3 Le centre d'authentification (AuC) : LAUC (Authentification Center) est associ un HLR et sauvegarde une cl d'identification pour chaque abonn mobile enregistr dans ce HLR. Cette cl est utilise pour fabriquer [EFORT]: Les donnes ncessaires pour authentifier labonn dans le rseau GSM. Une cl de chiffrement de la parole (Ki) sur le canal radio entre le mobile et la partie fixe du rseau GSM

La carte SIM qui transmet deux informations importantes. L'IMSI (International Mobile Subscriber Identity) qui est gre par le HLR (l'IMSI donne des informations sur le rseau d'origine et le pays entre autre) et le KI (cl de cryptage) qui est gr par la base de donnes AUC Prenons un exemple. IMSI + KI : Identification de l'abonn x MSISDN : Numro de tlphone de x (Mobile Station ISDN Number) Le HLR vrifie que le couple IMSI + KI = MSISDN LAUC vrifie que le couple IMSI + KI est valide [AGSM 02]. 5.4.4 L'enregistreur de localisation des visiteurs(VLR) : L'enregistreur de localisation des visiteurs est une base de donnes associe un commutateur MSC. Le VLR a pour mission d'enregistrer des informations dynamiques relatives aux abonnes de passage dans le rseau, ainsi l'oprateur peut savoir tout instant dans quelle cellule se trouve chacun de ses abonns. Les donnes mmorises par le VLR sont similaires aux donnes du HLR mais concernent les abonns prsents dans la zone concerne. A chaque dplacement d'un abonn le rseau doit mettre jour le VLR du rseau visite et le HLR de l'abonn afin d'tre en mesure d'acheminer un appel vers l'abonn concern ou d'tablir une communication demande par un abonn visiteur. Pour ce faire un dialogue permanent est tablit entre les bases de donnes du rseau. La mise jour du HLR est trs importante puisque lorsque le rseau cherche joindre un abonn, il interroge toujours le HLR de l'abonn pour connatre la dernire localisation de ce dernier, le VLR concern est ensuite consults afin de tracer le chemin entre le demandeur et le demand pour acheminer l'appel [AGSM 02]. 5.4.5 L'enregistreur des identits des quipements (EIR) : Malgr les mcanismes introduits pour scuriser l'accs au rseau et le contenu des communications, le tlphone mobile doit potentiellement pouvoir accueillir n'importe quelle carte SIM de n'importe quel rseau. Il est donc imaginable qu'un terminal puisse tre utilis par un voleur sans qu'il ne puisse tre repr. Pour combattre ce risque, chaque terminal reoit un identifiant unique (International Mobile station Equipment Identity, IMEI) qui ne peut pas tre modifi sans altrer le terminal. En fonction de donnes au sujet d'un terminal, un oprateur peut dcider de refuser l'accs au rseau. Tous les oprateurs n'implmentent pas une telle base de donnes [GSM 04]. Un EIR sauvegarde toutes les identits des quipements mobiles utiliss dans un rseau

GSM. Cette fonctionnalit peut tre intgre dans le HLR. Chaque poste mobile est enregistr dans l'EIR dans une liste [EFORT]: Liste "blanche" : poste utilisable sans restriction. Liste "grise" : poste sous surveillance (traage d'appels). Liste "noire" : poste vol ou dont les caractristiques techniques sont incompatibles, avec la qualit requise dans un rseau GSM (localisation non autorise).

5.5 Sous systme d'exploitation et de maintenance (OSS) :

5.5.1 L'administration de rseau : L'administration du rseau comprend toutes les activits qui permettent de mmoriser et de contrler les performances d'utilisation et les ressources de manire offrir un niveau correct de qualit aux usagers [UYAGSM]. On distingue 5 fonctions d'administrations [UYAGSM] : L'administration commerciale La dclaration des abonns et des terminaux, la facturation, les statistiques ... La gestion de la scurit La dtection des intrusions, le niveau d'habilitation ... L'exploitation et la gestion des performances L'observation du trafic et de la qualit (performance), les changements de configuration pour s'adapter la charge du rseau, la surveillance des mobiles de maintenance ... Le contrle de configuration du systme Les mises niveau de logiciels, les introductions de nouveaux quipements ou de nouvelles fonctionnalits ... La maintenance Les dtections de dfauts, les tests d'quipements ... Le systme d'administration du rseau GSM est proche du concept TMN qui pour objet de rationaliser l'organisation des oprations de communication et de maintenance et de dfinir les conditions techniques d'une supervision conomique et efficace de la qualit de service.

5.5.2 Architecture de TMN (Tlcommunications Management Network) : L'administration des premiers rseaux se faisait de manire individuelle sur chaque quipement partir d'un terminal simple directement connect. Ainsi les fonctions disponibles taient lies la structure matrielle de lquipement. Ce niveau d'administration est encore utilisable mais il est peu peu remplac par des terminaux dplaces et relies aux quipements par l'intermdiaire d'un rseau de donnes. Le rseau X.25 Transpac (rseau lanc par France Tlcom et bas sur la transmission des donnes par paquet) est une option possible [UYAGSM]. 5.5.3 Prsentation de I'OMC et du NMC : Deux niveaux de hirarchie sont dfinis dans la norme GSM. Les OMC (Operations and Maintenance Center) et le NMC (Network and Management Centre). Cette organisation a t dfinie afin de permettre aux oprateurs tlcoms de grer la multiplicit des quipements (metteurs, rcepteurs, bases de donnes, commutateurs...) et des fournisseurs. Le NMC permet l'administration gnrale de l'ensemble du rseau par un contrle centralis. Les OMC permettent une supervision locale des quipements (BSC /MSC / VLR) et transmettent au NMC les incidents majeurs survenus sur le rseau. Les diffrents OMC assurent une fonction de mdiation [AGSM 02].

5.6 Prsentation des interfaces

Les interfaces dsignes par des lettres de A H dans le tableau ci aprs ont t dfinies par la norme GSM. Bien souvent, le dcoupage des fonctions entre les lments du rseau (VLR et MSC) par exemple est effectue par les constructeurs (Ericsson, Nokia ...) qui ne respectent pas forcement celles dfinies dans le tableau [AGSM 02].

Tableau 1: interfaces GSM [AGSM 02].

Figure 4: interfaces GSM [EFORT].

5.7 Architecture rseau en couches (modle OSI) (annexe A):

La recommandation GSM tablit un dcoupage des fonctions et une rpartition de celles ci sur divers quipements. La structuration en couches reprend ce dcoupage en respectant la philosophie gnrale des couches du modle OSI [AGSM 02]. 5.7.1 Couches rseaux gres par le sous systme radio (BSS) Dans le BSS on retrouve les 3 couches de base du modle OSI [AGSM 02] : La couche physique dfinit l'ensemble des moyens de transmission et de rception physique de l'information. La couche liaison de donnes a pour objet de fiabiliser la transmission entre deux quipements par un protocole. La couche rseau a pour fonction d'tablir, de maintenir et de librer des circuits commuts (voix ou donnes) avec un abonn du rseau fixe. 5.7.2 Couches rseaux gres par le sous systme fixe (NSS) Le rseau fixe NSS que nous avons vu prcdemment regroupe ensuite les 4 couches complmentaires du modle OSI. Le rseau NSS en GSM est relie et gr avec le rseau RTC (Rseau Tlphonique Commut) rseau de tlphonie fixe initial. Les 4 couches complmentaires ?? Sont ainsi regroupes au sein de cet ensemble qui permet de grer les connexions entre abonnes mobiles et abonnes fixes [AGSM 02].

5.8 Description du canal physique

Au niveau de linterface Um, le GSM met en uvre deux techniques de multiplexage, un multiplexage frquentiel AMRF - accs multiple rpartition en frquence et un multiplexage temporel AMRT accs multiple rpartition dans le temps. 5.8.1 Le multiplexage frquentiel AMRF :

divise en 124 canaux de 200 kHz de large chacun, les deux plages de frquences (890-915 Mhz) terminal station de base et (935-960 MHz) station de base terminal, pour

offrir 124 voies de communication duplex en parallle, chaque sens de communication possdant une voie qui lui est rserve [GSM99]. 5.8.2 Le multiplexage temporel AMRT :

Le multiplexage temporel consiste diviser chaque canal de communication en 8 intervalles de temps de 0,577 [ms] chacun. La somme des 8 IT constitue une trame, qui est lunit temporelle de base. Une trame dure 4.615 ms dans le GSM. Le multiplexage temporel optimise lutilisation de la capacit de transmission dune voie [GSM99].

5.8.3

Typologie des paquets

Chaque trame consiste en un certain nombre de bits. Ces bits sont organiss suivant une structure qui diffre en fonction du protocole applicatif mis en ouvre pour chaque slot mais aussi de l'tat intermdiaire du protocole considr [PBFR 04]. La dure d'un paquet (0,577 ms) correspond l'mission de 156,25 bits, dont 114 bits de message net. La norme dfinit 5 types de paquets fonctionnels, appels bursts dans la terminologie GSM [PBFR 04]: 5.8.3.1 Le burst d'accs Ce burst est mis, sur un canal ddi, par la station mobile lorsqu'elle cherche entrer en contact avec le rseau soit pour l'tablissement d'une communication, soit pour un handover. Il est le plus court des quatre types car il ne contient que 77 bits (41 bits de synchronisation et 36 bits d'information). 5.8.3.2 Le burst de synchronisation Pour ce type de burst, 78 bits d'informations sont vhiculs pour les stations mobiles. Ces bits contiennent les renseignements concernant les frquences utiliser et la localisation (identit de la station de base, de la zone et de la cellule). 5.8.3.3 Le burst normal Ce burst transporte 2 *57 = 114 bits d'information spares par 26 bits qui sont une squence d'apprentissage destine rgler les paramtres de rception. De plus, la zone TB correspond 8,25 bits. Enfin, il faut ajouter cela 2 bits qui indiquent s'il s'agit d'un canal de donnes ou d'un canal de signalisation et 6 bits pour marquer la monte ou la descente en amplitude. 5.8.3.4 Le burst de correction de frquence Le type de burst au format le plus simple. La station de base envoie 142 bits de donnes servant prvenir des interfrences possibles avec des frquences voisines. 5.8.3.5 Le burst de bourrage Lorsqu'un mobile est allum, le terminal teste le niveau de puissance des frquences des cellules proches pour dterminer la station de base laquelle il doit s'asservir. Le burst de bourrage (dummy burst) est une squence prdfinie qui sert donc d'talon de puissance. Il est aussi utilis pour forcer une dcision de handover.

Figure 5: structures des 5 types de burst dfinis par la norme GSM [PBFR 04].

6. Prsentation de la gestion du rseau :

Un rseau de tlcommunication se compose des quipements physiques, mais aussi des logiciels associs, qui assurent les fonctions constituant les lments logiques de base. Les lments logiques servent btir les couches du rseau de transmission, qui sont des produits (analogiques, numriques). Ces produits permettent doffrir des services rseaux (service supports, tl services). La structure dun rseau se modlise avec trois niveaux logiques : - entits rseaux (quipement et le logiciel), - le rseau de transmission (radio, numrique et commut), - services (tl services, services supports) Le concept de rseau de gestion repose sur des rgles de dialogue (logique) et des interfaces physiques dfinies par les organismes internationaux [GSM 99]. La gestion dun rseau possde deux axes principaux, la gestion technique et la gestion administrative.

6.1 La gestion technique :

La gestion technique vise configurer les quipements (activer, dsactiver, initialiser, lancer une campagne de mesures, etc.), grer les alarmes, valuer les modes de fonctionnements, les performances, diter les tickets de taxation. Elle respecte les rgles de tlcommandes

dfinies par lexploitant. Un quipement qui reoit une tlcommande ralise certains contrles avec ses donnes de configuration avant dexcuter lordre reu tel que [GSM 99]. lhabilitation de loprateur le commander, un contrle de cohrence des paramtres, de lordre, un contrle dunicit de la squence en cours,

6.2 La gestion administrative :

La gestion administrative comprend linventaire qui recense tous les composants du systme, les fournisseurs, lannuaire des composants (nom, 1ocalisation, tat) et la gestion des abonns (Cration, facturation, relations commerciales) [GSM 99].

7.

Prsentation des services du rseau GSM :

7.1 LE SMS:
a) Architecture physique : Le service de messages courts offert par le rseau GSM (SMS, pour Short Messages Service) permet un utilisateur de composer un message textuel d'au plus 160 caractres (cods l'aide d'ASCII 7 bits sur 140 octets) partir de son terminal mobile et de l'envoyer un destinataire possdant galement un tlphone radio-mobile GSM ou une entit extrieure au rseau GSM appele SME (Short Message Entity). [GSM04-1] La messagerie textuelle de SMS soutient des langues internationalement. Cela fonctionne trs bien avec toutes les langues soutenues par Unicode, y compris l'arabe, le Chinois, le Japonais et le Coren. Ces messages mis et reus sont vhiculs par le rseau de signalisation smaphore n7 (SS7) (annexe B). Ils sont soit transmis directement au terminal destinataire du message (si celui-ci est allum), soient stocks dans le serveur de message courts (SMSC (annexe C), pour SMS Center) par lequel ils transitent. [GSM04-1] Les messages courts ne circulent pas dans les mmes canaux logiques que la voix ou les donnes (comme nous le verrons dans le paragraphe suivant) si bien qu'il est possible po un utilisateur en communication tlphonique (avec un autre correspondant) de recevoir des messages courts simultanment [GSM 04-1]. Le service SMS ncessite la mise en place d'un ou plusieurs serveurs spcifiques dans le rseau. Le serveur de messages courts (SMSC) (annexe C) assure le stockage des SM dans des bases de donnes, la distribution des SM aux terminaux mobiles destinataires (quand ceux-ci se sont manifests dans le rseau GSM auquel ils appartiennent) et le traitement des dates de validit des SM [GSM 04].

b) Architecture logique : canal de signalisation Un tlphone mobile GSM dispose de plusieurs types de canaux de transmission [GSM 04]: Le canal de la voix (abonnement classique) : la voix est encode et transmise numriquement par le rseau GSM. C'est le canal de tlphonie classique. Le canal des donnes (service Data/Fax de GSM): les donnes (issues d'un PC reli au tlphone mobile) sont encodes de manire diffrente de la voix et transmises par le rseau GSM. Les donnes et la voix sont transmises sur les mmes canaux logiques de trafic (TCH, pour Traffic CHannel). Le canal de signalisation (canal smaphore SS7 (annexe B)) : les messages courts transitent sur ce canal. Un tel canal est dsign par SDCCH, pour Stand-alone Dedicated Control CHannel. Les 2 types de canaux logiques de trafic (TCH) et de signalisation (SDCCH), il est ncessaire d'associer un canal logique de contrle des paramtres physiques de la liaison (SACCH, pour Slow Associated Control CHannel). Ces 3 types de canaux logiques (et bien d'autres encore) sont ensuite multiplexs dans des canaux physiques. c) Format d'un message court : Le format d'un message court est prsent ci-dessous

FIGURE 6: Le format d'un message court. Remarque La norme autorise la concatnation de 3 messages courts au plus. Pour un seul message transmis, la longueur des donnes sera de 135 octets correspondants l'en-tte + adresse du port applicatif + donnes utilisateur.

Avec 2 messages concatns, les longueurs des donnes utiles sont de 260 octets correspondants l'en-tte + @port + information de concatnation + donnes utilisateur + entte + @port +information de concatnation+ donnes utilisateur [GSM 04]. d) Les donnes qui peuvent envoyer par SMS Sans compter que le texte, les messages de SMS peuvent galement porter des donnes binaires. Il est possible d'envoyer des ringtones, des images, des logos d'oprateur, des papiers peints, des animations, des cartes de visite professionnelle de visite (par exemple VCards) et des configurations de WAP un tlphone portable avec des messages de SMS [GSM 04-1].

8. Conclusion
La mise en place d'un rseau GSM reprsente un investissement considrable. A l'heure actuelle les rseaux GSM ne cessent d'voluer afin d'assurer une qualit de couverture toujours plus importante. La couverture du rseau est assure par la multiplication des ensembles BTS BSC, nous verrons que (l'ensemble BTS BSC MSC devra tre chang ou modifi la base. Rappelons ici rapidement qu'une BTS couvre environ 500m de zone en ville et 10 km de zone en campagne.

hapitre2 : Le serveur OMC

Chapitre2 : Le serveur OMC

1. Introduction
Dans le chapitre prcdant nous avons vu la structure gnrale du rseau GSM. Parmi ces quipements on trouve lOMC qui gre la multiplicit des quipements et assure la supervision des quipements locale (BSC /MSC / VLR). Nous avons aussi vu quelques services du GSM (comme le SMS), et dans ce chapitre nous verrons le serveur OMC dans le dtail.

2. OMC
L'OMC ou Opration and Maintenance Center est un lment de base du rseau GSM. Son rle est d'assurer le contrle et la gestion de plusieurs BSC. Il contient des informations diverses sur le rseau: reflet du paramtrage utilis sur le rseau compteurs, par exemple le nombre de communications interrompues par jour sur une cellule donne L'OMC permet l'oprateur de connatre les points faibles de son rseau, les analyser et les corriger [WIKI].

2.1 Gestion d'un rseau de tlcommunications

FIGURE 7: figure montre un rseau de gestion de tlcommunications TMN [OMCWEDO04]

La figure 7 montre un rseau de gestion de tlcommunications TMN ce qui assure la gestion d'un rseau d'oprateur OTN. Dans l'exemple d'incorporation du rseau de gestion de tlcommunications TMN, un centre dopration et de maintenance OMC est reli par l'intermdiaire des interfaces normalises S11 Sln une multitudes dlments externes de gestion tels centre NMC de maintenance de rseau et d'autres applications externes EMA1 de gestion EMAn et aux lments de rseau NE1 NEn du rseau de tlcommunications d'oprateur OTN qui sont sous la porte de gestion. Le rseau de tlcommunication d'oprateur OTN se compose de plusieurs types d'quipement de tlcommunications analogues et numriques et d'quipements associs de support; ceux-ci comportent

typiquement les quipements terminaux UTA, UTB d'utilisateurs qui sont relis ensemble par l'intermdiaire des diffrents systmes de transmissions de loprateur, systmes de commutation, multiplex ; signalisation des bornes, des serveurs, etc., Un quipement est dsign gnralement sous le nom lments de rseau NE1 NEn. [OMCWEDO04]. Afin de fournir un environnement de gestion du rseau de l'oprateur de tlcommunications, le centre dopration et de maintenance OMC fournit un ensemble d'interfaces ouvertes S11 permettant aux outils externes et aux applications de gestion d'accder aux donnes qu'il contrle et/ou transmet des actions spcifiques et des commandes sur le rseau. Les exemples de telles applications externes plusieurs fournisseurs potentielles sont les centres NMC de gestion du rseau qui fournissent le contrle global et centralis en tant au-dessus de la hirarchie de la maintenance ; les applications d'optimisation de rseau de radio qui fournissent des services spcifiques l'oprateur pour augmenter la disponibilit de son rseau de transmissions mobiles ; ou applications (QoS) de reportage de qualit du service. [OMCWEDO04].

2.2 Larchitecture dOMC

FIGURE 8: figure montre un centre d'opration et de maintenance [OMCWEDO04]

La Figure 8 montre un centre d'opration et de maintenance. Dans l'exemple cit Dincorporation, le centre d'opration et d'entretien comporte une pluralit des bornes OMT1 d'opration et d'entretien OMTn et d'autres dispositifs DX ce qui sont relies par l'intermdiaire d'une NC du rseau de transmissions, telle qu'un rseau d'IP. Les bornes OMT1 d'opration et d'entretien OMTn sont gnralement des postes de travail ou des PC et sont organises et fonctionnent d'une faon de serveur/ client. Les

applications de gestion de lOMC sont accueillies sur un PC serveur et les interfaces utilisateurs de personnel d'oprateur le sont accueillies sur des PC clients. Tous peuvent tre relis par l'intermdiaire d'un rseau d'IP. Les dispositifs DX relis la NC du rseau de transmissions sont par exemple des dispositifs d'imprimeur, des appareils de communication externes, des serveurs de base de donnes spcifique-but, etc. Dans un scnario possible, un certain nombre de membres du personnel d'oprateur travaillent sur les diffrentes bornes OMT et d'un OMC en mme temps et en sessions parallles, chacune delle contrlant une tche diffrente sur le rseau de tlcommunications d'oprateur. Le personnel de loprateur prsente manuellement les commandes correspondantes par l'intermdiaire des moyens disponibles d'accs d'une faon squentielle et peut, mme visualiser et tracer l'excution des dites commandes sur son cran [OMCWEDO04]. Noter que la Figure 8 dcrit un exemple de la faon dont ce nouveau dispositif pourrait tre mis en application. Ici on montre comment l'information graphique est prsente aprs chaque action de commande ou un groupe dentre-elles. Les affichages centraux d'opration et de maintenance OMC sur la borne OMT d'opration et d'entretien. Une ligne de commande indiquant qu'elle attend une action de commande. Quand l'oprateur prsente une commande, celui-ci et le centre d'entretien a t configur a forcer l'oprateur ajouter un commentaire, alors le centre d'oprateur et d'entretien prsentera l'oprateur une ligne de commentaire exigeant de lui de prsenter un texte qui sera li la dite commande. Au cas o le centre d'opration et d'entretien nest pas configur pour forcer l'oprateur prsenter un commentaire pour chaque commande, il fournira toujours des moyens d'accs pour permettre l'oprateur de le faire pour quelques diffrentes commandes ou un groupe dentre-elles. Par exemple, l'oprateur peut marquer un groupe de commandes venant d'un outil externe d'application de gestion et vrifier une option fournie dans l'affichage de la borne OTM d'opration et d'entretien pour indiquer qu'il veut ajouter un commentaire. Naturellement on comprend que le centre d'opration et d'entretien peut tre galement configur pour forcer

l'introduction de la dite information avant ou aprs les commandes choisies. Aprs que l'oprateur ait prsent le commentaire, le centre d'oprateur et d'entretien continuera le processus avec une ligne de commande et ainsi de suite [FREEP]. Mais la possibilit pour ajouter un commentaire peut tre plus volue que celui montr et peuvent ne pas tre seulement texte simple, c.--d., il pourrait tre structur selon un oprateur ou une structure interne de fabricants, rfrence d'action, rfrence de procd, cause d'action/raison, etc. avec l'image obligatoire et/ou facultative diffrente et/ou les champs graphiques et/ou textuels. Certains champs tant remplis de ou liant aux listes de dfilement. Ces listes peuvent tre cres et enrichies pendant le cycle de vie d'exploitation de rseau de tlcommunications et tre partager entre tous les oprateurs et/ou clients et/ou fabricants [FREEP].

2.3 rle dOMC

Le rle dun centre d'opration et de maintenance (OMC) destin la gestion d'un rseau de tlcommunication d'oprateurs est [FREEP]: Fournir au moins l'affichage, l'entre et les moyens de communication pour un oprateur et/ou d'autres outils externes d'application de gestion de regards relatifs

l'information aux lments de rseau de tlcommunication (NE) sous la porte de gestion, de prsenter des actions de commande pour contrler les lments de dit rseau (NE), et pour communiquer des actions et des commandes aux lments du rseau ou pour recevoir l'information de leur statut Fournir des moyens de configuration permettant l'oprateur de dcider si l'information dite de commentaire, d'action ou de commande sera obligatoire ou facultative. Fournir des moyens qui permettent l'oprateur ou un outil externe d'application de gestion de rechercher parmi l'action historique de commande commente. LOMC peut caractrise en ce que l'information dite de commentaire en une information d'image, graphique ou textuelle.

2.4 Les fonctionnalits dOMC

Le but d'un rseau de gestion de tlcommunications est de rpondre aux exigences de gestion des oprateurs de tlcommunication de prvoir, la provision, linstallation, la

maintenance, lexploitation et ladministration des rseaux et des services de tlcommunication. Un OMC est connue comme tant qu'une partie du rseau de gestion de tlcommunication qui fournit les contrles dynamiques de l'opration et de maintenance des lments de rseau fonctionnant dans un secteur gographique donn. LOMC fournit un cadre par lequel une pluralit de tches fonctionnelles de gestion peuvent tre excutes ; La gestion de la configuration, la gestion de dfaut, la gestion du rendement, la gestion de supervision, la gestion comptable et la gestion de scurit sont certaines des fonctions qui peuvent tre fournies l'oprateur. Un certain nombre de services qui permet la structure, et les caractristiques d'un rseau de transmissions tre changer par l'oprateur. La disposition est galement prise pour l'accs, et l'affichage, derrire l'information de gestion contenue dans le rseau de gestion de tlcommunications au personnel d'oprateur [FREEP].

2.5 LOMC_R et LOMC_S

Dans les OMC (Opration and Maintenance Center), on distingue l'OMC/R (Radio) qui est reli toutes les entits du BSS, travers les BSC, l'OMC/S (System) [LEB]. 2.5.1 LOMC/R [CEMRAR3G] LOMC-R doit fournir le moyen de configurer les paramtres radio du rseau avec notamment des fonctionnalits puissantes pour aider loprateur effectuer les mises au point. LOMC-R doit fournir une interface ouverte vis--vis des applications de planification et de supervision de rseau. LOMC-R doit pouvoir dfinir des cellules GSM. LOMC-R doit donc pouvoir grer les organisations de rseau centralises et rparties. En outre, avec laugmentation progressive du nombre dabonns, lOMC-R sera appel passer dune prise en charge de quelques dizaines de cellules celle de plusieurs milliers de cellules. 2.5.2 LOMC/S Est reli au sous-systme NSS travers les MSC. Enfin l'OMC/M (Maintenance) contrle l'OMC/R et l'OMC/S [LEB].

3. Conclusion
Lexistence de lO.M.C dans un rseau de socit de tlphonie mobile est indispensable a cause de son rle majeur de contrle et de gestion au sein de la socit pour des raisons de configuration, de supervision, de rendement de scurit.

hapitre 3: supervision

Chapitre 3: supervision
1. Introduction
L'outil informatique est devenu un des lments primordiaux du systme d'information dans les entreprises. Toute panne de ce systme peut avoir des consquences importantes. De ce fait, La supervision des systmes et des rseaux, est devenue indispensable. Cette technique permet de surveiller lensemble du systme dinformation dune entreprise. La supervision est dtaille comme suit.

2. Dfinition
La supervision est une technique industrielle de suivi et de pilotage informatique de procs de fabrication automatiss des quipements de production et de service tel les rseaux de

tlcommunications. Elle concerne l'acquisition de donnes (mesures, alarmes, retour d'tat de fonctionnement) et des paramtres de commande des processus gnralement confis des automates programmables. Dans l'informatique, la supervision est la surveillance du bon fonctionnement dun systme ou dune activit [WIKI].

3. La supervision en informatique
La supervision est la "surveillance du bon fonctionnement dun systme ou dune activit". Elle permet de surveiller, rapporter les fonctionnements normaux et alerter les anormaux des systmes informatiques. Elle rpond aux proccupations suivantes [WIKI]: Technique : surveillance du rseau, de linfrastructure et des machines, Applicative : surveillance des applications et des processus mtiers, Contrat de service : surveillance respect des indicateurs, Mtier : surveillance des processus mtiers de lentreprise. On ajoutera les actions rflexes cette surveillance du systme. Ce sont les ractions automatises en fonctions dalertes dfinies. En cas de dysfonctionnement, le systme de supervision permet d'envoyer des messages sur la console de supervision, ou bien d'envoyer un courriel l'oprateur. Mais si le dysfonctionnement se produit en dehors des heures ouvrables, et en l'absence de systme appropri, l'alerte n'est pas reue par l'oprateur, et les utilisateurs des applications ne sont pas prvenus du dysfonctionnement [WIKI].

C'est pourquoi il peut tre utile de complter le superviseur par un logiciel de gestion des alertes, qui envoie automatiquement un courriel, un SMS, ou un appel tlphonique un oprateur sous astreinte [WIKI].

4. Supervision des procds

En informatique industrielle, la supervision des procds est un pupitre de commande volu. Elle permet de surveiller et/ou de contrler l'excution de tches du procd. Un logiciel de supervision fonctionne gnralement sur un ordinateur en communication, via un rseau local, avec un ou plusieurs quipements lectroniques, Automate Programmable Industriel ou ordinateurs de commande directe (commande numrique). Un logiciel de supervision est compos d'un ensemble de pages (d'crans), dont l'interface oprateur est prsente sous la forme d'un synoptique. Ce systme assure aussi un rle de gestionnaire d'alarmes, d'vnements dclenchs par des dpassements de seuils, pour attirer l'attention de l'oprateur et d'enregistrement d'historique de dfauts, de temps de fonctionnement, d'alarmes, de paramtres prdtermins [LEB].

5. Concepts de base
Prsentation des principaux concepts de base permettant d'introduire les notions de supervisions.

5.1 Les services en entreprises :

De nos jours les entreprises ont de plus en plus recours aux services informatiques. Ces besoins sont [SA 03-04]: internes pour permettre le travail des collaborateurs. Ils sont : Intranet, DNS, stockage de donnes, accs vers l'extrieur, messagerie, applications internes. L'accs aux applications peut se faire grce des clients lgers ou lourds (Annexe D). externes pour permettre la promotion de la socit, et des personnes externes de travailler avec des outils internes la socit. Ces accs peuvent se faire grce des clients lgers ou lourds (Annexe D). Les utilisateurs seront donc des personnes internes la socit. Ils utiliseront alors l'intranet de la socit ou des VPN dans le cas ou ils sont situs l'extrieur de la socit.

Ils peuvent tre aussi externes la socit. Ils utiliseront gnralement Internet pour accder aux services qui leur seront rservs [SA 03-04].

FIGURE 9: schma reprsentant une architecture type de rseau d'entreprise.

5.2 QoS:
Quality Of Service, est la qualit d'un service informatique pour un utilisateur qui varie fortement d'un service un autre. Ces points se regroupent gnralement en trois grands groupes [SA 03-04]: La disponibilit du service; Le temps d'attente pour obtenir le service; L'intgrit des donnes.

6. Pourquoi superviser?
La supervision en entreprise gnralement pour but de permettre [SA 03-04]: Dclencher des alarmes en cas de problmes (trap SNMP, email, SMS, ). En effet, bon nombre d'quipements professionnels sont capables de communiquer leur tat. Le plus gnralement cela se fait par l'intermdiaire de trap SNMP vers une application qui les recueille pour les analyser et dclencher l'apparition des alertes, d'informations... Publier des rapports de performances permettant de prvenir les problmes futurs et d'appliquer des actions de maintenances, d'volutions des matriels et applications.

7. Fonctionnement
La supervision travaille gnralement en mode Clients/Serveur. Les clients permettant de simuler le comportement des utilisateurs ou agents virtuels droulent les scnarii et envoient les donnes collectes au serveur. Les donnes collectes sont [SA 03-04]: La possibilit ou non d'accder une ressources; Le temps pour y accder; La valid de la ressource; Les messages d'erreur renvoye par l'application. Le serveur (la console) quant lui gnre les alertes si ncessaire. Il publie galement des rapports en temps rel. Autre point important. Il est parfois possible daccder une application par diffrents types de connexion. Il est donc possible d'utiliser un agent de test associ une connexion. Cela permet de dterminer si [SA 03-04]: L'application est indisponible pour tous les accs. On dduit un problme sur l'application elle-mme. L'application est indisponible sur une connexion spcifique. On en dduit un problme rseau spcifique ce type de connexion.

8. Les types de supervision:

On distingue deux types de supervision: Supervision technique Il sagit de la supervision des lments techniques. Elle porte sur la surveillance permanente du rseau, infrastructure et les machines du systme dinformation : routeur, CPU, mmoire, serveur... Son rle est de vrifier le bon fonctionnement des communications entre les composants, en dtectant les surcharges et les indisponibilits. Elle permet donc damliorer les performances du systme. Son but est de collecter des informations, anticiper et alerter sur des problmes techniques [MPSSA]. 8.2 Supervision applicative

Cette technique est plus subtile, elle nous permet de vrifier le fonctionnement dune application lance sur une machine. La supervision des applications (ou supervision applicative) permet de connatre la disponibilit des machines en termes de services rendus en testant les applications hberges par les serveurs. Le but est de surveiller en temps rel les applications mtiers pour rpondre aux exigences des contrats de services. La supervision applicative doit permettre de calculer le taux de disponibilit des applications [MPSSA]: Taux de disponibilit = MTBP : Lindice de fiabilit, est le temps moyen entre les dfaillances conscutives. MTTR : Lindice de maintenabilit, cest le temps moyen darrt.

9. Conclusion
La supervision est une technique qui concerne l'acquisition de donnes (mesures, alarmes, retour d'tat de fonctionnement) et la surveillance du bon fonctionnement dun systme ou dune activit, elle dclenche des alarmes en cas de problmes et Publier des rapports de performances permettant de prvenir les problmes futurs et d'appliquer des actions de maintenances, elle est soit technique ou applicative.

me partie : tude de lexistant

hapitre 4 : Etude de lexistant

Chapitre 4 : Etude de lexistant

1. Introduction:
Cette partie consiste mettre notre projet dans son contexte et de le positionner dans lenvironnement global de lentreprise afin de dmontrer son importance et sa valeur ajoute aux systmes qui excitent dj. Elle commence par une prsentation de la filiale ORASCOM TELECOM ALGERIE l'une des oprations GSM les plus russies de groupe ORASCOM TELECOM HOLDING qui a marqu son dbut en ALGERIE avec le lancement officiel de la marque Djezzy et avoir jou un rle majeur dans la rvolution des tlcommunications ces dix dernires annes. Elle contient ensuite une description de lorganisation interne, larchitecture du rseau et les outils et systmes disponibles pour la gestion et la surveillance de ce rseau.

2. GROUPE ORASCOM:
PRESENTATION: Fond en 1950 par M.Onsi Sawiris, Orascom tait une entreprise de construction qui, au fil du temps, diversifier ses activits. Actuellement, le groupe est compose de 4 quatre grands ples d'activit: Orascom Construction Industries (OCI) Orascom Projects & Touristic Development (OPTD) Orascom Technologies Orascom Telecom Holding (OTH) Prsent sur le march de la tlphonie mobile depuis 1998, Orascom Telecom Holding (OTH), prsid par M. Naguib Sawiris, est considre comme le plus grand et le plus diversifie des oprateurs dans le Moyen-Orient, Afrique de nord et l'Asie. A ce titre, OTH est le seul operateur tre solidement implante dans cette rgion du globe et avoir un tel degr de connaissance et d'expertise des ralits locales tout en ayant des standard de qualit de niveau international. La croissance continue que connait OTH lui octroie une place importante sur la scne des tlcommunications. Pour cela, en 2002 et aprs 4 ans d'exploitation, M. Naguib Sawiris a t lu membre du conseil de l'association GSM. Orascom Telecom dploie tout son savoir-faire pour procurer les meilleurs services ces clients, de la valeur pour ses actionnaires et un cadre motivant pour ses 20000 employs dans le monde.

Au 2eme trimestre 2007, le groupe Orascom Telecom comptait plus de 55 millions d'abonns travers l'ensemble de ses oprations. Orascom Telecom est list sur les places financires du Caire et dAlexandrie sous le symbole (ORTE.CA, ORAT EY), et la bourse de Londres sous le symbole (ORTEq.L, OTLD LI)

Prsence dans le monde:

FIGURE 10: les diffrant filial du groupe OT dans le monde.

Pays

Nom de la filiale Orascom Telecom Algerie Tunisiana Mobinil Telecel Zimbabwe (TeleZim)

Population (en million) 34.8

Nombre d'abonns 13765994

Part de march 62.7%

Algrie Tunisie Egypte Zimbabwe

10.2 78.8 12.6

3799062 16161486 242252

48.5% 48.8% 19.0%

Pakistan bangladesh

Monilink Banglalink

165.8 150.5

31774033 8310960

38.5% 21.3%

Tableau 2: les diffrentes filiales du groupe OT dans le monde et sa part de marche (Recenses en 2008)

3. ORASCOM TELECOM ALGERIE :

3.1 PRESENTATION:
Orascom Telecom Algrie est une entreprise jouant un rle majeur et prcurseur dans lenvironnement conomique et social algrien. Orascom Telecom Algrie, est une filiale de Orascom Telecom Holding. Elle a remport la deuxime licence de tlphonie mobile de type GSM au prix de 737 millions de dollars ($us) en 2001. Aujourd'hui, Orascom Telecom Algrie avec ses deux marques Djezzy et Allo OTA est devenu de loin l'operateur prfr des algriens et s'engage quotidiennement prserver son place de leader. OTA a cr plus de 70 000 emplois indirects, et plus de 5 000 emplois directs. Orascom Telecom Algrie dploie tous les moyens humains et financiers ncessaires afin d'amliorer et d'assurer une couverture rseau optimale grce des quipements la pointe de la technologie, et continue d'assurer des services de haute qualit tous ses clients sur tout le territoire national. OTA est actuellement leader avec plus 67% du march de la tlphonie mobile en Algrie. Sa stratgie commerciale est base sur quatre marques commerciales : Djezzy, Allo ota, OTAxiphone, Imtiyaz. Le capital social d'OTA est dtenu par le groupe Orascom Telecom hauteur de 96.8 % et 3.2 % sont dtenues par la socit Cevital spa. Aujourd'hui, Orascom Telecom Algrie reprsente prs de 45% du chiffre d'affaire de la holding Orascom. OTA a notamment permis la holding de devenir un groupe important du monde des tlcommunications.

3.2 HISTORIQUE et Dates Cls :

11 Juillet 7 Novembre 2001 26 Dcembre 28 Dcembre Acquisition de la licence GSM. Lancement de la marque Djezzy qui voque en arabe Djazza'a (rcompense) et Djazair (Algrie). Prsentation de la stratgie commerciale de Djezzy. Ouverture du premier centre de service Djezzy.

Lancement technique et ouverture du premier centre d'appel en Algrie. 15 Fvrier 2002 Aout Lancement du service prpay en Algrie sous le nom de Djezzy Carte. Orascom Telecom Algrie couvre les 48 wilayas.

2003

11 Septembre

Atteinte d'un million d'abonns.

13 Avril 2004 Aout 3 Dcembre

Acquisition de la licence VSAT par Orascom Telecom Algrie. Lancement de la marque Allo OTA Atteinte de 3 millions d'abonns.0

Juin 2005 28 Novembre

Lancement du premier programme de fidlit en tlphonie mobile en Algrie, Imtiyaz (qui veut dire "Excellent"). Atteinte de 7 millions d'abonns.

Mars Juillet 2006 1 Novembre 15 Novembre

Lancement d'OTAxiphone. Lancement du MedCable. Atteinte de 10 millions d'abonns. Lancement des solutions BlackBerry de Djezzy.

2007

21 Novembre

Atteinte de 14 millions d'abonns. Tableau 3: lhistorique dOTA

3.3 Prsentation gographique dOTA

Figure 11: les diffrents centres de services et les siges dOTA

3.4 Organigramme dOTA

Directeur Gnrale

Directeur Relation mdias

Directeur Gnrale Adjoint RH, Admin & Affaire juridique Direction des ressources humaines Directrice juridique Directeur des infrastructure s Directeur coordinateur des rgions Directeur Rgional Adjoint Est Directeur rgional adjoint Ouest

Directeur Gnrale Adjoint Charg de lInformatique

Directeur Gnrale Adjoint Commercial

Directeur Gnrale Adjoint Stratgie et Bus. Development

Directeur Gnrale Adjoint Finances

Directeur Gnrale Adjoint Oprations

Directeur charg et linterconnexion et de la rgulation

Direction des Ventes Directrice Marketing Directeur de la communication

Directeur de la comptabilit Directeur de Budget Directeur de la trsorerie par Intrim

Directeur du dploiement du rseau Directrice Support aux Oprations Directeur rseau daccs Directeur de lingnierie Directrice de service client

Figure 12: organigramme dOTA

3.5 Le rseau dOTA

Pour rappel, Orascom Tlcom Algrie est le leader de la tlphonie mobile en Algrie. Avec un simple rseau GSM plus de 7500 sites BTS et 20 switches (MSC), loprateur recouvre prs de 68% de la population, parce que cest aussi un oprateur lcoute de ses abonns qui a mis sur la proximit. Djezzy renforce chaque jour son rseau de distribution constitu de 7 distributeurs exclusifs, pour assurer la performance de la couverture de rseau, OTA un centre national de supervision.

4. Le centre national de la supervision

4.1 Prsentation de centre national de la supervision de rseau OTA :
Le NSC (Network Supervision center), la structure ou nous avons effectu notre stage de fin tude, est un centre oprationnel qui a une importante mission consistant recevoir, contrler, traiter, et faire le suivi de toutes alarmes influant sur le rseau national dO.T.A et le transfert vers dautres comptences pour la rsolution permanente des anomalies. Il englobe plusieurs NMS (Network Management System : OMC-R, OMC-S, etc..) relis aux diffrents quipements du rseau, et sont charg de remonter l'tat de ces quipements, gnrant des alarmes en temps rel en cas d'incident "le monitoring dalarmes", ces alarmes font l'objet d'analyse pour les traiter selon leur impact sur la performance de rseau.

4.2 Centre national de la supervision de rseau OTA :

4.2.1 Les moyens de la supervision : Qui se rsument : Des stations de supervision BSS Des stations de supervision NSS Des stations de supervision des plateformes INs Des stations de supervision SDH Des stations de supervision PDH Des stations de supervision compression Des stations de supervision GPRS Des stations de supervision MedCable Des stations de supervision DCN Des stations de supervision SMSC et VAS Des Stations de Travail Superviseur & support Des stations de supervision GATEWAY et international

Des Stations de Base de Donnes et application de gestion de la supervision. Un vido Wall gant sur mure des lignes tlphoniques PABX, Fixe et mobile Ces moyens et outils reprsentent l'infrastructure de la supervision de rseau dOTA et qui sont dlivrs prs de plusieurs fournisseurs. 4.2.2 Flux d'informations : 4.2.2.1 Alarme : Le rle majeur du systme de gestion du rseau "NMS" est la possibilit de dtecter en temps rel les problmes survenus sur les NEs "Alarmes". 4.2.2.1.1 Classification D'alarmes :

a) Alarme de scurit : Une alarme de ce type est principalement associe dans une condition concernant une violation de scurit, telle que la violation d'intgrit, la violation oprationnelle, violation physique, etc. b) Alarme de configuration : Une alarme de ce type est principalement associe une condition concernant un vnement de configuration tel que la cration ou la suppression d'objet ou la modification des paramtres. c) Svrit d'vnement : La svrit d'vnement peut tre classifie sous les 6 catgories de bases suivantes: Critique Majeur Mineur Warning Eclair indtermin d) Temporisation : Si un vnement "E" demeure un intervalle de temps plus longtemps que "D" puis il est qualifi comme "alarme" e) Frquence : Si le temps de l'vnement des "E" se produit plus qu'un "N" fois dans un intervalle "D" de temps, il est qualifi comme "alarme"

f) Corrlation D'vnement : La prsente partie explique la diffrence entre un incident et un vnement. Un incident peut tre un vnement simple, et pourrait tre un ensemble de srie homogne ou htrogne d'vnements. Dans beaucoup de cas les alarmes apparues sur lOMC ne dcrivent pas la cause du problme, et parfois pour le mme problme nous pourrions avoir plus d'un

vnement et plus d'une alarme, mais pour chaque problme qui se produit sur le systme il y a seulement un incident. Une autre diffrence importante est que les vnements et les alarmes dcrivent les consquences d'un problme, alors que l'incident dcrit le problme rel luimme. Le procd de transformer un ou plusieurs vnements/alarmes en un incident nomm Event Correlation . 4.2.2.1.2 Disponibilit, programmation et affichage : prvoira la collection continue d'alarmes moins que

Il est indispensable que le NMS

l'administrateur nen dcide autrement, il doit prvoir les fonctionnalits suivantes concernant le rapport vnement, et en particulier la disponibilit de collection. Le NMS doit tenir compte de la dfinition des vues de rseau pour diffrentes

comptences d'utilisateurs comme : reconnaissance automatique d'alarme dgagement automatique dalarme mcanismes d'escalade d'alarme Possibilit de changer manuellement le rapport d'vnement et le statut de collection d'un objet contrl pour "permettre l'oprateur d'arrter et de reprendre l'activit de collection d'alarmes pour un objet spcifique" Soutenir une retenue des objets contrls avec la propagation des tats d'alarme par la hirarchie (Child-Parent), et a la capacit de passer les alarmes vers le haut (les alarmes qui touche le Child doit tre apparue sur lobjet parent en spcifiant son impact sur lensemble) Le NMS doit tenir compte de l'assignation (ou la re-assignation) d'une personne

responsable (manager de maintenance) pour chaque partie de rseau. 4.2.2.1.3 Gestion et prsentation d'alarmes :

Le systme de gestion "NMS" prvoit les fonctionnalits suivantes concernant la gestion d'vnement et d'alarme en temps rel et la prsentation. l'application de gestion d'alarmes (alarme management) doit tre lie la mise jour automatique les donnes de gestion de configuration pour les objets contrls du rseau en

cas d'addition, de suppression et de modification, "une addition de BTS, swap vers un autre BSC, ou migration de BSC d'un MSC un autre ou addition/rsiliation". L'accs linterface des alarmes sera contrlable bas sur le nom d'utilisateur et sera configurable par ladministrateur qui pourra dfinir le profil de chaque utilisateur. Il doit supporter lAccs multiples. Plusieurs utilisateurs peuvent souscrire en mme temps la mme interface selon leurs profils. Un statut-mcanisme d'alarmes sera soutenu pour contribuer vers une meilleure manipulation d'alarme. Par exemple, les tats suivants pour des alarmes ont pu tre soutenus : Acknowledged Un-acknowledged Active Cleared handled (li un TT) Not handled (non li un TT) Archived L'alarme pourra tre manuellement claire dans n'importe quels tats ci-dessus Pour les entits qui ne sont pas encore oprationnel, les administrativement, fermes ou juste cres dans la base de donnes du systme doivent tre diffrentiables des entits oprationnelles. Les alarmes de telles entits ne doivent tre signales l'quipe de supervision que lorsque le statut sera oprationnel. L'illustration des alarmes sur des mappes, avec des indications graphiques des alarmes et des icnes reprsentant les objets contrles. L'oprateur pourra tre en mesure de : a. choisir les icnes reprsentant lobjet surveill et lancer les oprations de gestion b. laisser plusieurs fentres pour diffrentes reprsentations du rseau sur l'cran c. employer une bote de navigation et une fentre de clture pour diriger, faire bourdonner et entrer dans d'autres dtails d'alarme Des icnes graphiques reprsentants les objets contrls devraient tre assignes non seulement au objet de haut niveau (MSCs / BSCs etc) mais aussi pour les BTS et mme pour les composant des BTS et les liens MW etc. Une fentre en temps rel de vision d'alarmes sera supporte pour fournir une liste de toutes les alarmes. Les fonctionnalits suivantes seront exiges :

a. Soutenir la mise jour (en temps rel) dynamique de l'affichage comprenant les conditions de dfaut, sa svrit et acknowledgement statut. b. Contenir un sommaire tendu des alarmes. Permettre aux alarmes d'tre choisie pour l'affichage group par vue de rseau, objet contrl, type, svrit, priode d'occurrence, tat ou n'importe quelle combinaison de ces champs Permettre laffichage de tous les champs d'alarmes, et permet le dplacement des champs de l'affichage, pour la personnalisation des listes d'alarme. Permettre le choix des alarmes par l'intermdiaire d'une souris. Permettre l'envoi diffrents appareils de sortie tels que des imprimantes, courrier, dossier de totalit ou d'une liste choisie d'alarmes bases sur de certains critres et/ou seuils sur les champs dalarme (ex: imprimer tous les alarmes qui correspond au sites HS, les envoyer par courrier...etc.) Il faut quil soit possible de lancer de multiples exemples de la fentre d'alarmes en temps rel, chacune avec ses propres critres et configuration d'affichage Permettre de reprsenter la svrit et le statut d'acknowledgement avec des couleurs personnalises sur le graphique et les listes d'alarmes. A chaque fois qu'il y a une nouvelle alarme sur un objet contrl avec acknowledgement mais pas dclairement d'alarme, les informations additionnelles seront fournies pour attirer l'attention du superviseur (ex: clignotement ou oscillation) Comporter une alarme secondaire, lorsquun objet est compos de plusieurs entits, la gnration d'une alarme d'une certaine svrit venant d'une entit. L'icne reprsentant lobjet parent sera colore et clignotera, avec la couleur d'alarme la plus grave lie une ou plusieurs entits. Permettre aux oprateurs de dfinir ou de modifier les rgles et les seuils dterminant quand un vnement ou une combinaison dvnements deviendront une alarme vidente la fentre de vision d'alarme en temps rel. Permettre aux oprateurs de reconnatre des alarmes (faire acknowledge). Une reconnaissance d'une alarme sera vue par tous les utilisateurs, selon leurs droits souscrivant au systme qui correspond l'alarme. Permettre lacknowledge automatique d'alarme, bas sur les ensembles configurables des critres sur des champs d'alarme.

Permettre l'enregistrement de lidentite de lutilisateur et le moment de lidentification dalarme Acknowledge dalarme . En cas de lacknowledge automatique d'alarme, lidentit de systme et du temps doivent tre enregistre. Permettre le dgagement (clairement) d'alarme quand un vnement dtect annonce que le problme qui a caus l'alarme est rgl et donner la main loprateur pour valider la fermeture du Trouble ticket dans le cas o un TT est ouvert. Tenir compte de l'escalade de svrit d'alarme automatique base sur la priodicit de et sur un certain tat (ex: unacknowledged). La priodicit et l'tat seront configurables par l'administrateur, en outre, un intervalle diffrent de temps pourrait tre indiqu pour chaque svrit d'alarme. Permettre une alerte audible des alarmes unacknowledged, les superviseurs pourront permettre ou neutraliser un signal audible (ex: cloche) pour annoncer une nouvelle alarme. Lutilisateur pourra choisir si les nouvelles alarmes apparaissent au dbut ou l'extrmit d'un affichage. Les utilisateurs pourront effectuer une opration sur plus d'une alarme la fois. Le choix multiple d'alarme pourra tre excut par la souris en appliquant un ensemble de critres sur des champs d'alarmes et la description d'alarme (prdfinis et sauvegards probablement dans une liste). Les actions suivantes sur des choix multiples d'alarme sont : Acknowledgment Clearance Source sur la map Plein affichage de l'information Impression Permettre daccder directement lquipement depuis la fentre d'alarmes et dafficher les informations pour un NE avec un simple clic droit. 4.2.2.1.4 Notation D'vnement (Event log) :

Le systme de gestion met en application une opration de service de notation, prvoyant les fonctionnalits suivantes : Permettre la cration d'une notation d'vnement en se rfrant lexistant, utilisant ses attributs ou caractristiques principaux. Permettre la cration, la suppression et de la modification d'une notation d'vnement. Permettre l'association d'une notation d'vnement avec le rseau entier ou les parties choisies en lui formant une vue de rseau (domaine).

Admettre des notations multiples d'vnement. Il devrait y avoir trois types de notations : a. Notations d'vnement de base. b. Notations d'vnement corrles bases sur la corrlation de sous-systme/inter soussystme c. Les notations collectives de tout le systme. La base de donnes de notations d'vnement devrait permettre des mthodes et des procdures standard et avances. 4.2.2.1.5 Filtres dalarmes et corrlation :

Le systme de gestion de rseau prvoit les fonctionnalits suivantes concernant les filtrages d'vnement et de corrlation, Le mcanisme de filtrage : Prvoir la capacit de manipuler des vnements retards et de les employer dans des dcisions de corrlation, au besoin. Permettre la suppression en temps rel des vnements transitoires. Corrler des vnements dun objet et tous ces composants, pour pouvoir identifier la cause et les racines d'une alarme venant de diverses sources. Corrler des alarmes claires avec les alarmes actives concernant le mme problme. Possibilit de rduire le nombre d'vnements produits en crant un nouveau jet d'vnement avec des donnes consolides des vnements de source. Existence d'un filtrage, un concepteur et un simulateur de corrlation pour crer des rgles de filtrage et de corrlation. Ce service pourra tre lanc dans le module de base de gestion dalarmes. Possibilit d'diter des dossiers de configuration pour placer les divers attributs de filtre et de corrlation. Ceci peut tre employ comme une copie de remplacement de filtre, en cas de son indisponibilit pour n'importe quelle raison. 4.2.2.2 Exigences de Trouble ticketing : Le systme de gestion de rseau "NMS" est associ un mcanisme de gestion des troubles tickets (TTs), capable de crer des rapports entre les alarmes et les (TTs).De tels rapports seront tablies pour aider linvestigation sur un problme particulier. Le fournisseur doit spcifier l'interface qui peut tre employ en coopration avec des systmes de trouble ticketing pour crer ou modifier les TTs de cette application. Le systme prvoit fonctionnalits suivantes : Le systme tient en compte lassignation (ou le re-assignatin) une personne responsable (Responsable de la maintenance; intervenant; support...etc.) pour chaque TTs. les

Possibilit d'associer des alarmes (groupe) sur un TT. Cette association sera faite directement partir de la fentre de manipulation en temps rel (opration manuelle) ou automatiquement base sur des rgles de filtrage et de corrlation de l'vnement. Les alarmes pourront tre associes un nouveau TT cr spcifiquement pour tudier ce problme, ou un TT existant pour ajouter plus d'information a linvestigation du problme. Les alarmes pourront tre associes aux TTs rappelant ou indiquant les diffrentes actions pour un problme spcifique. Admettre au moins quatre niveaux de svrit des TTs, chacun est reli a un

temporisateur d'escalade. Le chemin d'escalade et les temporisateurs sont configurs selon la procdure d'escalade. Procder automatiquement lescalade selon une procdure choisie parmi une varit de procdures d'escalade dfinies par utilisateur.

Selon les procdures alternatives d'escalade, permettre la svrit du TT d'tre chang selon limpact des alarmes et la persistance du problme. par exemple si une BTS simple ne revient pas en service aprs 2 heures, la svrit de TT le statut devrait changer au prochain niveau de svrit. Permettre que des commentaires soient ajouts au TT. N'importe quel texte est considr utile sil rsout le problme et pourra tre enregistr par l'intermdiaire de cet outil Fournir aux utilisateurs linformation concernant l'endroit du problme et de son impact possible. Fournir les dispositifs d'accs aux bases de donnes, pour tenir compte d'une information qui concerne le TT. Les actions de tous les utilisateurs doivent tre notes. A la fermeture du rapport, prsentait un rcapitulatif de la rsolution du problme. Permettre l'analyse statistique et les possibilits de gnration des rapports qui : permettant aux utilisateurs didentifier facilement les points sensibles du rseau, les checs matriel et logiciel chroniques. Associer un accord de niveau de service un ou plusieurs fournisseurs, afin dvaluer la rponse du fournisseur. Tenir compte des dfinitions et de la personnalisation pour l'utilisateur en ce qui concerne:

Les dispositions priorits des troubles tickets gnration automatique de trouble ticket critres d'accs d'utilisateur mthodes pour informer les quipes de support 4.2.2.3 Rapports Techniques de la supervision : Il existe plusieurs rapports remplir : un rapport journalier des coupures de trafic affectant divers entits du rseau. rapport des alarmes denvironnement : rapport hebdomadaire sur les alarmes denvironnement actives BSS. rapport des alarmes hardware : rapport hebdomadaire sur les alarmes quipement actives BSS. rapport des instabilits des liens : rapport journalier sur les instabilits des liens enregistrer sur BSS (Alcatel& Siemens). un rapport qui contient tous les HS de la journe prcdente (rgl ou non). un rapport hebdomadaire qui contient ltat du rseau durant la semaine (problmes rgls ou non), il comprend aussi les sous-traitants ayant intervenus sur les problmes rgls. 4.2.2.4 Les Bases De Donnes : La rsolution des alarmes ncessite lexistence dun support de donne bien dfini qui permet le bon fonctionnement du systme, or il ny a aucune base de donnes contenant les informations fiables a lexception de certains fichiers Excel.

4.2.3 Les Taches de travail : Alarme dtect

NON

Problme QoS "BSS ou NSS ou Transmission"

OUI

Alerting du concern "Appel ou SMS"

Alerting du concern "Appel ou SMS" + mentionner sur daily report

OUI Sou trait

NON

NO N OUI

Sou trait NON

OUI

Envoie FAX au sou traitant " MAIL "

Poursuivre les procdures d'escalade pour chaque cas " Appel + SMS "

Sou trait

Envoie FAX au sou traitant " MAIL "

Envoie FAX au sou traitant " MAIL +FAX "Mentionner aux coupures PTT

Poursuivre les procdures d'escalade pour chaque cas " Appel + SMS + MAIL "

Figure 13: les taches de travail dans le centre de la supervision dOTA

4.2.4 Vision & Objective : Notre objectif est dtablir un systme de gestion et supervision centralis et automatis pour OTA. Cet outil a principalement pour but de centraliser sur une seule interface les alarmes remontes des diffrents NMS existants, les faire enrichir avec des donnes externes et des informations en provenance des diffrentes bases de donnes, pour permettre aux superviseurs de connaitre tout instant l'tat des lments du rseau et des services tournant sur les diffrents serveurs, d'envoyer des notifications ( courriel, message instantan, etc..) en cas de mise hors tension d'un quipement, l'arrt d'un service, le risque sur l'quipement ou une anomalie de fonctionnement. Il doit galement tre capable d'analyser le trafic du rseau afin de permettre une meilleure rpartition de ces ressources et dlivrer des rapports dans les plus brefs dlais sur l'tat du rseau Ce systme doit tre conforme ce que suit : Contrler et grer les dfauts Etre Capable dindiquer l'tat global du rseau n'importe quel moment Etre Capable de donner les informations sur chaque lment du rseau, et n'importe quel moment Contrler les quipements des plusieurs fournisseurs Contrler les multi types de serveurs (OMC-R, OMC-S,..) contrler les multi sous-ensembles (NSS, BSS, TRANS,..) Contrler les multi technologies (PDH, SDH,..) Gestion et rcolte d'alarmes Dcouverte automatique des quipements Interrogation/Configuration d'quipements Rcupration d'vnements et archivage des historiques Capables d'informer des personnes de divers informations/vnements en utilisant les divers moyens de communications. 4.2.5 Diagnostic Le but de ltude de lexistant est de recenser lensemble des anomalies informationnelles, techniques et organisationnelles rencontres, de dterminer les causes qui ont induit aux anomalies de ce dernier, en recensant les carences observes lors de ltude et le parachvement par la proposition de solutions, pour cela nous adopterons une mthode dite causale anomalies, causes.

Anomalie 1 : Retard de notification des alarmes signifie quil a y plusieurs problmes simultans Cause: Linexistence dun systme danalyse automatiquement les alarmes oblige lquipe de supervision de faire cette opration manuellement ceci retarde le temps de rponse pour la rsolution des dfauts. Ce facteur humain implique une augmentation du temps de rsolution du ce problme, se reproduisant diffrentes moments. Consquences : Possibilit doubli de lalerte des problmes. Retard dans la rsolution des problmes. Anomalie 2 : Absence de scurit informatique. Cause: Linexistence dune base de donnes pose un problme de scurit Labsence du contrle daccs des utilisateurs, Labsence de contrle des donnes lors de leurs manipulations. L'utilisation des documents Word et Excel et mme ceux transcrit pour la sauvegarde des donnes. Consquences : Possibilit de perte de donnes et de fichiers de sauvegarde. Modification des donnes concernant les sites, les intervenants, etc. Anomalie 3: La lenteur daccs aux informations. Elle est dpendante du nombre de taches excutes par la machine. Cause: Absence de logiciel gerant la base de donnes contenant toutes les informations ncessaires. Consquences : Cette lenteur daccs aux informations implique pour les utilisateurs des retards dans laccomplissement de leurs travaux cumulatifs. La consultation et la mise jour des donnes demandent de temps aux utilisateurs.

Anomalie 4 : Pas dinformation sur l'tat du rseau un moment donne. Cause: Linexistence de systme qui indique ltat du rseau en temps rel, pour chaque rgion et chaque quipement. Consquences : La non dfinition du nombre de sites, de BSC hors services par wilaya ou dans une

rgion donne et dans le temps.

Anomalie 5: La gestion manuelle des troubles tickets et des rapports. Cause: Linexistence dun systme qui gre les rapports et les troubles tickets automatiquement. Consquences : Le superviseur Perd beaucoup de temps dans louverture, la fermeture des tickets et la gnration des rapports. Anomalie 6 : Les erreurs de saisie dans la gnration des nouvelles informations ou des rapports. Cause: Linexistence dun systme pour la saisie des nouvelles informations (ex : lajout dun nouveau site dans la BDD, une addition de BTS, le swap vers un autre BSC, ou la migration de BSC d'un MSC un autre). Consquences : La rptition des saisies chaque erreur dtecte. Perte de temps.

5. Conclusion
Ltude de lexistant a permis la comprhension du systme et ce, travers lanalyse dtaille des postes, procdure de travail, des documents manipuls,etc. Ainsi que la dtection des dfaillances de fonctionnement et la connaissance des nouveaux besoins de lorganisation, donc la fixation des objectifs de ltude afin quelle soit la base de la conception dun systme dinformation performant.

me partie : Conception et ralisation

hapitre 5 : tude conceptuel

Chapitre 5 : Ltude conceptuelle

1. Introduction :
Une fois acheve la partie tude de lexistant qui nous a permis de dcrire lintrt dun tel systme nous entamons ltude conceptuelle. La phase de conception a pour objectif de dterminer des mthodes informatiques et techniques pour la mise en uvre et construction du systme analys au cours des phases prcdentes en tenant compte des contraintes informatiques et techniques.

2. Formalisme de modlisation choisi : UML

Toute dmarche de conception ncessite une modlisation. Notre choix sest port sur la mthode UML. Celle-ci offre la possibilit de modliser les entits du domaine tudi, tout en permettant la structuration de linformation gographique pour une meilleure organisation de la base de donnes. Ceci a pour consquence, de tendre vers une meilleure lisibilit et comprhension de loutil, en vue de sa mise jour et son volution. (Voir annexe E)

3. Modlisation du systme
La modlisation du systme est la premire tape de notre dmarche de dveloppement. Elle consiste quantifier les besoins fonctionnels et oprationnels, et est constitue les phases suivantes : 1) Identifier les acteurs. 2) Modliser le contexte 3) Prciser les cas dutilisations 4) Crer les diagrammes importants

3.1 Identifier les acteurs.

Lacteur est une entit qui interagit avec lapplication, il est soit un utilisateur (Humain), soit un systme qui fournit des services ou qui utilise les services de lapplication. Un acteur est abstraction dun rle cest - dire un acteur qui peut jouer deux rles diffrents ; Deux acteurs diffrents peuvent avoir le mme rle. Dans notre conception, les acteurs sont dcrits comme suit :

3.1.1 Ladministrateur du systme : Il soccupe de la gestion des profils des utilisateurs et de leurs privilges, de rsoudre les erreurs lies lauthentification et grer la maintenance du systme. 3.1.2 Le Superviseur Celui-ci gre les problmes lis au rseau. Il assure sa surveillance, lapplication de la procdure dalerting et descalade, louverture, le suivi et la fermeture des Tickets et transmettre des Emails ou des messages de notification vers les groupes de maintenance. Il assure aussi le rapport du ltat du rseau 3.1.3 Lquipe danalyse et de support Elle gre les feedbacks sur rapports du superviseur et la mise jour de ces rapports, ainsi que lanalyse sur la qualit du rseau et lefficacit des quipes de maintenance, base sur le calcul des KPI dvaluation. Elle a aussi, pour rle la mise jour des bases de donnes. 3.1.4 Responsable de la supervision Son rle est lOrganisation des quipes et du respect des procdures de la supervision. 3.1.5 Service maintenance (Owner) Il soccupe de la rsolution des problmes lis au Ticket ouvert par la supervision et assure la maintenance prventive et corrective du rseau. Il rpond au ticket par des commentaires dintervention dtaills, ce qui vont permettra lquipes de support de fermer le ticket avec une bonne information et de faire une assignation correcte au groupe concern. 3.1.6 Support de stockage : Cest un support contenant des fichiers input et output ayant un rle trs important dans notre systme. 3.1.7 SMSC (Loperateur): Cest lacteur qui dirige les SMS vers les stations mobiles. 3.1.8 OMC (serveur) Cest lacteur qui gre le rseau, corrle les alarmes des NE et les remonte sur lcran des superviseurs. 3.1.9 Outlook (serveur) Cest lacteur qui route les Emails vers les stations PC.

3.2 Modliser le contexte

La description des diffrents acteurs permet de dgager un diagramme de contexte pour le systme [gestions de la supervision de rseau GSM], il permet aussi de prsenter lutilisation du systme par les diffrents acteurs au vu de la solution adopte. Dans la figure ci-dessous, nous avons illustr les diffrents acteurs qui interagissent dans notre systme, et ceci travers un diagramme de contexte.

Owner Administrateur Lquipe danalyse et de support

Responsable de la supervision Outlook

Superviseur

OMC

Support de stockage

SMSC

Figure 14: le diagramme de contexte

3.3 Description des cas dutilisation (Voir annexe E) :

3.3.1 Dcoupage en catgories : Les cas dutilisation du systme gestion de supervision des rseaux GSM montrer le lien existant entre les cas dutilisation et les acteurs correspondants ainsi que les messages provenant du contexte. Le tableau ci-aprs rsume les principaux cas dutilisation qui seront dtaills par la suite. Cas dutilisation Authentification au systme Gestion des sites Acteurs Administrateur Utilisateurs Administrateur Finalit Laccs au systme. Tous les sites sont paramtrs et enregistres dans le systme. Tous les contacts sont paramtrs et enregistres dans le systme. Toutes les socits sont paramtres et enregistres dans le systme. Nouvelle Alarme enregistre et prise en charge pour le traitement. Archivage et filtrage des alarmes.

Gestion des contactes Gestion des socits partenaire gestion des Alarmes

Administrateur Administrateur Administrateur responsable de la supervision OMC Superviseur support de stockage superviseur

traitement des alarmes

alerte par SMS

Alerte par MAIL

Gestion des troubles tickets Escalade

gestion des rapports

Feedback

information des groupes de maintenance sur les alarmes qui SMSC existent dans le rseau. Superviseur Information des groupes de Outlook maintenance sur les problmes qui existent dans le rseau. Superviseur Archivage de lhistorique des support de stockage alarmes dans la BDD. Superviseur Information des suprieurs SMSC hirarchiques sur les problmes de Outlook grand impact et qui est persiste dans le rseau. lquipe danalyse et de support Gnrer et envoyer automatiquement support de stockage des rapports. Outlook Owner Mise jour de lhistorique des lquipe danalyse troubles tickets. et de support Owner administrateur. Ngligence des alarmes des sites en SW.

Travaux programms (PM)

Gestion des utilisateurs

Administrateur

gestion de la traabilit

Administrateur

Enregistrement des utilisateurs du systme et attribution des droits daccs. Le traage informatique des utilisateurs est dtermin.

Tableau 4: liste des cas dutilisation. 3.3.2 Etude dtaille des cas dutilisation : Dans ce qui suit nous allons dtailler les cas dutilisation de notre systme. 3.3.2.1 Cas dutilisation Authentification au systme :

Figure 15: diagramme du cas dutilisation authentification au systme

Authentification

But: Laccs au systme gestion de supervision des rseaux GSM . Rsum: Tout utilisateur a un login et un mot de passe pour pouvoir accder au systme et tre authentifi. Acteur: Les utilisateurs (de systme). Enchanements : Introduction du nom dutilisateur et du mot de passe. Validation des informations, Si le systme dtecte que le nom dutilisateur et/ou le mot de passe est incorrecte, alors excuter [Exception1]. Exceptions1 : Le mot de passe et/ou le nom dutilisateur incorrect.

3.3.2.2 Cas dutilisation gestion des sites Figure 16: diagramme du cas dutilisation gestion des sites

Gestion des sites administrateu

But : enregistrement de toutes les informations de nouveau site dans le systme. Acteur : administrateur du systme. Pr-condition : installation dun site dans un endroit dfini. Description des enchanements : Enchanement (A) : Ajouter un site afficher le formulaire pour ajouter le site. Remplir le formulaire qui contient toutes les informations dun site donne (code site, nom de site, wilaya, rgion, Owner, position GPS, autonomie, nombre de secteur dans le site, type dquipement, ). Valider ces informations. Si le systme dtecte que le site existe dj, alors excuter [Exception1], Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2].

Enchanement (B) : Mise jour des informations dun site Ladministrateur accde aux informations de site (en mode modification) en slectionnant cette dernire dans la liste des sites met jour les informations dsires. Valider les nouvelles informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2]. Enchanement (c) : suppression dun site Ladministrateur peut supprimer une ou plusieurs sites en le/les slectionnant dans la liste des sites et en cliquant sur le bouton Supprimer , le systme affiche un message de confirmation qui demande au ladministrateur de valider la suppression. Si ladministrateur valide lopration de suppression, le/les sites ou les sites en question seront supprime(s) de la base de donnes et la liste mise jour. Si ladministrateur clique sur le bouton Supprimer sans choisir aucun site alors excut [Exception3].

Exceptions : Exception1 : Le systme affiche un message derreur qui indique que le site existe dj. Exception2 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Exception3 : Le systme affiche un message derreur qui indique quil faut choisir au moins un site afin dexcuter lopration dsire. Post-conditions : Tous les sites sont paramtrs et enregistres dans le systme. 3.3.2.3 Cas dutilisation gestion des contacts Figure 17: diagramme du cas dutilisation gestion des contacts

Gestion des contactes administrateu But : enregistrer les informations dune contacte dans le systme. Acteur : administrateur du systme. Pr-condition : Owner ou employ contractuel avec OTA. Description des enchanements : Enchanement (A) : Ajouter un contact. afficher le formulaire contenant les informations dun contact. Remplir le formulaire qui contient toutes les informations du contact (numro, nom, prnom, rgion, numro de tlphone, adresse, grade, ). Valider ces informations. Si le systme dtecte que le contact existe dj, alors excuter [Exception1], Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2]. Enchanement (B) : Mise jour des informations dun contact. Ladministrateur accde aux informations des contacts selon des paramtres choisis (en mode modification), en slectionnant cette dernire dans la liste des contacts. mise jour les informations dsires. Validation des nouvelles informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2].

Enchanement (c) : suppression dune contacte Ladministrateur peut supprimer une ou plusieurs contacts en le/les slectionnant dans la liste des contacts et en cliquant sur le bouton Supprimer , le systme affiche un message de confirmation qui demande la validation de la suppression par ladministrateur. Celui-ci valide lopration de suppression, le/les contacts en question seront supprime(s) de la base de donnes et la liste mise jour. Si ladministrateur clique sur le bouton Supprimer sans choisir aucune contacte alors excut [Exception3]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique que la contact existe dj. Exception2 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Exception3 : Le systme affiche un message derreur qui indique quil faut choisir au moins un contact afin dexcuter lopration dsire. Post-conditions : Tous les contacts sont paramtrs et enregistres dans le systme.

3.3.2.4

Cas dutilisation Gestion des socits partenaire (SP)

Figure 18: diagramme du cas dutilisation gestion des societes partenaire

Gestion des socits partenaire administrateur

But : enregistrer les informations dune SP dans le systme. Acteur : administrateur du systme. Pr-condition : SP signer contrat avec OTA.

Description des enchanements : Enchanement (A) : Ajouter SP. afficher le formulaire qui contient les informations dune socit partenaire. Remplir le formulaire qui contient toutes les informations dune SP (code, nom, rgion, numro de tlphone, adresse, Email, ). Valider ces informations. Si le systme dtecte que la SP existe dj, alors excuter [Exception1], Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2]. Enchanement (B) : Mise jour des informations dune SP. Ladministrateur accde aux informations des SP (en mode modification) en slectionnant cette dernire dans la liste des SP. mise jour des informations dsires. Validation des nouvelles informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2]. Enchanement (c) : suppression dune SP Ladministrateur peut supprimer une ou plusieurs SP en la/les slectionnant dans la liste des socits et en cliquant sur le bouton Supprimer , le systme affiche un message de confirmation qui demande ladministrateur de valider la suppression. Sil valide lopration de la suppression, la SP ou les socits en question seront supprime(s) de la base de donnes et la liste mise jour. Si ladministrateur clique sur le bouton Supprimer sans choisir aucune SP alors excut [Exception3]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique que la SP existe dj. Exception2 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Exception3 : Le systme affiche un message derreur qui indique quil faut choisir au moins une SP afin dexcuter lopration dsire. Post-conditions : Toutes les SP sont paramtrs et enregistres dans le systme.

3.3.2.5 Cas dutilisation gestion des Alarmes Figure 19: diagramme du cas dutilisation gestion des alarmes

Gestion des Alarmes Administrate Responsable de la supervision

But : sauvegarder une alarme dans le systme pour traiter un type de problme qui pose des dfaillances dans le rseau. Acteur : administrateur du systme, responsable de la supervision. Pr-condition : larrive dun ordre de responsable de la supervision (EMAIL par exemple). Enchanement (A) : Ajouter Alarme. Ladministrateur du systme affiche et remplit le formulaire contenant les informations dune alarme (nom dalarme, priorit, impacte, ). Valider ces informations. Si un ou plusieurs champs obligatoires sont vide alors le systme excut [exception1]. Enchanement (B) : Mise jour des informations dune alarme. Ladministrateur accde aux informations des alarmes (en mode modification) en slectionnant cette dernire dans la liste des alarmes. met jour les informations dsires. Valider les nouvelles informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception1]. Enchanement (C) : suppression dune alarme. Ladministrateur peut supprimer une ou plusieurs alarmes en la/les slectionnant dans la liste des alarmes et en cliquant sur le bouton Supprimer , le systme affiche un message de confirmation qui demande la validation de suppression. Sil la valide, la/les alarmes en question seront supprime(s) partir du BDD et la liste mise jour.

Si ladministrateur clique sur le bouton Supprimer sans choisir aucune alarme alors excut [Exception2]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Exception2 : Le systme affiche un message derreur qui indique quil faut choisir au moins une alarme afin dexcuter lopration dsire. Post-conditions : Nouvelle Alarme enregistr et prise en charge pour le traitement. 3.3.2.6 Cas dutilisation travaux programms (SW) Figure 20: diagramme du cas dutilisation travaux programmes

Travaux programms Administrateu r But : nalerte pas les alarmes des sites en SW. Acteurs : Owner, administrateur. Pr-condition : larriv de lordre de lOwner. Enchanement : Afficher le formulaire pour ajouter le SW quarrive. Remplir le formulaire avec toutes les informations dun SW (code SW, description dun SW, dbut dun SW, la fin dun SW, impacte dun SW). Valider ces informations. Si le systme dtecte que le SW existe dj, alors excuter [Exception1], Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception2]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique que la SW existe dj. Exception2 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Post-condition : SW enregistrer dans notre systme. Owner

3.3.2.7 Cas dutilisation traitement des alarmes Figure 21: diagramme du cas dutilisation traitement des alarmes

Traitement des alarmes OM C Gestion des alarmes includ includ Superviseur

Travaux programms Support de stockage

But : Analyser les alarmes pour dfinir le type de problme et afficher le filtre des alarmes. Acteur : OMC, superviseur, support de stockage. Pr-condition : prise en charge dun nouveau problme dans un site donne. Enchanement (A) : envoie alarme. LOMC dtect tous les problmes qui existent dans les diffrents sites. LOMC envoy les alarmes vers les stations de la supervision. Les alarmes doivent tre consultes par les superviseurs. Enchanement (B) : acquisition des alarmes. A partir de toutes les stations de la supervision et laide de protocole FTP, on gnre un scripte (fichier Txt) contenant toutes les alarmes et on enregistre le fichier dans le support de stockage. Enchanement (C) : archivage des alarmes. Le superviseur accde au systme, en cliquant sur le bouton archivage des alarmes le systme affiche une fentre pour slectionner le fichier archiv, le superviseur choisi le dernier fichier rcupr puis enregistre ce fichier dans la BDD. Si le systme dtecte que le fichier dj archiv alors excut [exception1], si le format de fichier nest pas valide alors excut [exception2].

Enchanement (D) : analyser les alarmes et afficher le filtre. Le superviseur choisi partir de la liste des types dalarme et le filtre sera affich. A partir de cette slection le systme cherchera dans la liste des alarmes archives les problmes compatibles avec cette alarme. A partir du problme constat on extrait les informations du site associ au problme, afin dafficher le filtre des alarmes dans un tableau structur. Les donnes qui seront affiches dans le filtre sont les: (code site, nom de site, Owner de site, rgion, type quipement, alarme, date dalarme). Exceptions : Exception1 : Le systme affiche un message derreur indiqu que le fichier est dj archiv. Exception2 : Le systme affiche un message derreur indiquant le format du fichier slectionn nest pas exact. Post-condition : afficher le filtre des alarmes.

3.3.2.8 Cas dutilisation alerte par SMS Figure 22: diagramme du cas dutilisation alerte par sms

Alerte par SMS superviseur includ Traitement des alarmes SMSC

But : information des groupes de maintenance des alarmes existant dans le rseau. Acteur : superviseur, SMSC. Pr-condition : laffichage du filtre des alarmes.

Enchanement : A partir du filtre des alarmes affiches le superviseur slectionne les nouvelles alarmes qui nont pas tre alert puis choisi alerte par SMS et valide cette slection, le systme envoie le SMS vers le SMSC qui transfrera ces alertes vers les groupes de maintenances. Si le superviseur slectionne une alarme dj alert alors excut [exception1], si le superviseur clique sur le bouton alerte par SMS sans choisir aucune alarme alors excut [Exception2]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique que lalarme est dj alerte. Exception2 : Le systme affiche un message derreur qui indique quil faut choisir au moins une alarme afin dexcuter lopration dsire. Post-condition : SMS archivs (source, destinataire, contenu, la date denvoi).

3.3.2.9 Cas dutilisation alerte par Mail Figure 23: diagramme du cas dutilisation alerte par mail

Alerte par mail superviseur includ Traitement des alarmes Outlook

But : informer les groupes de maintenance sur les alarmes qui existent dans le rseau. Acteur : superviseur, serveur Outlook. Pr-condition : laffichage du filtre des alarmes. Enchanement : A partir du filtre des alarmes affiches le superviseur slectionne les nouvelles alarmes qui nont pas tre alertes, et choisi lalerte par Mail et valide

cette slection. Le systme envoie lEmail vers le serveur qui transfre ces alertes vers les groupes de maintenances. Si le superviseur slectionne une alarme dj alert alors excut [exception1], si le superviseur clique sur le bouton alerte par Mail sans choisir aucune alarme alors excut [Exception2]. Exceptions : Exception1 : Le systme affiche un message derreur qui indique que lalarme est dj alerte. Exception2 : Le systme affiche un message derreur qui indique quil faut choisir au moins une alarme afin dexcuter lopration dsire. Post-condition : Mail archivs (source, destinataire, contenu, la date denvoi).

Remarque1 : les superviseurs peuvent choisir lalerte par mail et par SMS au mme temps.

3.3.2.10 Cas dutilisation gestion des troubles tickets (TT) Figure3.3.2.11 24: diagramme du cas dutilisation gestion des tt

Gestion des TT superviseur includ Traitement des alarmes

But : archiver lhistorique des alarmes. Acteur : superviseur, support de stockage. Pr-condition : SMS ou Email envoy. Enchanement (A) : ouverture dun ticket

Senerio1 : afficher le formulaire gestion des tickets Remplir les informations dun ticket (numro de ticket, code site, nom de site, wilaya, rgion, Owner, type dalarme, date dalarme, date dalerte, date douverture de ticket, commentaire). Mettre les tickets en tat OPEN . La date dclairement des alarmes doit tre null. Valider ces informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception1]. Senerio2 : A partir du filtre des alarmes affiches, le superviseur slectionne la liste de celles-ci, puis clique sur le bouton ouvrir ticket . Le systme ouvre automatiquement un ticket sur cette alarme. Si le superviseur ne slectionne aucune nalarme alors excution [exception2]. Enchanement (B) : archivage les alarmes claires. A partir de toutes les stations de la supervision, le responsable gnre un fichier TXT contenant les informations (nom de site, lalarme, la date dbut dalarme, la date dclairement dalarme) de toutes les alarmes claires puis sauvegarde ce fichier dans le support de stockage. Enfin le superviseur accde au systme et, en cliquant sur le bouton archivage des alarmes claires, le systme affiche une fentre pour slectionner le fichier archiver, le superviseur choisi le dernier fichier gnr puis enregistre ce fichier dans la BDD. Si le systme dtecte que le fichier dj archiv alors excut [exception3], si le format de fichier nest pas valide alors excut [exception4]. Enchanement (C) : faire lhistorique et fermer les tickets. On compare les informations (nom de site, type dalarme, date dalarme) dun ticket ouvert avec les informations (nom de site, type dalarme, date dalarme) de la liste des alarmes claires archives, sil y a galit alors on met ltat de ce ticket CLOSE et on met aussi la date dclairement dalarme qui sera rcupr partir de la liste des alarmes claires. Exceptions : Exception1 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Exception2 : Le systme affiche un message derreur qui indique quil faut choisir au moins une alarme afin dexcuter lopration dsire.

Exception3 : Le systme affiche un message derreur indiquant que le fichier est dj archiv. Exception4 : Le systme affiche un message derreur prcisant que le format du fichier slectionn nest pas exact. Post-condition : alarmes archives (heure dbut, heure fin, description). 3.3.2.12 Cas dutilisation escalade 2. Figure 25: diagramme du cas dutilisation ESCALADE

Escalade includ Superviseur

SMS C

Traitement des alarmes Outlook

But : Informer les responsables suprieurs sur les problmes de grand impacte et quest rest longtemps dans le rseau. Acteurs : Superviseur, SMSC, Outlook. Pr-condition : problmes persistants dans le rseau. Enchanement : Lescalade a un processus dfini selon le temps dexistence des alarmes sur le rseau. Le systme affiche le filtre des alarmes escalader suivant une slection dalerte automatique. A partir du filtre des alarmes escalader, le superviseur slectionne lalarme puis la valider, si le superviseur na choisi aucune alarme alors excut [Exception1]. Lescalade se fait par Mail ou SMS. Exception1 : Le systme affiche un message derreur qui indique quil faut choisir au moins une alarme afin dexcuter lopration dsire. Post-condition : SMS ou Email archiv.

3.3.2.1

Cas dutilisation gestion des rapports

Figure 26: diagramme du cas dutilisation gestion des rapports Gestion des rapports includ Support de stockage Gestion des TTs Outlook Outlook But : gnration automatique des rapports. Acteurs : lquipe danalyse et de support, le support de stockage, le serveur des Emails(Outlook). Pr-conditions : le personnel de lquipe danalyse et de support sauthentifier. Description des enchanements : Enchanement (A) : gnrer un rapport. Lutilisateur accd au sous-systme rapporting selon son profil. Il peut choisir un type de rapport, le systme gnre automatiquement le rapport slectionn selon les paramtres choisis et enregistre le rapport dans la BDD. Enchanement (B) : envoi de rapport . Lutilisateur accde au sous-systme rapporting puis clique sur le bouton envoi rapport . Le systme affiche une fentre pour slectionner le rapport envoyer, lutilisateur sera slectionn partir de la liste des rapports affichs, puis valider cette slection. Le rapport sera envoy par Mail laide du serveur des Emails (Outlook). Post-condition : le rapport envoy sera archiv (source, destination, contenu, la date denvoi).

support de stockage Lquipe danalyse et de support

3.3.2.2

Cas dutilisation feedback

Figure 27: diagramme du cas dutilisation feedback

Feedback Owner Lquipe danalyse et de support

But : faire la mise jour des tickets pour gnrer le rapport des KPI. Acteur : Owner, lquipe danalyse et de support. Pr-condition : Rcupration du rapport Enchainement : LOwner Vrifier les informations des rapports reus. Il rpond aussi par des rapports dintervention dtaill. Les rclamations arrivent chez lquipe danalyse et de support. Vrification de lhistorique des alarmes. Lintervenant de lquipe danalyse et de support accde aux informations des tickets (en mode modification). met jour les informations dsires. Valide les nouvelles informations. Si un ou plusieurs champs obligatoires sont vides, alors excuter [Exception1]. Exception1 : Le systme affiche un message derreur qui indique quil existe un/des champ(s) obligatoire(s) non remplis. Post-condition : MAJ tickets enregistr.

3.3.2.3

Cas dutilisation Gestion des utilisateurs

But : Enregistrement des utilisateurs du systme et attribution des droits daccs. Acteurs : Administrateur. Pr-conditions : Ladministrateur sauthentifie. Description des enchanements : Enchanement (a) : Ajout dun nouvel utilisateur. Ladministrateur slectionne le profil du nouvel utilisateur (superviseur, quipe danalyse et de support, Responsable de la supervision,

), puis remplit les informations personnelles du nouvel utilisateur avec les droits daccs (nom dutilisateur et mot de passe), enfin il valide.

Enchanement (b) : Mise jour des utilisateurs existants. Ladministrateur peut modifier les informations personnelles, le profil ou les droits daccs des utilisateurs existant dans le systme, aprs les modifications apportes, il valide lopration. Enchanement (c) : Gestion des profils utilisateur. Ladministrateur peut mettre jour le profil daccs des utilisateurs existants, il ajoute, ou retire un ou plusieurs profils aux utilisateurs existants. Post-conditions : Tous les comptes utilisateurs sont enregistrs et mis jour avec les droits et profils daccs.

3.3.2.4

Cas dutilisation gestion de la traabilit

But : Avoir la traabilit de toutes les oprations effectues par les utilisateurs durant leurs utilisations du systme. Acteurs : Administrateur. Pr-conditions : Ladministrateur sauthentifie. Description des enchanements : Enchanement (a) : Afficher la trace dun ou plusieurs utilisateurs. Ladministrateur slectionne les utilisateurs pour lesquels il veut afficher la trace informatique. Il prcise ensuite la priode (date dbut et la date fin) souhaite. Le systme affiche alors toutes les oprations effectues par les utilisateurs slectionns. Pour chaque opration est prcise lheure de dbut et de fin. Enchanement (b) : Afficher la trace du systme. Ladministrateur slectionne loption dafficher la trace du systme. Il prcise comme dans le premier cas, la priode souhaite. Le systme alors affiche toutes les oprations effectues par les diffrents utilisateurs durant cette priode. Dans les deux cas, ladministrateur systme peut imprimer la trace informatique affiche. Post-conditions : La trace informatique des utilisateurs est dtermine, et peut servir de preuve pour faire face aux problmes.

3.3.3 Regroupement des cas dutilisation : Nous proposons de dcouper les cas dutilisation en 4 packages, savoir : 3.3.3.1 Le package administration : Authentification. Gestion des sites. Gestion des contacts. Gestion des socits partenaires. Gestion des Alarmes. Gestion des utilisateurs. Gestion de la traabilit. 3.3.3.2 Le package Gestion des alertes : Traitement des alarmes Alerte par SMS Alerte par MAIL Escalade Travaux programms (PM) 3.3.3.3 Le package gestion des tickets : Gestion des troubles tickets. Feedback. 3.3.3.4 Le package statistique et rapports : Gestion des rapports. Evaluation des KPYs.

Figure 28: le package administration

Figure 29: le package gestion des alertes

Figure 30: le package gestion des ticket

Figure 31: le package statistique et rapports

3.4 Identifier les diagrammes importants

Aprs avoir fait une premire description des cas dutilisation visant recenser les diffrents acteurs et objets qui caractrisent notre systme, et aprs avoir dfini le model statique, une analyse plus approfondie des scnarios permet de trouver les relations temporaires et vnementielles entre objets. Cette analyse base sur la modlisation des diagrammes suivants :

3.4.1 Diagrammes des calasses (Voir annexe E): 3.4.1.1 Diagramme de classes par packages : i. Diagramme de classe associe la gestion des administrations

Figure 32: diagramme de classe associe a la gestion dadministrateur.

ii. Diagramme de classe associe la gestion des utilisateurs

Figure 33: diagramme de la gestion des a la gestion des utilisateurs. iii. Diagramme de classe associe classe associetravaux programms

Figure 34: diagramme de classe associe a la gestion des travaux programmes.

iv. Diagramme de classe associe la gestion des alertes

Figure 35: diagramme de classe associe a la gestion des alertes.

v. Diagramme de classe associe la gestion des tickets

Figure 36: diagramme de classe associe a la gestion des tickets.

vi. Diagramme de classe associe la gestion des rapports

Figure 37: diagramme de classe associe a la gestion des rapports. 3.4.1.2 Classes Description dtaille des classes : Attributs description

Le code de site est cod comme suite Code_site Libell_site SITES Adresse_site Position_GPS Autonomie Nbr_secteur Categorie Code_site_BSC (caractre1/code_wilay/caractre2/nombre entier) le caractre2 selon le type de site par exemple on a X pour les sites BTS, BSC pour les sites BSC etc. Nbr_secteur : pour le nombre de secteur dans les sites BTS tel que le nombre = 0 dans les autres sites. Code_site_BSC : indique la BSC qui lie avec la BTS, ce code existe sauf dans les sites BTS. Code_NE Network lment Libell_NE Network lment est un site BTS, site BSC, micro BTS, site trans, MSC et autres.

code_TA libell_TA

Les alarmes importantes sont celles des nergies, les problmes HS et les problmes de

TYPE ALARME

sverit_TA categorie_TA priorit_TA

liaison entres les sites. Chaque NE un type dalarme (on a par exemples nergie BTS, nergie BSC, ), la priorit des alarmes est dtermine selon limportance des NE.

WILAYA

Code_wil Libell_wil

Rgion

Code_Rgion Libell_Rgion

Les Rgions sont est, ouest, sud, nord, centre.

LOCALISER

Code_wil Libell_wil

La localisation pour dfinir la rgion et la wilaya de chaque site. Les Owner sont les groupes de maintenance dOTA et chaque Owner un code et nom spcifi.

OWNER

Code_ OWNER Libell_ OWNER

Libell_ O&M O&M siege_O&M tel_O&M fax_O&M libell_SP SOCIETE PARTENAIRE siege_SP tel_SP fax_SP email_SP Num_contact Nom_ contact Prnom_ contact Date_niss_ contact Lieu_niss_ contact CONTACT Email_O&M Sexe Photo Num_tel Email Grade

O&M sont des groupes de maintenance dOTA et chaque O&M un nom spcifique, un tlphone fax.

Les SP sont des groupes de maintenance prive, la responsabilit des SP sera limite sauf sur les sites BTS et chaque SP un nom, tlphone, fax et Email.

Contact est un personne physique, le contact soit O&M ou autre, chaque contact a un nom, prnom, date et lieu de naissance, sexe, photo, numro tlphone, email, grade. Le numro du contact est un numro squentiel.

utilisateur

code_util Pseudo_util login_util

Chaque utilisateur du systme a un code spcifique et un mot de passe, nom dutilisateur.

PRIVILEGE

code_priv liblle_priv type_priv

Les droits daccs des utilisateurs sont bien dfinis.

Travaux programms

id_SW descreption_SW date_debut date_fin impact_SW code_alarme

Chaque tche programme est codifie, date dbut et date fin, plus limpact de ce SW sur le rseau. LOwner planifie les SW.

Toutes les alarmes remontes sur les sites ont des codes, des dates de dclenchement et des dates dclairement. Ces alarmes portent aussi les noms des sites. La notification est lanalyse des alarmes et de toutes les notifications un code, type, contenu, date (date dalerte). Le type de notifications soit mail au SMS ou les deux.

ALARMES

description_alarme date_declenche date_claire

NOTIFICATION

id_not type_not contenu_not date_not

TROUBLE TICKET

num_TT tat_TT action_user assignement_TT -commantaire date_alerting

Chaque ticket associe une alarme porte un numro, tat (open, close), date dassignation du ticket, commentaire, date dalerte.

FEEDBACK

num_FB pb_type date_debut_alarme date_fin_alarme intervention commantaire tat_gel

Chaque feedback un numro, numro de ticket, type de problme sur le site, date de dbut et de fin, lintervention de lOwner, son commentaire, sa justification sur le retard pris pour rgler les alarmes (tat de gel), date de dbut et de fin de maintenance, et la date de lenvoi des feedbacks.

date_debut date_fin AC date_FB RAPPORT id_rapport chemin_rapport TYPE RAPPORT id_type_rapport libell_type_rapport Chaque rapport un code, un chemin denregistrement. Il existe trois type de rapport trs importants qui sont : le rapport Daily (journalier) les weekly (hebdomadaire) et le rapport dvaluation des KPI. Tableau 5: description des classes. 3.4.1.3 Les rgles de gestion :

Le responsable dun site peut tre une socit partenaire ou un O&M ou les deux. Un Owner peut tre une socit partenaire, ou un O&M ou autre. Un contact peut tre une maintenance O&M ou un autre. Un utilisateur peut tre une socit partenaire ou un contact. Une notification lie une alarme peut tre alerter vers les socits partenaires, les O&M ou vers les deux. On escalade les alarmes de grand impact et qui dure dans le rseau. On peut ouvrir un ticket sur une seule alarme ou plus. Les feedback tablis par les O&M ou par les socits partenaires. Les tickets sont lis avec les alarmes du rseau ou avec un autre problme.

3.4.2 Diagrammes des squences (Voir annexe E): 3.4.2.1 Diagramme de squence associ lAuthentification :

Figure 38: diagramme de squence de lauthentification systme.

3.4.2.2 Diagramme de squence associ la gestion des sites :

Figure 39: diagramme de squence gestion des sites.

3.4.2.3 Diagramme de squence associ traitement des alarmes :

Figure 40: diagramme de squence traitements des alarmes. 3.4.2.4 Diagramme de squence associ lalerte par SMS :

Figure 41: diagramme de squence de lalerte par SMS.

3.4.2.5 Diagramme de squence associ la gestion des TTs :

Figure 42: diagramme de squence gestion des TTS.

3.4.2.6 Diagramme de squence associ aux travaux programms :

Figure 43: diagramme de squence des travaux programmes.

3.4.2.7 Diagramme de squence associ la gestion des rapport :

Figure 44: diagramme de squence gestion des rapports

3.4.2.8 Diagramme de squence associ feedback :

Figure 45: diagramme de squence des feedback.

3.4.3 Diagrammes dactivits (Voir annexe E): Nous distinguons dans ces diagrammes les activits du systme (automatiques) et celles dclenches par des humains (non automatiques). 3.4.3.1 Diagramme dactivit associe la gestion des sites : Dans la figure 5.27 on distingue les activits faites par le systme ou autres, et dclenches par ladministrateur (facteur humain), tel que ce diagramme reprsentent les diffrents processus excuts pour sauvegarder les informations dun site donn dans notre systme.

Figure 46: diagramme dactivits gestion des sites.

3.4.3.2 Diagramme dactivit associe la gestion des alertes : Le schma 5.28 reprsente les diffrentes activits raliser pour alerter les groupes de maintenance et ouvrir un ticket la fin dune alerte.

Figure 47: diagramme dactivits gestion des alertes.

3.4.3.3 Diagramme dactivit associe la publication dun rapport :

Figure 48: diagramme dactivits publier rapports.

4. Prsentation de larchitecture du nouveau systme :

4.1 Schma dtaill du nouveau systme :
Alarme s Rseau GSM dOTA Dclenchement dun problme Serveur OMC Acquisition des alarmes a laide du serveur FTP PC2

PC1

PCn

Notre systme
Module de reporting +KPI

3 4
Module de gestion des EVR Module de notification Module de filtrage des alarmes

Module de traitement des alarmes

Publier rapports

Alerte 1234alarmes accept alarmes ignor afficher le filtre crier lEVR

Par SMS Les groupes de maintenances (Owner)

Par MAIL

Figure 49: schma dtaille de la solution propose.

4.2 Les avantages du nouveau systme :

Centralisation des ressources : Le serveur dapplication gre les ressources communes tous les utilisateurs. Il peut traiter plusieurs requtes clients en mme temps et contrler laccs aux ressources. Ce qui simplifie lexploitation du systme et assure sa cohrence globale. Scurit des donnes : Toutes les donnes sont stockes au niveau du serveur de base de donnes (se trouvant en dehors du serveur dapplication). Tout accs ces donnes par les clients est trac et scuris. Intgrit des donnes : Les donnes sont gres par le serveur de base de donnes dune faon centralise, ce qui vite les problmes de redondance et de contradiction ; Simplifier les tches de travail des superviseurs : tel que les tches dalerting (par SMS au par MAIL) et de repporting qui sont tous automatiss.

5. Conclusion :
Dans ce chapitre, nous avons commenc par dfinir loutil de conception et la mthode choisie, expliqu la dmarche, et les diffrentes tapes suivre dans notre conception qui a t faite sur le modle UML. Nous avons prsents ensuite larchitecture du principe de la solution propose. Dans le chapitre suivant, nous aborderons le dploiement du systme qui consiste spcifier la disposition physique de notre systme dcisionnel savoir les logiciels utiliss et la scurit de notre systme.

hapitre 6 : Ralisation et scurit du nouveau systme

Chapitre 6: Ralisation et scurit du nouveau systme

1. Introduction :
Etant la dernire tape dans le cycle de dveloppement des systmes dinformations, la ralisation couronne les parties prcdentes, et donne un aspect tangible aux suggestions prsentes lors de ltude de lexistant, et une forme concrte la conception ; cela en procdant comme suit : Prsentation les diffrents serveurs et outils (technologiques et logiciels) utiliss pour le dveloppement de lapplication. Prsentation de lapplication via des prises dcrans, afin de figurer le travail fait et dillustrer et les principales fonctionnalits ralises ; Description des diffrents facteurs de risques pouvant nuire le bon fonctionnement du systme. Ainsi, la politique de scurit adopte face ces risques.

2. Prsentation des outils utiliss :

2.1 Environnement de dveloppement : Visual Studio 2010
Visual Studio .NET ne fait pas partie du Framework .NET. Il s'agit tout simplement d'un environnement de dveloppement intgr propos par Microsoft pour dvelopper des applications conformes aux spcifications de .NET (Web et Windows).

2.2 Systme de gestion de base de donnes : SQL Server 2008

Le Systme de Gestion de Bases de Donnes que nous avons choisi est SQL Server. SQL Server est un SGBD relationnel dvelopp par Microsoft, il est considr parmi les leaders mondiaux des SGBD. Pour notre travail nous avons adopt la version SQL Server 2008.

2.3 Langages de dveloppement C#

Le C# est un langage de programmation orient objet typiquement fort, cr par la socit Microsoft, et notamment un de ses crateurs, Anders Hejlsberg, le crateur du langage Delphi. Il a t cr afin que la plate-forme Microsoft .NET soit dote d'un langage permettant d'utiliser toutes ses capacits. Il est trs proche du Java dont il reprend la syntaxe gnrale ainsi que les concepts (la syntaxe reste relativement semblable celles de langages C++ et C).

3. Prsentation du prototype ralis (prises dcran) :

Laffichage de linterface dadministrateur pour la modification des donnes.

Gnration des rapports

Nom dutilisateur

Mot de passe dutilisateur

Gestion des troubles tickets

Laffichage du filtre et lalerte des groupes de maintenances

Figure 6.01 : Interface de dmarrage

4. Scurit du systme :
La tlcommunication est un domaine qui utilise des moyens technologiques avancs assurant une disponibilit quasi-permanente, ce qui intensifie la vulnrabilit de nimporte quel systme dinformation, et l, ce dernier se voie face diffrents risques qui peuvent lui porter une diversit de menaces qui peuvent nuire son fonctionnement, et surtout dans le cas o ce systme traite des informations trs sensible. A linstar de tout systme baignant dans ces conditions, notre systme est dans lobligation de prendre des prcautions et des mesures face toutes ses menaces. Pour assurer ces tches indispensables en matire de scurit, on a besoin de dnombrer ces risques et les classifier pour une traabilit des plans de changements, les solutions prconiser et les dispositifs mis en uvre.

4.1 Facteurs de risque et mesures de scurit :

On peut classer les diffrents facteurs de risque qui reprsente un danger pour notre systme en trois principales catgories. 4.1.1 Les accidents : Ce sont les risques qui ne peuvent tre totalement prdis, rsultant suivants des facteurs denvironnement du systme, et qui causent des dommages physiques et/ou logiques : Les catastrophes naturelles (sisme, incendies, etc.) Dfaillance des installations (cblage, matriel, etc.) Pannes dlectricit. Les mesures prendre se rsument quelques dispositifs de prvision pour protger le systme de ces accidents et de rduire, le plus possible, les dommages potentiels : Installation des machine serveur dans des btisses construites selon les normes mondiales anti-sisme. Disposition des groupes lectromoteurs. Dfinition dune politique de sauvegarde durgence (environnement logiciel interne du systme et des bases de donnes) qui dclenche automatiquement en cas de catastrophe. Dfinition de conduite tenir pour le personnel pour viter les accidents, ainsi que les tapes dintervention pour la protection des installations en cas de catastrophe.

4.1.2 Les erreurs : Les menaces et incidents dus aux erreurs produisant principalement dans les phases dorganisation, de conception, de ralisation et dexploitation o elles portent sur les fonctions de saisie, de transfert, de traitement et de restitution des donnes et des informations. Gnralement, elles causent des dommages dintgrit de donne et leur exactitude. Parmi les risques derreurs affectent notre systme, on peut citer : Les erreurs de saisies commises par les utilisateurs. Les erreurs de transfert. Quand il y a transmission de l'information, les erreurs lies la nature des rseaux utiliss et du type de donnes transmises. Les erreurs de manipulation et dexploitation des utilisateurs, comme laccomplissement des tches (Gestion des transitions de ressources). Celles-ci est causes par le nonrespect des procdures en vigueur ou le manque de matrise du systme. Pour rduire ces risques derreurs, on envisage les recommandations suivantes : Passer par une priode de test du systme, dite priode de mise en preuve, afin de dvoiler lensemble des bugs ou anomalies. Assurer lamlioration et lvolution continue des interfaces utilisateurs (En : Users Interfaces) du systme pour assurer une meilleure exploitation avec moins de risques derreurs de saisie ou de manipulation. Suivre les connexions et la marche des transmissions ncessaires pour le fonctionnement du systme. Permettre aux utilisateurs daccompagner les manuels daide et de support disponibles durant leur exploitation du systme. Assurer la formation continue des superviseurs dOTA, aprs la mise en uvre du systme et chaque amlioration. 4.1.3 Les malveillances : Ce sont les menaces les plus dangereuses et les plus destructrices (relativement), parce quelles manent des intentions hostiles de malveillants qui veulent volontairement nuire au fonctionnement du systme, on cite les malveillances suivantes : Fautes dolosives lors de lutilisation du systme afin de compromettre lintgrit et lexactitude des informations traites (changer le mot de passe dun utilisateur). L'altration des biens immatriels : qui correspond soit la destruction physique directe de tout ou partie de l'ensemble des fichiers et des logiciels, ou leur destruction indirecte

par l'intermdiaire d'instructions informatiques introduites dans les logiciels telles que virus, bombes logiques, ou encore par des usurpations d'identit donnant accs aux fonctions d'exploitation du systme informatique. Afin de limiter les risques de problmes informatiques, dues des malveillances, leur minimum, on propose de : Installer un Antivirus et un Firewall (Pare-Feu) sur les ordinateurs et le cas chant sur le rseau informatique afin d'viter que des virus ou hackers attaquent notre systme. Restreindre laccs aux diffrentes fonctionnalits du systme, et tracer toutes les oprations accomplies lors de son utilisation (profils daccs et systme de privilges, systme de traabilit, historiques, etc.). Mettre en place une politique de sauvegarde de base de donnes.

4.2 Qualits scuritaires du nouveau systme :

Le systme comprend beaucoup daspects face ces diffrentes menaces qui sont dcrit comme suit: 4.2.1 Confidentialit : Etant un aspect capital du systme, la confidentialit rassemble toutes les procdures qui limitent le nombre des personnes ayant accs au systme : Restriction des accs : Les accs aux diffrents modules de systme dpendent des utilisateurs, raliss laide dun systme de gestion de profils. Ces derniers sont assigns un utilisateur pour en dterminer les oprations permises et les sections accessibles dans lapplication. Seul ladministrateur peut crer, modifier, suspendre un compte utilisateur. Scurit des donnes : Nous citons quelques diapositifs pour la protection des donnes : Politique de sauvegarde assurant la sret des donnes en effectuant une copie de la base de donnes de faon quotidienne. crypt Les informations confidentielles Au niveau de la base de donns. Scurit de lapplication : Afin de protger le systme on se tient aux indications suivantes : Contrle des donnes et des informations introduites au systme lors de son exploitation pour contrer toute tentative de sabotage ou faute dolosive ou non intensionnelle (formes rgulires, injections SQL, etc.), cela grce aux diffrentes classes de contrle. Munir les serveurs dAntivirus professionnel (mis jour automatiquement via internet) tel celui propos (Kaspersky Internet Security).

4.2.2 Intgrit : Un aspect qui ne manque pas dimportance de la confidentialit, assurant lexactitude des informations et donc par la suite des rsultats justes, optimaux et lucratifs. Redondance justifie et rflchie : Les redondances et les rptitions des donnes sont faites en basant sur les besoins qui se sont prsents afin doptimiser lexploitation de ces donnes et du systme tout entier la fois. Contrles de champs : Les champs sont contrls pour diminuer les fautes commises lors de la saisie par les utilisateurs.

5. Conclusion :
Afin de bien conclure cette dernire partie du processus de dveloppement, nous devons mise en vidence, que la ralisation ntait jamais ltape finale du processus de dveloppement dun systme dinformations (tel le sujet de cette tude) ; et comme constat au cours de ltude des risques et des mesures prendre et ce qui sen suit du ct du systme, on confirme quil faut continuer le suivre et le superviser, et cela par la mise en exploitation ou la mise en essai du systme par les utilisateurs, dans le but de dtecter les ventuels bugs et anomalies et les rectifier pour assurer la stabilit et la fiabilit du systme.

onclusion gnrale

Conclusion gnrale et perspectives:

Ce projet qui sinscrit dans le cadre de la gestion de supervision des rseaux GSM, comme objectif rpondre aux fonctionnalits suivantes : Analyse des alarmes. Alerte par SMS ou MAIL. Suivi des alarmes durant la phase de maintenance. Gnration des rapports. Afin datteindre ce but, les tapes tait les suivantes, la collecte dinformations, puis ltude du systme existant, ainsi la conception du systme et, enfin le dploiement et la mise en uvre de cette solution, cette dernier donne comme plus : Lacclration des processus de notification des alarmes au sous-traitant. La gnration automatique des rapports. Toujours dans le cadre de ce projet nous avons abord le domaine de tlcommunication ainsi que la technologie du SMS et du MAIL. Pour la mise en place dune solution complte permettant de fournir toutes les fonctionnalits ne sont pas atteintes, nous prvoyons ajouter dautres fonctionnalits notre systme : La gnralisation de la solution pour la diversit du matriels dOTA (siemens, Hewaie,etc) Loptimisation de la dure dalerting par SMS ou mail. Loptimisation de la dure daffichage des filtres des alarmes.

nnexes

Lannexe A : le modle OSI. 1. Le rseau

Un rseau est un systme complexe d'objets ou de personnes interconnects ( relis. ) Un rseau informatique est linterconnexion de plusieurs entits: Ordinateurs Imprimantes Photocopieurs Terminaux Un rseau est constitu de deux catgories dentits: Les lments physiques : tels que les interfaces dinterconnexions, les cbles de liaisons, les quipements de connexion, ordinateurs,etc Les lments logiques (logiciels): tels que les navigateurs, des protocoles, les services (web, mail,ftp ,,)

2. Modles de conception dun rseau

Deux grands modles sont utiliss : Modle OSI de lISO Modle TCP/IP 2.1 Le modle OSI [RI05]: Le modle de rfrence OSI (Open System Interconnexion - interconnexion de systmes ouverts) est publi en 1984 par lISO. OSI est un modle abstrait, il a t cr comme une architecture descriptive en couches pour une conception dun rseau. Le modle de rfrence OSI constitue un cadre qui aide comprendre comment les informations circulent dans un rseau. Le modle OSI est compos de 7 couches 2.1.1La couche physique [RI05]: C'est la couche spcifique la "tuyauterie" du rseau. Elle permet de transformer un signal binaire en un signal compatible avec le support choisi (cuivre, fibre optique, HF etc.) et rciproquement. C'est ce niveau que se situe l'adresse MAC (Medium Access Control). Cette couche fournit des outils de transmission de bits la couche suprieure, qui les utilisera sans se proccuper de la nature du mdium utilis.

2.1.2La couche liaison [RI05]: Cette couche assure le contrle de la transmission des donnes. Une trame doit tre envoye ou reue en s'affranchissant d'ventuels parasites sur la ligne. Le contrle est effectu au niveau du paquet de bits (trame), au moyen d'un "checksum". Elle est elle-mme divise en deux sous-couches. La sous-couche MAC (Medium Access Control). C'est ce niveau que l'on trouve le protocole de diffusion de linformation: Ethernet, Token Ring, ATM, etc. Pour un rseau domestique, c'est Ethernet qui est utilis. Par ailleurs, cette couche fournit des services de base pour la transmission de donnes, via LLC (Logical Link Control) ou HDLC (High level Data Link Control). Ces services peuvent tre classs en trois groupes : Les services sans connexion et sans acquittement. Les services sans connexion, mais avec acquittement. Les services orients connexion. Cette couche fournit des outils de transmission de paquets de bits (trames) la couche suprieure. Les transmissions sont "garanties" par des mcanismes de contrle de validit. 2.1.3La couche Rseau [RI05]: Cette couche assure la transmission des donnes sur les rseaux. C'est ici que la notion de routage intervient, permettant l'interconnexion de rseaux diffrents. C'est dans le cas de TCP/IP20 la couche Internet Protocol. En plus du routage, cette couche assure la gestion des congestions. Disons simplement que lorsque les donnes arrivent sur un routeur, il ne faudrait pas que le flot entrant soit plus gros que le flot sortant maximum possible, sinon il y aurait congestion. Une solution consiste contourner les points de congestion en empruntant d'autres routes (phnomne bien connu des vacanciers sur les routes). Le problme de la

congestion est un problme pineux, auquel il nous arrive assez souvent hlas d'tre confront. Cette couche est la plus haute dans la partie purement "rseau". Cette couche fournit des outils de transmission de paquets de bits (trames) la couche suprieure. Les transmissions sont routes et la congestion est contrle.

2.1.4La couche Transport [RI05]: Cette couche apparat comme un superviseur de la couche Rseau. Qu'est-ce dire? Il n'est par exemple pas du ressort de la couche rseau de prendre des initiatives si une connexion est interrompue. C'est la couche Transport qui va dcider de rinitialiser la connexion et de reprendre le transfert des donnes. Son rle principal est donc de fournir la couche suprieure des outils de transport de donnes efficaces et fiables. 2.1.5La couche Session [RI05]: La notion de session est assez proche de celle de connexion. Il existe cependant quelques dtails qui peuvent justifier la prsence de ces deux concepts. Une seule session peut ouvrir et fermer plusieurs connexions, de mme que plusieurs sessions peuvent se succder sur la mme connexion. Comme cette explication n'est pas forcment claire pour tout le monde, essayons de prendre quelques exemples : Vous avez un message transmettre par tlphone un de vos amis, votre pouse doit faire de mme avec celle de ce mme ami. Vous appelez votre ami (ouverture d'une connexion), vous discutez avec lui un certain temps (ouverture d'une session), puis vous lui dites que votre pouse voudrait parler la sienne (fermeture de la session). Les pouses discutent un autre certain temps (ouverture d'une seconde session), puis n'ont plus rien se dire (fermeture de la seconde session) et raccrochent (fin de la connexion). Dans cet exemple, deux sessions ont eu lieu sur la mme connexion. Vous avez un travail raliser avec un collgue, par tlphone. Vous l'appelez (ouverture de la connexion et ouverture de la session). Il vous demande des informations qui ncessitent de votre part une recherche un peu longue, vous raccrochez aprs lui avoir dit que vous le rappellerez ultrieurement (fermeture de la connexion, mais pas de la session). Votre recherche effectue, vous rappelez votre collgue (ouverture d'une seconde connexion pour la mme session), vous lui transmettez les informations demandes, vous n'avez plus rien vous dire (fermeture de la session), vous raccrochez (fermeture de la connexion). Dans cet exemple une session s'tend sur deux connexions. Cette couche fournit donc la couche suprieure des outils plus souples que ceux de la couche transport pour la communication d'informations, en introduisant la notion de session.

2.1.6La couche prsentation [RI05] : Cette couche est un peu un "fourre tout" de la conversion entre reprsentation interne et externe des donnes. L encore, cette explication n'est pas d'une grande clart... Prenons donc quelques exemples. Le format de codage interne des donnes Les "mots" sont une suite d'octets. Un mot de 32 bits est donc une collection de 4 octets. Chez Intel, les octets sont numrots de droite gauche, alors que chez Motorola, ils le sont de gauche droite. Il s'en suit que si une machine base Intel envoie des mots une machine base Motorola, il vaut mieux tenir compte de ce dtail pour ne pas s'y perdre... La compression des donnes Certains transferts de donnes se font par le biais d'algorithmes de compression. C'est intressant pour certains types de documents comme le son, l'image ou la vido. Dans le modle OSI, ces algorithmes sont fournis par la couche prsentation. Le cryptage des donnes Mme chose pour la cryptographie. Ce ne sont que des exemples, le modle dfinissant bien d'autres fonctions. 2.1.7La couche Application [RI05] : A priori, cette couche pourrait tre la plus simple comprendre, ce n'est pas obligatoirement le cas. En effet, dans le modle OSI, cette couche propose galement des services: Principalement des services de transfert de fichiers, (FTP), de messagerie (SMTP) de documentation hypertexte (HTTP) etc. Dans le modle, les applications ayant faire du transfert de fichiers utilisent le service FTP fourni par la couche 7.

7 6 5 4 3 2 1

Application Prsentation Session Transport Rseau Liaison de donnes Physique

Figure 1: Larchitecture en 7 couches de modle OSI

LAnnexe B : le rseau de signalisation smaphore n7 (SS7) 1. Introduction

Paralllement la numrisation du rseau tlphonique commut, la ncessit damliorer la rapidit des changes de signalisation a t ressentie. De nouveaux services comme le transfert dappel ont t ouverts. Ils peuvent ncessiter un change de signalisation sans tablissement rel dun circuit de communication. Il a donc fallu sparer la signalisation de la transmission et faire transiter cette signalisation sur des liaisons spcifiques. Cest la signalisation par canal smaphore (CCS, Common Channel Signaling). La signalisation par canal smaphore est une mthode dans laquelle le canal smaphore (SL, Signaling Link) achemine sous la forme de trames smaphores, linformation de signalisation se rapportant des circuits ou des messages de gestion et de supervision. Lensemble des canaux smaphores forme un rseau spcialis dans le transfert de la signalisation, appel SS7 (Signaling System 7). Ce rseau smaphore numro 7 fonctionne suivant le principe de la commutation de paquets. Il possde des routeurs de paquets appels points de transfert smaphore (STP, Signaling Transfer Point) et des quipements terminaux qui sont des centraux tlphoniques, des serveurs et des bases de donnes. Les quipements terminaux sont appels des points smaphores (SP, Signaling Point). Grce au rseau smaphore, deux centraux peuvent schanger tout moment des mess ages de signalisation indpendamment des circuits tablis entre eux. Par ailleurs, les changes entre les lments SSP (Service Switching Point) et SCP (Service Control Point) du rseau intelligent transitent eux aussi travers le rseau smaphore. Le Rseau Smaphore n7 (SS7) a donc pour but d'acheminer des informations de contrle entre les lments d'un rseau de tlcommunication, tels que les centraux tlphoniques, les bases de donnes et les serveurs. Le rseau smaphore n7 est la cl pour l'introduction de services valeur ajoute.

2. Structure dun rseau smaphore

2.1 L e mode smaph ore Il existe trois modes smaphores pouvant tre utiliss. Ces trois modes dpendent de la relation entre le canal et l'entit qu'il sert [RSN7].

2.2

Mode associ

Le mode le plus simple est appel mode associ. Dans ce mode, le canal smaphore est parallle au circuit de parole pour lequel il permet l'change de signalisation (Figure 1). Il est forcment tabli entre deux points smaphores (SP, Signaling Point). Ce mode n'est bien sur pas idal car il requiert un canal smaphore entre un SP donn et tous les autres SPs. Les messages de signalisation suivent alors la mme route que la voix mais sur des supports diffrents [RSN7].

Figure 2: le mode associe 2.1.1 Le mode non associe Le mode non associ utilise un chemin diffrent de celui de la voix. Un grand nombre de nuds intermdiaires, savoir les points de transfert smaphores (STP, Signaling Transfer Point), est impliqu dans l'acheminement des messages de signalisation. Les STPs sont utiliss afin de router les donnes de signalisation entre SPs. Par ailleurs, les messages destination dun point smaphore peuvent emprunter des routes diffrentes ; le fonctionnement du mode non associ est similaire celui du protocole IP [RSN7]. 2.1.2 Le mode quasi-associ Le mode quasi-associ ressemble au mode non associ mais un nombre minimum (au maximum 2) de STP est travers pour atteindre la destination finale. C'est le mode le plus utilis afin de minimiser le temps ncessaire l'acheminement du message. Par ailleurs, les messages achemins vers une destination donne empruntent tous la mme route. Un exemple de mode quasi-associ est prsent la figure 2. Les messages de signalisation associs ltablissement des circuits de parole entre les commutateurs A et B suivent le chemin A-C-B. Le STP C relaie les messages mis par le SP A au SP B [RSN7].

Figure 3: le mode quasi-associ 2.3 Poi n t de transf ert smap hore

Tous les messages ou paquets contenant des donnes de signalisation sont mis d'un SP un autre SP et transitent travers des points de transfert smaphores (STP, Signaling Transfer Point) qui peuvent tre considrs comme les routeurs du rseau smaphor e. Les messages ne sont gnralement pas gnrs par le STP lui-mme. Le point STP achemine les messages reus des points SPs origine aux points SPs destination. Il existe des STPs qui jouent le rle la fois de SP et de STP (on parle alors de STP intgr ) ; il existe par ailleurs des STPs qui ne jouent que ce rle de STP (appels STPs autonomes). Peu de constructeurs mettent en uvre des STPs autonomes [RSN7]. 2.4 Canau x smaph ores [RSN7]

Un canal smaphore est un support bidirectionnel qui permet le transport fiable de messages smaphores entre deux points smaphores directement relis. Les extrmits des canaux smaphores implantent les fonctions du niveau 2. Un canal smaphore est un support bidirectionnel qui permet le transport fiable de trames smaphores entre entits smaphores adjacentes. Les canaux smaphores sont labelliss partir de leur fonction dans le rseau smaphore. Il n'existe aucune diffrence entre les diffrents types de canaux. Il existe six diffrents types de canaux smaphores dans un rseau smaphore (Figure 3): Des canaux de types A (Access Link) reliant des SPs des STPs, des canaux de type B (Bridge Link) reliant des STPs de diffrentes rgions entre eux, des canaux de type C (Cross Link) reliant une paire de STPs de mme rgion, des canaux de type D (Diagonal Link) reliant des STPs d'un niveau donn (e.g., local,rgional) des STPs de niveau suprieur (e.g., rgional, national), des canaux de type E (Extended Link) reliant un SP d'une rgion donne un

STP d'uneautre rgion, des canaux de type F (Full-associated Link) reliant des SPs directement entre eux, i.e., en mode associ.

Figure 4: les C anaux s m aphores 2.5 Fai sceau smaphore

Les canaux smaphores son placs dans des groupes, appels faisceaux smaphores (linkset). Tous les canaux dans le mme faisceau doivent avoir le mme nud adjacent (Figure 4). Deux SPs ou deux STPs peuvent tre relis entre eux travers un faisceau smaphore contenant jusqu 8 canaux smaphores. Un SP et un STP ou un STP et un SP peuvent tre lis entre eux travers un faisceau smaphore dont le nombre maximum de canaux smaphores est 16 [RSN7].

Figure 5: les faisceaux s m aphores

3. Gestion du rseau smaphore [RSN7]

La gestion du rseau smaphore fournit deux principales fonctions : reconfiguration en situation de dfaillance, et gestion du trafic en situation de congestion. Des dfaillances peuvent se prsenter sur tout lment constituant un rseau SS7 : les canaux smaphores, les SPs et les STPs. Une route smaphore est compose de ces lments et la dfaillance dun des composants rend la route indisponible ce qui provoque le dtournement du trafic smaphore vers dautres routes. Une congestion peut apparatre sur une partie du rseau smaphore. Il sagit alors de rduire temporairement le trafic en llment encombr. Sur la base de ces considrations, la gestion du rseau smaphore est dcompose en trois fonctions: La fonction de gestion des canaux smaphores (Signaling link management) : cette fonction fournit les procdures ncessaires la gestion des canaux smaphores rattachs un point smaphore donn : activation, rtablissement, dsactivation. Ces canaux sont contrls individuellement. La fonction de gestion du trafic smaphore (Signaling trafic management) : Lorsquun point smaphore devient indisponible la suite dune dfaillance, il est ncessaire de dtourner le trafic achemin par le canal indisponible sur dautres canaux disponibles. De mme, lorsquune route vers une destination donne devient indisponible, il est ncessaire de dtourner le trafic sur dautres routes vers cette destination. Le redploiement du trafic est aussi exig la suite dune dsactivation dun canal ou dune route. En cas dencombrement en un point smaphore, le trafic vers ce point doit tre ralenti temporairement. Le trafic doit tre dtourn lors de la dfaillance dun point smaphore et lors de son rtablissement La fonction de gestion des routes smaphores (Signaling route management) : cette fonction assure la disponibilit et la fiabilit des routes smaphores entre points smaphores.

LAnnexe C : le serveur SMSC

1. Dfinition Un centre de SMS (SMSC : Short Messaging Service Center) est responsable d'effectuer les oprations de SMS d'un rseau sans fil. Quand un message de SMS est envoy d'un tlphone portable, il atteindra un centre de SMS d'abord. Le centre de SMS expdie alors le message de SMS vers la destination. Un message de SMS peut devoir passer par plus d'une entit de rseau avant d'atteindre la destination. Le devoir principal d'un SMSC est de conduire des messages SMS et de rgler le processus. Si le destinataire est indisponible (par exemple, quand le tlphone portable est coup), le SMSC stockera le message SMS. Il expdiera le message de SMS quand le destinataire est disponible. Trs souvent un SMSC est consacr pour traiter le trafic SMS d'un rseau sans fil. Un oprateur de rseau habituellement contrle son propre SMSC et les localise l'intrieur de son systme de rseau sans fil. Cependant, il est possible quun oprateur de rseau emploie un tiers SMSC qui est situ en dehors du systme de rseau sans fil [DEV]. Le SMSC prend en charge la facturation qui doit ventuellement avoir lieu. Il y a au moins un Short Message Service Centre (SMSC) par rseau GSM. En pratique il y en a trs souvent plusieurs. Un SMSC joue galement le rle de passerelle entre rseau IP et rseau GSM. En particulier, un serveur peut y accder par connexion TCP afin d'envoyer des SMS vers la destination [WIKI]. 2. Structure du SMSC :

Le SMSC peut se relier aux systmes suivants [ETSI 98]: Passerelles d'accs, parmi lesquelles celle des diteurs de services (ESME). Systme de facturation. Systmes d'opration, d'administration et de maintenance (OAM). Systme prpay. Dun Systme dOpration. Il peut tre Solaris ou Linux. Dune base de donnes spcifique avec son serveur. Elle peut tre de type MySQL ou SQL Server ou Oracle.

3. Gestion de messages [GSM04-1]:

Figure 6 : Les principes des lments [GSM04-1]. Le service SMS ncessite la mise en place d'un ou plusieurs serveurs spcifiques dans le rseau. Le serveur de messages courts (SMSC) assure le stockage des SM (dans des bases de donnes), la distribution des SM aux terminaux mobiles destinataires (quand ceux-ci se sont manifests dans le rseau GSM auquel ils appartiennent) et le traitement des dates de validit des SM. Ds que le terminal mobile se manifeste, le rseau avertit le SMSC qu'il peut dlivrer le message son destinataire avec succs. Le SMSC est repr par un numro de tlphone appartenant au PLMN. Le dialogue entre le SMSC et le terminal mobile se fait travers le MSC. Pour l'acheminement d'un SM vers un terminal mobile destinataire, une passerelle (gateway) est ncessaire : la SMS-G-MSC. Celles-ci routent les SM vers le MSC visit (VMSC pour Visited MSC) en interrogeant le HLR. Un SM issu d'un terminal mobile est rout vers le SMSC du MSC associ au terminal mobile vers le MSC associ au SMSC (appel ici SMS-IW-MSC pour SMS-InterWorking-MSC car il est responsable de l'interfonctionnement entre PLMN et SMSC). Notant que le SMSC comporte une interface normalise ct rseau GSM (SMS-GMSC ou SMS-IW-MSC) reposant sur le protocole MAP (Mobile Application

Part) qui gre les dialogues entre les quipements du sous-systme rseau (NSS) de GSM l'aide de signalisation smaphore (canal SS7 (Annexe B)); mais galement une interface non normalise ct plate-forme logicielle. Les principaux lments traverss sont reprsents sur la figure 2.03.

LAnnexe D : client lger ou lourd

Client lger : permet par l'intermdiaire d'un explorateur Web d'accder une application. Le site Web se comporte pour l'utilisateur comme l'application finale. Les gros avantages sont [SA 03-04]: possibilit d'accder depuis n'importe quel explorateur (sur tous les systmes d'exploitation) possibilit d'accder depuis n'importe o. il n'y a rien installer sur la machine de l'utilisateur finale. trs peut donne stock sur la machine de l'utilisateur. parfaitement synchrone. maintenance aise. Les dfauts sont [SA 03-04]: gros trafic rseau. l'utilisateur ne peut pas travailler sens tre connect. ncessite une trs haute disponibilit de l'application. Client lourd : permet d'accder directement une application. Les avantages sont [SA 0304]: faible trafic rseau. l'utilisateur n'a pas besoin d'tre connect en permance. disponibilit des serveurs moins crutilale. Les dfauts sont [SA 03-04]: dveloppement spcifique pour chaque systme d'exploitation maintenance complexe. forte disparit des donnes entre le client et le serveur ractivit plus longue. SNMP : Simple Network Management Protocol. Protocole d'administration distante ou locale, utilis sur les rseaux de type Internet, l'origine conu pour les ponts et les routeurs, maintenant utilis pour a peu prs tout [SA 03-04].

VPN : Virtual Private Network. Rseau priv virtuel permettant d'accder de manire scuris au rseau interne de l'entreprise [SA 03-04].

LAnnexe E: UML 1. Introduction

Pour penser et concevoir objet, il faut savoir "prendre de la hauteur", jongler avec des concepts abstraits, indpendants des langages d'implmentation et des contraintes purement techniques. Les langages de programmation ne sont pas un support d'analyse adquat pour "concevoir objet". Ils ne permettent pas de dcrire des solutions en termes de concepts abstraits et constituent un cadre trop rigide pour mener une analyse itrative. Pour conduire une analyse objet cohrente, il ne faut pas directement penser en terme de pointeurs, d'attributs et de tableaux, mais en terme d'association, de proprits et de cardinalits... Utiliser le langage de programmation comme support de conception ne revient bien souvent qu' juxtaposer de manire fonctionnelle un ensemble de mcanismes d'implmentation, pour rsoudre un problme qui ncessite en ralit une modlisation objet.

2. Definition [CUML]:
UML comble une lacune importante des technologies objet. Il permet d'exprimer et d'laborer des modles objet, indpendamment de tout langage de programmation. Il a t pens pour servir de support une analyse base sur les concepts objet. UML est un langage formel, dfini par un mta modle. Le mta modle d'UML dcrit de manire trs prcise tous les lments de modlisation (les concepts vhiculs et manipuls par le langage) et la smantique de ces lments (leur dfinition et le sens de leur utilisation). En d'autres termes : UML normalise les concepts objet. Un mta modle permet de limiter les ambiguts et encourage la construction d'outils. Il permet aussi de classer les diffrents concepts du langage (selon leur niveau d'abstraction ou leur domaine d'application) et expose ainsi clairement sa structure.

3. Les digrammes dUML :

UML permet de reprsenter un systme selon diffrentes vues complmentaires : les diagrammes. Un diagramme UML est une reprsentation graphique, qui s'intresse un aspect prcis du modle ; c'est une perspective du modle. Chaque type de diagramme UML possde une structure (les types des lments de modlisation qui le composent sont prdfinis) et vhicule une smantique prcise (il offre toujours la mme vue d'un systme) [CUML]. 3.1 Diagramme des Classe: Le diagramme des classes identifie la structure des classes d'un systme, y compris les proprits et les mthodes de chaque classe. Les diverses relations, telles que la relation d'hritage par exemple, qui peuvent exister entre les classes y sont galement reprsentes. Le diagramme des classes est le diagramme le plus largement rpandu dans les spcifications dUML [MGA 01]. 3.2 Diagramme des composants : Les diagrammes des composants tombent sous la catgorie des diagrammes d'implmentation un genre de diagramme qui modlise l'implmentation et le dploiement du systme. Le diagramme des composants est principalement employ pour dcrire les dpendances entre les divers composants logiciels tels que la dpendance entre les fichiers excutables et les fichiers source. Cette information est semblable celle contenue dans les fichiers makefile, qui dcrivent des dpendances des codes sources qui doivent tre employs pour compiler correctement une application [MGA 01]. 3.3 Diagramme d'activit : Les diagrammes d'activit sont utiliss pour documenter le droulement des oprations dans un systme, du niveau commercial au niveau oprationnel (de haut en bas). En regardant un diagramme d'activit, vous trouverez des lments des diagrammes d'tat. En fait, le diagramme d'activit est une variante du diagramme d'tat o les "tats" reprsentent des oprations, et les transitions reprsentent les activits qui se produisent quand l'opration est termine. L'usage gnral des diagrammes d'activit permet de faire apparatre les flots de traitements induits par les processus internes par rapport aux vnements externes [MGA 01].

3.4 Diagrammes de cas d'utilisation [CUML] : Les lments de modlisation des cas d'utilisation sont : Acteur La premire tape de modlisation consiste dfinir le primtre du systme, dfinir le contour de lorganisation et le modliser. Toute entit qui est en dehors de cette organisation et qui interagit avec elle est appel acteur selon UML. Formalisme :

Le cas dutilisation Le cas dutilisation (ou use case) correspond un objectif du systme, motiv par un besoin dun ou plusieurs acteurs. L'ensemble des use cases dcrit les objectifs (le but) du systme. Formalisme :

La relation Elle exprime linteraction existant entre un acteur et un cas dutilisation. Formalisme :

Il existe 3 types de relations entre cas dutilisation : - la relation de gnralisation

- la relation dextension - la relation dinclusion 3.5 Le diagramme de collaboration [CUML] : Le diagramme de collaboration permet de mettre en vidence les interactions entre les diffrents objets du systme. Dans le cadre de lanalyse, il sera utilis - pour prciser le contexte dans lequel chaque objet volue - pour mettre en vidence les dpendances entre les diffrents objets impliqus dans lexcution dun processus ou dun cas dutilisation. Un diagramme de collaboration fait apparatre les interactions entre des objets et les messages quils changent. Les interactions Une interaction dfinit la communication entre les objets sous la forme dun ensemble partiellement ordonn de messages. Les messages Les messages sont le seul moyen de communication entre les objets. Ils sont dcrits essentiellement par lobjet metteur et lobjet rcepteur. Leur description peut tre complte par un nom, une squence, des arguments, un rsultat attendu, une synchronisation, une condition dmission. 3.6 Le diagramme de squence [CUML] : Le diagramme de squence est une variante du diagramme de collaboration. Par opposition aux diagrammes de collaboration, les diagrammes de squence possdent intrinsquement une dimension temporelle mais ne reprsente pas explicitement les liens entre les objets. Ils privilgient ainsi la reprsentation temporelle la reprsentation spatiale et sont plus aptes modliser les aspects dynamiques du systme. En revanche, ils ne rendent pas compte du contexte des objets de manire explicite, comme les diagrammes de collaboration. Le diagramme de squence permet de visualiser les messages par une lecture de haut en bas. Laxe vertical reprsente le temps, laxe horizontal les objets qui collaborent. Une ligne verticale en pointill est attache chaque objet et reprsente sa dure de vie.

Bibliographie :
Marc VAN DROOGENBROECK anne 2004.

Webographie et bibliographie

PBFR 04 : Principes de base du fonctionnement du rseau GSM Cdric DEMOULIN,

GSM 99 : le rseau GSM AERNOUTS Ludovic (Cnam de Lille 1999). GSM 04: le rseau GSM Jean-Marie FRESSENON, Vincent NOVAS 4 dcembre 2004. AGSM 02 : architecture rseau GSM Stphane GIRODON juin 2002. EFORT: Global System for Mobile Communications Architecture, Interfaces et Identits Copyright EFORT 2008. UYAGSM: UNIVERSITY OF YAOUNDE I architecture GSM, GPRS ET UMTS Emmanuel TONYE, Landry EWOUSSOUA. GSM04-1: Global System for Mobile Franois-Xavier MAMPAEY Sylvain PREUX 2004. OMCWEDO04: Operation and Maintenance Center with Enhanced Documentation of operations Brose, Gerhard 17 November 2004. CEMRAR3G : Centre dExploitation et de maintenance pour rseau accs radio 3G D.Rinchet, R.Tingaud 2001. ETSI 98 : Digital Cellular Telecommunications System , European elecommunications Standards Institute, Version 7.5.0, 1998. SA 03-04: Supervision Applicative Thomas BRIET anne 2003-2004. MPSSA : Mise en place dun systme de supervision applicative Universit du Havre URF ST Mansoriya HAMIDOU Master 2 MaTIS du 1er mars au 31 aout 2010. RI05: Les rseaux informatiques Christian CALECA, 6 mars 2005 RSN7: le rseau smaphore numro 7 Principe, Architecture et protocoles Simon Zanaty, 2008. CUML : ECOLE NATIONALE DES INGENIEURS DES TRAVAUX AGRICOLES DE BORDEAUX, DEPARTEMENT ENTREPRISE ET SYSTEME, UNITE DE FORMATION INFORMATIQUE ET GENIE DES EQUIPEMENTS cours UML J.STEFFE, Mars 2005 MGA 01 Modlisation Objet avec UML , Pierre-Alain Muller et Nathalie Gaertner, 2001.

Webographie et bibliographie
Webographie :
DEV: http://www.developershome.com/sms/ (Vu en mars 2011) FREEP: http://www.freepatentsonline.com/ (Vu en janvier 2011) LEB: http://www.lebguide.com/home.asp (Vu en janvier 2011) WIKI: http://fr.wikipedia.org/wiki (Vu en mars 2011)