PFE1

Table des Matires
TABLE DES MATIRES
INTRODUCTION GENERALE ........................................................................................................... 1 I. GENERALITES SUR LES RESEAUX MOBILES ..................................................................... 2 I.1. INTRODUCTION ................................................................................................................................. 2 I.2. EVOLUTION DES RESEAUX CELLULAIRES .......................................................................................... 2 I.3. PRESENTATION GENERALE DU RESEAU GSM .................................................................................... 2 I.3.1. Architecture du rseau GSM .................................................................................................... 3 a. La station mobile MS ........................................................................................................ 3 b. Le sous-systme radio BSS ............................................................................................... 3 c. Le sous-systme rseau NSS ............................................................................................ 4 d. Sous Systme dExploitation et de Maintenance OSS ..................................................... 5 I.3.2. Les interfaces ............................................................................................................................ 5 I.4. PRESENTATION DU RESEAU UMTS ................................................................................................... 6 I.4.1. Objectifs .................................................................................................................................... 6 I.4.2. Architecture du rseau UMTS .................................................................................................. 6 a. Le domaine UE ....................................................................................................................... 7 b. Le rseau daccs radio universel UTRAN ....................................................................... 7 c. Le rseau cur (CN) ............................................................................................................... 9 I.4.2. Les interfaces ............................................................................................................................ 9 I.5. CONCLUSION .................................................................................................................................. 10 II. ETUDE DES RESEAUX DE SUPERVISIONS ET DU SYSTEME IMANAGER2000 DE HUAWEI ................................................................................................................................................ 11 II.1. INTRODUCTION.............................................................................................................................. 11 II.2.CONCEPT DE LA SUPERVISION ........................................................................................................ 11 II.3. LE SOUS-SYSTEME DE SUPERVISION DES RESEAUX CELLULAIRES .................................................. 11 II.3.1. Le centre dexploitation et de maintenance OMC................................................................. 11 II.3.2. Le rseau dexploitation et maintenance............................................................................... 11 II.3.3. Les diffrents types de maintenance ...................................................................................... 12 a. La maintenance prventive ................................................................................................... 12 b. La maintenance curative ....................................................................................................... 12 II.3.4. Protocoles dexploitation et de maintenance ........................................................................ 13 a. ICMP (Internet Control Message Protocol) .......................................................................... 13 b. SNMP (Simple Network Management Protocol) ................................................................. 14 c. OMAP (Operation and Maintenance & Administration Part) .............................................. 15 d. TMN (Telecommunication Management Network) ............................................................. 15 II.4. LE SYSTEME M2000 DE HUAWEI................................................................................................... 16 II.4.1. Position du systme M2000 dans le rseau mobile ............................................................... 16 II.4.2. Structure du systme M2000 ................................................................................................. 17 a. Architecture du Systme ....................................................................................................... 17 b. Configuration logicielle ........................................................................................................ 18
Projet de fin dtudes 2011/2012
Table des Matires

II.4.3. Rseau du systme M2000..................................................................................................... 19 II.4.4. Les fonctions principales effectues par le systme M2000 .................................................. 19 a. Gestion commune lensemble des quipements................................................................. 19 b. Gestion centralise des pannes .............................................................................................. 20 c. Gestion de la performance centralise .................................................................................. 20 d. Gestion de la configuration centralise ................................................................................. 20 e. Maintenance distance ......................................................................................................... 21 II.5. CONCLUSION ................................................................................................................................. 21 III. PLANIFICATION DU RESEAU DE SUPERVISION UTILISANT LA SOLUTION HUAWEI ................................................................................................................................................ 22 III.1. INTRODUCTION ............................................................................................................................ 22 III.2. TOPOLOGIE ET ARCHITECTURE DU RESEAU A PLANIFIER .............................................................. 23 III.3. GESTION DE CAPACITE ET PLANIFICATION DE LA BANDE PASSANTE ............................................. 24 III.3.1. Calcul par la mthode des lments quivalents du rseau ................................................ 24 III.3.2. Conversion dlments physiques du rseau vers des lments quivalents ...................... 25 III.3.3. Moyens de calcul de l'tendue du rseau ............................................................................. 25 III.3.4. Bandes passantes ncessaires .............................................................................................. 27 III.4. PLANIFICATION DU RESEAU POUR LE SYSTEME DE SUPERVISION .................................................. 27 III.4.1. Rseau HA servers ......................................................................................................... 28 a. Architecture du systme M2000 HA .................................................................................... 28 b. Avantages du Systme M2000 HA ....................................................................................... 29 III.4.2. Rseau Remote HA servers ............................................................................................ 29 a. Architecture logique du Systme M2000 Remote HA ......................................................... 29 b. Avantages du systme M2000 Remote HA .......................................................................... 30 III.4.3. Rseau SLS servers ........................................................................................................ 31 a. Structure logique du systme M2000 SLS ............................................................................ 31 b. Avantages du systme M2000 SLS ...................................................................................... 32 III.5. LES MODES DE GESTION DU RESEAU............................................................................................. 32 III.5.1. Gestion du rseau IP ............................................................................................................ 32 III.5.2. Gestion du rseau Full E1 ............................................................................................. 34 a. Exemple de mise en rseau Full-E1/T1 ................................................................................ 35 III.5.3. Gestion du rseau Partial E1 ......................................................................................... 36 a. Exemple de mise en rseau Partial E1/T1 ............................................................................. 37 III.6. CONCLUSION ................................................................................................................................ 37 IV. APPLICATIONS ........................................................................................................................ 38
IV.1. APPLICATION 1: PLANIFICATION DU RESEAU DE SUPERVISION DE LA PARTIE ACCES RADIO (GSM, UMTS) POUR LOPERATEUR DE LA TELEPHONIE MOBILE ALGERIEN MOBILIS. ....................... 38 IV.1.1. Introduction .......................................................................................................................... 38 IV.1.2. Objectif ................................................................................................................................. 38 a. Planification de la topologie ................................................................................................. 38 b. Planification de la capacit et ltendue rseau .................................................................... 38 c. Le choix du systme de serveurs utiliser............................................................................ 40 d. Planification de la Bande Passante........................................................................................ 43
Table des Matires

IV.1.3. Prsentation du logiciel M2000 client ................................................................................. 44 a. La Gestion de la topologie .................................................................................................... 44 b. Gestion des alarmes et des sites distants ............................................................................... 46 IV.2. APPLICATION 2: CONCEPTION DUN LOGICIEL DE PLANIFICATION ............................................... 49 IV.2.1. Prsentation du logiciel ....................................................................................................... 49 IV.2.2. Prsentation de linterface graphique GUI du logiciel ....................................................... 50 CONCLUSION GENERALE .............................................................................................................. 52
Table des Figures
TABLE DES FIGURES

FIGURE I-1: ARCHITECTURE DU RESEAU GSM ........................................................................................... 3 FIGURE I-2: ARCHITECTURE GENERALE DU RESEAU UMTS ....................................................................... 7 FIGURE I-3: LEMENTS DU RESEAU DACCES UTRAN ............................................................................... 8 FIGURE I-4: ARCHITECTURE DU RESEAU RELEASE 99 UMTS / GSM ....................................................... 10 FIGURE II-1: INTERCONNEXION DES DIFFERENTS RESEAUX AU M2000 .................................................... 16 FIGURE II-2: POSITION DU SYSTEME M2000 ............................................................................................ 16 FIGURE II-3: STRUCTURE DU SYSTEME M2000 ........................................................................................ 17 FIGURE II-4: STRUCTURE DU SYSTEME M2000 ........................................................................................ 18 FIGURE II-5: SCHEMA DU RESEAU DU SYSTEME M2000 ........................................................................... 19 FIGURE III-1: LE PROCESSUS DE CONCEPTION .......................................................................................... 22 FIGURE III-2: LA TOPOLOGIE DU SYSTEME M2000................................................................................... 23 FIGURE III-3: L'ARCHITECTURE LOGIQUE DU SYSTEME M2000 HA ......................................................... 29 FIGURE III-4: L'ARCHITECTURE LOGIQUE DU SYSTEME M2000 REMOTE HA . .................................... 30 FIGURE III-5: LA STRUCTURE LOGIQUE DU SYSTEME M2000 SLS ........................................................... 31 FIGURE III-6: GESTION DU RESEAU IP ...................................................................................................... 33 FIGURE III-7: MISE EN RESEAU LAN ....................................................................................................... 33 FIGURE III-8: MISE EN RESEAU WAN ...................................................................................................... 34 FIGURE III-9: RESEAU FULL E1 ............................................................................................................... 35 FIGURE III-10: EXEMPLE DE MISE EN RESEAU FULL-E1/T1 ...................................................................... 35 FIGURE III-11: RESEAU PARTIAL E1 ........................................................................................................ 36 FIGURE III-12: EXEMPLE DE MISE EN RESEAU PARTIAL E1/T1 ................................................................. 37 FIGURE IV-1: TOPOLOGIE DU RESEAU DE SUPERVISION MOBILIS SITUE A BATNA ................................. 38 FIGURE IV-2: CONNEXIONS PHYSIQUES ENTRE SERVEURS, BAIES DE DISQUES ET COMMUTATEURS ....... 41 FIGURE IV-3: INTERFACE GRAPHIQUE GUI DU LOGICIEL M2000 CLIENT ................................................. 44 FIGURE IV-4: LA GESTION DE TOPOLOGIE PAR LE LOGICIEL M2000 CLIENT ............................................ 45 FIGURE IV-5: TOPOLOGIE ET LIENS ENTRE LES BTS ET LA BSC1 D'ORAN ............................................... 45 FIGURE IV-6: CREATION DUN OBJET DE TOPOLOGIE ............................................................................... 46 FIGURE IV-7: GESTION DES ALARMES PAR LE LOGICIEL M2000 CLIENT .................................................. 47 FIGURE IV-8: BTS HORS SERVICE ............................................................................................................ 48 FIGURE IV-9:BTS EN SERVICE ................................................................................................................. 48 FIGURE IV-10: DIAGRAMME DE CLASSE DE LA BASE DE DONNEES............................................................ 49 FIGURE IV-11: LES FONCTIONS DE PLANIFICATION .................................................................................. 49 FIGURE IV-12: INTERFACE GRAPHIQUE GUI DU LOGICIEL ELEMENTS RESEAU ................................... 50 FIGURE IV-13: INTERFACE GUI DU LOGICIEL PLANIFICATION RESEAU ............................................... 50 FIGURE IV-14: RESULTAT DE PLANIFICATION DE LA CAPACITE................................................................ 51 FIGURE IV-15: RESULTAT DU CALCUL DE LA BANDE PASSANTE .............................................................. 51
Liste des Tableaux

LISTE DES TABLEAUX
TABLEAU III-1: CAPACITE DE GESTION DES NE DU SYSTEME M2000 ...................................................... 24 TABLEAU III-2: NOMBRE DES NE EQUIVALENTS CORRESPONDANT A CHAQUE NE WCDMA (PERIODE DE 30 ET 60 MINUTES) ....................................................................................................... 25 TABLEAU III-3: NOMBRE DES NE EQUIVALENTS CORRESPONDANT A CHAQUE NE WCDMA (PERIODE DE 15 MINUTES) ................................................................................................................. 26 TABLEAU III-4: NOMBRE DES NE EQUIVALENTS CORRESPONDANT A CHAQUE NE GSM (PERIODE DE 30 ET 60 MINUTES) ....................................................................................................................... 26 TABLEAU III-5: NOMBRE DES NE EQUIVALENTS CORRESPONDANT A CHAQUE NE WCDMA (PERIODE DE 15 MINUTES) ................................................................................................................. 26 TABLEAU III-6: BANDES PASSANTES REQUISE POUR LA RNC ................................................................... 27 TABLEAU III-7: BANDES PASSANTES REQUISE POUR LA BSC .................................................................... 27 TABLEAU III-8: BANDES PASSANTES REQUISE ENTRE LE SERVEUR M2000 ET LES PERIPHERIQUES DEXPLOITATION ............................................................................................................................... 27 TABLEAU IV-1: CALCUL DES ELEMENTS RESEAU EQUIVALENTS .............................................................. 39 TABLEAU IV-2: TABLEAU COMPARATIF DES DIFFERENTS SYSTEMES DE SERVEURS.................................. 40 TABLEAU IV-3: SEGMENTS DU SOUS-RESEAU IP ...................................................................................... 41 TABLEAU IV-4: PLAGES DES SOUS-RESEAUX ........................................................................................... 42 TABLEAU IV-5: ADRESSES IP DES PERIPHERIQUES ................................................................................... 42 TABLEAU IV-6: BANDE PASSANTE POUR LES DIFFERENTES INTERCONNEXIONS ....................................... 43
Introduction Gnrale
Introduction Gnrale
Ces dernires annes, la tlphonie mobile a t sans doute le secteur le plus dynamique, le plus rentable et le plus innovant de toute lindustrie des tlcommunications. Avec lessor rapide quelle connat, elle simpose de plus en plus comme le moyen le plus privilg i de communication et conquiert davantage de parts de march conduisant une croissance importante du nombre dabonns. Les exigences de ces derniers en matire de qualit de service sont de plus en plus importantes. En fait, dans un march des tlcommunications mobiles forte concurrence, la satisfaction du client passe au premier plan dans les objectifs des oprateurs des rseaux mobiles. Par consquence, lide est de concevoir un rseau de supervision fiable totalement indpendant de celui des donnes. En effet, ces rseaux de supervision sont devenus ncessaires et indispensables au bon fonctionnement des rseaux mobiles. Tout problme ou panne peut avoir de lourdes consquences aussi bien financires quorganisationnelles. Ils permettent entre autre davoir une vue globale du fonctionnement et problmes pouvant survenir sur le rseau mais aussi davoir des indicateurs sur la performance de son architecture et de pouvoir ragir le plus rapidement possible pour effectuer les rparations ncessaires, afin dviter un arrt systme de trop longue dure. Plus le systme est important et complexe, plus la supervision devient complique do la ncessit dune bonne planification de ces rseaux. Cest, effectivement, ce niveau que se situe notre projet de fin dtudes qui a pour but l tude, la planification et lintgration dun systme de supervision HUAWEI dans un rseau d'un oprateur de tlphonie mobile. La planification reprsente une tape incontournable du cycle de vie des rseaux de supervision. Le rle de la planification est de dfinir de faon prvisionnelle, sur papier ou l'aide de logiciels, les configurations matrielles et logicielles, si possibles optimales, rpondant aux objectifs techniques et conomiques fixs par les engagements de licences. Cette tape fait appel des donnes de toutes sortes, gographiques, marketing, techniques, ainsi qu' des donnes concernant le rseau mobile GSM et UMTS grer et superviser. Dans ce mmoire, nous prsentons notre travail en quatre chapitres : En premier chapitre, nous introduisons dune manire gnrale les technologies et la structure des rseaux tlphoniques cellulaires GSM et UMTS qui font donc lobjet de la supervision. Dans le deuxime chapitre, nous prsentons la structure et les fonctions du rseau de supervision et en particulier celui de HUAWEI, cest--dire le iManager M2000 . Dans un troisime chapitre, nous prsentons les diffrentes tapes suivre pour la planification dun rseau de supervision fiable en passant par la conception de la bande passante puis les diffrents types de systme de serveurs et enfin les diffrents modes de gestion utilises. Enfin nous avons pris comme application la planification et la mise en service du rseau de supervision de loprateur tlphonique algrien MOBILIS.
Page 1
Chapitre I : Gnralits Sur les Rseaux Mobiles
I. I.1. Introduction
Gnralits Sur les Rseaux Mobiles
Dans ce chapitre nous allons dcrire dune manire gnrale larchitecture et les caractristiques des rseaux cellulaires GSM 1 et UMTS 2 . En effet nous allons surtout mettre laccent sur les diffrents sous -systmes et quipements constituant les rseaux de ces deux technologies vu qui savre ncessaire pour la comprhension globale du projet, aprs avoir prsent lvolution des rseaux cellulaires.
I.2. Evolution des rseaux cellulaires

La tlphonie a t l'origine des premiers rseaux de tlcommunication. Les progrs de l'informatique, la numrisation de l'information et la banalisation de l'Internet ont fait converger les rseaux tlphoniques vers les rseaux informatiques avec une volont et une ncessit d'unification. Un autre concept est prendre en considration : le dveloppement de la mobilit en tlcommunication qui permet le passage de terminaux fixes, c'est dire relis au rseau, des terminaux mobiles transports par l'usager et connectables n'importe quel point gographique. Pour la tlphonie, cette tendance a conduit au dveloppement de rseaux d'accs mobiles de type cellulaire. Les premiers rseaux de ce type taient bass sur le transport d'informations analogiques comme l'tait, au dpart, la tlphonie fixe. Ces premiers rseaux sont qualifis de 1re gnration, le plus connu, en France tait Radiocom2000. Ces rseaux ont laiss assez rapidement la place une nouvelle gnration (2me gnration) mettant en application les technologies numriques. Elles ont notamment donn naissances aux rseaux GSM (en Europe), PDC (au Japon) et PCS (aux Etats-Unis). Une nouvelle famille de normes UMTS conduit aujourd'hui une troisime gnration de rseaux et de terminaux mobiles. En fait, il existe des gnrations intermdiaires appeles 2,5G, 2,75G dont les reprsentants sont le GPRS3 et le EDGE4.
I.3. Prsentation gnrale du rseau GSM

Le GSM est un rseau de radiophonie numrique, dfini par la norme europenne ETSI 5. La bande ddie par lUIT6 au systme GSM est de 890-915 Mhz pour le lien montant et de 935960 pour le lien descendant. Un rseau GSM permet bien videmment deffectuer des appels tlphoniques mais aussi la transmission de donnes jusqu 9,6 kbit/s, laccs un rseau commutation de paquets, le transfert de messages courts et tous les services supplmentaires offerts sur les rseaux modernes (renvoi dappels, signal dappel, groupe ferm dusagers...).
1 2
GSM: Global System for Mobile communications. UMTS: Universal Mobile Telecommunications System. 3 GPRS: General Packet Radio Service. 4 EDGE: Enhanced Data Rates for GSM Evolution. 5 ETSI: European Telecommunications Institute. 6 UIT: Union Internationale des Tlcommunications.
Page 2

I.3.1. Architecture du rseau GSM Le rseau GSM a comme premier rle de permettre des communications entre abonns mobiles (GSM) et abonns du rseau tlphonique commut (RTC - rseau fixe). Il sinterface avec le rseau RTC. Il se distingue par un accs spcifique : la liaison radio. Le rseau GSM est compos de quatre sous-ensembles : La station mobile (MS), le sous-systme radio (BSS), le soussystme dacheminement (NSS), le sous-systme dexploitation et de maintenance (OSS) comme lindique la figure suivante :
Figure I-1: Architecture du rseau GSM
a. La station mobile MS La station mobile MS Mobile Station permet labonn daccder aux services GSM travers le systme cellulaire. Elle est compose dun terminal mobile reconnu par une identit internationale IMEI International Mobile Equipment Identity et dune carte SIM Subscriber Identity Mobile qui contient lidentit de labonn IMSI International Mobile Subscriber Identity et la cl Ki2 Individual Subscriber Authentication Key servant lauthentification et au chiffrement des donnes sur la liaison radio. b. Le sous-systme radio BSS Le BSS Base Station Sub-system est un ensemble regroupant le BSC et les BTS qui lui sont associes. Il assure la gestion du canal radio, cest dire la configuration des canaux, laffectation de ces canaux, la supervision de la communication, le timing des messages, le contrle de la puissance, les sauts de frquence, le codage du canal, le transcodage de la parole, le handover entre BTS, le processus dmissions discontinues.
Page 3

La Station de base BTS La BTS Base Transceiver Station est un ensemble dmetteurs-rcepteurs appels TRX. Elle se charge de la transmission radio : modulation, dmodulation, galisation, codage correcteur derreur. Elle gre plus gnralement toute la couche physique : multiplexage TDMA, saut de frquence lent, chiffrement. Elle ralise aussi lensemble des mesures radio ncessaires pour vrifier quune communication en cours se droule correctement. Ces mesures ne sont pas exploites par la BTS mais directement transmises au BSC. La BTS gre la couche liaison de donnes pour lchange de signalisation entre les mobiles et linfrastructure laide du protocole LAPDm. Enfin, elle gre la liaison de donnes avec le BSC afin dassurer la fiabilit du dialogue. Le contrleur de stations de base BSC Le BSC Base Station Controller administre un ensemble de stations de base. Il est lorgane intelligent du sous-systme radio. Le BSC effectue la gestion du trafic des BTS. Il assure lallocation de canaux, la gestion du saut de frquence, le transfert intercellulaire des communications, la gestion de la signalisation sur voie radio. Il assure aussi des fonctions de liaison avec le centre dexploitation et de maintenance. c. Le sous-systme rseau NSS Le NSS Network Switching Subsystem prend en charge les fonctions de commutation et de routage. Il est compos des lments suivants : Le centre de commutation mobile MSC Le MSC Mobile-services Switching Center gre les procdures de contrle dappel ainsi que celles de gestion de la mobilit des abonns avec le VLR. Il prend en charge ltablissement des communications entre un mobile et un autre terminal tlphonique, la transmission des messages courts et lexcution des handover lorsquil est impli qu. Le registre de localisation nominale HLR Le HLR Home Location Register est la base de donnes centrale contenant toutes les informations administratives relatives aux abonns dun rseau donn utilisant deux cls dentre : - IMSI (International Mobile Subscriber Identity) : Cest un numro unique allou chaque abonn stock dans la carte SIM et utilis par le rseau pour la transmission des donnes de labonn. - MSISDN (Mobile Subscriber Integrated Services Digital Network ) : Cest le numro dappel de labonn li lIMSI dans le HLR; les appels destins labonn sont transcrits en numro dIMSI ce qui permet sa recherche et ltablissement de la communication. Le registre de localisation des visiteurs VLR Le VLR Visitor Location Register est une base de donnes relie un MSC qui stocke temporairement les informations concernant chaque mobile dans la zone de travail du MSC, (identit de labonn, sa dernire zone de localisation, les services complmentaires souscrits p ar celui-ci, les ventuelles restrictions ou interdictions dtablissement de la communication).
Page 4

Le centre dauthentification AuC LAuC Authentication Center est une base de donnes protge qui contient une copie de la cl secrte inscrite sur la carte SIM de chaque abonn. Cette cl est utilise pour vrifier lauthenticit de labonn et pour le cryptage des donnes envoyes. Le registre didentification des quipements EIR LEIR Equipement Identification Register est une base de donnes annexe contenant les identits des terminaux (IMEI). Elle peut tre consulte lors des demandes de services dun abonn pour vrifier si un terminal Mobile a ou na pas le droit daccs au systme. d. Sous Systme dExploitation et de Maintenance OSS LOSS Operation Subsystem est compos dun sous-systme dexploitation et de la maintenance du BSS, appel OMC-R et dun sous systme dexploitation et de maintenance du NSS, appel OMC-NSS : LOMC-R Assure les fonctions dexploitation et de gestion du BSS, savoir la gestion des cellules, laffichage des performances du BSS, la visualisation des alarmes , etc. LOMC-R permet galement le paramtrage et lintgration des nouveaux quipements dans le BSS (dc laration des nouvelles cellules, nouveaux BSC). LOMC-S Permet la centralisation de lexploitation technique du sous -systme rseau. Parmi les principales fonctions de lOMCS, on a la visualisation des tats de diffrents organes (software et hardware) composant le sous-systme rseau. I.3.2. Les interfaces Des interfaces normalises sont utilises entre les entits du rseau pour la transmission du trafic (paroles ou donnes) et pour les informations de signalisation. Toutes les liaisons entre les quipements GSM sont des liaisons numriques sauf celle entre BTS et MS qui est radio numrique. Interface Um : Appele aussi linterface Air ou radio, entre BTS et MS. elle s'appuie sur le protocole LAPDm (Link Access Protocol on the D mobile channel) qui est utilis pour le transport du trafic et des donnes de signalisation. Interface A-bis : Entre BTS et BSC s'appuie sur le protocole LAPD. Il est utilis pour le transport du trafic et des donnes de signalisation. Interface A : Entre BSC et MSC, s'appuie sur le protocole smaphore N7 du CCITT. Il est utilis pour le transport du trafic et des donnes de signalisation. Le sous-systme radio et le soussystme rseau communiquent par l'intermdiaire de l'interface A. Interface B : entre MSC et VLR. Interface C : entre MSC et HLR. Interface E : entre MSC et MSC. Interface F : entre MSC et EIR. Interface G : entre VLR et VLR.
Page 5

Interface D : entre VLR et HLR/AuC s'appuient sur le protocole smaphore N7 du CCITT (UIT-T). Ces interfaces sont utilises en particulier pour le transport des donnes relatives l'application des mobiles. Les Interfaces REM : Entre OMC-R (Radio) et BSS ou entre OMC-S (Switch) et NSS, utilisent un rseau de transmission de donne de type X25.
I.4. Prsentation du rseau UMTS

Lexpression UMTS (Universal Mobile Telecommunications System) dsigne la norme cellulaire numrique de troisime gnration retenue en Europe. Les mobiles de la troisime gnration sont des terminaux, aux dbits de loin suprieurs ceux de nos portables actuels, avoisinant au maximum de leurs possibilits peu prs 2Mbps. Ils ne se limitent pas au transfert de la voix mais ils peuvent galement offrir une large gamme de services multimdia (visiophonie, transfert de fichiers, navigation sur le Web, ). Enfin, ils ont pour ambition de proposer au consommateur un service accessible depuis n'importe quel pays, abstraction faite de toute norme et particularisme rgional. I.4.1. Objectifs L'UMTS a plusieurs objectifs dont nous citons: Lunification de l'ensemble des systmes qui existent travers le monde en la dfinition dune norme internationale. La compatibilit avec les systmes 2me gnration et la transparence du rseau pour l'usager (l'usager ne doit pas se rendre compte qu'il passe d'un rseau un autre). Supporter le multimdia : les terminaux auront la capacit d'accepter simultanment des services de natures diffrentes (voix, visiophonie, navigation web, transfert de fichier). Augmenter les dbits supports par le rseau par rapport au rseau de 2 me gnration. Proposer quatre classes de services 7 en prenant en compte 3 contraintes (le dlai de transfert de l'information, la variation du dlai de transfert des informations et la tolrance aux erreurs de transmission). I.4.2. Architecture du rseau UMTS Le rseau UMTS repose sur une architecture flexible et modulaire. Cette architecture nest associe ni une technique daccs radio, ni un ensemble de services, ce qui assure sa compatibilit avec dautres rseaux mobiles et garantit son volution. Une telle architecture, illustre la figure I-2, est compose de trois domaines : le domaine de lquipement de lusager UE (User Equipment), celui du rseau daccs radio universel UTRAN ( Universal Terrestrial Radio Access Network) et celui du rseau cur CN (Core Network).
La classe A (Conversational), La classe B (Streaming), La classe C (Interactive), La classe D (Background).
Page 6

Chaque domaine ralise une fonction bien prcise dans le rseau, tandis que des points dchange, dnots par Uu et Iu, servent dinterfaces permettant les changes entre les diffrentes parties du rseau.
Figure I-2: Architecture gnrale du rseau UMTS
a. Le domaine UE Il comprend tous les quipements terminaux et permet labonn laccs linfrastructure et ses services par le biais de linterface Uu. LUE contient deux parties: Lquipement mobile (ME : Mobile Equipement) : cest un terminal radio utilis pour les communications travers linterface radio Uu. LUSIM (UMTS Subscriber Identity Module) : cest lquivalent de la carte SIM en GSM. Il fournit lidentit de labonn, tablit les algorithmes dauthentification, enregistre les clefs dauthentification et de cryptage,etc. b. Le rseau daccs radio universel UTRAN Il fournit lUE les ressources radio et les mcanismes ncessaires pour accder au rseau cur. Il contrle les fonctions lies la mobilit et laccs au rseau. Comme illustr par la figure prcdente, lUTRAN constitue le trait dunion entre lUE et le rseau cur. Il est compos dun ensemble de sous-systmes nomms RNS (Radio Network Subsystem) et de plusieurs stations de base appeles Nodes B. Ces quipements sont connects entre eux au travers de plusieurs interfaces (Iub, Iur) et connects aux diffrentes parties externes (CN et UE) travers les interfaces Iu et Uu. Node B : Il assure la transmission et la rception dinformations entre lUTRAN et un ou plusieurs quipements usagers, ainsi que le contrle de puissance. En effet, la puissance dmission de lUE est contrle systmatiquement pour lui assurer la mme qualit de service indpendamment de sa position dans le rseau. Cela permet galement daccrotre lautonomie de
Page 7

la batterie tout en vitant daugmenter inutilement le niveau dinterfrence dans la c ellule. Le Node B est connect lUE en utilisant linterface Uu, qui reprsente la connexion radio. Le RNC : Le RNC contrle les ressources radio de lUTRAN et gre le protocole RRC (Rad io Ressource Control) dfinissant les procdures et les messages entre le mobile et lUTRAN. Il est en liaison avec le rseau cur pour les transmissions en mode paquet travers linterface Iu - PS et en mode circuit travers linterface Iu - CS. Le RNC directement reli un Node B par linterface Iub est un CRNC (Controlling RNC), il gre : -Le contrle de la charge des diffrents Node B. -Le contrle dadmission et dallocation des codes pour les nouveaux liens radio qui stablissent dans les cellules gres. Lorsquun mobile est li des Node B contrls par diffrents RNC, deux types de RNC se distinguent: Le SRNC (Serving RNC) et le DRNC (Drift RNC). Le SRNC est celui qui fournit la connexion Iu pour le mobile vers le rseau cur. Lorsque le mobile est en situation de Soft Handover, plus quune liaison Iub et une liaison Iur sont tablies. Seul le SRNC fournit linterface Iu vers le CN. Les autres ont pour fonction principale de router les donnes de faon transparente. Ces RNC sont appels alors DRNC. La figure suivante schmatise le rseau daccs UTRAN :
Figure I-3: lments du rseau daccs UTRAN
Nouveauts par rapport au BSS Quatre nouvelles interfaces ouvertes (normalises). Utilisation du CDMA comme mthode daccs. Gestion des donnes des services PS et CS par la mme pile de protocoles de linterface radio ;
Page 8

Utilisation dATM comme protocole de transport, permettant des dbits variables et des dlais de transmission respects ou garantis. A partir de la release 5 cest IP qui remplacera lATM. Support du soft-handover, ceci est limpact majeur du design de lUTRAN. Gestion de la mobilit indpendamment du rseau cur . Lorsque ceci est possible, une interoprabilit avec le rseau daccs GSM peut exister. c. Le rseau cur (CN) Il regroupe lensemble des quipements assurant les fonctions tel les que le contrle des appels, le contrle de la scurit et la gestion de linter face avec les rseaux externes. Il se dcompose en deux parties : le domaine paquet PS et le domaine circuit CS. Le domaine circuit : Ce domaine permet de grer les services temps rels tels que les appels tlphoniques, la visioconfrence et les applications multimdias. Ces applications temps rel, exigent un temps de transfert trs rduit. Le dbit support par ce mode peut arriver jusqu 384 Kbits/s. Linfrastructure pour le domaine circuit sappuie sur un MSC/VLR (Mobile Switching Center / Visitor Location Register) correspondant un commutateur tlphonique auquel est rattach une base de donnes pour les abonns visiteurs de la zone de service de ce MSC et sur un GMSC (Gateway MSC), pour la commutation vers les rseaux externes tels que le RTCP (Rseau Tlphonique Commut Publique). Le domaine paquet : Le domaine paquet est constitu dun backbone IP. Le routage des informations se fait soit dans le mme rseau, soit vers les rseaux paquets externes savoir (Internet, X25, VPN, ). Ce domaine traite les services non temps rels tels que le tlchargement des fichiers ou des E-mails, les jeux en rseau, la navigation sur le web, etc. Le temps de transfert pour ce type dapplications nest pas critique. Le dbit pourra atteindre 2 Mbits/s. Le rseau IP est bas sur un SGSN (Serving GPRS Support Node) jouant le mme rle que le MSC/VLR en mode paquet et un GGSN (Gateway GPRS Support Node) pour faire transiter les donnes vers les rseaux externes de transmission de donnes, et ngocier la qualit de service rseau avec un serveur de politique tel que COPS (Common Open Policy Server). On trouve le HLR (Home Local Register), comme un lment commun aussi bien pour le domaine paquet que pour le domaine circuit. Il sagit dune base de donnes contenant les profils et toutes informations concernant les abonns. I.4.2. Les interfaces La spcificit signaler dans le cadre de lUMTS est que les interfaces sont ouvertes c'est-dire quil y a une interoprabilit entre les quipements des diffrents constructeurs condition quils respectent la norme. On note quatre interfaces : Linterface Uu : cest linterface radio de lUMTS. A travers cette interface les mobiles peuvent accder au rseau. Linterface Iub : cest linterface entre le Node B et le RNC, cest lquivalent de linterface Abis en GSM. Linterface Iur : cest une nouvelle interface entre deux RNCs et elle est ncessaire pour le mcanisme du Soft Handover.
Page 9

Linterface Iu : cette interface permet lUTRAN de communiquer avec le rseau cur, elle se dcline, du point de vue fonctionnel, en deux interfaces Iu-CS et Iu-PS . La premire permet au RNC de communiquer avec le MSC/VLR (Mobile Switching Center/Visitor Location Register), cest dire avec la partie du rseau qui gre les services commutation de circuits, tandis que linterface Iu PS permet au RNC de communiquer avec le SGSN (Serving GPRS Support Node), la partie du rseau qui gre les services commutation de paquets. Lensemble de ces interfaces sont ouvertes et permettent par consquent de faire dialoguer entre eux des quipements fournis par des constructeurs diffrents. Ceci offre aux oprateurs des degrs de libert supplmentaires dans le choix de leurs fournisseurs dquipements de rseaux. LUMTS est assez semblable au rseau GSM actuellement trs rpandu : lensemble des constituants et des interfaces du rseau cur GSM a t repris dans larchitecture du rseau cur UMTS. La figure I-4 montre un rseau cur R99 commun un rseau daccs BSS et UTRAN.
Figure I-4: Architecture du rseau Release 99 UMTS / GSM
I.5. Conclusion
Larchitecture du rseau UMTS dans sa premire version est similaire celle du GSM. Ce choix darchitecture a t dict, dune part, par le souci des oprateurs europens de rutiliser les investissements lourds, dj effectus pour le dploiement du GSM et qui ntaient pas encore rentabiliss, et dautre part, par la volont de finaliser trs rapidement la prem ire version des spcifications (Release 99). Par consquent, larchitecture modulaire de lUMTS rend possible linterconnexion de son rseau avec des systmes daccs radio autres que lUTRAN, tel que le GSM/EDGE. Alors par consquence il est possible dinterconnecter les deux rseaux daccs BSS et UTRAN au mme rseau cur et superviser leurs diffrents lments rseau en utilisant un rseau de supervision commun qui va tre prsent dans le chapitre suivant.
Page 10
Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei
II.
Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei
II.1. Introduction
Dans cette partie, nous allons prsenter dune manire gnrale lentit de gestion et dexploitation du rseau, qui est lOMC. Aprs avoir dfini les rseaux dexploitation et maintenance nous allons prendre un exemple dtude de ces rseaux qui est le iManager M2000 de la socit HUAWEI qui est lobjet de notre tude.
II.2.Concept de la supervision
La supervision se dfinit comme une technique utilisant au mieux les ressources informatiques pour obtenir des informations sur l'tat des rseaux et de leurs composants. Ces donnes seront ensuite traites et affiches afin de mettre en lumire d'ventuels problmes. La supervision peut rsoudre les problmes automatiquement ou dans le cas contraire prvenir via un systme d'alerte (email ou SMS par exemple) les administrateurs. Plusieurs actions sont ainsi ralises : Acquisition de donnes, analyse, puis visualisation et raction. Un tel processus est ralis plusieurs niveaux d'un parc de machines : Au niveau interconnexions (Rseau), au niveau de la machine elle-mme (Systme) et au niveau des services offerts par cette machine (Applications).
II.3. Le sous-systme de supervision des rseaux cellulaires

II.3.1. Le centre dexploitation et de maintenance OMC Le centre dexploitation et de maintenance (OMC) regroupe trois activits principales de gestion: la gestion administrative, la gestion commerciale et la gestion technique. La gestion administrative et commerciale du rseau sintresse aux abonnements en termes de cration, modification, suppression et de facturation, ce qui suppose une interaction avec la base de donnes "HLR ". Tandis que, la gestion technique veille garantir la disponibilit et la bonne configuration matrielle des quipements du rseau. Ses axes de travail sont la supervision des alarmes mises par les quipements, la suppression des dysfonctionnements, la gestion des versions logicielles, de la performance et de la scurit. Cet OMC s'appuie sur un rseau de transfert de donnes, totalement dissoci du rseau de communication GSM. II.3.2. Le rseau dexploitation et maintenance Le rseau dexploitation et maintenance comprend les centres dexploitation et maintenance (OMC : Operations and Maintenance Center) qui sont les entits fonctionnelles permettant loprateur du rseau de contrler son systme. Un OMC-R (OMC-Radio) prend en charge la supervision et le contrle de lensemble des quipements du rseau daccs BSS et UTRAN. Un OMC-S (OMC-Switching) permet de superviser et contrler un ensemble de MSC/VLR. Au-del des OMC-R et OMC-S, on peut trouver, si limportance du rseau le justifie, un NMC (Network Management Centre) qui assure l'administration gnrale centralise du rseau.
Page 11

Le systme dexploitation et de maintenance OMC se connecte aux MSC et BSC travers le rseau X25. Les fonctions suivantes peuvent tre spcifiquement identifies : Laccs distance tous les lments qui composent le rseau GSM/ UMTS (BSS, MSC, VLR, HLR). La gestion des alarmes et de ltat du systme avec la possibilit d'effectuer diffrentes sortes de test permettant lanalyse des prestations et la surveillance de la qualit de fonctionnement de ce dernier. Le stockage de toutes les donnes relatives au trafic des abonns, ncessaires la facturation. La supervision du flux du trafic dans les centrales et lintr oduction de changements ventuels dans le mme flux. La visualisation de la configuration du rseau avec la possibilit d'effectuer des changements partir d'endroits loigns. La gestion des abonns et la possibilit de localiser leur position lintri eur de zone de couverture. La gestion des performances. La gestion de la scurit. II.3.3. Les diffrents types de maintenance Lobjectif principal du service maintenance est dassurer une bonne qualit de service en garantissant le bon fonctionnement des quipements. Pour ce faire, le service maintenance dfinit deux types de maintenance. La maintenance curative qui doit survenir pour remdier aux dfaillances signales alors que la maintenance prventive doit se faire de faon cyclique pour viter dventuels problmes. a. La maintenance prventive La maintenance de routine est une forme de maintenance active. Elle est aussi appele maintenance prventive ou maintenance priodique. La maintenance de routine est excute priodiquement pendant les oprations normales de lquipement incluant la maintenance de routine hebdomadaire, mensuelle, trimestrielle et annuelle. Cette maintenance prventive a pour objectifs de : - supprimer les risques potentiels pour garantir un fonctionnement normal du systme; - garantir un fonctionnement normal du rseau par une bonne coordination ; - sassurer quun nouveau quipement et lextension dun quipement sont correctement connects au rseau ; - sassurer que la performance et les diffrents services rpertoris ont des spcificat ions appropries conformes lquipement. Pour la maintenance mensuelle et trimestrielle, comme tches nous avons : - une vrification cohrente des donnes. - une vrification de la validit des donnes. - la maintenance des armoires. - la vrification du systme dalimentation. La maintenance annuelle quant elle consistera vrifier les cbles sur les quipements. b. La maintenance curative Les tches curatives regroupent lensemble des actions ralises pour remdier aux problmes signals sur sites par le systme de gestion des alarmes Alarm Management System .
Page 12

Le personnel du BSS peut, partir de ce systme, reprer les pannes sur les sites et avoir une ide de la nature de la panne, ceci pour une rsolution dans un dlai trs bref. Lemploy de maintenance responsable du site dfectueux doit, son tour, ragir le plus rapidement possible pour rparer la faute. Le but atteindre pour la maintenance curative est de minimiser le temps dintervention lors des pannes pour que le temps dindisponibilit du s ervice dans le site concern soit minimal. En effet, les tches curatives sont les plus importantes et les plus frquentes de lactivit de maintenance. Elles sont donc prioritaires par rapport aux tches prventives et aux autres oprations de maintenance et tirent leur importance de leurs effets directs sur le client et sur le systme. La sous quipe BSS de HUAWEI dispose actuellement dun registre de maintenance dans lequel sont enregistres manuellement les pannes qui surviennent dans le rseau. Lorsquune alarme est signale, par le systme de gestion des alarmes, lemploy responsable du site deux cas possibles de rsolution du problme : 1er cas : Lemploy repre la panne au niveau du systme A ce niveau lemploy rsout le problme en utilisant des commandes qui sont bien dfinies en fonction des tches excuter. 2e cas : Lemploy ne repre pas la panne au niveau du systme Ici la panne demande un dplacement sur le site et pour rechercher le problme, on effectuera des traces sur le site et aprs identification de lorigine du problme il sera rsolu. Ces mthodes de rsolution ntant pas enregistres pour un usage ultrieur, le travail qui consiste rsoudre une panne qui tait dj survenue sera effectu chaque fois que celle-ci se reproduira sur le mme site ou sur un autre site. II.3.4. Protocoles dexploitation et de maintenance Il existe des protocoles rseau qui permettent de rcuprer des informations sur le parc informatique. Nous allons tudier en particulirement les plus importants et qui sont largement utiliss par les logiciels de supervision. a. ICMP (Internet Control Message Protocol) ICMP est un protocole de couche rseau (couche 3 du modle OSI) qui vient palier l'absence de message d'erreur du protocole IP (Internet Protocol). En effet sil y a un incident de transmission les quipements intermdiaires vont utiliser ce protocole pour prvenir la machine mettrice. Les paquets ICMP sont encapsuls dans des paquets IP (malgr qu'ils soient au mme niveau OSI), et peuvent contenir des bouts de paquets IP pour citer celui ayant gnr l'erreur. Afin de catgoriser les erreurs, elles sont divises en types eux-mmes parfois re-diviss en codes. Par exemple le type 3 reprsente un destinataire inaccessible : Il existe 16 codes diffrents en fonction de la raison pour laquelle le destinataire n'est pas joignable. C'est un protocole trs simple, qui n'a pas pour fonction directe la supervision d'un rseau mais qui est utilis comme source d'information sur la qualit du rseau ou sur la prsence d'une machine.
Page 13

b. SNMP (Simple Network Management Protocol) Prsentation SNMP (Simple Network Management Protocol) est un protocole de couche applicative qui a pour but de superviser les rseaux. Il a t conu en 1988 par l'IETF (Internet Engineering Task Force) avec pour ide directrice de crer un protocole simple qui ne vienne pas gner le trafic du rseau qu'il supervise. Depuis sa cration, le protocole a volu par soucis de scurit: La version 2 qui est pour l'instant la plus utilise possde une notion de communaut qui est utilise comme un mot de passe, la version 3 durcit un peu plus le protocole en y ajoutant le chiffrement. Fonctionnement Par soucis de simplicit et donc de rapidit, SNMP ne transporte que des variables et s'appuie sur le protocole UDP (User Datagram Protocol). SNMP va crer un dialogue entre des agents installs sur des machines superviser et un serveur de supervision. Les changes entre agents et serveur se rsument trois oprations, les alarmes, les requtes et les rponses : Une requte est mise du serveur vers un agent via le port 161 UDP si le serveur veut demander ou imposer quelque chose cet agent. La requte peut tre de quatre types :
GetRequest : Demande la valeur d'une variable un agent GetNextRequest : Demande la valeur suivante de la variable GetBulk : Demande un ensemble de variables regroupes SetRequest : Demande la modification de la valeur d'une variable sur un agent L'agent va ensuite traiter cette requte et mettre une rponse via le mme port. Si tout se passe bien, l'agent rpond avec un GetResponse accompagn de la valeur demande. Mais dans le cas contraire l'agent ajoutera un code d'erreur en rponse (par exemple No Access ou Read Only). Une alarme est cre par un agent en cas d'vnement et utilise un message dit de type trap ou de type inform pour prvenir le serveur. Ce message SNMP transite via le port 162 UDP. Les alarmes peuvent prendre les formes suivantes :

ColdStart(0) : Redmarrage froid du systme WarmStart(1) : Redmarrage chaud du systme LinkDown(2) : Le lien rseau n'est plus oprationnel LinkUp(3) : Le lien rseau est oprationnel AuthentificationFailure(4) : Tentative d'accs l'agent avec un mauvais nom de communaut EGPNeighboorLoss(5) : La passerelle adjacente ne rpond plus EntrepriseSpecific(6) : Alarme propre aux constructeurs
tant donn que ces requtes utilisent des noms de variables, ceux-ci doivent tre communs tout matriel que l'on souhaite superviser (et supportant SNMP). C'est pour cette raison que les donnes sont stockes dans une base normalise nomme MIB (Managed Information Base). Cette base organise de manire hirarchique est assez
Page 14

complique lire pour un humain. Chaque information (les fameuses variables prcdentes) est identifie par un OID (Object IDentifier). c. OMAP (Operation and Maintenance & Administration Part) Le protocole OMAP fournit les procdures de gestion et de supervision du rseau smaphore. Il dfinit les protocoles dapplication et les procdures de monitoring, test et contrle des ressources SS7. Les procdures OMAP assurent entre autres les fonctions suivantes:
Vrification des routes SSTM, dtection de boucles, dlais excessifs, et indisponibilit des PTS (Points de transfert smaphores) ; Vrification des routes SCCP et gestion du routage ; Analyse de trafic ; Gestion des liens. d. TMN (Telecommunication Management Network) Le protocole TMN (Telecommunication Management Network) ou rseau de gestion des tlcommunications a pour but de rpondre aux exigences dexploitation, dadministration et de maintenance des rseaux de tlcommunications d e tout type de technologie. Il prsente lavantage de se situer dans un contexte multi fournisseurs. En effet, le TMN tient compte de la diversit des quipements de tlcommunication et de celle des centres informatiques qui les grent. Il permet galement lexploitant du rseau de dvelopper de nouvelles applications de gestion tout en sadaptant lorganisation de son rseau. Afin de fournir aux usagers des services avec un certain niveau de qualit et de cot, le TMN recouvre l'ensemble des activits de surveillance, d'analyse, de contrle et de planification du fonctionnement des ressources d'un rseau de tlcommunication. Dans cette optique, le TMN s'appuie sur cinq aires fonctionnelles appeles aussi SMFA (System Management Functional Area) ou classiquement les fonctions FCAPS: La gestion des fautes (F). la gestion de la configuration (C). la gestion de la comptabilit (A = accounting). la gestion des performances (P). La gestion de la scurit (S).
Page 15

II.4. Le systme M2000 de Huawei
iManager M2000 est le systme de gestion du rseau mobile qui gre dune manire centralise les diffrents quipements Huawei dans les rseaux GSM / GPRS / UMTS, y compris les MSC / HLR / BSC / UCP / BTS etc, et d'autres quipements tels que PDSN / RADIUS / HA. La figure suivante prsente linterconnexion des diffrents rseaux lOMC M2000:
Figure II-1: Interconnexion des diffrents rseaux au M2000
Le M2000 offre des fonctions basique telles que la gestion de la configuration, des performances, des pannes, de la scurit, du journal des alarmes, de la topologie etc. II.4.1. Position du systme M2000 dans le rseau mobile Le systme M2000 est dfini comme tant un rseau de maintenance rgionale, mais il peut tre utilis dune manire locale pour fournir une interface vers un rseau de maintenance plus lev comme le rseau NMS. La figure suivante montre les connexions entre le systme M2000 et les autres dispositifs
Figure II-2: Position du systme M2000
Page 16

Les priphriques connects au systme M2000 peuvent tre classs dans les deux types suivants: - Dispositifs connects par un cble srie tels que le modem et la bote d'alarme. Ces dispositifs sont en liaison avec le serveur M2000, M2000 client, et le serveur d'accs distance, qui forment le systme M2000 au sens large. - Les priphriques connects par l'intermdiaire du rseau OM bas sur TCP / IP, tels que les divers NE grs par le NMS et le M2000, et dispositifs de connexion rseau, tels que le dispositif rpartiteur de multiplexage, les commutateurs Ethernet, le routeur, et le pare-feu. II.4.2. Structure du systme M2000 En se basant sur le mode Client/serveur Le systme M2000 se compose dun ou plusieurs serveurs M2000 et de multiples clients M2000. Le systme Single-Server M2000 est configur avec un seul serveur M2000. Le systme M2000 HA et Remote HA (High availability) est configur avec deux serveurs M2000. Alors que le systme SLS est configur avec 2 7 serveurs8. -Le serveur M2000 fonctionne sur la plate-forme Unix. Il traite et stocke les donnes des lments du rseau. - tandis que les clients M2000 fonctionnent sur la plate-forme Windows. Ils fournissent une interface graphique pour lexploitation et la maintenance sur les lments rseau. La figure qui suit reprsente la structure gnrale du systme M2000.
Figure II-3: Structure du systme M2000
a. Architecture du Systme Le systme M2000 est subdivis en trois couches principales : couche dadaptation, couche de traitement et couche dapplication.
Ces systmes seront plus dtaills dans le chapitre trois.
Page 17

1. La couche dadaptation : Elle est compose principalement des lments de traitement des protocoles qui sert collecter les donnes provenant des lments de rseau. 2. La couche de traitement : Elle contient plusieurs lments fonctionnels principaux et indpendants qui peuvent fonctionner sur diffrents serveurs. 3. La couche application : Cette couche a pour rle de fournir les services des applications. Remarque : La couche dadaptation et la couche de traitement peuvent s'excuter sur les mmes serveurs ou des serveurs diffrents.
Figure II-4: Structure du systme M2000
b. Configuration logicielle La plateforme logicielle du serveur M2000 est constitue de : un logiciel pour le systme dexploitation : Solaris version 2.8 un logiciel de gestion de la base de donnes : Sybase version 11.9.2 un logiciel pour lapplication serveur le logiciel adaptateur du M2000 peut tre intgr dans l'quipement serveur M2000, et peut galement fonctionner dans un autre serveur de faon indpendante. La plateforme logicielle du client M2000 est constitue de : un systme dexploitation Windows une application logicielle pour le client.
Page 18

II.4.3. Rseau du systme M2000 Le rseau M2000 est caractris par une structure facilement extensible qui interconnecte plusieurs types de rseaux daccs et des technologies comme illustr d ans la figure qui suit :
Figure II-5: Schma du rseau du systme M2000
II.4.4. Les fonctions principales effectues par le systme M2000 a. Gestion commune lensemble des quipements Dans ce type de gestion seffectue les tches communes tous les quipements du rseau en mme temps, dont on trouve : Gestion de topologie Le systme affiche la topologie avec les mthodes de l'arbre de navigation et carte vectorielle MapInfo. La topologie supporte l'affichage de NE / virtuelle ou NE / BTS, et galement la connexion de la direction de bureau et de lien. Le systme peut afficher l'tat d'alarme NE avec la mthode dindicateur d'alarme, et aussi gre l'affichage de la direction d'alarme lien/ bureau dans la topologie. Gestion de la scurit la gestion de sous-rseau Lensemble des NE peut tre divis en un certain nombre de sous -rseaux selon la rgion et le type de NE; Un NE peut appartenir plusieurs sous-rseaux; Chaque sous-rseau contient un utilisateur gestionnaire et un ou plusieurs utilisateurs ordinaires;
Page 19

La ralisation de deux niveaux de gestion; administrateur de rseau et administrateur de sous-rseau. Gestion des comptes dutilisateurs Lexploitation du NE et l'autorit de maintenance (O & M) Gestion dauthentification Gestion dauthentification en temps rel (quatre utilisateurs au maximum peuvent tre surveills en mme temps). La gestion dauthentification des postes clients comprend laffichage, lajout, la mise jour et la suppression. Auto dconnexion Si l'heure de dconnexion automatique a t fixe, et aucune opration n'est mene prsent au sein du terminal de maintenance au temps voulu, le systme met une dconnexion automatique. b. Gestion centralise des pannes La solution centralise de gestion des pannes permet de : Reflter l'tat de marche de l'ensemble du rseau en temps rel; redfinir le niveau d'alarme pour rpondre la demande des diffrents clients. Enregistrer les alarmes sur la base de donnes afin de faciliter la collecte des expriences de la maintenance et ltablissement dun systme de reconnaissance des pannes. Analyser la relativit d'alarme: rduire la quantit d'alarme, localiser prcisment la source d'alarme et amliorer l'efficacit du dnouement. Le systme centralis de gestion des pannes de lOMC, fournit les fonctions de statistiques d'alarme l o l'utilisateur peut : Configurer la condition de flexibilit des statistiques en fonction des exigences; Imprimer le rsultat des statistiques et prparer le tableau complet de ce dernier; Effectuez les statistiques, le suivi de la quantit d'alarme en temps rel. Le systme de gestion centralis M2000 peut raliser l'envoi de l'alarme par SMS et par e-mail. c. Gestion de la performance centralise Le M2000 fourni les fonctions de base de gestion de performance en assurant les fonctions suivantes : Des statistiques de performance mises en uvre et le rsultat de collecte de l'ensemble du rseau. Rsultat de la requte conditionnelle, affichage graphique et de style assistant sommaire. Personnaliser les paramtres de performance. Alarme de performance: suivi en temps rel du rseau en cours d'excution d'tat. d. Gestion de la configuration centralise Parcourir les ressources de lensemble des quipements rseau . L'affichage graphique de la structure de la trame. Interrogation des ressources de tous les quipements rseau. Sauvegarde de l'historique des donnes de configuration.
Page 20

e. Maintenance distance Le systme supporte un modem dial-up pour accder au serveur M2000 et effectuer la maintenance distance. En mme temps, le systme peut surveiller la maintenance et enregistrer distance les dtails dentretien en temps rel.
II.5. Conclusion
Dans le rseau de supervision, la gestion tant lune des tches proccupantes des administrateurs rseaux, larchitecture du rseau et du systme M2000 ainsi que son modle client/serveur offre une facilit pour les tches de gestion et dadministration trs remarquable et un systme rseau fiable. Ce but ne peut tre atteint que si larchitecture est correctement dimensionne, Ce qui constitue le but de notre tude dans le chapitre qui suit.
Page 21
Chapitre III : Planification du rseau de supervision utilisant la solution Huawei
III.
Planification du rseau de supervision utilisant la solution Huawei
III.1. Introduction
Dans ce chapitre nous allons mettre laccent sur les diffrentes tapes de planification du rseau dexploitation et maintenance qui se composent de cinq phases : la prparation du projet, la collecte des informations, la conception haut niveau (HLD 9), la conception bas niveau (LLD 10), le rapport de conception et l'acceptation de service. Le schma suivant illustre le processus de conception du rseau avec les rapports produits chaque tape:
Figure III-1: Le processus de conception
La prparation du projet : Le but principal dans la phase de dmarrage du projet est de faire des prparations pour le service de planification du rseau, y compris la gestion des ressources humaines, lobtention des donnes de base au sujet du projet ainsi que les documents et les outils. Collection d'informations : Le but de la phase de collecte des informations est de rassembler les informations exiges pour le service de conception du rseau y compris ltendue du rseau bas sur le nombre des lments rseau, le rseau de transmission bas sur le type du backbon e et ltat du rseau actuel ainsi que la distribution des lments du rseau NE. La conception haut niveau : Le but dans la phase de HLD est de dterminer la topologie du rseau et les principaux paramtres de planification : lanalyse et lvaluation de la capacit en NE quivalents, le choix du systme rseau et serveur appropris et le calcul de la bande passante requise. La conception bas niveau : Base sur une srie d'arrangements de gestion de rseau spcifiques dans le HLD, le LLD vise dterminer la taille du rseau, la planification des donnes de chaque lment du rseau, les paramtres d'interface (nom dinterface, adressage IP, et numro de port), et la gestion des connexions rseau.
10
HLD : High Level Design LLD : Low Level Design
Page 22

L'acceptation de service : Le but, dans cette phase est de gnrer le rapport de conception du rseau et d'organiser l'acceptation pour le service conception du rseau SLS 11 avec le client et signer le contrat d'acceptation de service.
III.2. Topologie et architecture du rseau planifier

Avant dentamer la planification proprement dite nous rappelons larchitecture du systme M2000 qui comprend des serveurs, des clients d'exploitation et de maintenance et des priphriques du rseau relatifs tels quillustrs sur la figure suivante :
Figure III-2: La topologie du systme M2000
Comme reprsent dans la figure II-1, le but est de dterminer la topologie du rseau M2000 et de schmatiser les diffrents types de NE relis au site central du M2000 en indiquant le type de backbone utiliser. Le lieu central se rapporte au site o le serveur M2000 est plac. Tous les priphriques qui peuvent tre connects au serveur M2000 par le rseau LAN sont les NE du site d'exploitation central. Les sites distants se rapportent aux NE qui sont connects au serveur M2000 par le rseau WAN. Lors de la gestion du rseau et de la planification du systme M2000, le concepteur a besoin de dterminer le mode de gestion de rseau du M2000 appropri, et puis de calculer la bande passante ncessaire entre chaque site distant avec le site central et de spcifier les priphriques du rseau configurer.
11
SLS : Multi-Server Load-Sharing system
Page 23

III.3. Gestion de capacit et planification de la bande passante
Le M2000 gre les diffrents types dlments rseaux de diffrentes technologies. Les concepteurs doivent mesurer la capacit de gestion et dterminer la spcification du serveur M2000 qui va tre configur pour satisfaire l'exigence relle pendant le dimensionnement du rseau. La solution Huawei prsente le concept de NE quivalent pour convertir les diffrents NE physiques en NE quivalents. Ainsi, l'tendue du rseau peut tre calcule dune manire plus commode. Par suite, le systme M2000 peut tre configur selon l'tendue du rseau calcul. Le traitement des donnes de performance des NE exige un processeur et des ressources mmoire du serveur M2000 fixs selon la capacit de gestion de ce dernier. III.3.1. Calcul par la mthode des lments quivalents du rseau Le traitement des donnes de performance des NE est un facteur important qui affecte la capacit de traitement du M2000. Donc, un NE quivalent est dfini comme une unit pour mesurer la capacit de traitement du serveur M2000. Les NE physiques rapportent leurs donnes de performance au M2000 toutes les 30 minutes ou dans une priode plus longue par le protocole FTP. La capacit de traitement de donnes d'un NE quivalent est gale la capacit pour le serveur M2000 pour faire l'analyse et stocker pas moins d e 5500 rsultats standard au cours dune certaine priode. Un rsultat standard se rfre un rsultat de mesure de performance de 35 compteurs de mesure dans une unit de mesure. Si les PRS12 et M2000 sont dploys sur un serveur, la capacit de gestion du NE diminue de 30 %. Si le NetEco13 et M2000 sont dploys sur un serveur, la capacit de gestion du NE diminue de 10 %. Plateforme Hardware 2 CPU Sun M4000 4 CPU Sun M4000 4 CPU Sun M5000 6 CPU Sun M5000 8 CPU Sun M5000 Capacit de gestion (nombre de NE quivalent) 100 190 190 270 340
Tableau III-1: Capacit de gestion des NE du systme M2000
Remarque Il est possible dtendre le rseau en ajoutant des CPU.
Il est possible dtendre le rseau en ajoutant des CPU.
Mme si les configurations matrielles des serveurs M2000 sont identiques, la capacit de gestion des NE varie selon la version du systme d'exploitation et de la base de donnes sur les serveurs M2000. Des serveurs Sun sont installs avec Solaris10 comme systme d'exploitation et
12
Le PRS est un systme utilis pour archiver une grande quantit les donnes de supervision pendant une trs longue dure. 13 Le NetEco est un quipement HUAWEI utilis pour gestion de puissance et denvironnement des sites contenant les quipements HUAWEI.
Page 24

la base de donnes Sybase 15. Le tableau ci-dessus dcrit la capacit de gestion dun serveur simple et du systme HA haute disponibilit. III.3.2. Conversion dlments physiques du rseau vers des lments quivalents Les ressources consommes quand le M2000 gre les NE varient selon des types de NE. Il existe des relations pr-tablies entre NE physiques et NE quivalents. Cette section dcrit comment convertir les NE de diffrents types en NE quivalent. Pour cela, il faut considrer les trois facteurs suivants lors de la conversion : Types et versions de NE physiques : les ressources M2000 consommes par les NE varient selon des types et des versions de NE. Par consquent, les NE de diffrents types et versions peuvent tre convertis en un nombre de NE quivalent diffrents. Nombre de compteurs de performance : pour un NE, rapportant tous ses compteurs de performance ou rapportant son KPI14 exigent des capacits diffrentes pour le M2000. Donc, les NE avec les nombres diffrents de compteurs de performance peuvent tre en un nombre de NE quivalent diffrents. Priode d'excution : pour un NE, rapportant ses donnes de performance toutes les 15, 30 ou 60 minutes exigent des capacits de matriel diffrentes pour le M2000. Donc, les concepteurs doivent calculer l'tendue du rseau sur la base de leurs exigences relles avant la configuration du systme M2000. III.3.3. Moyens de calcul de l'tendue du rseau Gnralement, les MBTS dans le rseau de SingleRAN M2000 se composent de deux BTS logiques, savoir GBTS et NodeB. Le nombre de NE quivalents correspondant un MBTS est calcul en fonction des cellules 3G et des TRX 2G. Le tableau suivant dcrit le nombre de NE quivalents qui correspondent NE physiques du site. Le concepteur peut dterminer un type de serveur configurer en fonction du nombre total de NE quivalents. Le tableau suivant prsente le nombre des NE quivalents correspondant chaque NE WCDMA pour une priode de 30 et 60 minutes : Nombre de NE Equivalents Type de NE WRAN Version de NE RAN6 RAN10 RAN11 RAN12 RAN13 Unit de conversion Compteur KPI 1 Cellule 1 Cellule 1 Cellule 1 Cellule 1 Cellule 1/55 1/52.5 1/50 1/50 1/50 Compteur total 1/38.5 1/36.75 1/35 1/35 1/35
Tableau III-2: nombre des NE quivalents correspondant chaque NE WCDMA (priode de 30 et 60 minutes)
14 KPI: Key Performance Indicator
Page 25

Cette section prend la version RAN6.0 comme exemple. Selon le tableau 6-1, un ensemble de 55 cellules UMTS quivaut un NE quivalent si les KPI sont signals toutes les 60 minutes ou 30 minutes. Un ensemble de 38,5 cellules UMTS quivaut un NE quivalent si tous les compteurs sont signals. Puis, le nombre des NE quivalents peuvent tre calculs sur la base du nombre de cellules UMTS qui doivent tre crs dans le rseau courant. Ce tableau prsente le nombre des NE quivalents correspondant chaque NE WCDMA pour une priode de 15 minutes: Nombre de NE Equivalents Type de NE WRAN Version de NE RAN6 RAN10 RAN 11 / 12 / 13 Unit de conversion Compteur KPI Compteur total 1 Cellule 1 Cellule 1 Cellule 1/33 1/31.5 1/30 1/23.1 1/22.05 1/21
Tableau III-3: nombre des NE quivalents correspondant chaque NE WCDMA (priode de 15 minutes)
Le tableau qui suit prsente le nombre des NE quivalents correspondant chaque NE GSM pour une priode de 30 et 60 minutes : Unit de conversion 1 TRX 1 TRX Nombre de NE Equivalents Compteur KPI Compteur total 1/125 1/125 1/90 1/75
Type de NE GBSS
Version de NE GBSS 8.0 GBSS 8.1 / 9.0 / 12.0 / 13.0
Tableau III-4: nombre des NE quivalents correspondant chaque NE GSM (priode de 30 et 60 minutes)
Ce tableau prsente le nombre des NE quivalents correspondant chaque NE GSM pour une priode de 15 minutes : Unit de conversion 1 TRX Nombre de NE Equivalents KPI-Counter 1/75 1/75 Compteur total 1/54 1/45
Type de NE GBSS
Version de NE GBSS 8.0
GBSS 8.1/ 9.0 / 12.0 / 13.0 1 TRX
Tableau III-5: nombre des NE quivalents correspondant chaque NE WCDMA (priode de 15 minutes)
Selon le tableau prcdent, le nombre de NE quivalents varie en fonction des besoins de gestion des services, mme avec l'tendue mme du rseau. Par consquent, diffrents serveurs M2000 sont ncessaires.
Page 26

III.3.4. Bandes passantes ncessaires Les conditions de largeur de bande sont dtermines comme suit : Condition de bande passante pour la communication entre le serveur M2000 et les NE : Les tableaux suivant dcrivent les besoins en bande passante minimum pour accder aux priphriques du rseau radio pour le M2000. Les dispositifs du rseau daccs radio sont de diffrents types dpendant des diffrentes technologies. Nombre total de NodeB dans chaque RNC Bande passante totale (kbit /s) 100 384 200 512 400 768 600 832 800 1024 1000 1152
Tableau III-6: bandes passantes requise pour la RNC
La bande passante requise pour la gestion des lments du rseau daccs GBSS
Nombre total de BTS dans chaque GO BSC6900 100 BTS et 600 TRX 200 BTS et 1200 TRX 400 BTS et 2400 TRX 600 BTS et 3600 TRX 800 BTS et 4800 TRX
Bande passante totale (kbit /s)
512
768
1472
2212
2816
Tableau III-7: bandes passantes requise pour la BSC
Condition de bande passante pour la communication entre le serveur M2000 et les clients M2000 : La communication directe entre chaque client M2000 et le serveur M2000 exige une largeur de bande de 512 Kbits/s. Quand celle rserve entre le client Citrix et le serveur Citrix elle est de 64 Kbit/s. Condition de bande passante pour la communication entre le serveur M2000 et les NMS de couche suprieure ou dautre EMS : Exige un minimum de bande passante de 256 Kbits/s. Bande passante requise pour les diffrents types de client et vers le rseau NMS (Kbit/s) client M2000 distant 512 Interface vers le NMS 256 l'quipement dinteraction d'IP et du serveur M2000 16 les clients et serveur Citrix 64
Tableau III-8: bandes passantes requise entre le serveur M2000 et les priphriques dexploitation
Le concepteur a besoin de dterminer le mode de gestion du rseau du M2000, et puis de calculer la condition de largeur de bande entre chaque site distant avec le site d'exploitation principal, pour spcifier les dispositifs de gestion du rseau configurer. Demande de bande passante totale = la somme des largeurs de bande de tous les NE.
III.4. Planification du rseau pour le systme de supervision

L'OSS Operation and Maintenance System constitue le cur d'un rseau de communication mobile. Si les services de lOM sont interrompus, le rseau de communication mobile entier est paralys, rsultant en une perte norme pour les oprateurs. Pour amliorer la
Page 27

comptitivit des services de tlcommunication et rduire les cots d'exploitation des oprateurs, les utilisateurs ont besoin dassurer la scurit et la fiabilit du rseau de l'OSS. Pour cela nous allons prsenter dans cette partie de ce chapitre quelques solutions proposes par la socit HUAWEI pour grer les diffrents problmes de scurit et le manque de fiabilit du rseau de supervision. III.4.1. Rseau HA servers Le systme M2000 HA 15 est compos de deux serveurs placs dans le mme site et une baie de disque Disk Array partag entre eux pour la synchronisation des donnes. Le systme M2000 HA travaille en mode actif/secours. Les services M2000 sont excuts sur le nud actif et sont en tat dattente sur le nud de secours. Le nud de se cours et le nud actif sont installs avec le mme logiciel M2000. Si le nud actif est dfectueux et ne peut pas rtablir les services d'application, le systme commute ces services d'application vers le nud de secours et assure que ce nud reprend rapidement les services du rseau existant. Ceci assure la continuit de services M2000. Le systme M2000 HA peut tre utilis dans les scnarios suivants : L'interruption frquente des services de tlcommunication qui rduit la comptitivit et augmente la dpense d'exploitation (OPEX 16 ) des oprateurs. Le M2000 gre l'quipement de communications mobile dune faon centralise et joue un rle important dans un rseau de gestion des tlcommunications (TMN17). S'il y a de hautes exigences sur la fiabilit du M2000, le systme M2000 HA peut tre utilis dans ce cas. Le systme M2000 HA offre une solution de redondance complte double nud dans laquelle les nuds serveurs, les baies de disques, les interfaces rseau, et tous les commutateurs Ethernet sont doubls. Cette solution empche lexistence dun point de dfaillance unique, amliore la fiabilit du dispositif, raccourcit la dure d'interruption de service et assure la fiabilit et la continuit des services du systme. a. Architecture du systme M2000 HA Le systme M2000 HA comprend les serveurs M2000 et les baies de disques, tel que : - Les serveurs actifs et de secours fonctionnent en tant que serveurs M2000 excutant le logiciel M2000 serveur et le logiciel de mdiation 18 du rseau. Le logiciel de surveillance du cluster est utilis pour la surveillance du basculement entre les serveurs actifs et de secours. - Les baies de disques fournissent lespace de stockage pour les ressources qui peuvent tre partages entre le serveur actif et de secours. Les baies de disques communiquent et transmettent les donnes avec les serveurs par le biais du bus SCSI ou en utilisant un commutateur optique. - Les commutateurs de rseau local forment les plans de rseau actif et de secours pour mettre en uvre la communication entre chaque composant : entre le serveur M2000 et les systmes externes.
15 16
HA : High Availability OPEX : Operating Expenditure 17 TMN : Telecommunication Management Network 18 Logiciel de mdiation :
Page 28

- La figure ci-dessous montre l'architecture logique du systme M2000 HA qui utilise les plates-formes HP ou SUN. Lorsque le systme M2000 HA utilise la plate-forme ATAE, une seule baie de disques est configure dans le systme.
Figure III-3: L'architecture logique du systme M2000 HA
b. Avantages du Systme M2000 HA Les avantages du systme M2000 HA sont comme suit : Le contrle et la gestion des serveurs sont raliss par le logiciel de cluster Cluster Software . Le systme M2000 HA dtecte automatiquement les erreurs logicielles et les dfaillances matrielles ce qui amliore considrablement la disponibilit du systme. La solution HA supporte le basculement entre les modes actif et rserve, qui amliore la disponibilit des services du systme M2000. Il supporte la fois le basculement manuel et automatique. III.4.2. Rseau Remote HA servers Puisque le systme traditionnel redondant M2000 HA prsente beaucoup danomalies dans les situations de catastrophe comme les incendies, tremblements de terre, tsunami, et les guerres ou la dure d'interruption des services augmente considrablement et leurs restauration est trs difficile. Le systme Remote HA est mis en uvre pour empcher les services M2000 d'tre affects par de telles menaces, et cela en plaant les deux nuds actif et de secours dans deux sites diffrents. a. Architecture logique du Systme M2000 Remote HA Le systme M2000 Remote HA se compose de : serveurs M2000, routeurs, et les baies de disques.
Page 29

Le lien Heartbeat19 actif et le canal de synchronisation des donnes : Ce canal vhicule les signaux de signalisation et lchange dinformation entre le nud actif et le nud de secours pour permettre ces deux derniers de surveiller, mutuellement et en temps rel, l'tat des services en cours d'excution. Ce lien Active Heartbeat link est galement responsable de la synchronisation et la duplication des donnes entre les nuds actif et de secours. Le lien Heartbeat de secours et le canal de service dOM 20 : ces deux liens sont connects au rseau de service dexploitation et de maintenance. Ils ont pour rle dassurer linterconnexion du serveur M2000 avec les lments rseaux et avec le terminal du client M2000. Ce canal est utilis en tant que lien de secours Heartbeat . Si le Heartbeat actif est dconnect, les nuds actif et de secours peuvent toujours surveiller mutuellement l'tat de marche travers le lien Heartbeat de secours. La figure III-4 montre l'architecture logique du systme M2000 Remote HA .
Figure III-4: L'architecture logique du systme M2000 Remote HA .
b. Avantages du systme M2000 Remote HA En plus des avantages fournis par le systme M2000 HA traditionnel, ce systme : Supporte deux serveurs dans des emplacements diffrents. N'a aucune limite sur la distance entre les deux serveurs, amliorant la scurit physique du systme et supporte le rtablissement en cas de dsastre. Peut tre divis au systme de serveur seul, amliorant la flexibilit du systme et rduisant le temps d'interruption de service pendant la mise jour. Supporte la duplication des donnes entre les deux serveurs; permettant un serveur de reprendre les services OM21 de l'autre serveur en panne.
19 20
Active heartbeat link OM : Operation and Maintenance 21 OM : Operation and Maintenance
Page 30

III.4.3. Rseau SLS servers Avec l'augmentation de ltendue du rseau, le systme de serveur seul M2000 ne peut pas entreprendre la gestion centralise du rseau entier. Alors, le systme M2000 bas sur des serveurs multiples est exig pour excuter la gestion distribue du rseau. Le systme M2000 bas sur la solution SLS fourni par Huawei combi ne des nuds multiples dans un systme de gestion de rseau. Le systme SLS dploie des services diffrents dans des nuds diffrents pour mettre en uvre la gestion centralise des systmes M2000 multiples. Ainsi, l'EMS22 est facilement tendu et les cots de maintenance des systmes M2000 multiples sont rduits. Le systme SLS du M2000 est compos de N+1 serveurs, tel que 2N6, y compris un serveur matre, n-1 serveurs esclaves et 1 serveur de secours. Il est aussi appel " la solution N:1 ". Le serveur matre fournit des services de gestion publics, les serveurs esclaves fournissent des services de gestion caractristique comme la gestion de la performance et la gestion de la configuration. Le serveur de secours agit comme une redondance des serveurs matres et esclaves. Le passage matre/secours ou le passage esclave/secours peuvent tre mis en uvre dans le systme entier par le contrle du cluster Cluster monitoring. De plus, le systme M2000 SLS fournit des nuds de secours pour soutenir le rtablissement en cas de dsastre. a. Structure logique du systme M2000 SLS Le systme M2000 SLS se compose des lments logiques suivants: le serveur matre, les serveurs esclaves, serveur de secours, M2000 clients, les baies de disques, les commutateurs optiques et la bote d'alarme. La figure 1 montre la structure logique du systme M2000 SLS. On suppose dans cet exemple que N est gal 3 .
Figure III-5: La structure logique du systme M2000 SLS
22
EMS : Element Management System
Page 31

- Serveur matres et serveurs esclaves: Chaque serveur du systme M2000 SLS est un nud de traitement, qui doit excuter le logiciel M2000 serveur et le logiciel de base de donnes. - Serveur de secours: Lorsque le serveur matre ou lun des serveurs esclaves est en dfaut, les services peuvent tre commuts vers le serveur de secours. -Baies de disques: Elles sont utilises pour stocker les donnes. Le serveur matre et chaque serveur esclave est respectivement configur avec une baie de disque. - Commutateurs optiques: les commutateurs optiques servent connecter les baies de disques aux serveurs travers la fibre optique. - Le client M2000: Le client M2000 se rfre un PC excutant le logiciel client M2000. - Le boitier des alarmes: Le botier d'alarme est reli au client M2000. Si une alarme est signale, le botier d'alarme gnre une alarme sonore et met une lumire en fonction de la gravit de l'alarme pour avertir les utilisateurs. b. Avantages du systme M2000 SLS Les avantages du M2000 SLS sont les suivants : Le systme est constitu de multiples serveurs pour excuter des services et fournir la capacit de gestion pour de trs grands rseaux. Il supporte le partage de charge qui permet daugmenter le retour sur investissement. Il a la capacit de grer dune faon centralise le rseau entier comme une partie logique d'EMS. Il contrle et gre les serveurs par le logiciel de cluster Cluster Software et amliore la disponibilit du logiciel et du matriel en dcouvrant automatiquement les problmes matriels et les erreurs logicielles. Il supporte le passage matre/secours Master/Standby et le passage d'esclave/secours Slave/Standby qui amliore ainsi la disponibilit de services de gestion des lments. Il supporte l'extension facile du rseau (sans affecter les services existants) en connectant les nouveaux lments rseau NE aux nouveaux serveurs esclaves.
III.5. Les modes de gestion du rseau

III.5.1. Gestion du rseau IP Ce mode rseau est applicable dans les zones o l'oprateur a son propre rseau de transmission IP privs fiables et efficaces. Parce que le routage sur le site central et le site distant est mis en uvre par l'oprateur lui -mme. L'quipement de NMS n'a besoin que de fournir des interfaces rseau. La bande passante est alloue par l'oprateur suivant les exigences. Le rseau IP priv ncessite des ressources de transmission prive qui sont coteuses.
Page 32
Dans les rseaux IP, nous devons configurer seulement les commutateurs Ethernet, comme le montre la figure 3.
Figure III-6: Gestion du rseau IP
La mise en rseau IP se compose du mode de mise en rseau LAN (Rseau couche 2 bas sur les commutateurs) et le mode de mise en rseau WAN (Rseau couche 3). Mise en rseau LAN Si le serveur et le client M2000, et les NE grer sont dans le mme rseau local, la communication entre eux peut tre mise en uvre par les deux commutateurs Ethernet qui sont configurs avec le serveur M2000 par dfaut comme illustr ci-dessous :
Figure III-7: Mise en rseau LAN
Page 33

Mise en rseau WAN Le mode de mise en rseau WAN IP-Based WAN doit tre adopt si les priphriques des NE (sauf BTS) et du M2000 sont placs dans des zones ou le rseau local ne peut pas les couvrir. Pour cela ils ont besoin d'tre connects via le routeur tel que le montre la figure suivante :
Figure III-8: Mise en rseau WAN
Le rseau doprateur est souvent mis en place sur IP DCN 23 pour la communication entre le systme M2000 et les dispositifs de chaque site. Par consquent, seuls les commutateurs Ethernet dans le site central et les sites distants ont besoin d'tre configurs en mode rseau IP. Ensuite, les commutateurs Ethernet ont besoin d'tre connects IP DCN. Huawei et les oprateurs ont besoin de spcifier les largeurs de bande et affecter des segments d'adresses IP entre le site central et les sites distants. III.5.2. Gestion du rseau Full E1 La liaison E1 (CEPT), systme de transmission numrique, est le plus bas niveau de la hirarchie de communication numrique de l'Union Europenne. Une installation E1 fournit une transmission full-duplex 2,048 Mbps. La bande passante est divise en 32 canaux multiplexs (byte-entrelac) de 64 Kbps. Selon le format de la trame, un ou deux des canaux 64 Kbps sont utiliss pour la dlimitation de la trame et autres fonctions dentte. La largeur de bande restante (1,920 ou 1,984 Mbps) peut tre utilise pour transporter soit de la voix ou des donnes. La mise en rseau en mode Full E1 ne ncessite pas d'extraction et d'change dintervalle de temps. L'ensemble des 2 Mbit/s de la bande passante est disponible pour transmettre les donnes du systme NMS. Ce mode s'applique dans les conditions o il y a de grandes quantits de donnes changer et des ressources de transmission suffisantes. Dans ce mode, les NE contrler sont situs dans des sites distants. La liaison entre le serveur M2000 et les NE sont portes par le lien E1. Habituellement, un ou plusieurs liens Full E1 sont exigs. Le mode de gestion de rseau FullE1 est souvent employ dans le rseau de
23
DCN, Digital Core Network
Page 34

transmission traditionnel. Le routeur avec les ports E1 doit tre configur entre le site d'exploitation principal et les sites distants. Pour le rseau FullE1, nous devons configurer les quipements tels que les routeurs et les commutateurs Ethernet, comme le montre la figure :
Figure III-9: Rseau Full E1
a. Exemple de mise en rseau Full-E1/T1
Figure III-10: Exemple de mise en rseau Full-E1/T1
Passerelle par dfaut du serveur M2000: 192.168.0.1 Passerelle par dfaut des lments rseaux NE: 192.168.10.1 Route statique du routeur : AR46-20: 192.168.10.0/24 192.168.13.2 192.168.10.0 indique l'adresse IP de destination du rseau. 24 indique le nombre de chiffres dans le masque de sous rseau. 192.168.13.2 indique l'adresse IP du saut suivant. On utilise les adresses IP 192.168.0.0 sur le segment rseau afin d'accder des adresses IP sur le segment du rseau 192.168.10.0. Le routeur AR46-20 transfre les paquets au segment de rseau 192.168.13.0. Route statique du routeur : AR28-13: 192.168.0.0/24 192.168.13.1 192.168.0.0 indique l'adresse IP de destination du rseau. 24 indique le nombre de chiffres dans le masque de sous rseau. 192.168.13.1 indique l'adresse IP du saut suivant. On utilise les
Page 35

adresses IP sur le segment du rseau 192.168.10.0 pour accder aux adresses IP 192.168.0.0 sur le segment de rseau. Le routeur AR46-20 transfre les paquets au segment de rseau 192.168.13.0. Limitations et prcautions prendre pour la configuration rseau:
III.5.3. Gestion du rseau Partial E1 Dans les annes 1990, le mode Partial E1 est devenu trs populaire et beaucoup doprateurs ont commenc offrir ce service. De cette faon, les clients pouvaient louer une partie de la bande passante du 2Mbps du MIC (E1) une fraction de cot d'un E1 entier. Par rapport aux services de Partial E1, Full E1 taient encore plus rentable si la bande passante a t presque entirement utilise ou si les liens taient assez courts. Pour la plupart des applications actuelles, les boucles locales partial E1 sont rarement utilises, car elles ne sont ni conomique ni pratique. Il s'agit d'un mode de mise en rseau commune. Ce mode utilise les intervalles de temps inactifs dans la ligne de transmission existant E1/T1 pour transmettre les donnes NMS. L'avantage de ce mode en rseau, c'est que chaque oprateur dispose d'un rseau de transmission E1/T1 indpendant, ce qui contribue fournir des canaux de transmission, l'attribution d'adresses de rseau, et de maintenir les canaux de communication bases sur les ressources disponibles. Ce mode permet d'conomiser beaucoup en gestion du rseau de l'oprateur. En partielle E1/T1 rseau, nous devons configurer le priphrique de brassage numrique Mercury 3600, les routeurs, les commutateurs Ethernet comme le montre la figure :
Figure III-11: Rseau Partial E1
Dans ce mode, peu dintervalles de temps du E1 principal sont utiliss pour transmettre des donnes de l'OM. Ce mode ne ncessite pas un rseau de transmission priv, mais exige lutilisation de l'quipement de multiplexage temporel. L'quipement d'interconnexion de multiplexage, c.--d., le Mercury 3600, est utilis pour ajouter les donnes M2000 OM des intervalles de temps E1. Les bandes passantes de certains NE
Page 36

ne sont pas rpertories parce qu'ils occupent une bande passante troite et peuvent partager les intervalles de temps configurs avec d'autres NE. Dans la pratique, nous devons rserver plus de largeur de bande pour chaque NE pendant la gestion de rseau. a. Exemple de mise en rseau Partial E1/T1 Ce schma illustre les raccordements du M2000, du NEs, des commutateurs LAN et des routeurs de rseau Partial E1/T1. 1A, 1B, 1C, et 2A se rapportant au numro de port du Mercury 3600.
Figure III-12: Exemple de mise en rseau Partial E1/T1
Passerelle par dfaut du serveur M2000: 192.168.0.1 Passerelle par dfaut des lments rseaux NE: 192.168.10.1 Route statique du routeur : AR46-20: 192.168.10.0/24 192.168.13.2 Route statique du routeur : AR28-13: 192.168.0.0/24 192.168.13.1
III.6. conclusion
Dans ce chapitre nous avons prsent les diffrentes tapes suivre pour planifier un rseau dexploitation et de maintenance fiable qui rpond aux exigences des oprateurs et qui sadapte avec le rseau doprateurs et les backbones actuels. Et afin de bien comprendre comment utiliser ces diffrentes notions prsentes dans ce chapitre nous allons dans le chapitre suivant prendre le cas dun projet de planification du rseau de supervision ; le rseau daccs de loprateur de la tlphonie mobile algrien MOBILIS.
Page 37
Chapitre IV : Applications
IV. Applications
IV.1. Application 1: Planification du rseau de supervision de la partie accs radio (GSM, UMTS) pour loprateur de la tlphonie mobile algrien MOBILIS.
IV.1.1. Introduction Vu lextension rapide du rseau de loprateur tlphonique mobile MOBILIS dans le rseau actuel GSM, et le lancement du projet de la troisime gnration UMTS. Il est ncessaire de sparer le rseau de supervision du rseau cur (Core Network) de celui du rseau daccs radio. Ce qui nous a offert une opportunit de travailler sur ce projet et concrtiser notre tude dans la conception du rseau dexploitation et de maintenance pour MOBILIS et linstallation dun OMC la rgion Est du pays Batna, qui connecte tous les quipements Wireless Huawei du rseau national MOBILIS. IV.1.2. Objectif Notre objectif consiste concevoir un rseau de supervision de tous les quipements Wireless Huawei du rseau MOBILIS, en se basant sur les procdures suivantes : a. Planification de la topologie Dans notre cas dtudes, nous avons propos la topologie rseau illustre sur la figure suivante :
Figure IV-1: Topologie du rseau de supervision MOBILIS situ Batna
b. Planification de la capacit et ltendue rseau Dans le projet actuel (le swap GSM, UMTS) que la socit HUAWEI a eu avec loprateur MOBILIS, 14 BSC (GU) vont tre connects au serveur M2000 de Batna, avec une estimation de 3000 cellules 2G et 900 cellules 3G.
Page 38
Dans un futur proche Huawei prvoit lajout de 12 autres BSC avec 200 0 cellules 2G qui vont tre connectes au mme serveur. Do la ncessit de planifier aussi lextension de ce rseau. Remarque : Dans ce projet, le mode utilis est S 4/4/4, dans lequel chaque secteur peut supporter 4 TRX, donc nous allons avoirs (3000 cellule * 4) = 12000 TRX pour le projet actuel et (2000 cellule * 4) = 8000 TRX ajouter dans le prochain projet. Le calcul des lments rseau quivalents En se basant sur les diffrents tableaux du troisime chapitre, nous allons rsumer dans le tableau suivant les diffrentes tapes de la planification de la capacit :
Donnes de performance des NE collectes toutes les 30 ou 60 minutes Type de NE Version tendue ou Nombre Total Nombre de NE Equivalents Correspondants lors de la collecte des KPIs Nombre de NE Equivalents Correspondants lors de la collecte de Tous les Compteurs (12000 + 8000 ) * 1/75 = 160 + 106.67 =266.67 (900 * 1 /35 ) = 25.71
GSM
GBSS13.0
12000 + 8000 TRX 900 Cellules UMTS
(12000+8000 ) * 1/125 = 96 + 64 = 160 (900 * 1/50) = 18
WRAN
RAN13.0
Nombre total de NE quivalents Type de serveur M2000 recommand
178 4 CPU Sun M4000 ou 4 CPU Sun M5000
292.38 6 CPU Sun M5000
Donnes de performance des NE collectes toutes les 15 Minutes Type de NE Version tendue ou nombre total Nombre de NEs quivalents correspondants lors de la collecte des KPIs (12000 + 8000 ) * 1/75 = 160 + 106.67 =266.67 (900 * 1/30) = 30 Nombre de NE quivalents correspondants lors de la collecte de tous les compteurs (12000 + 8000) * 1/45 = 266.67 + 177.78 = 444.45 (900 * 1/21) = 42.86
GSM
GBSS13.0
12000 + 8000 TRX 900 cellules UMTS
WRAN
RAN13.0
Nombre total de NE quivalents Type de serveur M2000 recommand
296.67 6 CPU Sun M5000
487.31 8CPU Sun M5000
Tableau IV-1: Calcul des lments rseau quivalents
Page 39
c. Le choix du systme de serveurs utiliser Dans le choix du systme M2000 appropri pour linstallation du rseau de supervision, les lments suivants sont pris en considration : 1- Les cots: Ils incluent principalement le cot qui dpend de type du serveur livr et le cout de maintenance. 2- Ltendue du rseau (nombre des NE quivalents) 3- La structure du rseau OM Type de systme de serveur SingleServer HA Cots (Equipements, Maintenance) Cot faible Cout moyen Cout moyen mais besoin de deux sites et des quipements en plus pour assurer le lien entre ces deux sites Cout lev Capacit et tendue de rseau Petit Moyen
Extension Non Supporte lextension
Avantages / Utilis pour le rseau moyen et assure une bonne disponibilit Utilis dans les situations o il y a trop de catastrophes naturelles Utilis dans les rseaux trs grande tendue
Remote HA
Moyen
Supporte lextension Extension facile
SLS
Trs Grand
Tableau IV-2: Tableau comparatif des diffrents systmes de serveurs.
Daprs ce tableau comparatif des diffrents systmes de serveurs, le nombre total des NE quivalents et par considration du rapport Cout/Besoin ainsi que lextension future envisage du rseau MOBILIS ; le systme le plus recommand pour le projet M2000 MOBILIS de Batna est bien le systme HA local, avec le serveur Sun M5000 de 8 CPU. Par consquent, le rseau de serveurs sera configur comme suit :
Page 40
Connexion du matriel Le schma suivant montre les connexions matrielles entre les deux serveurs du systme M2000 HA, les baies de disques et les serveurs Citrix et PRS, avec les noms et les liens des diffrentes interfaces de chaque priphrique en utilisant les commutateurs LAN.
Figure IV-2: Connexions physiques entre Serveurs, Baies de disques et Commutateurs
Planification des adresses IP Lors de lutilisation du serveur M5000 de Sun dans le systme M2000 HA, il est ncessaire de prvoir 16 adresses IP pour le systme M2000. Par dfaut, le mode double niveau de gestion de rseau est support. L o, 9 adresses IP sont utilises en tant que segment d'O&M ou segment public. Les autres 6 adresses IP sont utiliss pour la transmission entre les entits de composant interne, qui utilise ladresse IP du segment du rseau priv interne, Pa r dfaut, le segment est 192.168.X.X/24. En outre, il y a un autre IP 172.16.0.0 /16, principalement utilis pour la gestion de rseau HeartBeat . Les segments du sous-rseau IP, du systme HA bas sur le serveur M5000
Segment
Publique
IP/Masque
10.40.0.0/25
Description
Connecte les lments rseaux NE et postes clients, pour le fonctionnement du rseau daccs Radio RAN . Connecte les ports de maintenance des serveurs, pour l'administration du systme de supervision OM .
Tableau IV-3: Segments du sous-rseau IP
Interne
10.40.0.128/25
Page 41
Le tableau suivant montre les plages du sous-rseau planifies et utilises pour les diffrents types des priphriques, noter que cest le client (MOBILIS) qui prvoit la marge totale des adresses IP pouvant tre utilise dans la planification du projet: IP/Masque Segment Planification Remarque
1~9 10~19 20~49 50~62 64~76 77-126 129~140 201~210 141~200, 240~253 Passerelles, Routeurs Adresse logique des serveurs Pour les ports des serveurs Les postes clients Pour les ports des serveurs(SC) Rserv Passerelles, Routeurs Baies de disques Disk Array Rserv
10.40.0.0/25 (10.40.0.1~10.40.0.126)
Publique
10.40.0.128/25 (10.40.0.129~10.40.0.253.254)
Interne
Tableau IV-4: Plages des sous-rseaux
En utilisant le tableau prcdent, nous pouvons planifier les adresses IP pour les dfrents priphriques constituant le systme M2000 de Batna, comme prsent dans le tableau suivant :
Equipment Nom
Gateway(R1) R2 R3 R4 sys1-osssvr-1 nxge0 bge0 floating nxge0 bge0 floating floating XSCF0 XSCF1 XSCF0 XSCF1 eth0 eth1 prs-svr2 Osssvr1-nxge3 Osssvr2-nxge3 S2600-1-CtrA S2600--1-CtrB S2600-2-CtrA S2600-2-CtrB eth0 eth1 M5000-1 M5000-2 S2600-1 S2600-2 nxge3 nxge3 eth2A eth2B eth2A eth2B
Sous-Module (interface)
IP/Masque
10.40.0.33/27 10.40.0.34/27 10.40.0.35/27 10.40.0.36/27 10.40.0.37/27 10.40.0.38/27 10.40.0.41/27 10.40.0.39/27 10.40.0.40/27 10.40.0.42/27 10.40.0.43/27 10.40.0.44 10.40.0.45 10.40.0.53/27 10.40.0.54/27 10.40.0.55/27 10.40.0.56/27 10.40.0.57 10.40.0.58 10.40.0.59 10.40.0.60 10.40.0.61 10.40.0.62
Segment
AR46 40
M5000-1
M5000-2 M2000 HA System Sun M5000-1 XSCF Sun M5000-2 XSCF
sys1-osssvr-2 sys1-osssvr osssvr1 -XSCF osssvr2-XSCF Citrix-svr1
HP-DL380 antivirus server HP-DL380 PRS server
Interne Interne Interne Interne
Tableau IV-5: Adresses IP des priphriques
Page 42
d. Planification de la Bande Passante Pour que le client puisse superviser ses lments de rseau il a besoin dallouer des bandes passantes de supervision pour chacun de ces quipements. Le tableau en dessous et, en se rapportant au chapitre trois du notre mmoire, rsume les diffrents lments et la bande passante minimale ncessaire pour les voies de supervision:
Type de NE Echelle ou le Nombre Totale Bande passante Demander (kbit/s) 2048 kbit/s * 14 = 28672 kbit/s 2048 kbit/s * 12 = 14336 kbit/s 1 * 64 kbit/s = 64 kbit/s 14 * 64 kbit/s = 896 kbit/s 1 * 16 kbit/s = 16 kbit/s 43984 kbit/s
BSC GU
14 (Contrle : 300 NodeB + 1000 BTS) 12 (Contrle : 667 BTS)
Serveur dapplication Citrix Clients Citrix Serveur PRS
1 14 1
Total de la bande passante ncessaire (kbit/s)
Tableau IV-6: Bande passante pour les diffrentes interconnexions
Page 43
IV.1.3. Prsentation du logiciel M2000 client La figure suivante reprsente linterface graphique du logiciel client M2000 avec ces diffrentes barres constituantes : la barre de menu, la barre des outils, la barre des tats ainsi que sa fentre daffichage des informations systme.
Figure IV-3: Interface graphique GUI du logiciel M2000 client
Fentre daffichage des informations systme : La fentre daffichage des informations systme situe en bas de la fentre du logiciel M2000 client, affiche les messages sur lutilisateur du logiciel et les diffrent temps : de dbut et fin dexcution, des alarme etc. en se rfrant lhorloge du serveur. Barre de menu : affiche le menu principal du systme. Barre doutils : affiche les icnes de raccourci pour les tches principales de fonctionnement. Barre des tats : affiche les informations d'tat actuelles au sujet du systme, tel que l'utilisateur courant et l'adresse IP du serveur connect. a. La Gestion de la topologie La topologie principale La topologie affiche les diffrents quipements et la connexion entre eux sous forme d'arbre et vue de la topologie. Elle fournit galement les fonctions lies la configuration, la gestion d'alarme, et la gestion des performances par le client. L'arbre de navigation du ct gauche affiche tous les quipements impliqus dans la topologie, tels que les NE, sous-rseaux, et de l'architecture hirarchique entre ces quipements.
Page 44
La vue de la topologie du ct droit affiche tous les quipements de la topologie dans le rseau actuel et la relation demplacement reliant ces quipements. Le systme synchronise l'arbre de navigation et la vue de la topologie automatiquement.
Figure IV-4: la Gestion de topologie par le logiciel M2000 client
La figure suivante prsente la topologie du rseau et les diffrents liens dinterconnexion entre la BSC1 d ORAN et les diffrents BTS/NodeB en indiquant le nom de BTS et le lien de transmission.
Figure IV-5: Topologie et liens entre les BTS et la BSC1 d'Oran
Page 45
Ajout dun nouvel lment rseau la topologie existante Pour crer un NE physique sur la topologie existante, on excute les tapes suivantes : Slectionner longlet Topology de la barre de menu puis aller au NEW et ensuite choisir Create Topology Object. La fentre suivante saffiche :
Figure IV-6: Cration dun objet de topologie
Dans cette fentre on doit choisir lquipement ajouter et configurer ses paramtres comme lindique la figure prcdente, puis cliquer sur OK.
b. Gestion des alarmes et des sites distants Catgories d'alarme Les alarmes peuvent tre classes en quatre catgories en se basant sur deux principes : Par le contenu de l'alarme : alarmes d'vnement et alarmes de dfaut Par traitement et habilitation d'alarme : alarmes des fautes historiques et alarmes protges Ces quatre catgories dalarmes sont dcrites comme suit : Les alarmes de dfaut, telles qu'une alarme de dfaut de panneau, sont produites quand les fautes surviennent dans les quipements ou des exceptions se produisent pour introduire des fonctions. Les alarmes de dfaut sont plus graves que des alarmes d'vnement. Des alarmes d'vnement, telles qu'une alarme d'encombrement, sont produites de temps en temps pendant le fonctionnement du matriel. Les alarmes d'vnement indiquent seulement le mode du matriel un certain moment. Le systme produit des alarmes d'vnement priodiquement. Les alarmes d'vnement n'ont pas besoin dintervention manuelle. Les alarmes de dfaut historique se rapportent aux alarmes de dfaut effaces et reconnues.
Page 46
Des alarmes protges sont produites pendant une courte priode. Les alarmes appariant les rgles de corrlation place sur le client M2000 sont les alarmes protges, et elles sont enregistres dans le M2000 protgeant la bibliothque. Les alarmes protges peuvent seulement tre des alarmes de dfaut ou d'vnement. Niveaux de svrit des alarmes Le niveau de svrit dune alarme indique le gravit de lune alarme produite. Tries dans l'ordre dcroissant, les alarmes ont quatre niveaux de svrit : critique, principal, mineur, et avertissement. Les alarmes critiques, telles que l'alarme de dfaut de circuit d'alimentation lectrique ou l'alarme de dfaut d'horloge de sortie, affectent l'exploitation du systme entier. Les alarmes critiques exigent le traitement immdiat quel que soit lheure de la journe. Les alarmes majeures, telles que des alarmes au sujet des fibres dconnectes ou de dfaut de la ligne physique. Ces alarmes peuvent affecter les services, si on nintervient pas temps. Les alarmes mineures, telles que l'alarme pour des erreurs de bit dans quelques lignes physiques, se rapportent aux alarmes communes de mode qui indiquent le statut de fonctionnement des panneaux ou lignes. Les alarmes d'avertissement indiquent les modifications ou les vnements de mode qui n'affectent pas le systme. La figure suivante montre les diffrentes alarmes ainsi que leur svrit, nom, temps de dtection, etc renvoye de la BSC1 dOran et des lments du rseau daccs (BTS/NodeB/PSU) connects avec.
Figure IV-7: Gestion des alarmes par le logiciel M2000 Client
Page 47
Aprs dtection dalarmes et lanalyse de son origine, lquipe dingnieur BSC les traite par ordre de svrit et une maintenance sera effectue soit par mode commande ou par intervention sur site, si elle est ncessaire. La figure qui suit montre ltat dune BTS en faute et en fonctionnement normal aprs avoir trait lalarme :
Figure IV-8: BTS hors service
Figure IV-9:BTS en service
Page 48
IV.2. Application 2: Conception dun logiciel de planification
IV.2.1. Prsentation du logiciel Notre deuxime application consiste concevoir un logiciel qui planifie la capacit et la bande passante du rseau de supervision partir des diffrents lments rseau et leurs paramtres. Le logiciel est un site web dynamique reli une base de donnes MySQL nomme NE qui contient les tables suivantes BSCs, NodeBs, BTSs, Servers comme illustr par le diagramme de classe suivant :
Figure IV-10: diagramme de classe de la base de donnes
Trois mthodes (fonctions) vont tre programmes pour parvenir : Calculer la capacit du rseau en NE quivalent et choisir le type de serveur appropri en utilisant le script PHP Capacityplanif.php - Calculer les bandes passante requise pour les diffrents NE par le script PHP Bandwidthplanif.php La figure suivante schmatise les diffrentes mthodes utilises dans la planification. -
Figure IV-11: Les fonctions de planification
Page 49
IV.2.2. Prsentation de linterface graphique GUI du logiciel Nous avons conu le logiciel en utilisant lditeur Wysiwyg Dreamweaver de Ad obe, les pages web, son programme en XHTML strict v 1.0 avec lusage des feuilles de style CSS. La base de donnes a t cre par le biais des requtes MySQL et en utilisant phpMyAdmin. Les fonctions de planification et les mthodes de base (ajout, suppression, modification) on t programme en langage PHP v5.0 o nous avons utilis laccs par objet MySQL et les classes PDO. De plus notre logiciel offre une fonction de recherche interactive qui a t programme par lusage du JavaScript et AJAX. Les figure qui suit prsente quelques recopies dcran de linterface GUI du logiciel et de lexcution des diffrentes fonctions :
Figure IV-12: Interface graphique GUI du logiciel lments rseau
Figure IV-13: Interface GUI du logiciel planification rseau
Page 50
Aprs avoir cliqu sur le lien Calcul of The Capacity le tableau de la figure suivante saffiche en donnant les rsultats de la planification des lments rseau dj enregistr dans la base de donnes.
Figure IV-14: Rsultat de planification de la capacit
Et en cliquant sur le deuxime lien qui est BandWith Requirement un tableau contenant le dtail du calcul de la bande passante saffiche sur une nouvelle fentre du navigateur.
Figure IV-15: Rsultat du calcul de la Bande passante
Page 51
Conclusion Gnrale
Conclusion gnrale
Les rseaux cellulaires constituent une source de revenus rentables pour les oprateurs de tlcommunications. Les oprateurs toujours attirs par les investissements scuriss optent pour lutilisation du rseau de supervision qui leurs permet le bon fonctionnement dune architecture rseau, et de ragir rapidement en cas de problmes ou pannes, tout en garantissant une bonne qualit de service et une haute fiabilit du rseau. Avertissant l'administrateur en cas de problme, suggrant une volution afin de prvenir une panne, centralisant les donnes sur une console, la supervision fait gagner du temps et est devenue un outil indispensable de la fiabilisation d'un rseau. Cette tude met en lumire la mthode de planification et de conception dun rseau de supervision qui passe par plusieurs tapes : le choix de la topologie, la conception de l'architecture, la gestion des capacits et la planification de la bande passante, le calcul de ltendue du rseau, la planification des adresses IP et le choix du mode de gestion de ce rseau IP. Il existe actuellement des solutions compltes qui grent l'ensemble des aspects de la supervision et permettent d'administrer les diffrents quipements dont lampleur peut tre trs grande. Dans le cas de MOBILIS qui dispose dun nombre d'quipements trs important grer, le serveur M5000 HA et client Citrix, sur lesquels se base le logiciel de supervision iManger2000 sont exigs et permettent de surveiller le rseau de donnes en mode Partial E1, visualiser larchitecture du rseau, relever et analyser les alarmes, dclenche r des alertes en cas de problmes, effectuer des actions en fonction des alarmes. La diversit des solutions de supervision en termes du choix dquipement et leurs capacits, ainsi que le dimensionnement de ce rseau, nous a conduits maitre en ouvre et concevoir un logiciel de planification des rseaux de supervision. La majeure contribution personnelle est llaboration dun document rfrence contenant toutes les tapes quun ingnieur OSS-Wireless pourrait suivre lors du processus de planification et de conception dun systme de supervision, ainsi que le dveloppement dun logiciel de planification bas sur la modlisation des diffrents NE en entits de base de donnes et sur le regroupement de lensemble des tableaux capacits en scriptes squenti els rapide. Nous souhaiterons par cette contribution que notre projet de fin dtudes servira comme rfrence pour les planificateurs (concepteurs), un projet qui pourrait tre complter par les promotions venir, notamment avec la planification pour les quipements du domaine rseau cur et leur inclusion dans ce rseau que nous avons mis en uvre .
Page 52

PFE1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PFE1

Uploaded by

Copyright:

Available Formats

Table des Matires

TABLE DES MATIRES

Projet de fin dtudes 2011/2012

Table des Matires

Projet de fin dtudes 2011/2012

Table des Matires

Projet de fin dtudes 2011/2012

Table des Figures

TABLE DES FIGURES

Projet de fin dtudes 2011/2012

Liste des Tableaux

Projet de fin dtudes 2011/2012

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Gnralits Sur les Rseaux Mobiles

I.2. Evolution des rseaux cellulaires

I.3. Prsentation gnrale du rseau GSM

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Figure I-1: Architecture du rseau GSM

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

I.4. Prsentation du rseau UMTS

La classe A (Conversational), La classe B (Streaming), La classe C (Interactive), La classe D (Background).

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Figure I-2: Architecture gnrale du rseau UMTS

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Figure I-3: lments du rseau daccs UTRAN

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Projet de fin dtudes 2011/2012

Chapitre I : Gnralits Sur les Rseaux Mobiles

Figure I-4: Architecture du rseau Release 99 UMTS / GSM

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

II.3. Le sous-systme de supervision des rseaux cellulaires

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Figure II-1: Interconnexion des diffrents rseaux au M2000

Figure II-2: Position du systme M2000

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Figure II-3: Structure du systme M2000

Ces systmes seront plus dtaills dans le chapitre trois.

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei

Figure II-4: Structure du systme M2000

Projet de fin dtudes 2011/2012

Chapitre II : Etude des Rseaux de Supervisions et du Systme iManager2000 de Huawei