Rapport KKR Conte Nu

Epigraphe
Mmoire de fin dtude dIngnieur de conception en Tlcommunication Par KWATE KWATE Rodrigues
i

J'prouve l'motion la plus forte devant le mystre de la vie.
Le sentiment fonde le beau et le vrai, il suscite l'art et la science.

ALBERT EINSTEIN ALBERT EINSTEIN ALBERT EINSTEIN ALBERT EINSTEIN

Epigraphe
Ddicace

ii

Je ddie ce travail,

Au Dieu tout puissant sans qui rien nest possible

A mes parents,
Papa KWATE Jean Ledoux
et
Maman KWATE ne NZOUGONG Marie
madeleine
qui ont sacrifi des annes de leurs vies pour que je
sois l aujourd'hui.

Ddicace
Remerciements

iii

uil nous soit permis dexprimer notre profonde gratitude et nos sincres
remerciements toutes les personnes qui ont contribu de prs ou de loin
ldification de ce travail. Nos penses vont :
Au Dieu tout puissant qui je rends grce pour ce souffle de vie quil me donne.
Au Directeur de lISS de MAROUA, Pr.Dr.Ing.habil KOLYANG.
Au Directeur gnrale de Camtel, M. NKOTO EMANE David.
Au corps enseignant et administratif de lISS pour leffort fourni dans le progrs de la
jeunesse estudiantine Camerounaise.
Au personnel de Camtel Yaound, et en particulier ceux du Centre des Jonctions
Urbaines de Yaound pour laccueil trs chaleureux quils mont rservs, je pense
M. ONOMO Dieudonn, M. KOUAM Sylvestre, M. OVAMBE Franois
A mes encadreurs, acadmique Dr. VIDEME BOSSOU Olivier et professionnel M.
ONOMO Dieudonn pour leur soutient et les prcieux conseils.
Aux membres du Jury qui ont accept dvaluer ce travail.
A toute la famille KWATE
A toute la famille TAMETHE, pour laccueil et lhbergement Yaound, seul le
tout puissant vous remerciera la juste valeur, je pense ainsi Papa, Maman,
Tantine, Ulrich, Christelle, et surtout mon frre et ami Stphane NZOKOU qui me
permet dintgrer cette famille formidable.
A toute la famille de mon trs cher ami et grand frre M. MHAMED Amin, Sous-
prfet de larrondissement de Makary, je pense galement son papa M.
MOHAMAN Oumate
A tous mes camarades de promotion de Master INFOTEL 2010-2012
A mes camarades FOIDIENG KENTSA Narcisse et MEWE NJOCK Donald
Aux grands frres, Ing. Jean Bosco KIAMPI FOPAK, Ing. Lopold NANA
NGANYEP pour les orientations de tout ordre.
A mes amis et frres denfance du quartier Bepanda 7
cmc
Douala.
Q
Remerciements
Table des Matires

iv

Epigraphe _________________________________________________________________ i
Ddicace __________________________________________________________________ ii
Remerciements ____________________________________________________________ iii
Table des Matires _________________________________________________________ iv
Rsum - Abstract __________________________________________________________ vii
Liste des tableaux _________________________________________________________ viii
Liste des figures et illustrations _______________________________________________ ix
Glossaire __________________________________________________________________ x
Introduction Gnrale ______________________________________________________ 13
Chapitre 1 : Contexte et Problmatique ________________________________________ 15
1.1 Introduction _______________________________________________________________ 15
1.2 Prsentation de la structure daccueil : CAMTEL ___________________________________ 16
1.2.1 Bref Historique ____________________________________________________________________ 16
1.2.2 Les services et produits offerts _______________________________________________________ 17
1.2.2.1 LOffre aux particuliers __________________________________________________________ 17
1.2.2.2 LOffre aux entreprises__________________________________________________________ 18
1.2.3 Infrastructures et Donnes Cls ______________________________________________________ 18
1.2.4 Organigramme Administrative _______________________________________________________ 20
1.3 Problme pos _____________________________________________________________ 22
1.4 Objectifs atteindre _________________________________________________________ 24
1.5 Mthodologie ______________________________________________________________ 25
1.6 Conclusion _________________________________________________________________ 26
Chapitre 2 : Gnralits _____________________________________________________ 27
2.1 Introduction _______________________________________________________________ 27
2.2 Les supports de transmission dans les rseaux Mtropolitains : cas de la Fibre Optique ___ 28
2.2.1 Les trois types de fibre optique ____________________________________________________ 28
2.3 Les techniques de multiplexage ________________________________________________ 30
2.3.1 La hirarchie numrique plsiochrone _________________________________________________ 30
2.3.1.1 Les insuffisances de la PDH ______________________________________________________ 30
2.3.2 La hirarchie numrique synchrone ___________________________________________________ 31
2.3.2.1 Dfinition des lments de la hirarchie synchrone ________________________________ 33
2.3.3 Architecture et quipements dun rseau SDH : Cas CAMTEL ____________________________ 36
2.3.3.1 Architecture _______________________________________________________________ 36
2.3.3.2 Les quipements ___________________________________________________________ 37
2.3.3.3 Les services Vhiculs dans la boucle Mtropolitaine ______________________________ 41
Table des Matires
Table des Matires

v

2.3.4 Les indicateurs de performance dun rseau de transmission ____________________________ 42
2.3.5 Les alarmes dans un rseau SDH ___________________________________________________ 46
2.4 Conclusion _________________________________________________________________ 49
Chapitre 3 : Ralisation de loutil de gestion des services et suivi des performances :
Analyse __________________________________________________________________ 50
3.1 Introduction _______________________________________________________________ 50
3.2 Analyse de loutil de gestion des services et suivi des performances __________________ 51
3.2.1 Rappel du cahier des charges ________________________________________________________ 51
3.2.1.1 Besoins fonctionnels ___________________________________________________________ 51
3.2.1.2 Besoins non fonctionnels ________________________________________________________ 52
3.2.2 Protocole dacquisition des donnes __________________________________________________ 52
3.2.3 Architecture de la plateforme ________________________________________________________ 53
3.2.3.1 Module de rapatriement des donnes_____________________________________________ 54
3.2.3.2 Module de traitement et mise dans la Base de Donnes _______________________________ 54
3.2.3.3 Module de remonte des alarmes par SMS _________________________________________ 55
3.2.3.4 Module de prsentation des donnes aux utilisateurs ________________________________ 55
3.3 Conclusion _________________________________________________________________ 56
Conception et ralisation ____________________________________________________ 57
4.1 Introduction _______________________________________________________________ 57
4.2 Conception de lapplication ___________________________________________________ 58
4.2.1 Diagrammes des Cas dutilisation _____________________________________________________ 58
4.2.2 Diagramme des classes _____________________________________________________________ 61
4.2.3 Diagramme de squences ___________________________________________________________ 64
4.3 Ralisation de lapplication ___________________________________________________ 65
4.3.1 LEnvironnement de travail __________________________________________________________ 65
4.3.2 Les Choix techniques de ralisation ___________________________________________________ 65
4.3.2.1 Mapping objet-relationnel _______________________________________________________ 65
4.3.2.2 Choix du SGBD ________________________________________________________________ 67
4.3.2.3 Choix du langage de programmation ______________________________________________ 67
4.3.2.4 Stratgie de remonte automatique des alarmes par SMS _____________________________ 67
4.4 Conclusion _________________________________________________________________ 69
Chapitre 5 : Rsultats et Commentaires ________________________________________ 70
5.1 Introduction _______________________________________________________________ 70
5.2 Quelques rsultats __________________________________________________________ 71
5.2.1 Lot 1 : Rapatriement des fichiers _____________________________________________________ 71
5.2.3 Lot 2 : Acquisition des donnes et chargement dans la base de donnes _____________________ 73
5.2.3 Lot 3 : Remonte automatique des alarmes par SMS _____________________________________ 73
5.2.4 Lot 4 : Linterface Client et ses diffrentes fonctionnalits _________________________________ 75
5.3 Conclusion _________________________________________________________________ 82
Conclusion et Perspectives ___________________________________________________ 84
Table des Matires

vi

1. ___________________________________________________________________________ 84
Bibliographie _______________________________________________________________ a
Annexes ___________________________________________________________________ b
Annexe A : Photos dquipements dun rseau SDH et Fibre Optique ______________________ b
Annexe B : Synoptique dune liaison BSC-BTS _________________________________________ b
Annexe C : Code denvoi de SMS ____________________________________________________ c
Annexe D : Quelques Commandes AT ________________________________________________ c

Rsum - Abstract

vii

Rsum
objectif de ce mmoire est de concevoir et raliser un outil pour le suivi des
performances des liaisons Optiques SDH dans le cadre de la boucle
mtropolitaine de Yaound.
Pour atteindre cet objectif, nous avons dabord commenc par tudier les
techniques de multiplexage, SDH et PDH, ainsi que la transmission par Fibre optique.
Ensuite, nous avons prsent des rappels sur les indicateurs de performance. En fin,
nous avons tudi loutil (TNMS-Tlcommunication Network Management System)
utilis par la Cameroon Tlcommunication (CAMTEL) dans la boucle
mtropolitaine de Yaound. Cette tude nous a permis montrer ses faiblesses et le
besoin dun outil complmentaire qui apporte dautres fonctionnalits en termes de
gestion des services et de suivi des performances. Nous avons ralis, aprs une tape
danalyse et de conception, loutil de gestion METROPERF_CJU V1.0. Loutil
permet la gestion des services, le rapatriement automatique et priodique des logs et le
suivi des performances.
Mots cls : Technique de multiplexage (PDH, SDH), Supervision, optimisation,
Indicateurs de performance

Abstract
he objective of this thesis is to design and implement a tool for monitoring the
performance of Optical SDH links within the loop Metropolitan Yaound.
To achieve this goal, we began by studying the multiplexing techniques, PDH
and SDH and optical fiber transmission. Then, we presented reminders on
performance indicators. In the end, we studied the tool (TNMS-Telecommunications
Network Management System) used by the Cameroon Telecommunications
(CAMTEL) in the loop Metropolitan Yaound. This study allowed us to show
weaknesses and the need for a complementary tool that provides additional
functionality in terms of service management and performance monitoring. We
realized after a stage of analysis and design, management tool METROPERF_CJU
V1.0. The tool allows the management of services, and automatic extraction of
periodic logs and performance monitoring.
Keywords: Technical multiplexing (PDH, SDH), Supervision, optimization,
performance indicators
L
T
Rsum - Abstract
Liste des Tableaux

viii

Tableau 1: Les capacits daccs Internet exploites par Camtel. _____________________________________ 20
Tableau 2: Les diffrents containers Cn _________________________________________________________ 33
Tableau 3: Les cartes du HIT 7070 ______________________________________________________________ 40
Tableau 4: Les Cartes du HIT 7060 _____________________________________________________________ 40
Tableau 5: Caractristiques cibles des paramtres d'erreur. Rf [5] ___________________________________ 44
Tableau 6: Les types d'vnement _____________________________________________________________ 47
Tableau 7: Svrit des alarmes _______________________________________________________________ 48

Liste des tableaux
Liste des figures et illustrations

ix

Figure 1: le cble SAT3/WASC/SAFE (source : www.safe-sat3.co.za, Octobre 2003) ______________________ 16
Figure 2: Organigramme de CAMTEL ___________________________________________________________ 21
Figure 3: Principe de rflectomtrie ____________________________________________________________ 22
Figure 4: Propagation de la lumire dans les trois types de fibre _____________________________________ 29
Figure 5: Les dbits plsiochrone dfinis par l'UIT. Ref.[3] __________________________________________ 30
Figure 6: Principe de Justification dans le SDH ____________________________________________________ 32
Figure 7: Construction d'un Conteneur Virtuel. Ref [3] _____________________________________________ 33
Figure 8: Gestion du VCn dans un rseau SDH. Ref [3] _____________________________________________ 33
Figure 9: Structure du multiplexage Synchrone. Ref [4] ____________________________________________ 34
Figure 10: Limite des RS, MS, VC sur le rseau SDH. _____________________________________________ 35
Figure 11: Organisation de la trame STM1 _______________________________________________________ 36
Figure 12: Boucle Mtropolitaine SDF/FO Siemens de Camtel Yaound ________________________________ 37
Figure 13: Principe d'un ADM _________________________________________________________________ 38
Figure 14: Exemple d'un rseau SDH. Ref [4] _____________________________________________________ 38
Figure 15: diagramme illustrant la dtection d'anomalies, de dfauts ES et SES. Ref [5] __________________ 46
Figure 16 Architecture de la plateforme METROPERF_CJU __________________________________________ 53
Figure 17: Organigramme du module Client _____________________________________________________ 54
Figure 18: Diagramme de Cas d'utilisation Gnrale _______________________________________________ 59
Figure 19: Diagramme de cas d'utilisation pour la consultation de l'tat du rseau ______________________ 60
Figure 20: Diagramme de cas d'utilisation pour la gestion des utilisateurs et du serveur __________________ 61
Figure 21: Diagramme de classe _______________________________________________________________ 63
Figure 22: Rapatriement des fichiers et insertion dans la BD ________________________________________ 64
Figure 23:Architecture de modlisation sans ORM ________________________________________________ 66
Figure 24: Architecture de modlisation avec ORM ________________________________________________ 66
Figure 25: Configuration du serveur ___________________________________________________________ 71
Figure 26: Page d'accueil du serveur lorsqu'il est lanc _____________________________________________ 71
Figure 27: rpertoire de Rapatriement et traitement de logs (Alarmes et PM) __________________________ 72
Figure 28: Exemple de Fichier d'alarme _________________________________________________________ 72
Figure 29: Exemple de Fichier de PM ___________________________________________________________ 73
Figure 30: Quelques tuples de la table equipement_alerte _______________________________________ 73
Figure 31: Configuration de la remonte des alarmes par SMS/MAIL _________________________________ 74
Figure 32: Une remonte d'alarme par SMS _____________________________________________________ 74
Figure 33: Page D'authentification _____________________________________________________________ 75
Figure 34: interface d'accueil _________________________________________________________________ 76
Figure 35: Performances des quipements _______________________________________________________ 77
Figure 36: Courbes de performance ESR du port 1_101_1 de lADM_CTN pendant une priode _____________ 78
Figure 37: courbes disponibilit d'un port pendant une priode ______________________________________ 78
Figure 38: courbes de performance SESR pendant une priode_______________________________________ 79
Figure 39: Alarmes reus _____________________________________________________________________ 80
Figure 40: Rapport de Capacit des ADMs _______________________________________________________ 81
Figure 41: Graphe capacit des ADMs du CJUY ___________________________________________________ 81
Figure 42: SURPASS hiT 7070 __________________________________________________________________ b
Figure 43: Tiroir Optique ______________________________________________________________________ b
Figure 44: Liaison BTS-BSC_____________________________________________________________________ b
Liste des figures et illustrations
Glossaire

x

A
ADM
Add and Drop Multiplexer (Insertion/Extraction de signaux
numriques)
ADSL
Asymmetric Digital Subscriber Line (rseau de raccordement
numrique asymtrique)
Alignement
(Justification)
Opration permettant de prserver lintgralit et la visibilit des
affluents
ATM
Asynchronous Transfer Mode (Mode de transfert asynchrone)
B
BTS
Base Terminal Station (Station de base)
C
CAMTEL
Cameroon Telecommunications
CCITT
Consultative Commitee for International Telegraphe and
Telephone (Comit Consultatif International Tlgraphique et
Tlphonique)
CDMA
Code Division Multiple Access
CTN
Centre Transmission Numrique
F
FEBE
Far End Block Error (nombre de blocks reus errons)
FERF
Far End Remote Failure dfaut l'extrmit distante
FTP
File Transfert Protocol, Protocole de manipulation et de transfert
de fichiers distance.
I
INFOTEL
INFOrmatique et TELcommunications
ISS
Institut Suprieur du Sahel
M
MSOH
Multiplex Section OverHead (Surdbit de section de multiplexage)
N
NG-SDH
Next Generation Synchronous Digital Hierarchy
O
ORM
Object Relational Mapping
P
PDH
Plsiochrone Digital Hierarchy (Hirarchie numrique
plsiochrone), Deux signaux sont dits plsiochrones lorsque leurs
instants significatifs correspondants se prsentent la mme
cadence nominale
POH
Path Other Head (Surdbit de gestion)
R
RNIS
Rseau Numrique Intgration de Services
RSOH
Regenerator Section OverHead (Surdbit de section de
Glossaire
Glossaire

xi

rgnration)
RTC
Rseau Tlphonique Commut
S
SDH
Synchronous Digital Hierarchy (Hirarchie numrique synchrone)
SGBD
Systme de Gestion de Base de Donnes
SMS
Short Message Service
SONET
Synchronous Optical NETwork (Rseau Optique Synchrone)
STM
Synchronous Transport Module (Module de transport synchrone)
T
TNMS
Tlcommunication Network Management System
U
UIT-T
Union Internationale des Tlcommunications Bureau de la
normalisation des tlcommunications
UML
Unified Modeling language
V
VSAT
Very Small Aperture Terminal
Introduction Gnrale

12

Introduction
gnrale
Introduction Gnrale

13

es rseaux de transmission dfinissent les chemins permanents permettant de
transporter de manire transparente dun point un autre les services Voix,
Donnes ou Vido. Les nuds et les liens que nous y trouvons sont utiliss pour crer
les conduits avec une bonne qualit de service tout en surveillant cette qualit. Les
technologies de multiplexage hirarchique sont utilises en transmission pour viter de
rserver une ressource physique un utilisateur et parvenir une gestion plus
modulaire de la capacit. Les problmes de propagation du signal dans un guide
donde et bien dautres vnements perturbateurs dus au fonctionnement des
quipements provoquent une dtrioration de la qualit du signal. Cette dtrioration
peut aller jusqu la rupture totale des liaisons.
Les tches de maintenance prventive dans le rseau de transmission permettent
danticiper sur les incidents (lis aux quipements et conduits) qui pourraient entraner
ces perturbations du trafic et donc un grand dsarroi chez les clients. La gestion des
performances (Performance Monitoring) du rseau de transmission permet de mesurer
et quantifier la qualit de la transmission pendant une priode donne. Elle permet
loprateur de sassurer que les indicateurs de qualit (secondes errones, secondes
indisponibles, Blocs errons, taux derreur ) sur chaque conduit ou sur le rseau
globalement respectent les objectifs dfinis par la norme.
Cest dans cet ordre dides que sinscrit ce projet de fin dtudes. Projet que
jai eu loccasion de mener au sein du Centre des Jonctions Urbaines (CJU) de
Yaound de lentreprise Cameroon Telecommunications. Le travail faire consiste
concevoir et mettre en uvre un outil de gestion des services et de suivi des
performances dans un rseau de transmission : Application la boucle SDH/FO
de Camtel Yaound.
Le prsent mmoire est organis en cinq chapitres. Dans le premier chapitre,
nous parlerons du cadre de travail et du sujet, nous y prsenterons galement
lenvironnement du stage ainsi que le sujet traiter. Le second chapitre sera consacr
aux rappels sur les techniques de multiplexage PDH et SDH, la Fibre Optique et les
indicateurs de performance dans un rseau de transmission SDH. Le troisime chapitre
L
Introduction Gnrale
Introduction Gnrale

14

sera rserv lanalyse de la plateforme dvelopper, nous y prsenterons le cahier
des charges, les protocoles dacquisition des donnes et larchitecture de notre systme
ainsi que le diagramme des cas dutilisation. Le quatrime chapitre sintressera la
conception et la ralisation de loutil. Enfin, le dernier chapitre concerne la
prsentation des rsultats obtenus et commentaires.

Chapitre 1 : Contexte et Problmatique
Aperu et Introduction

15

Aperu
Chapitre 1 : Contexte et Problmatique ________________________________________ 15
1.1 Introduction _______________________________________________________________ 15
1.2 Prsentation de la structure daccueil : CAMTEL ___________________________________ 16
1.2.1 Bref Historique ____________________________________________________________________ 16
1.2.2 Les services et produits offerts _______________________________________________________ 17
1.2.2.1 LOffre aux particuliers __________________________________________________________ 17
1.2.2.2 LOffre aux entreprises__________________________________________________________ 18
1.2.3 Infrastructures et Donnes Cls ______________________________________________________ 18
1.2.4 Organigramme Administrative _______________________________________________________ 20
1.3 Problme pos _____________________________________________________________ 22
1.4 Objectifs atteindre _________________________________________________________ 24
1.5 Mthodologie ______________________________________________________________ 25
1.6 Conclusion _________________________________________________________________ 26

1.1 Introduction
Ce chapitre nous plonge dans le contexte de ltude de notre projet et reprend
les diffrentes parties qui seront dveloppes tout au long de notre mmoire. Une
attention particulire sera porte sur la mthodologie et les rsultats qui constituent
notre apport personnel.
Chapitre Chapitre Chapitre Chapitre
1
Prsentation de la structure daccueil : CAMTEL

16

1.2 Prsentation de la structure daccueil : CAMTEL
1.2.1 Bref Historique
amtel est ne en 1998 de la transformation de la direction des
tlcommunications (Ministre des postes et tlcommunications) en
socit anonyme laquelle s'ajouta l'entreprise publique Intelcam, alors en charge des
communications tlphoniques internationales. La filiale de tlphonie mobile,
Camtel-Mobil, fut vendue l'oprateur de tlcommunication MTN en fvrier
2000.Ces changements sont intervenus lors de la libralisation du secteur des
tlcommunications au Cameroun.
En 2005, la socit a lanc le service de tlphonie Mobile CT-Phone, base sur
la technologie CDMA. Au cours de lanne 2009, elle a enfin acquis une licence
GSM (principal attrait des investisseurs). Pour ce qui est de la fourniture daccs
Internet, aprs larrimage du Cameroun au rseau transcontinental du systme
SAT3/WASC/SAFE (South Atlantic cble N3/West African Submarine Cable/South
Africa Far East) en 2003, CAMTEL a largement densifi son offre Internet aussi bien
aux particuliers quaux entreprises, parmi lesquelles de nombreux fournisseurs
daccs.

Figure 1: le cble SAT3/WASC/SAFE (source : www.safe-sat3.co.za, Octobre 2003)
Avec le dploiement de la fibre optique sur le territoire national (plus de 5600
km de longueur prvu), CAMTEL compte capitaliser sur cette dernire pour raliser
C

17

une dorsale nationale de transmission appele Backbone qui sera utilis par tous
les oprateurs des tlcommunications et surtout qui lui facilitera la mise en place de
ses rseaux dentreprises.
1.2.2 Les services et produits offerts
Lentreprise CAMTEL est loprateur public de tlphonie au Cameroun. Au
rang des services quil fournit, on peut citer principalement :
La tlphonie fixe (Avec ou sans fil)
La tlphonie mobile type CDMA (Offre City Phone )
Internet (par Dial-up, ADSL, VSAT, Wireless )
Les rseaux dEntreprises (lignes spcialises, VSAT, )
Ces principaux services sont offerts sous deux formes : loffre aux particuliers
et loffre aux entreprises.
1.2.2.1 LOffre aux particuliers
Loffre aux particuliers regroupe principalement trois services : la tlphonie,
laccs Internet et les services Internet.
La tlphonie
Le service de tlphonie regroupe quatre principales offres :
Le fixe filaire
Le CT Phone
La tlcopie (Fax)
Le tlphone de masse
Laccs Internet
Le rseau Internet est accessible par deux nuds d'accs au Backbone
international Douala et Yaound travers le cble sous-marin SAT3 pour un dbit
total de 933Mb/s (soit 622Mb/s Douala et 311Mb/s Yaound).
Ce dbit est appel crotre dans un futur proche compte tenu de la demande
sans cesse croissante. Les principaux moyens daccs Internet offerts par CAMTEL
aux particuliers sont : le RTC, lADSL, le CT Phone, le RNIS et le Wireless.
Les cartes prpayes s'acquirent par achat direct auprs des distributeurs ou
des Agences Commerciales Camtel. Elles se prsentent sous quatre formes : Easy
Recharge, Easy call, E@sy Net et A puce.

18

Les services Internet
Les services Internet offerts sont de quatre types :
Lallocation des noms de domaine (.tv, .org, .biz, .net, )
La cration des sites Internet
Lhbergement des sites Internet
E-mail perso
Tous ces services constituent les offres proposs aux particuliers.
1.2.2.2 LOffre aux entreprises
Les offres aux entreprises sont catalogues comme suit :
Solution Tlphonie fixe
Offres prfrentielles
Numro vert
Solution de Mobilit
Easy Pro
Business Privilege
Solution Internet Pro
LS filaires (Liaisons Spcialises) Urbaines et Interurbaines
Liaison sans fil
ADSL haut dbit
Sites et applications web
Hbergement professionnel
Nom de domaine
Messagerie d'entreprise
E-publicit
Rseaux d'Entreprise
LS Nationales
LS Internationales
Faisceau hertzien (VSAT, )
1.2.3 Infrastructures et Donnes Cls
Pour faire face aux nombreux besoins des particuliers comme les
entreprises, la CAMTEL est dote de :

19

- 47 centraux tlphoniques entirement numriques et autant de rseaux locaux
pour un parc de 153.818 lignes tlphoniques en rseau de cble et 140.946 en
commutation. Le programme de modernisation des infrastructures prvoit l'extension
de tous les centraux tlphoniques.
- 76 concentrateurs permettant d'offrir la tlphonie rurale autant de localits pour
une capacit de 10940 lignes.
- Un rseau national de transmission en numrisation progressive, compos d'une
cinquantaine de centres de transmission et d'environ 75 stations relais pour une
couverture presque totale du pays.
- 3 centres de tlcommunications par satellite Bpanda, Zamengo et Garoua
qui comptent parmi les plus modernes au monde et disposent de stations terriennes
gres par ordinateurs, de deux autocommutateurs numriques pour le transit
international et un hub pour les systmes VSAT. Le Cameroun est ainsi reli au reste
du monde par numrotation directe automatique.
- 2 autocommutateurs lectroniques qui assurent le trafic tlex national et
international, auxquels sont relis 109 centres d'exploitation tlgraphique.
- SAT3
- Fibre optique
Enfin, CAMTEL s'est associe aux organismes INTELSAT et INMARSAT
pour offrir grce leurs satellites des solutions de transmission de la voix, des
donnes, et des images par VSAT ou par petites units portatives.

Liaisons daccs
Satellite

Fibre Optique SAT-3 Anne
1998 256Kb/s 0
2000 5Mb/s 0
2001 8Mb/s 0
2002 8Mb/s 0
2003 8Mb/s 34 Mb/s
2004 4Mb/s 34 Mb/s
2005 4Mb/s 34Mb/s
2006 0 155 Mb/s

20

2007 0 310 Mb/s
2008 0 455 Mb/s
2009 0 933Mb/s
Tableau 1: Les capacits daccs Internet exploites par Camtel.
Ainsi, le dbit daccs linternational est pass de 8Mbps un dbit de
933Mbps entre 2003 et 2009, grce la Fibre Optique SAT3.
Actuellement, CAMTEL ne dispose pas d'autres systmes de cble de
racheminement du trafic en cas de panne sur la liaison SAT-3. Pour viter des
incidents comme celui vcu en novembre 2007 (coupure de la fibre sous-marine
SAT3), le Cameroun a uvr pour une solution de backup en s'inscrivant comme
membre du projet WAFS (Cble sous-marin de la cte Ouest de l'Afrique).
Pour ce qui est des rseaux dentreprises, grce une infrastructure fortement
dploye lchelle nationale (des boucles mtropolitaines optiques largement
densifies notamment dans les villes de Douala et Yaound et de grandes boucles
interurbaines) CAMTEL est le principal oprateur au Cameroun actuellement offrant
ce type de services aux entreprises ou organisations ayant des besoins de raccordement
leurs diffrents sites. Pour cette offre, son principal client reste lEtat camerounais
(interconnexion des ministres, dlgations rgionales, ).
1.2.4 Organigramme Administrative
Place sous la tutelle du MINPOSTEL (Ministre des Postes et
Tlcommunications), CAMTEL est dote d'un Conseil d'Administration compos
comme suit :
Un prsident ;
Six membres reprsentant l'tat du Cameroun;
Un membre reprsentant le personnel ;
Un membre reprsentant la Commission Technique de Privatisation
et des Liquidations.
Ce conseil se prononce rgulirement (en conseils ordinaires et extraordinaires)
sur les grandes orientations stratgiques de l'entreprise. La gestion quotidienne de la
socit est assure par un Directeur Gnral assist de deux Directeurs Gnraux
adjoints.

21

Figure 2: Organigramme de CAMTEL
Problme pos

22

1.3 Problme pos
Il ressort de la phase dimprgnation de notre stage un certain nombre de
constats :
La cration des services, ou encore lenregistrement des quipements se
faisait uniquement de faon manuelle dans des registre.
La maintenance dans le centre est essentiellement curative et base sur
deux principes : la boucle et la rflectomtrie.
La boucle
Ce principe consiste raliser des boucles de proche en proche travers les
rpartiteurs afin de pouvoir dceler exactement sur quelle portion de la liaison il ya
problme.
La rflectomtrie
Par rapport la rflectomtrie, il nous permet de mesurer ltat dune liaison et
de ressortir des informations telles que le taux derreurs, le niveau du signal en
mission et en rception. Cela nous permet galement en cas de dfaillance
(gnralement coupure de la fibre optique) de savoir quelle distance cela sest
produit. Son principe est rsum sur la figure 3 suivante.

Figure 3: Principe de rflectomtrie
Problme pos

23

On constate galement que les alarmes mettent parfois du temps avant de
parvenir aux techniciens du centre. Ceci peut causer un certain manque
de promptitude et defficacit dans les interventions. Il faut surtout
prciser un dfaut darchivage des alarmes.
Au vu et su de tous ces constats, notre problmatique peut se rsumer en cinq
questions fondamentales qui prsentent les manquements du systme actuel :
Comment automatiser les oprations de gestion des services (cration,
modification, visualisation, suppression )?
Comment rapatrier (protocole) sur un poste dexploitation les logs (alarmes et
performances) gnrs depuis les quipements vers le serveur TNMS ?
Comment surveiller de faon automatique lactivit du rseau, analyser sa
performance (quipements et surtout les conduits vhiculant des services
divers) et signaler les dpassements de seuils ?
En dautres termes comment faire des prvisions sur ltat de fonctionnement
des quipements partir des statistiques de progression lies aux
performances?
Comment remonter une alarme jusquau tlphone portable dun technicien du
centre ?
Objectifs atteindre

24

1.4 Objectifs atteindre
Les objectifs fixs dans le cadre de ce projet consistent proposer une solution
logicielle permettant de :
Communiquer de faon journalire et priodique avec le serveur de
supervision TNMS pour rapatrier automatiquement les logs dalarmes et de
performances.
Analyser de faon priodique les logs rapatris afin de produire des statistiques
diverses : variation des indicateurs de performances, listing des alarmes dans un
intervalle de temps donn pour un quipement..... Ceci dans loptique de mettre
en place une politique de maintenance prventive et de fournir aux techniciens
des pistes doptimisation
Fournir des interfaces permettant dautomatiser la gestion des services, des
conduits, des fibres et des quipements via des oprations de cration,
modification, suppression, consultation. Ceci dans le but de produire galement
des rapports dtat ou doccupation du rseau et des matrices de trafic qui
actuellement se font manuellement.
Dclencher des alertes SMS vers les techniciens du centre en cas de
dfaillances majeures dans le rseau ceci dans loptique de rduire le temps de
raction face un problme, car les problmes nous sont gnralement signals
par les responsables des services que nous transportons (Cas du BSS qui nous
informe gnralement des BTS qui ne fonctionnement pas).
Sauvegarder toutes ces informations dans une base de donnes pour des
besoins futures.

Approche ou Mthodologie

25

1.5 Mthodologie
Au vue de tout ce qui a t prsent dans le contexte, la problmatique et les
objectifs, nous avons entrepris une dmarche mthodologique qui stend sur les
quatre grandes tapes rsumes comme suit :

Etape 1
Etudier de la politique de maintenance et doptimisation existante.
Etape 2
Etudier globalement les rseaux de transmission et particulirement
ceux a base des technologies hirarchie numrique synchrone.
Etudier les indicateurs de performance dans les rseaux de
transmission numrique.
Etape 3
Mettre en place dun outil qui permetttra d'automatiser :
la Gestion des services, quipements, conduits, et fibres.
la Gestion des performances avec la possibilit de produire des
statistiques et des rapports.
la Gestion des alarmes avec la possibilit de remonte automatique des
alarmes par SMS.
Etape 4
Effectuer des tests pour la validation de l'application.
Formuler les perspectives.
Chapitre 2 : Gnralits
Conclusion

26

1.6 Conclusion
Dans ce premier chapitre, nous avons prsent le cadre de ce projet de fin
dtudes ainsi que le sujet traiter qui est le dveloppement dun outil pour la
gestion des services et le suivi des performances des liens Optiques SDH . Dans
le chapitre suivant il sera premirement question dtudier le support de transmission
fibre optique. Deuximement dtudier les techniques de multiplexage PDH, SDH.
Troisimement de passer en revue la topologie, les indicateurs de performances et la
supervision dans un rseau SDH.


27

Aperu
Chapitre 2 : Gnralits _____________________________________________________ 27
2.1 Introduction _______________________________________________________________ 27
2.2 Les supports de transmission dans les rseaux Mtropolitains : cas de la Fibre Optique ___ 28
2.2.1 Les trois types de fibre optique ____________________________________________________ 28
2.3 Les techniques de multiplexage ________________________________________________ 30
2.3.1 La hirarchie numrique plsiochrone _________________________________________________ 30
2.3.1.1 Les insuffisances de la PDH ______________________________________________________ 30
2.3.2 La hirarchie numrique synchrone ___________________________________________________ 31
2.3.2.1 Dfinition des lments de la hirarchie synchrone ________________________________ 33
2.3.3 Architecture et quipements dun rseau SDH : Cas CAMTEL ____________________________ 36
2.3.3.1 Architecture _______________________________________________________________ 36
2.3.3.2 Les quipements ___________________________________________________________ 37
2.3.3.3 Les services Vhiculs dans la boucle Mtropolitaine ______________________________ 41
2.3.4 Les indicateurs de performance dun rseau de transmission ____________________________ 42
2.3.5 Les alarmes dans un rseau SDH ___________________________________________________ 46
2.4 Conclusion _________________________________________________________________ 49

2.1 Introduction
Ce Chapitre dcrit les gnralits en relation avec notre projet. En effet il sera
tout dabords question de prsenter le support de transmission fibre Optique, en suite
de mettre en vidence les techniques hirarchie numrique plsiochrone et
synchrone, enfin de ressortir les indicateurs de performances et les alarmes dans les
rseaux de transmission.

2
Les supports de transmission dans les rseaux Mtropolitains : cas de la Fibre Optique

28

2.2 Les supports de transmission dans les rseaux
Mtropolitains : cas de la Fibre Optique
Le rseau de transmission SDH de CAMTEL utilise comme support physique
pour relier ses MIE des fibres optiques monomodes. La fibre optique est un support
physique de transmission permettant la transmission de donnes haut dbit grce
des rayons optiques. La fibre optique est constitue de trois lments :
Le cur, partie de la fibre optique servant la propagation des rayons
lumineux ;
La gaine optique, entourant le cur, constitu dun matriau dont lindice de
rfraction est infrieur celui du cur, de telle manire confiner la
propagation des rayons lumineux ;
Le revtement de protection, charg de protger la gaine optique des
dgradations physiques.
2.2.1 Les trois types de fibre optique
La fibre saut d'indice constitue d'un cur et d'une gaine optique en verre de
diffrents indices de rfraction. Cette fibre provoque de par l'importante section
du cur, une grande dispersion des signaux la traversant, ce qui gnre une
dformation du signal reu. Elle est gnralement utilise pour de courtes
distances (LAN et MAN) tout comme la fibre gradient dindice. Lmetteur
utilis ici est la LED.
La fibre gradient d'indice dont le cur est constitu de couches de verre
successives ayant un indice de rfraction proche. On s'approche ainsi d'une
galisation des temps de propagation, ce qui veut dire que l'on a rduit la
dispersion nodale. Bande passante typique 200-1500Mhz par km. C'est ce type
de fibre qui est utilis l'intrieur des btiments de l'Universit (62.5/125) et
entre certains sites desservis par les PTT (50/125).
La fibre monomode dont le cur est si fin que le chemin de propagation des
diffrents modes est pratiquement directe. La dispersion nodale devient
quasiment nulle. La bande passante transmise est presque infinie (> 10Ghz/km).
Cette fibre est utilise essentiellement pour les sites distance (rseaux MAN et
Les supports de transmission dans les rseaux Mtropolitains : cas de la Fibre Optique

29

WAN). Le petit diamtre du cur (10um) ncessite une grande puissance
d'mission, donc des diodes au laser qui sont relativement onreuses.

Figure 4: Propagation de la lumire dans les trois types de fibre
Le rseau de transmission SDH utilise comme support physique pour relier ses
MIE des fibres optiques monomodes, correspondant la recommandation G.652 de
lIUTT. La fibre optique utilise les longueurs donde autour de 1300nm et 1550nm.

Les techniques de multiplexage

30

2.3 Les techniques de multiplexage
Le multiplexage consiste faire passer plusieurs affluents sur un mme tronon
de rseau. On distingue ici deux techniques de multiplexage :
2.3.1 La hirarchie numrique plsiochrone
La premire technique de multiplexage numrique utilise fut la technique
Plesiochronous Digital Hierarchy (PDH). Dans cette technique, les signaux
lmentaires sont multiplexs sans tenir compte de leur ordre darrive. Le signal haut
dbit obtenu est donc un mlange non ordonn de signaux bas dbit ; il est impossible
didentifier directement un signal bas dbit dans le train haut dbit. Pour retrouver le
signal bas dbit, on est donc oblig deffectuer les tapes inverses du multiplexage
(dmultiplexage) ce qui est coteux en quipement et en probabilit derreurs
matrielles. Cest une limitation forte de cette technique.
Dans ce mode, chaque niveau sont insrs :
Un mot de verrouillage de trame,
Des bits de justification de niveau de multiplexage,
Des signaux de service.
La technique est transparente , cest--dire quelle ne fait pas dhypothse
sur la trame et la nature du signal.
2.3.1.1 Les insuffisances de la PDH
Cette technique, par ailleurs prouve, comporte cependant les limitations indiques
par la Figure 5

Figure 5: Les dbits plsiochrone dfinis par l'UIT. Ref.[3]
En ce qui concerne les dbits, les dbits maxima normaliss se limitent 140 Mbit/s.

31

La technique PDH est une technique de point point, et non une technique de
rseau et qui conduit en outre dmultiplexeur chaque point de service les
dbits lmentaires pour les extraire, ce qui se traduit en des appareillages
compliqus et coteux,
La technique PDH ne permet pas une organisation du rseau en anneau
permettant dobtenir des disponibilits de service importantes,
La technique PDH ne prvoit pas lexistence de canaux de gestion et ne permet
pas une centralisation de lexploitation dun rseau national
La technique PDH ne permet pas linterconnexion optique entre interface
provenant de constructeurs diffrents, car elle est sur 3 normes diffrentes
(AINSI aux USA, CEPT en EUROPE, et celle du Japon)
2.3.2 La hirarchie numrique synchrone
Le rseau de transmission numrique actuel tait bas sur lutilisation de la
hirarchie numrique plsiochrone. Cette technique sest montre, au fil des annes,
quelque peu limite. En effet, lvolution des dbits des diffrents services, les besoins
en flexibilit du rseau de transmission, la ncessit damliorer les fonctions
dexploitation et de maintenance, laugmentation continue de la capacit de
transmission sur fibre optique et le besoin dinterconnexion entre oprateurs des
dbits levs et normaliss. Tous ces lments ont montr les limitations de la
hirarchie actuelle et ont conduit la normalisation de la hirarchie numrique
synchrone (SDH). Celle-ci, fonde sur les concepts de Synchronous Optical NETwork
(SONET), proposs par Bellcore en 1985, constitue une volution importante des
rseaux de transmission. Les travaux de normalisation ont t lancs en 1986 au
CCITT. En 1988, un premier consensus permettait de dfinir les grands principes de
base de la norme SDH. Les travaux nont pas cess depuis et se poursuivent
aujourdhui en particulier sur les architectures du rseau, sa modlisation et sa gestion.
La SDH introduit de nouvelles possibilits dans les rseaux de transmission :
Souplesse accrue par la possibilit dextraire ou dinsrer directement un signal
constituant du multiplex de ligne.

32

Facilits dexploitation et de maintenance : des dbits importants sont rservs
ces fonctions.
Possibilit dvolution vers des hauts dbits : les trames synchrones haut dbits
sont construites par multiplexage synchrone de lentit de base. Cette entit de
base dfinit implicitement toutes les trames haut dbit, la limitation nest plus
que technologique.
Interconnexion de systmes haut dbit facilite par la normalisation de la
trame de ligne et des interfaces optiques correspondantes.
Architectures de rseaux assurant la scurisation contre les dfauts de ligne ou
dquipement.
La modularit des quipements SDH est plus adapte aux progrs de la
technologie des quipements plsiochrone.
Les lments de base du multiplexage SDH
Les trains de signaux incorpors dans la trame synchrone, savoir 1,5 ou 2
Mbit/s, admis cependant dans cette trame avec des dphasages dus aux temps de
propagation ou aux dphasages entre horloges. La trame comporte 270 colonnes de 9
octets, expdis toutes les 125s, soit 8000 fois par seconde ou un dbit de 155,520
Mbit/s. 9 colonnes doctets sont rserves la gestion de la section de multiplexage
qui a donc une charge utile (payload) de 2349 octets (9 lignes et 261 colonnes).
Loriginalit de la technique SDH est lutilisation de pointeurs et de la
justification positive, ngative ou nulle, permettant de prserver lintgralit et la
visibilit des affluents. Le pointeur repre chaque instant ladresse de linformation
utile dans la trame STMn.

Figure 6: Principe de Justification dans le SDH

33

2.3.2.1 Dfinition des lments de la hirarchie synchrone
Le conteneur Cn, le conteneur virtuel VCn
Les signaux plsiochrones sont insrs dans un conteneur dsign selon sa
charge comme nous montre le Tableau suivant:
Dnomination Dbit (Mbits/s)
C11 1,544
C12 2,048
C2 6
C3 34,368 ou 44,736
C4 139,264
Tableau 2: Les diffrents containers Cn
Comme illustre la Figure 7, un sur-dbit de conduit, Path Overhead (POH-
utilis pour la gestion du conteneur), est associ au conteneur Cn pour former le
conteneur virtuel VCn

Figure 7: Construction d'un Conteneur Virtuel. Ref [3]
C'est le conteneur virtuel VC qui est l'entit gre par le rseau SDH comme illustr
dans la figure 8 suivante

Figure 8: Gestion du VCn dans un rseau SDH. Ref [3]

34

Les VCn dordres 11, 12 et 2 sont dits dordre infrieur (LOP, Low Ordre Path), les
VCn dordre 3 et 4, sont dits dordre suprieur (HOP, High OrdrePath).
Lunit affluent (TU), le groupe daffluents (TUG) et lunit
dadministration (AU), le Groupe dAU, trame dordre n
Lunit daffluent, Tributary Unit (TU), se compose dun conteneur virtuel
dordre infrieur et dun pointeur PTR qui indique lemplacement du VCn dans le
conteneur dordre suprieur. (TUn = VCn + PTR).
Un groupe dunits daffluents (TUG) est un multiplex temporel dunits
daffluents TU 1,2 ou 3 multiplexs entre eux. Ainsi le TUG 2 regroupe 4 TU 11 ou 3
TU 12 ou 1 TU 2. Un TUG 3 regroupe de mme 7 TU 2 ou 1 TU 3.
Lunit dadministration (AU) se compose dun conteneur virtuel dordre
suprieur associ un pointeur dAU. La valeur de ce pointeur indique lemplacement
du dbut du conteneur dans la trame STMn utilise.
Un groupe dunit dadministration nest pas une nouvelle entit physique, mais
seulement une structure virtuelle de trame. LAUG correspond la place que doit
occuper lAU-4 dans la trame de transport ou la place de 3 units dordre 3
multiplexes. Les trames de transport STM sont obtenues en multiplexant n AUG et en
ajoutant un sur dbit de section SOH (Section Overhead).

Figure 9: Structure du multiplexage Synchrone. Ref [4]

35

La trame de base du SDH
La trame de base est donc caractrise par :
Sa longueur 2430 octets,
Sa dure 125 s,
son dbit 155,520 Mbit/s,
Sa capacit utile 2349 octets.
Elle se dcompose en trois zones reprsentes ci-dessous :
Surdbit de section, divis en surdbit pour la section de rgnration
(RSOH) et sur dbit de section de multiplexage (MSOH),
RSOH (Regenerator Section Overhead) : elle contient les
informations sur les lments de liaisons et est utilise pour
dialoguer avec et entre les rgnrateurs. Il sagit notamment du
mot de verrouillage de trame, la surveillance des erreurs.
MSOH (Multiplex Section Overhead) : La Section de
Multiplexage de lentte contient les informations ncessaires
pour le dialogue entre les multiplexeurs.
La Figure 10 prsente les limites des sections RS, MS et VC sur le rseau SDH

Figure 10: Limite des RS, MS, VC sur le rseau SDH.
RS= Regenerator Section (Section de Rgnration)
MS= Multiplex Section (Section de Multiplexage)
VC= Virtual Container (Conteneur Virtuel)
Les pointeurs dAU,
Les charges utiles VC 4, une pour STM1, 4 pour STM 4 ou 16 pour
STM 16
La Figure 11 prsente en dtail lorganisation de la trame STM1 :

36

Figure 11: Organisation de la trame STM1
2.3.3 Architecture et quipements dun rseau SDH : Cas CAMTEL
2.3.3.1 Architecture
La SDH, en tant que technique de multiplexage, permet dassocier des dbits
incidents pour former un dbit suprieur, plus facile transmettre et grer dans le
rseau de transmission. Cette hirarchie numrique synchrone a donc t mise en place
CAMTEL dans le but dunifier les structures rseaux sur le plan national et mme
international, aussi dans le but de rduire les cots de management des rseaux et
dliminer les inconvnients de la hirarchie PDH qui ne permettait pas cette
simplification et normalisation.
Le rseau de transmission SDH de CAMTEL est constitu par un rseau
interurbain encore appel Backbone et de deux rseaux mtropolitains dans les deux
grandes villes du Cameroun, Douala et Yaound. Larchitecture du rseau
mtropolitain de Yaound est un anneau bidirectionnel deux fibres permettant le
transport des services divers dans la rgion du centre. Ce sont des fibres monomodes
rpondant la norme G652 composs dun cble 3 tubes de 6 brins chacun. Selon le
synoptique de la Figure 12 ci-dessous, nous avons des fibres de 18 brins pour chacune
des directions.


37

Figure 12: Boucle Mtropolitaine SDF/FO Siemens de Camtel Yaound
2.3.3.2 Les quipements
Les quipements de la SDH sont de 4 types :
Les rgnrateurs ou rpteurs pour amplifier le signal afin quil garde un
niveau raisonnable ncessaire une bonne interprtation larrive.
Les multiplexeurs, on distingue 2 cas :
Les multiplexeurs terminaux (MTS) ou daccs qui sont utiliss pour la
projection et le multiplexage des affluents PDH, des affluents produits
par dautres standards (ADM, ) et des affluents SDH pour produits des
trames STMn
Le hub multiplexeurs pour linterconnexion des trafics transports sur
des fibres ou des anneaux
Les ADM (Add and Drop Multiplexer) ou MIE (Multiplexeur Insertion
ou Extraction) extraient ou injectent aisment un affluent dans un multiplex.
On distingue du ct rseau d'oprateur, les agrgats et du ct rseau d'abonn,
les affluents

38

Figure 13: Principe d'un ADM
Les DXC (Digital Cross Connect) ou brasseurs numriques sont charge de
rarranger les affluents dans les trames STMn et de commuter les signaux des
multiplex dentre dans les multiplex de sortie
La Figure 14 suivante prsente une utilisation de ces quipements dans un rseau
complet :

Figure 14: Exemple d'un rseau SDH. Ref [4]

39

Dans la boucle mtropolitaine, le logiciel install dans les moniteurs de
supervision est le TNMS (Tlcommunications Network Management System). Le
TNMS est le systme de gestion pour les quipements optiques de nouvelle gnration
de la famille SURPASS de lquipementier Siemens. Il prend en compte tous les
aspects de la gestion des rseaux de la couche lment la couche business en passant
par les couches rseau et service. En dautres termes, il assure les fonctionnalits
suivantes :
Gestion des configurations (Cross Connect etc.)
Gestion des alarmes (LOS, AIS, RDI, LOF, LOP )
Gestion des lments du rseau
Gestion de la scurit (Protection)
Gestion des connexions lquipement
Le composant central de la famille des produits TNMS est le TNMS-Core qui
fournit une gestion intgre et centralise des rseaux optiques multiservices sur les
couches de gestion de llment, du rseau, et des services. Il est install CAMTEL
pour le HiT 7070 sous la version 10.0.18.3. Une des variantes de la famille des TNMS
est le TNMS-M install pour les HiT7060 (comme dans le cas du centre de
NKOLBISSON).
Les tableaux 4 et 5 prsentent les types de cartes installes dans le systme SDH
de CAMTEL :
Nom : SURPASS HiT 7070
Equipementier Siemens
NMS/EMS TNMS-Core 10.0.18.3
N Type Description
1 IF2M Interface de 63 ports E1 (lectriques)
2 IF345 Interface de 3 ports E3 (lectriques)
3 IFO155M Interface de 8 ports STM-1 (optiques)
4 IFQ622M Interface de 4 ports STM-4 (optiques)
5 IFS2G5B Cartes de 1 STM-16 (optique)

40

6 SF10G Carte de commutation bas niveau (ou de cross connect)
7 SF160G Carte de commutation haut niveau
8 LSU Carte dinterruption (en protection)
9 CLU Horloge interne
10 SCOH Carte contrleur principale
11 LNQ Carte de connexion aux shelfs dextension
12 FAN Unit Systme de ventilation
13 FMX Interface bas dbit N*64 Kbps ; sortie 2Mbps
Tableau 3: Les cartes du HIT 7070
Nom : SURPASS HiT 7060
Equipementier Siemens
NMS/EMS TNMS-M 10.3
N Type Description
1 LC5, LC4 Interface client 63*E1 lectrique
2 EC1, EC2 Interface client 3*E3/DS3 lectrique
3 LC2, LC3 Interface ligne 2*STM1 optique
4 CC1& CC2 Cross Connect and Timing Function Card [70G/5G]
5 PW1 &
PW2
Panneau dalimentation
6 SC System Controller
7 FAN Tray Systme de ventilation
8 FMX Interface bas dbit N*64 Kbps ; sortie 2Mbps
Tableau 4: Les Cartes du HIT 7060
Le systme SDH de CAMTEL prvoit quen cas de coupure de ligne, le signal
est automatiquement rachemin sur un secours. Nous avons donc deux types de
configuration pour la scurit du trafic dans nos rseaux mtropolitains : une
protection ligne EPS 1+1 et une protection de multiplexage MSP 1+1 (Multiplex
Section Switching 1+1).

41

2.3.3.3 Les services Vhiculs dans la boucle Mtropolitaine
Le rseau SDH/FO de Camtel donne accs trois types de services :
Les services supports pour le transport dinformation de bout en bout entre
deux interfaces, il y a le service tlphonique (transport des circuits vocaux
MIC) et le service numrique (transport des flux variables tels quATM ou
TVHD aprs conversion)
Les tl-services il sagit des services tels que la vidoconfrence et la
visiophonie
Les complments de services correspondent un enrichissement de loffre
tlphonique. Ces prestations donnent lieu facturation.


42

2.3.4 Les indicateurs de performance dun rseau de
transmission
La Recommandation UIT-T G.826 dfinit un ensemble dvnements lis aux
caractristiques derreur bases sur la notion de bloc et des paramtres destins au
contrle en service des caractristiques derreur dun conduit SDH.
Bloc erron, EB (Errored Block) : Bloc dont un ou plusieurs bits sont errons.
A savoir quun bloc est un ensemble de bits conscutifs associs au conduit,
chaque bit appartenant un bloc et un seul. Des bits conscutifs peuvent ne pas
tre contigus dans le temps.
Seconde errone, ES (Errored Second) : Priode dune seconde comportant
un ou plusieurs blocs errone ou au moins un dfaut et pendant laquelle une
perte du signal (Loss Of Signal) ou un signal dindication dalarme AIS (Alarm
Indication Signal) est dtect.
Seconde gravement errone, SES (Severely Errored Second) : Priode dune
seconde comportant un taux de blocs errons suprieur ou gal 30% ou au
moins un dfaut. Lensemble des secondes gravement errones est un sous
ensemble des secondes errones.
Des secondes gravement errones peuvent conduire des priodes
dindisponibilit, en particulier lorsquaucune procdure de restauration/protection
nest pas utilise. Des priodes de T secondes gravement errones conscutives 2<=
T<10 (certains oprateurs de rseaux dsignent ces vnement des pannes) peuvent
affecter gravement le service ; elles peuvent, par exemple, entrainer la dconnexion
des services commuts.
Seconde indisponible, UAS (Unavailable Seconde) : Une UAS est une
seconde qui fait partie dune priode dindisponibilit.
Bloc erron rsiduel, BBE (Background Block Error) : Bloc erron
survenant en dehors dune seconde gravement errone.

43

La dfinition de la taille de bloc et des vnements lis aux caractristiques
derreur pour la section multiplex (MS, Multiplex Section) en mode SDH et la section
de rgnration (RS, Regenerator Section) est prsente dans la Recommandation
UIT-T G.829. Chaque direction dun conduit peut se trouver dans lun des tats
suivants : temps de disponibilit et temps dindisponibilit. Les critres qui
dterminent la transition entre les deux tats sont indiqus ci-aprs. Une priode
dindisponibilit commence au dbut dvnements de 10 secondes gravement
errones conscutives. Ces 10 secondes font partie du temps dindisponibilit.
Une nouvelle priode de disponibilit commence au dbut dvnements de 10
secondes conscutives ne comportant pas de seconde gravement errone. Ces dix
secondes font partie du temps de disponibilit. Un conduit est disponible si, et
uniquement si, les deux directions sont disponibles. Les paramtres de disponibilit
dfinis sont le taux de disponibilit (AR, Availability Ratio) et la dure moyenne entre
interruptions de conduit numrique, Mo. Le complment 1 du taux AR est le taux
dindisponibilit (UR, Unavailability Ratio). Ainsi, AR+UR = 1. Linverse de Mo est
dfini comme tant la frquence dinterruption (OI, Outage Intensity). Ainsi, Mo
=1/OI. Mo reprsente le nombre de priodes dindisponibilit par an.
De ces vnements caractristiques derreurs, lUIT Rf [5]- dfinit les
paramtres caractristiques derreur comme suit :
Le taux de secondes Errones ESR (Errored Seconds Ratio), donne par la
relation : FSR =
FS
S
aua||
avec S
aua||
, le temps total de disponibilit de la liaison
durant la priode dobservation;
Le taux de Secondes Svrement Errones SESR (Severely Errored Seconds
Ratio), donne par la relation : SFSR =
SFS
S
aua||

Le taux de blocks de rsiduels Errones BBER (Background Block Error
Ratio), donne par la relation : BBFR =
BBF
N
aua||
avec N
aua||
le nombre total de
blocks dans la priode de disponibilit de la liaison. Ce paramtre sapplique
uniquement aux conduits

44

Le tableau 6 prsente les caractristiques cibles pour un conduit numrique infrieur
ou gal 27000 Km tel que dfini par lUIT:
DEBITS NOMBRE DE BITS
PAR BLOC
ESR SESR BBER
64 Kbits/s au dbit
primaire
Non applicable 0.4 0.002 Non
applicable
1.5 5 Mbits/s 800-5000 0.4 0.002 2x1u
-4

5 15 Mbits/s 2000-8000 0.5 0.002 2x1u
-4

15 55 Mbits/s 4000-20000 0.075 0.002 2x1u
-4

55 160 Mbits/s 6000-20000 0.16 0.002 2x1u
-4

160 3500 Mbits/s 15000-30000 Pas
spcifi
0.002 1u
-4

Tableau 5: Caractristiques cibles des paramtres d'erreur. Rf [5]
LIUT Rf [5]- nous propose galement un diagramme illustrant la dtection
d'anomalies, de dfauts ES et SES. Ce diagramme est expliqu avec les notes
suivantes :
NOTE 1 - La dtermination des temps d'indisponibilit introduit un retard de
dix secondes. Ce dlai doit tre considr lors du comptage BBE, ES et SES.
NOTE 2 - cES, cSES et cBBE des chiffres de ES, SES, BBE, respectivement.
Ces chiffres sont remis zro au dbut d'une priode de mesure.
NOTE 3 - EB est le nombre de blocs dfectueux au sein d'une EB% tandis que
ES reprsente la proportion de blocs errones au sein d'une ES par rapport au
nombre de blocs par seconde.
NOTE 4 Les paramtres G.826 peuvent tre valus au cours ou la fin
dune priode de mesure P comme suit, en tenant compte des secondes
dindisponibilt (UAS):
BBER = cBBE / [(P - SAMU - cSES) blocs par seconde ]
ESR = EC / (P - UAS)
SESR = cSES / (P - UAS)

45

NOTE 5 - Dans le schma simplifi, aucune mesure n'est prise si le chemin est
dans l'tat d'indisponibilit. C'est parce que le schma ne tient pas compte de la
transition entre les tats de disponibilit, alors qu'en ralit, les compteurs
d'vnements doit tre modifie de manire rtrospective. Dans la pratique, le
statut de seconde (soit exempt d'erreurs, ES ou SES) doit toujours tre
dtermin avant un test qui est effectu sur le statut de disponibilit d'une voie.
En d'autres termes, les vnements d'erreur sont toujours dtect
indpendamment du fait que le chemin est disponible ou non - que le comptage
des vnements est inhibe pendant des priodes d'indisponibilit pour les fins
de suivi de la performance long terme. Ce processus se traduit par
lorganigramme bien que les actions qui en dcoulent sur les changements d'tat
de disponibilit ny sont pas.


46

Figure 15: diagramme illustrant la dtection d'anomalies, de dfauts ES et SES. Ref [5]
2.3.5 Les alarmes dans un rseau SDH
Une alarme est toute condition de dfaut (dfaut logiciel, dfaut matriel, dfaut
transitoire) qui apparait (disparait) dans un quipement. Cest gnralement un
message renvoy par les ressources rseau qui ont dtects des dfaillances concernant
leur tat. Une alarme est dfinit par lusage dun certain nombre de paramtres
savoir :
Le problme spcifique (Specific Problem)

47

Ce paramtre lorsquil est remont donne de faon un peu plus fine la cause de
lalarme. Il est soit un ensemble dentier ou un ensemble dobjets identifiables.
La cause probable (Problem Cause)
Ce paramtre dfinit la cause probable de lalarme, sa valeur appartient un ensemble
de valeur possibles dfinit dans les recommandations X.721, M3100
Le nom de la ressource (Friendly Name)
Ce paramtre identifie la ressource qui a gnr lalarme
Linstant de lvnement (Event Time)
Le type de lvnement (Event Type)
Ce paramtre dfinit le type de problme rfrenc par cette alarme.
Le tableau 7 prsente les diffrents types dvnements et leur description
Type dvnement Indications
Communication Un problme avec un processus ou une procdure utilis pour
envoyer de linformation
Qualit de service Dgradation de la qualit de service dans le rseau
Erreur de traitement Un logiciel ou un dfaut de traitement
Equipement Un quipement en dfaut
environnement Un problme dans lenvironnement contenant lquipement
Tableau 6: Les types d'vnement
La svrit (severity)
Le niveau de svrit indique quel niveau lobjet manag affecte le rseau. Il existe 4
niveaux de svrit dtaills dans le tableau 8 :
Svrit Description
Critical Un dfaut srieux qui requiert une action correctrice immdiate.
Exemple : Un objet supervis est hors service
Major Un dfaut qui requiert une action correctrice urgente. Exemple :
svre dgradation dans les oprations dun objet supervis
Minor Un dfaut qui naffecte pas le service mais qui ncessite une action
correctrice pour viter des dommages plus srieux
Warning Dtection dune potentielle condition de dfaut. Une action doit tre

48

prise pour diagnostiquer et corriger le problme pour viter des
dommages
Tableau 7: Svrit des alarmes
Grce aux octets d'en-tte (MSOH, RSOH et POH) de la trame de base, un
rseau SDH peut transporter un grand nombre d'alarmes. L'exploitant dispose donc de
nombreuses sources de diagnostique. La liste non exhaustive des alarmes est donne
comme suit :
LOS: Loss of Signal. Absence de signal
AIS : Alarm Indication Signal (MS-AIS, PATH-AIS...)
RDI : Remote Defect Indication (Erreur venant du distant)
LOF: Loss of Frame
LOP: Loss of Pointer
Mismatch C2 : la structure reue n'est pas celle attendue
Mismatch J1 : l'identifiant reu n'est pas celui attendu
etc...

Conclusion

49

2.4 Conclusion
Dans ce chapitre il a t question de passer en revue les gnralits relatives
notre travail, savoir, la transmission par Fibre Optique, les techniques de
multiplexage SDH et PDH, larchitecture des rseaux SDH avec tout en insistant sur
les indicateurs de performances et les types dalarmes possibles. Apres avoir prsent
cela, nous pouvons prsent nous intresser lanalyse de notre application, cest ce
qui fera lobjet du chapitre suivant.

Chapitre 3 : Ralisation de loutil de gestion des services et suivit des performances : Analyse

50

Chapitre 3 : Ralisation de loutil de gestion
des services et suivi des performances :
Analyse
Aperu
Analyse __________________________________________________________________ 50
3.1 Introduction _______________________________________________________________ 50
3.2 Analyse de loutil de gestion des services et suivi des performances __________________ 51
3.2.1 Rappel du cahier des charges ________________________________________________________ 51
3.2.1.1 Besoins fonctionnels ___________________________________________________________ 51
3.2.1.2 Besoins non fonctionnels ________________________________________________________ 52
3.2.2 Protocole dacquisition des donnes __________________________________________________ 52
3.2.3 Architecture de la plateforme ________________________________________________________ 53
3.2.3.1 Module de rapatriement des donnes_____________________________________________ 54
3.2.3.2 Module de traitement et mise dans la Base de Donnes _______________________________ 54
3.2.3.3 Module de remonte des alarmes par SMS _________________________________________ 55
3.2.3.4 Module de prsentation des donnes aux utilisateurs ________________________________ 55
3.3 Conclusion _________________________________________________________________ 56

3.1 Introduction
Apres avoir prsent les gnralits sur les rseaux de transmission, les
techniques de multiplexage, les indicateurs de performance, il est prsent question
proposer une analyse du cahier des charges atteindre. Ceci afin de produire une
architecture qui nous permettrait de respecter les contraintes fonctionnelles et non
fonctionnelles.
3
Analyse de loutil de gestion des services et suivit des performances

51

3.2 Analyse de loutil de gestion des services et suivi des
performances
Le TNMS prsente ce jour des limites. La dtection et la gestion des
ressources disponibles , telle quelle est faite actuellement , passe par la manipulation
dune multitude de fichiers textes, extrait manuellement sur le TNMS puis traites
manuellement, ceci avec des risques derreur.
Par ailleurs le suivi de la qualit des liaisons seffectue par extraction du TNMS
de la liste des alarmes suivi dun traitement manuel de ces alarmes et production des
rapports ; vraiment fastidieux et inefficace quand on sait quil peut y avoir un
moment donn prs de 10 000 alarmes a traites dans le rseau. A cela il faut ajouter
limpossibilit de produire efficacement des rapports sur des services et capacits des
quipements car cela jusqu ce jour se fait manuellement dans des registres.
Ceci tant le cahier des charges et lanalyse suivante va essayer de rpondre au
mieux aux proccupations suscites
3.2.1 Rappel du cahier des charges
Plusieurs contraintes poses dune part par lentreprise, et dautre part par
lapplication elle-mme, ont permis de dgager les besoins fonctionnels et non
fonctionnels suivants :
3.2.1.1 Besoins fonctionnels
Loutil dvelopper doit rpondre plusieurs exigences dont les plus
importantes sont les suivantes :
Communiquer de faon journalire et priodique avec le serveur pour un souci
de rapatriement automatique des logs dalarmes et performances.
Analyser de faon quotidienne les logs rapatris afin de produire des
statistiques diverses : variation des indicateurs de performances, listing des
alarmes dans un intervalle de temps donn pour un quipement, un conduit
donns ... Ceci dans loptique de mettre en place une technique de maintenance
prventive et de fournir aux techniciens des pistes doptimisation.
Fournir des interfaces qui permettrons dautomatiser la gestion des services,
conduits, fibre et quipements via des oprations de cration, modification,

52

suppression, consultation. Ceci dans le but de produire galement des rapports
dtat ou doccupation du rseau et des matrices de trafic ce qui actuellement se
fait manuellement.
Dclencher une alerte SMS vers les techniciens du centre en cas de dfaillances
majeurs dans le rseau ceci dans loptique de rduire le temps de raction face
un problme, car les problmes nous sont (dans le centre des jonctions
urbaines) gnralement signals par les responsable des services que nous
transportons (Cas du BSC qui nous informe gnralement des BTS qui ne
fonctionnement pas car notre transmission nest pas bonne).
Sauvegarder toutes ces informations dans une base de donnes pour des besoins
futures.
3.2.1.2 Besoins non fonctionnels
Lapplication doit tre modulaire pour assurer sa maintenance et son
extensibilit afin de pouvoir ladapter des besoins futurs. Lutilisation de cet outil
doit tre simple et prsenter une interface conviviale et comprhensible par les
employs du Centre des Jonctions Urbaine et du centre de supervision des rseaux. Le
temps de rponse aux requtes des utilisateurs doit tre acceptable.
3.2.2 Protocole dacquisition des donnes
Lapplication TNMS Core tant installe sur un serveur Windows Server 2003
dot du SGBDR Microsoft Windows Server SQL, il se prsente deux possibilits de
rapatriement automatique.
Transfert par protocole FTP : Il sagit de configurer le poste qui hberge le
TNMS en serveur FTP. Il sera question via le TNMS coreSysAdmin de
paramtrer les sauvegardes vers un rpertoire prcis qui servira galement de
rpertoire principal pour le service FTP. Cest dans ce rpertoire que le client
FTP de notre plateforme viendra rcuprer les fichiers logs pour rapatriement
Transfert par rplication de la Base de donnes centrale du TNMS : Cette
solution serait vraiment idale, mais il savre que le constructeur na pas donn
larchitecture de sa Base de donnes et vue la fragilit et la haute importance du
TNMS, il sera judicieux de ne pas attaquer directement sa base de donne.
Nous proposerons de ce fait, la premire solution, celle par protocole FTP.

53

3.2.3 Architecture de la plateforme
La mise en place de la plateforme a t aborde de faon modulaire suivant un
concept Client-Serveur comme lillustre larchitecture prsente par la Figure 16.

Figure 16 Architecture de la plateforme METROPERF_CJU
Cette architecture comprend un client et un serveur qui reposent sur 4 modules
savoir :
Du cot serveur, METROPERF_CJU_Server:
Un module de rapatriement des donnes.
Un module de traitement et mise dans la Base de Donnes.
Un module de remonte des alarmes pas SMS.
Du cot Client, METOPERF_CJU_Client :

54

Un module de prsentation des donnes aux utilisateurs.
Linterface graphique de ce module devra respecter lorganisation suivante :

Figure 17: Organigramme du module Client
3.2.3.1 Module de rapatriement des donnes
Le module de rapatriement des donnes consiste rcuprer les donnes par
FTP partir du serveur TNMS et les stocker dans le poste dexploitation qui est
galement la machine qui hberge notre base de donnes. Pour cela nous avons install
lapplication FileZilla Server sur le poste TNMS, crer un utilisateur et orienter le
rpertoire de travail de cet utilisateur vers le rpertoire ou sont gnr les logs par le
module SysAdmin du TNMS. Cest avec les paramtres de ce compte que notre
socket client FTP devra se connecter de faon priodique au serveur TNMS pour
assurer le rapatriement vers un rpertoire bien spcifier du poste dexploitation.
3.2.3.2 Module de traitement et mise dans la Base de Donnes
La premire partie de ce module est de se rendre dans le rpertoire ou a t
dpos le fichier rcupr du serveur TNMS et de les mettre en forme afin de mieux
les intgrer dans la base de donnes. La deuxime partie consiste stocker dans la base

55

de donnes les informations issus de ces fichiers et dinformer au module de remonte
des alarmes par SMS en cas dalarme de svrit crittique.
3.2.3.3 Module de remonte des alarmes par SMS
Ce module est charg principalement de remonter automatiquement les alarmes
qui lui sont envoys par le module prcdent vers les techniciens du centre. Il
comprend deux parties :
La construction du message envoyer.
Lenvoie du message aux exploitants concerns et marqus dans la base de
donnes.
Lescalation de lenvoi des SMS selon les temps et les niveaux qui auront t
dfinis
3.2.3.4 Module de prsentation des donnes aux utilisateurs
Il est question ici de prsenter les donnes stock dans la base de donnes sous
forme dinterface java. De permettre galement des oprations diverses sur ces
donnes. Il faut ajouter cela la gestion des services, des conduits, des fibres, des
quipements et des utilisateurs.

Conclusion

56

3.3 Conclusion
Dans ce chapitre nous avons prsent le cadre de notre application qui
comprend une tude de lexistant et une spcification des besoins ainsi que les cas
dutilisation de lapplication. Pour illustrer la concrtisation de la spcification, le
chapitre suivant prsente la conception et limplmentation des diffrentes
fonctionnalits de notre application.

Chapitre 4 : Ralisation de loutil de gestion des services et suivit des performances : Conception

57

Chapitre 4 : Ralisation de loutil de
gestion des services et suivi des
performances : Conception et ralisation
Aperu
Conception et ralisation ____________________________________________________ 57
4.1 Introduction _______________________________________________________________ 57
4.2 Conception de lapplication ___________________________________________________ 58
4.2.1 Diagrammes des Cas dutilisation _____________________________________________________ 58
4.2.2 Diagramme des classes _____________________________________________________________ 61
4.2.3 Diagramme de squences ___________________________________________________________ 64
4.3 Ralisation de lapplication ___________________________________________________ 65
4.3.1 LEnvironnement de travail __________________________________________________________ 65
4.3.2 Les Choix techniques de ralisation ___________________________________________________ 65
4.3.2.1 Mapping objet-relationnel _______________________________________________________ 65
4.3.2.2 Choix du SGBD ________________________________________________________________ 67
4.3.2.3 Choix du langage de programmation ______________________________________________ 67
4.3.2.4 Stratgie de remonte automatique des alarmes par SMS _____________________________ 67
4.4 Conclusion _________________________________________________________________ 69

4.1 Introduction
Cette partie nous permet de prsenter les diagrammes UML correspondants et le
choix des outils utiliser pour limplmentation effective du travail demand.
4
Conception de lapplication

58

4.2 Conception de lapplication
4.2.1 Diagrammes des Cas dutilisation
Un cas d'utilisation modlise un dialogue entre un acteur et le systme. C'est la
reprsentation d'une fonctionnalit offerte par le systme. L'ensemble des cas
d'utilisation forme toutes les faons possibles d'utilisation du systme. Les principaux
objectifs des cas dutilisation sont :
Permettre de structurer les besoins des utilisateurs et les objectifs
correspondants dun systme.
Centrer lexpression des exigences du systme sur ses utilisateurs.
Se limiter aux proccupations relles des utilisateurs : ils ne prsentent pas de
solutions dimplmentation et ne forment pas un inventaire fonctionnel du
systme.
Identifier les utilisateurs du systme (acteurs) et leurs interactions avec le
systme.
Vu le nombre important des actions du modle des cas dutilisation du systme
et pour des raisons de simplification de la reprsentation, le modle va tre divis en
diagrammes prsentant quelques-unes des diverses fonctionnalits offertes par notre
outil. La Figure 18 reprsente une vue gnrale sur les diffrents cas dutilisation de
notre application en se basant sur la mthodologie UML que lon a adopt (Voir
Annexe A. Le langage de modlisation UML).


59

I nvit
Administrateur
Gestion des Utilisateurs et
du Serveur
Include
I nclude
Include
Include
Authentification
Consulation des Services,
des Equipements,
des Fibres et des Conduits.
gnration des rapports
Consulations de l'tat
du rseau,
Alarmes et Performances
Configuration et Suppression
des services, des conduits,
des quipements, des fibres

Figure 18: Diagramme de Cas d'utilisation Gnrale
Lopration de consultation de ltat du rseau figure parmi les fonctionnalits
principales que lapplication doit offrir. La Figure 19 prsente en dtail ce cas
dutilisation.


60

Acteur
Authentification
Include Consulations de l'etat
du reseau,
Alarmes et Performances
Consultation
des
Alarmes
Consultation
des
performances
Selection le paneau
equipement
Extend
Selection du paneau
Conduit
Extend
Listage des
performances
Equipements
Listage des
Performances
des Conduis
Extend Extend
Statistique
Extend
Extend
Filtre:
selection Equipement, Port,
Indicateur, periode
Filtre:
selection Conduit,
Indicateur, periode
Gneration des
Graphes de
Performance
Extend
Extend
listage de
Alarmes
survenues
Extend

Figure 19: Diagramme de cas d'utilisation pour la consultation de l'tat du rseau
Pour assurer son volutivit, le systme doit galement offrir la possibilit de
slectionner les diffrents paramtres de la connexion, dajouter et de supprimer des
utilisateurs et de configurer les serveurs de transmission.
Ces diffrentes oprations ncessitent lidentification de lutilisateur. Seuls les
utilisateurs connects avec un compte administrateur ont le droit dajouter et de
supprimer des utilisateurs et aussi configurer les serveurs. La Figure 20 prsente le cas
dutilisation Gestion des Utilisateurs et du Serveur.


61

Gestion des Utili sateurs et
du Serveur
Administrateur
Authent if icat ion
Ajouter Uti lisat eur
Modif ier Ut ilisat eur
Suppri mer Utilisateur
Ajouter Serveur
Modif ier serveur
Ext end
Ext end
Extend
Ext end
Include
Extend

Figure 20: Diagramme de cas d'utilisation pour la gestion des utilisateurs et du serveur
4.2.2 Diagramme des classes
Notre programme contient lensemble des classes suivantes, ces classes
constituent la couche Codes qui nous servira de mapping relationnel/objet:
Classe
Role
Alarmes_SMS Enregistrer les alarmes qui ont dj t envoy par SMS
Carte Grer toutes les cartes d'un quipement
Classe_Trafic Indiquer la classe d'un conduit ou celle d'un service
Conduit_equipement Enregistre dans l'ordre tous les quipements du conduit y
compris les fibres rencontres.
Conduit_perf Enregistre les logs de performance sur les conduits
Conduit Enregistrer les conduits avec les infos de dparts
(ID_Equipement, PORT, SUBRACK, CARTE) d'arrive et
intermdiaire
Equipement_alerte Enregistrement des alertes sur les quipements
Equipement_perf Enregistrements des logs de performance sur les quipements
Equipement Gestion des quipements

62

Fibre Grer les fibres et leurs caractristiques
Brin_Fibre Grer les brins de chaque fibre
Tube_Fibre Grer les Tubes de chaque fibre
Port Grer tous les ports d'une carte
Service Gestion des services
Subrack Grer tous les Subrack d'un quipement
Type_equipement Enregistrer les types d'quipements disponibles. Donc un
Equipement aura une cl trangre rfrenant son Type
Utilisateurs Gestion des utilisateurs
ServeurFTP Gestion des serveurs (@IP, User, Password, Periodicit, )
SMS Enregistre la configuration du modem GSM (Port, vitesse et
autres) pour lenvoi des SMS.

Le diagramme dcoule de lanalyse ralis au chapitre prcdent.

63

Figure 21: Diagramme de classe

64

4.2.3 Diagramme de squences
A cause du nombre important des scnarios qui peuvent tre implments dans
ce systme et pour des raisons de simplification de la reprsentation, on va juste
choisir un scnario. La Figure 22 prsente le scnario de tlchargement des fichiers
partir du serveur de transmission et de linsertion dans la base de donnes.

Figure 22: Rapatriement des fichiers et insertion dans la BD
Ralisation de lapplication

65

4.3 Ralisation de lapplication
4.3.1 LEnvironnement de travail
Pour la mise en place de cette application, un ordinateur ayant la configuration
minimale suivante doit tre mis en service :
Processeur : Pentium IV 2.4 GHz.
Disque Dur : 40Go.
Mmoire RAM : 512 Mo.
Et la configuration logicielle suivante :
Eclipse INDIGO, ORM JPA-Toplink, WindowsBuilderPro, les librairies
diverses (JfreeChart, Jcalendar ).
EasyPHP (Apache, Php et Mysql).
Serveur FileZilla.
4.3.2 Les Choix techniques de ralisation
Le terme choix technique de ralisation veut dire la slection des diffrents
supports informatiques qui seront utiliss lors de limplmentation de loutil
4.3.2.1 Mapping objet-relationnel
Un mapping objet-relationnel (en anglais object-relational mapping ou
ORM) est une technique de programmation informatique qui cre l'illusion d'une base
de donnes oriente objet partir d'une base de donnes relationnelle en dfinissant
des correspondances entre cette base de donnes et les objets du langage utilis. On
pourrait le dsigner par correspondance entre monde objet et monde relationnel .
cela consiste globalement associer une ou plusieurs classes avec une table, et
chaque attribut de la classe avec un champ de la table. Parmi les multiples Framework
de mapping objet-relationnel en JAVA, on peut citer JPA (Java Persistence API) qui
est une interface de programmation Java permettant aux dveloppeurs d'organiser des
donnes relationnelles dans des applications utilisant la plateforme Java.
LAPI JPA est rcente. Elle na t disponible qu partir du JDK 1.5. La
couche JPA sa place dans une architecture multicouche. Considrons une telle
architecture assez rpandue, celle a 3 couches :

66

Figure 23:Architecture de modlisation sans ORM
La couche [1], appel ici [ui] (User Interface) est la couche qui dialogue avec
lutilisateur, via une interface graphique Swing, une interface Web ou une
interface console.
La couche [2], appel ici [mtier] est la couche qui applique les rgles dites
mtier, ie : la logique spcifique de lapplication, sans se proccuper de savoir
do viennent les donnes quon lui donne, ni o vont les rsultats quelle
produit
La couche [3], appel ici [dao] (Data Access Object) est la couche qui fournit
la couche [2] des donnes prenregistres (Fichiers, bases de donnes) et qui
enregistre certains des rsultats fournis par la couche [2]
La couche [JDBC] est la couche standard utilise en Java pour accder des
bases de donnes cest ce quon appelle habituellement le pilote Jdbc du
SGBD.
De multiples efforts ont t faits pour faciliter lcriture de ces diffrentes
couches par le dveloppeur. Parmi ceux-ci, JPA vise faciliter lcriture de la couche
[dao]. Une solution sur laquelle nous avons port notre attention est celle de Toplink.

Figure 24: Architecture de modlisation avec ORM
Toplink et Hibernate sont des ORM (Object Relational Mapping). Un ORM
est un outil qui fait le pont entre le monde relationnel des classes de donnes et celui
des objets manipuls par Java. Le dveloppeur de la couche [dao] ne voit plus la

67

couche [Jdbc] ni les tables de la base de donnes dont il veut exploiter le contenu. Ce
concept nous a permis dtre plus fficace et rapide dans le dveloppement de notre
plateforme.
4.3.2.2 Choix du SGBD
MySQL est le serveur de base de donnes le plus utilis dans le monde. Son
architecture logicielle le rend extrmement rapide et facile personnaliser. Ce dernier
possde plusieurs avantages dont les plus importantes sont la rapidit, la robustesse, la
facilit dutilisation et dadministration. Mais lavantage le plus majeur de MySQL est
la documentation trs complte et bien construite.
4.3.2.3 Choix du langage de programmation
Tout dabord, java simplifie le processus de dveloppement : quelle que soit la
machine sur laquelle on code, le compilateur fournit le mme code. Ensuite, quel que
soit le systme utilis, cet unique code est directement oprationnel :
Fichier Source Compilateur Java Fichier Classe Interprteur Java.
En effet, la compilation dune source Java produit du pseudocode Java qui sera
excut par tout interprteur java sans aucune modification la recompilation. Java
permet galement de crer des applications autonomes qui peuvent se substituer des
applications dvelopps en langage compil. Pour ces applications lAPI Java apporte
un ensemble trs riche de classes rpondant de nombreux besoins et pouvant tre
tendue, cet unique API simplifie la cration et le dploiement des applications, en
effet cette application sexcutera sur tout systme en utilisant laspect visuel de ce
systme.
4.3.2.4 Stratgie de remonte automatique des alarmes par SMS
Le module denvoi des SMS a t ralis dans le but de pouvoir aviser en cas
dalertes, cest--dire lorsquon a une alarme ayant un certain degr de criticit
spcifi, un SMS est envoy un groupe dutilisateurs. Pour effectuer un envoi de
SMS un certain nombre doutils sont ncessaires savoir:
Un tlphone portable avec une carte SIM (Subscriber Identification Module)
Un cble de donnes RS232/USB (Data cble) permettant de connecter le
tlphone Mobile au PC(Ordinateur)

68

Avoir le ncessaire de crdit pour effectuer lenvoi des SMS.
Une fois que vous disposez de ces quipements, il va falloir maintenant
configurer le logiciel qui assurera linterface TlphoneOrdinateur. Lenvoi des SMS
au mobile ncessite lemploi des commandes AT tablies par LETSI (Europeean
Telecommunications Standards Institute).

Conclusion

69

4.4 Conclusion
A ce stade de notre travail nous avons prsent les diffrentes mthodes et
procdures dployes pour limplmentation de la solution que nous avons adopte.
Toute la suite du prsent document sera donc consacre la prsentation des divers
rsultats obtenus.

Chapitre 5 : Rsultats et Commentaires

70

Aperu
Chapitre 5 : Rsultats et Commentaires ________________________________________ 70
5.1 Introduction _______________________________________________________________ 70
5.2 Quelques rsultats __________________________________________________________ 71
5.2.1 Lot 1 : Rapatriement des fichiers _____________________________________________________ 71
5.2.3 Lot 2 : Acquisition des donnes et chargement dans la base de donnes _____________________ 73
5.2.3 Lot 3 : Remonte automatique des alarmes par SMS _____________________________________ 73
5.2.4 Lot 4 : Linterface Client et ses diffrentes fonctionnalits _________________________________ 75
5.3 Conclusion _________________________________________________________________ 82

5.1 Introduction
Dans cette partie, il est question pour nous, dillustrer les diffrents rsultats
que nous avons obtenus tout au long de notre travail. Les aboutissements auxquels
nous sommes parvenus peuvent tre regroups en plusieurs lots que nous allons
parcourir tour tour:
Lot 1 : Rapatriement des fichiers ;
Lot 2 : Acquisition des donnes et chargement dans la base de donnes ;
Lot 3 : Remonte automatique des alarmes par SMS ;
Lot 4 : Linterface Client et ses diffrentes fonctionnalits.

5
Etude de cas

71

5.2 Quelques rsultats
5.2.1 Lot 1 : Rapatriement des fichiers
Avant toute chose il faut au pralable paramtrer ce travail dautomatisation en
informant lapplication sur les paramtres du serveur distant (@IP du serveur FTP,
identifiant du client FTP, mot de passe du client FTP et Priodicit de rapatriement),
linterface de la Figure 25 du module client permet de le faire.

Figure 25: Configuration du serveur
La Figure 26 prsente linterface daccueil du module serveur
Metro_Perf_CJU-SERVER, cest travers ce module que nous allons dclencher
divers processus automatiques. On peut ainsi dmarrer et stopper le fonctionnement du
serveur. Cela implique le rapatriement des fichiers logs du serveur de supervision
TNMS vers le rpertoire C\ :ftpClient (rpertoire quil faudra au pralable crer !) du
poste dexploitation (Figure 27)

Figure 26: Page d'accueil du serveur lorsqu'il est lanc
Etude de cas

72

Figure 27: rpertoire de Rapatriement et traitement de logs (Alarmes et PM)
Les figues suivantes prsentent les formats des fichiers rapatris. On peut ainsi avoir :
A la Figure 28 un prototype de fichier des alarmes dont la structure dune
entre est la suivante,
<svrit>:<EVT_TIME=AAAA-MM-JJ_hh-mm-ss>:<NE_NAME
>:<ENTITY=Subrack_carte_port>:<EVT_TYPE>:<Cause
Probable>:<NRSV>:<CLR>:<NACK>:<NO>:<0>;
A la Figure 29 un prototype de fichier des performances dont la structure est
galement la suivante , < NE_NAME >:< ENTITY_PERF >:< EVT_TIME
>:< ES>:<SES>:<BBE><UAS>:<EB>:<SER>:<BBER;

Figure 28: Exemple de Fichier d'alarme
Etude de cas

73

Figure 29: Exemple de Fichier de PM
5.2.3 Lot 2 : Acquisition des donnes et chargement dans la
base de donnes
Apres avoir rapatri les fichiers, notre application nous permet galement une mise en
forme et un chargement automatique dans la base de donnes. La Figure 30 nous prsente
quelques tuples de la Table equipement_alerte dans la base de donnes
metroperf_cju .

Figure 30: Quelques tuples de la table equipement_alerte
5.2.3 Lot 3 : Remonte automatique des alarmes par SMS
Ce travail ne peut se faire quaprs paramtrage. Le paramtrage qui consiste
dtecter le modem denvoi de SMS et enregistrer les informations (Vitesse, Port de
Etude de cas

74

communication, personnes contacter) dans la base de donnes travers linterface de
la Figure 31.

Figure 31: Configuration de la remonte des alarmes par SMS/MAIL
Apres ce paramtrage, si le module MetroPerf_CJU__Server est lanc on
pourra en cas de svrit CRITICAL, recevoir un SMS comme la Figure 32 le
montre.

Figure 32: Une remonte d'alarme par SMS
Etude de cas

75

Ce SMS informe que le port 1_201_43 de lADM de NKOMO une alarme
critique de nature LOS (Loss of Signal), cela due la communication et a t gnr
le 10-06-2012 10h 30 minutes 45 secondes
5.2.4 Lot 4 : Linterface Client et ses diffrentes fonctionnalits
Chaque utilisateur doit sauthentifier avant de pouvoir effectuer les oprations
diverses. La Figure 33 prsente les champs ncessaires (Login et Password) remplir
pour se connecter lapplication.

Figure 33: Page D'authentification
Une fois lauthentification russie, linterface principale suivante apparait. Elle
nous prsente larchitecture du rseau en place, elle nous propose galement une barre
de menues qui contient les diffrentes actions que nous pouvons mener.
Etude de cas

76

Figure 34: interface d'accueil
A partir de cette interface, nous pouvons obtenir des rsultats de performances,
alarmes et statistiques sur les quipements, comme le montre les Figures 35, 37, 39
suivantes.
La figure 31 nous prsente les indicateurs de performances sur les diffrents
quipements.
Etude de cas

77

Figure 35: Performances des quipements
Les diffrentes options de tri sur la Figure 35 permettent de faire des requtes :
Suivant le type de lquipement
Suivant le nom de lquipement ;
Suivant la priode (date inferieure et date suprieure) de recherche;
Suivant les seuils de performances des indicateurs.
Ou en faisant des combinaisons de ces diffrents critres de filtres
Les Figures 35, 36 et 37 suivantes nous prsentent les statistiques sur les
indicateurs de performance (ESR, SESR et DISPONIBILITE) sur le port 1_101_1 de
lADM_CTN. Ces statistiques permettront aux techniciens du centre de voir
lvolution des indicateurs pendant une priode, ceci dans loptique de pouvoir
prvenir les alarmes.
Etude de cas

78

Figure 36: Courbes de performance ESR du port 1_101_1 de lADM_CTN pendant une priode

Figure 37: courbes disponibilit d'un port pendant une priode
Etude de cas

79

Figure 38: courbes de performance SESR pendant une priode
Etude de cas

80

Figure 39: Alarmes reus
Les diffrentes options de tri sur la Figure 39 permettent de faire des requtes :
Suivant le type de lquipement
Suivant le nom de lquipement ;
Suivant la priode (date inferieure et date suprieure) de recherche;
Autre chose que la plateforme nous propose cest la gnration sur demande,
des rapports. Pour le moment lapplication ne permet de gnrer que deux rapports
savoir, la capacit doccupation des ADMs et la matrice des trafics vhiculs sur le
rseau entier. Les Figures 40 et 41 nous prsentent ces diffrents rapports. Ces
rapports constituent un rel outil de planification et doptimisation du rseau.
Etude de cas

81

Figure 40: Rapport de Capacit des ADMs

Figure 41: Graphe capacit des ADMs du CJUY
Conclusion

82

5.3 Conclusion
Ce chapitre a mis en exergue les diffrents aboutissements de nos travaux sur la
maintenance prventive par la gestion des services et le suivi des indicateurs de
performance du rseau SDH/FO. Actuellement, nous allons faire un bilan du travail
accompli ensuite, ouvrir des perspectives sur lavenir pour des ventuelles
amliorations de ces rsultats.

Conclusion et Perspectives

83

Conclusion et
Perspectives
Bilan du Travail

84

Nous avions pour objectifs de concevoir et raliser un outil daide la
maintenance prventive bas sur la gestion des services et le suivi de la performance
du rseau SDH par Fibre Optique. Au terme de ce travail, nous avons dvelopp une
application client-serveur qui prend en charge de faon automatique les fonctions
suivantes dans le rseau :
La gestion (Cration, Modification, Suppression, consultations) des services,
des quipements et des conduits qui constituent le rseau SDH/FO du rseau de
Camtel.
Le rapatriement des fichiers de performance et des alarmes des quipements
SDH travers un dialogue quotidien avec le serveur de supervision TNMS.
La mise en forme et le chargement des donnes rapatries dans une base de
donnes ;
La mise la disposition des quipes dexploitation et de maintenance les
indicateurs de qualit de performance du rseau SDH travers une application
JAVA Standalone sur le rseau interne.
La remonte automatique des alarmes par SMS,
Tout Ceci dans loptique de mettre en place une politique de maintenance
rapide et efficace dans la gestion des ressources matrielles
Nous pouvons donc affirmer sans pour autant prtendre lexhaustivit que
toute lanalyse et toute la conception du projet ont t faites conformment notre
cahier de charge. Limplmentation a t amorce et ncessite davantage de temps
pour en arriver une solution totalement exploitable par les quipes dexploitation et
maintenance de lentreprise. Le dploiement dun tel outil permettra ces quipes
davoir constamment et automatiquement les informations utiles sur ltat et la qualit
de fonctionnement des quipements SDH du rseau. Cette plateforme concoure
galement rendre plus souple lanalyse des indicateurs de qualit de transmission et
donc une maintenance proactive des quipements.
Perspectives

85

En guise de perspectives ce travail dans le fond et dans la forme peut subir des
amliorations. En effet dans un point de vue conceptuel il serait trs utile selon le
responsable de la supervision du rseau national de CAMTEL, dtendre les
fonctionnalits de supervision et de gestion de cette plateforme diffrents types de
rseaux, savoir CDMA, EWSD et bien dautres, ceci dans loptique de faire une
relle corrlation entre les performances et les alarmes de ces rseaux dans un contexte
dinteroprabilit afin doffrir une politique convergente et harmonise doptimisation.
Une autre perspective est dassocier cette mme plateforme une base de
connaissance sur les actions mener pour rsoudre un incident. Cette base devra tre
consultable partout et suivant nimporte quelle plateforme (Web, Console, Standalone
) et ce de faon scuris via VPN. Lobjectif principal de cette base de connaissance
est de permettre une maintenance efficace, rapide et objective tout en se basant sur les
actions correctives et prventives qui ont dj t mens dans le mme cas de figure.
Il serait aussi fort intressant que la plateforme puisse fournir une interface de
communication bidirectionnelle par SMS de telle sorte que les techniciens puissent
envoyer un SMS au systme afin dtre inform sur ltat du rseau, dun quipement,
dun conduit, ou encore dun service spcifique.

Bibliographie

a

[1] Nazim Agoulmine Omar Cherkaoui ; Pratique de la gestion de rseau [Groupe
Eyrolles, 2003] ; Chapitre 1
[2] Mmoire de fin dtudes de ltudiant NGANYEP NANA Lopold Conception
et ralisation dune plateforme de maintenance prventive et performance rseau
de transmission SDH par faisceaux hertziens : Cas du rseau Orange
Cameroun , Ecole National Suprieur Polytechnique de Yaound, promotion 2006.
[3] Mmoire de fin dtudes de ltudiant Ahmed KRICHEN, Conception dun
outil de suivi des performances des liens radio SDH du rseau GSM de
TUNISIANA , lcole suprieur des communications de Tunis (SUPCOM),
Promotion 2009.
[4] Support de cours, UV TDRN 501, Transmission de donnes et Rseaux
Numriques, Ecole National Suprieur Polytechnique de Yaound, Pr. Emmanuel
TONYE,
[5] G.826 (02/99), SERIES G: TRANSMISSION SYSTEMS AND MEDIA,
DIGITAL SYSTEMS AND NETWORKS, Digital transmission systems Digital
networks Quality and availability targets, ITU-T, Error performance parameters
and objectives for international, constant bit rate digital paths at or above the
primary rate
[6] AT Commands for CDMA Wireless Modems, Multi-Tech Systems, Inc,
[7] Benot de DINECHIN, La SDH ; http://www.epinard.free.fr

Bibliographie
Annexes

b

Annexe A : Photos dquipements dun rseau SDH et Fibre
Optique

Figure 43: Tiroir Optique

Annexe B : Synoptique dune liaison BSC-BTS
ADM CTN
Siemens
ADM JAMOT
Siemens
36 - 72V= 1- 0.5A
A
CONSOLE
B
+- +- Modem Otique/Electrique
Rpartiteur ADM JAMOT
Cat alyst 2950 SER IES 10BaseT/100BaseTX
SYST RPS
STAT UTIL DUPLX SPEED
MODE
1x 8x 7x 6x 5x 4x 3x 2x 12x 11x 10x 9x 16x 15x 14x 13x 22x 21x 20x 19x 18x 17x 23x 24x 24x 24x
100Base-FX
Tiroir Optique
36 - 72V= 1- 0.5A
A
C ONSOLE
B
+- +- Modem Otique/Electrique
DDF
Cat alyst 2950 SERIES 10BaseT/100BaseTX
SYST RPS
STAT UTIL DUPLX SPEED
MODE
1x 8x 7x 6x 5x 4x 3x 2x 12x 11x 10x 9x 16x 15x 14x 13x 22x 21x 20x 19x 18x 17x 23x 24x 24x 24x
100Base-FX
Tiroir Optique 36- 72V= 1- 0.5A
A
CON SOLE
B
+-+- Modem Otique/Electrique
Catalyst 2950 SERI ES 10BaseT/100BaseTX
SYST RPS
STAT UTIL DUPLXSPEED
MODE
1x 8x 7x 6x 5x 4x 3x 2x 12x 11x 10x 9x 16x 15x 14x 13x 22x 21x 20x 19x 18x 17x 23x 24x 24x 24x 100Base-FX
Tiroir Optique
Rpartiteur BSC
HEWLETT
PACKARD
COMP ACT
BSC CTN
Re set
HE WLETT PA CKAR D NetServer 5/100 LH.
1 2
Tap e Cl ean
H EWL ET T P AC KA R D J etSt ore 6000
1 2 3
10GB 10GB 10G B
4 5 6 BTS MESSASSI, CDMA EVDO 1x, 800Mhz
FO
FO
FO
FO
Fibre optique Metro
STM-16
F
i
b
r
e

o
p
t
i
q
u
e
F
i
b
r
e

o
p
t
i
q
u
e

S
T
M
-
1
ADM CTN
Huawei
Fibre optique
STM-1
F
i
b
r
e

o
p
t
i
q
u
e

S
T
M
-
1
FO
FO

Figure 44: Liaison BTS-BSC
Annexes

Figure 42: SURPASS hiT 7070

Annexes

c

Annexe C : Code denvoi de SMS

Annexe D : Quelques Commandes AT
Nous nous intresserons exclusivement aux commandes AT qui permettent
lenvoi des SMS.
Commandes Description
Module de Contrle, dtat et didentification
AT ATtention
ATI Afficher toutes les informations didentification du produit
ATZ Rgler tous les paramtres courants du profile Utilisateur
SMS (Text /PDU)
AT+CMGF Slectionner le format des messages
AT+CMGF=1, pour le mode Texte
AT+CMGF=0, pour le mode PDU
AT+CMGS Envoyer un SMS
AT+CMGS= NumTel avec indicatif du pays (Ex :
+23722345690) Enter
>Votre message CntrlZ

Rapport KKR Conte Nu

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport KKR Conte Nu

Transféré par

Droits d'auteur :

Formats disponibles

Epigraphe

Vous aimerez peut-être aussi