Definiifparker88

Epigraphe
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues i
« J'éprouve l'émotion la plus forte devant le mystère de la vie.
Le sentiment fonde le beau et le vrai, il suscite l'art et la science. »
ALBERT EINSTEINALBERT EINSTEINALBERT EINSTEINALBERT EINSTEIN
Epigraphe

Dédicace
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues ii
Je dédie ce travail,
Au Dieu tout puissant sans qui rien n’est possible
A mes parents,
Papa KWATE Jean Ledoux
et
Maman KWATE née NZOUGONG Marie
madeleine
qui ont sacrifié des années de leurs vies pour que je
sois là aujourd'hui.
Dédicace

Remerciements
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues iii
u’il nous soit permis d’exprimer notre profonde gratitude et nos sincères
remerciements à toutes les personnes qui ont contribué de près ou de loin à
l’édification de ce travail. Nos pensées vont :
Au Dieu tout puissant à qui je rends grâce pour ce souffle de vie qu’il me donne.
Au Directeur de l’ISS de MAROUA, Pr.Dr.Ing.habil KOLYANG.
Au Directeur générale de Camtel, M. NKOTO EMANE David.
Au corps enseignant et administratif de l’ISS pour l’effort fourni dans le progrès de la
jeunesse estudiantine Camerounaise.
Au personnel de Camtel Yaoundé, et en particulier à ceux du Centre des Jonctions
Urbaines de Yaoundé pour l’accueil très chaleureux qu’ils m’ont réservés, je pense à
M. ONOMO Dieudonné, M. KOUAM Sylvestre, M. OVAMBE François
A mes encadreurs, académique Dr. VIDEME BOSSOU Olivier et professionnel M.
ONOMO Dieudonné pour leur soutient et les précieux conseils.
Aux membres du Jury qui ont accepté d’évaluer ce travail.
A toute la famille KWATE
A toute la famille TAMETHE, pour l’accueil et l’hébergement à Yaoundé, seul le
tout puissant vous remerciera à la juste valeur, je pense ainsi à Papa, Maman,
Tantine, Ulrich, Christelle, et surtout mon frère et ami Stéphane NZOKOU qui me
permet d’intégrer cette famille formidable.
A toute la famille de mon très cher ami et grand frère M. M’HAMED Amin, Sous-
préfet de l’arrondissement 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 frères, Ing. Jean Bosco KIAMPI FOPAK, Ing. Léopold NANA
NGANYEP pour les orientations de tout ordre.
A mes amis et frères d’enfance du quartier « Bepanda 7 » à Douala.
Q
Remerciements

Table des Matières
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues iv
Epigraphe _________________________________________________________________ i
Dédicace __________________________________________________________________ ii
Remerciements ____________________________________________________________ iii
Table des Matières _________________________________________________________ iv
Résumé - Abstract__________________________________________________________ vii
Liste des tableaux _________________________________________________________ viii
Liste des figures et illustrations _______________________________________________ ix
Glossaire __________________________________________________________________ x
Introduction Générale ______________________________________________________ 13
Chapitre 1 : Contexte et Problématique ________________________________________ 15
1.1 Introduction _______________________________________________________________ 15
1.2 Présentation de la structure d’accueil : CAMTEL___________________________________ 16
1.2.1 Bref Historique____________________________________________________________________ 16
1.2.2 Les services et produits offerts _______________________________________________________ 17
1.2.2.1 L’Offre aux particuliers__________________________________________________________ 17
1.2.2.2 L’Offre aux entreprises__________________________________________________________ 18
1.2.3 Infrastructures et Données Clés ______________________________________________________ 18
1.2.4 Organigramme Administrative _______________________________________________________ 20
1.3 Problème posé _____________________________________________________________ 22
1.4 Objectifs à atteindre_________________________________________________________ 24
1.5 Méthodologie ______________________________________________________________ 25
1.6 Conclusion_________________________________________________________________ 26
Chapitre 2 : Généralités _____________________________________________________ 27
2.1 Introduction _______________________________________________________________ 27
2.2 Les supports de transmission dans les réseaux Métropolitains : 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 hiérarchie numérique plésiochrone_________________________________________________ 30
2.3.1.1 Les insuffisances de la PDH ______________________________________________________ 30
2.3.2 La hiérarchie numérique synchrone ___________________________________________________ 31
2.3.2.1 Définition des éléments de la hiérarchie synchrone________________________________ 33
2.3.3 Architecture et équipements d’un réseau SDH : Cas CAMTEL ____________________________ 36
2.3.3.1 Architecture _______________________________________________________________ 36
2.3.3.2 Les équipements ___________________________________________________________ 37
2.3.3.3 Les services Véhiculés dans la boucle Métropolitaine ______________________________ 41
Table des Matières

Table des Matières
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues v
2.3.4 Les indicateurs de performance d’un réseau de transmission____________________________ 42
2.3.5 Les alarmes dans un réseau SDH ___________________________________________________ 46
2.4 Conclusion_________________________________________________________________ 49
Chapitre 3 : Réalisation de l’outil de gestion des services et suivi des performances :
Analyse __________________________________________________________________ 50
3.1 Introduction _______________________________________________________________ 50
3.2 Analyse de l’outil 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 d’acquisition des données __________________________________________________ 52
3.2.3 Architecture de la plateforme________________________________________________________ 53
3.2.3.1 Module de rapatriement des données_____________________________________________ 54
3.2.3.2 Module de traitement et mise dans la Base de Données_______________________________ 54
3.2.3.3 Module de remontée des alarmes par SMS _________________________________________ 55
3.2.3.4 Module de présentation des données aux utilisateurs ________________________________ 55
3.3 Conclusion_________________________________________________________________ 56
Conception et réalisation ____________________________________________________ 57
4.1 Introduction _______________________________________________________________ 57
4.2 Conception de l’application ___________________________________________________ 58
4.2.1 Diagrammes des Cas d’utilisation_____________________________________________________ 58
4.2.2 Diagramme des classes _____________________________________________________________ 61
4.2.3 Diagramme de séquences___________________________________________________________ 64
4.3 Réalisation de l’application ___________________________________________________ 65
4.3.1 L’Environnement de travail__________________________________________________________ 65
4.3.2 Les Choix techniques de réalisation ___________________________________________________ 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 Stratégie de remontée automatique des alarmes par SMS _____________________________ 67
4.4 Conclusion_________________________________________________________________ 69
Chapitre 5 : Résultats et Commentaires ________________________________________ 70
5.1 Introduction _______________________________________________________________ 70
5.2 Quelques résultats __________________________________________________________ 71
5.2.1 Lot 1 : Rapatriement des fichiers _____________________________________________________ 71
5.2.3 Lot 2 : Acquisition des données et chargement dans la base de données _____________________ 73
5.2.3 Lot 3 : Remontée automatique des alarmes par SMS _____________________________________ 73
5.2.4 Lot 4 : L’interface Client et ses différentes fonctionnalités _________________________________ 75
5.3 Conclusion_________________________________________________________________ 82
Conclusion et Perspectives ___________________________________________________ 84

Table des Matières
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues vi
1. ___________________________________________________________________________ 84
Bibliographie_______________________________________________________________a
Annexes___________________________________________________________________b
Annexe A : Photos d’équipements d’un réseau SDH et Fibre Optique______________________ b
Annexe B : Synoptique d’une liaison BSC-BTS_________________________________________ b
Annexe C : Code d’envoi de SMS ____________________________________________________c
Annexe D : Quelques Commandes AT ________________________________________________c

Résumé - Abstract
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues vii
Résumé
’objectif de ce mémoire est de concevoir et réaliser un outil pour le suivi des
performances des liaisons Optiques SDH dans le cadre de la boucle
métropolitaine de Yaoundé.
Pour atteindre cet objectif, nous avons d’abord commencé par étudier les
techniques de multiplexage, SDH et PDH, ainsi que la transmission par Fibre optique.
Ensuite, nous avons présenté des rappels sur les indicateurs de performance. En fin,
nous avons étudié l’outil (TNMS-Télécommunication Network Management System)
utilisé par la Cameroon Télécommunication (CAMTEL) dans la boucle
métropolitaine de Yaoundé. Cette étude nous a permis montrer ses faiblesses et le
besoin d’un outil complémentaire qui apporte d’autres fonctionnalités en termes de
gestion des services et de suivi des performances. Nous avons réalisé, après une étape
d’analyse et de conception, l’outil de gestion METROPERF_CJU V1.0. L’outil
permet la gestion des services, le rapatriement automatique et périodique des logs et le
suivi des performances.
Mots clés : 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
Résumé - Abstract

Liste des Tableaux
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues viii
Tableau 1: Les capacités d’accès Internet exploitées par Camtel._____________________________________ 20
Tableau 2: Les différents containers Cn _________________________________________________________ 33
Tableau 3: Les cartes du HIT 7070______________________________________________________________ 40
Tableau 4: Les Cartes du HIT 7060 _____________________________________________________________ 40
Tableau 5: Caractéristiques cibles des paramètres d'erreur. Réf [5] ___________________________________ 44
Tableau 6: Les types d'évènement _____________________________________________________________ 47
Tableau 7: Sévérité des alarmes _______________________________________________________________ 48
Liste des tableaux

Liste des figures et illustrations
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues ix
Figure 1: le câble SAT3/WASC/SAFE (source : www.safe-sat3.co.za, Octobre 2003) ______________________ 16
Figure 2: Organigramme de CAMTEL ___________________________________________________________ 21
Figure 3: Principe de réflectométrie ____________________________________________________________ 22
Figure 4: Propagation de la lumière dans les trois types de fibre _____________________________________ 29
Figure 5: Les débits plésiochrone définis 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 réseau SDH. Ref [3] _____________________________________________ 33
Figure 9: Structure du multiplexage Synchrone. Ref [4] ____________________________________________ 34
Figure 10: Limite des RS, MS, VC sur le réseau SDH. _____________________________________________ 35
Figure 11: Organisation de la trame STM1_______________________________________________________ 36
Figure 12: Boucle Métropolitaine SDF/FO Siemens de Camtel Yaoundé ________________________________ 37
Figure 13: Principe d'un ADM _________________________________________________________________ 38
Figure 14: Exemple d'un réseau SDH. Ref [4] _____________________________________________________ 38
Figure 15: diagramme illustrant la détection d'anomalies, de défauts 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 Générale _______________________________________________ 59
Figure 19: Diagramme de cas d'utilisation pour la consultation de l'état du réseau ______________________ 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 modélisation sans ORM ________________________________________________ 66
Figure 24: Architecture de modélisation avec ORM ________________________________________________ 66
Figure 25: Configuration du serveur ___________________________________________________________ 71
Figure 26: Page d'accueil du serveur lorsqu'il est lancé _____________________________________________ 71
Figure 27: répertoire 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 remontée des alarmes par SMS/MAIL_________________________________ 74
Figure 32: Une remontée 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 l’ADM_CTN pendant une période_____________ 78
Figure 37: courbes disponibilité d'un port pendant une période ______________________________________ 78
Figure 38: courbes de performance SESR pendant une période_______________________________________ 79
Figure 39: Alarmes reçus _____________________________________________________________________ 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
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues x
A
ADM Add and Drop Multiplexer (Insertion/Extraction de signaux
numériques)
ADSL Asymmetric Digital Subscriber Line (réseau de raccordement
numérique asymétrique)
Alignement
(Justification)
Opération permettant de préserver l’intégralité 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 Télégraphique et
Téléphonique)
CDMA Code Division Multiple Access
CTN Centre Transmission Numérique
F
FEBE Far End Block Error (nombre de blocks reçus erronés)
FERF Far End Remote Failure défaut à l'extrémité distante
FTP File Transfert Protocol, Protocole de manipulation et de transfert
de fichiers à distance.
I
INFOTEL INFOrmatique et TELécommunications
ISS Institut Supérieur du Sahel
M
MSOH Multiplex Section OverHead (Surdébit de section de multiplexage)
N
NG-SDH Next Generation Synchronous Digital Hierarchy
O
ORM Object Relational Mapping
P
PDH Plésiochrone Digital Hierarchy (Hiérarchie numérique
plésiochrone), Deux signaux sont dits plésiochrones lorsque leurs
instants significatifs correspondants se présentent à la même
cadence nominale
POH Path Other Head (Surdébit de gestion)
R
RNIS Réseau Numérique à Intégration de Services
RSOH Regenerator Section OverHead (Surdébit de section de
Glossaire

Glossaire
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues xi
rgénération)
RTC Réseau Téléphonique Commuté
S
SDH Synchronous Digital Hierarchy (Hiérarchie numérique synchrone)
SGBD Système de Gestion de Base de Données
SMS Short Message Service
SONET Synchronous Optical NETwork (Réseau Optique Synchrone)
STM Synchronous Transport Module (Module de transport synchrone)
T
TNMS Télécommunication Network Management System
U
UIT-T Union Internationale des Télécommunications Bureau de la
normalisation des télécommunications
UML Unified Modeling language
V
VSAT Very Small Aperture Terminal

Introduction Générale
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues 12
Introduction
générale

es réseaux de transmission définissent les chemins permanents permettant de
transporter de manière transparente d’un point à un autre les services Voix,
Données ou Vidéo. Les nœuds et les liens que nous y trouvons sont utilisés pour créer
les conduits avec une bonne qualité de service tout en surveillant cette qualité. Les
technologies de multiplexage hiérarchique sont utilisées en transmission pour éviter de
réserver une ressource physique à un utilisateur et parvenir à une gestion plus
modulaire de la capacité. Les problèmes de propagation du signal dans un guide
d’onde et bien d’autres événements perturbateurs dus au fonctionnement des
équipements provoquent une détérioration de la qualité du signal. Cette détérioration
peut aller jusqu’à la rupture totale des liaisons.
Les tâches de maintenance préventive dans le réseau de transmission permettent
d’anticiper sur les incidents (liés aux équipements et conduits) qui pourraient entraîner
ces perturbations du trafic et donc un grand désarroi chez les clients. La gestion des
performances (Performance Monitoring) du réseau de transmission permet de mesurer
et quantifier la qualité de la transmission pendant une période donnée. Elle permet à
l’opérateur de s’assurer que les indicateurs de qualité (secondes erronées, secondes
indisponibles, Blocs erronés, taux d’erreur …) sur chaque conduit ou sur le réseau
globalement respectent les objectifs définis par la norme.
C’est dans cet ordre d’idées que s’inscrit ce projet de fin d’études. Projet que
j’ai eu l’occasion de mener au sein du Centre des Jonctions Urbaines (CJU) de
Yaoundé de l’entreprise Cameroon Telecommunications. Le travail à faire consiste à
concevoir et à mettre en œuvre « un outil de gestion des services et de suivi des
performances dans un réseau de transmission : Application à la boucle SDH/FO
de Camtel Yaoundé».
Le présent mémoire est organisé en cinq chapitres. Dans le premier chapitre,
nous parlerons du cadre de travail et du sujet, nous y présenterons également
l’environnement 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 réseau de transmission SDH. Le troisième chapitre
L

sera réservé à l’analyse de la plateforme à développer, nous y présenterons le cahier
des charges, les protocoles d’acquisition des données et l’architecture de notre système
ainsi que le diagramme des cas d’utilisation. Le quatrième chapitre s’intéressera à la
conception et la réalisation de l’outil. Enfin, le dernier chapitre concerne la
présentation des résultats obtenus et commentaires.

Chapitre 1 : Contexte et Problématique
Aperçu et Introduction
Aperçu
Chapitre 1 : Contexte et Problématique ________________________________________ 15
1.1 Introduction _______________________________________________________________ 15
1.2 Présentation de la structure d’accueil : CAMTEL___________________________________ 16
1.2.1 Bref Historique____________________________________________________________________ 16
1.2.2 Les services et produits offerts _______________________________________________________ 17
1.2.2.1 L’Offre aux particuliers__________________________________________________________ 17
1.2.2.2 L’Offre aux entreprises__________________________________________________________ 18
1.2.3 Infrastructures et Données Clés ______________________________________________________ 18
1.2.4 Organigramme Administrative _______________________________________________________ 20
1.3 Problème posé _____________________________________________________________ 22
1.4 Objectifs à atteindre_________________________________________________________ 24
1.5 Méthodologie ______________________________________________________________ 25
1.6 Conclusion_________________________________________________________________ 26
1.1 Introduction
Ce chapitre nous plonge dans le contexte de l’étude de notre projet et reprend
les différentes parties qui seront développées tout au long de notre mémoire. Une
attention particulière sera portée sur la méthodologie et les résultats qui constituent
notre apport personnel.
ChapitreChapitreChapitreChapitre
1

Présentation de la structure d’accueil : CAMTEL
1.2 Présentation de la structure d’accueil : CAMTEL
1.2.1 Bref Historique
amtel est née en 1998 de la transformation de la direction des
télécommunications (Ministère des postes et télécommunications) en
société anonyme à laquelle s'ajouta l'entreprise publique Intelcam, alors en charge des
communications téléphoniques internationales. La filiale de téléphonie mobile,
Camtel-Mobil, fut vendue à l'opérateur de télécommunication MTN en février
2000.Ces changements sont intervenus lors de la libéralisation du secteur des
télécommunications au Cameroun.
En 2005, la société a lancé le service de téléphonie Mobile CT-Phone, basée sur
la technologie CDMA. Au cours de l’année 2009, elle a enfin acquis une licence
GSM (principal attrait des investisseurs). Pour ce qui est de la fourniture d’accès
Internet, après l’arrimage du Cameroun au réseau transcontinental du système
SAT3/WASC/SAFE (South Atlantic câble N°3/West African Submarine Cable/South
Africa Far East) en 2003, CAMTEL a largement densifié son offre Internet aussi bien
aux particuliers qu’aux entreprises, parmi lesquelles de nombreux fournisseurs
d’accès.
Figure 1: le câble SAT3/WASC/SAFE (source : www.safe-sat3.co.za, Octobre 2003)
Avec le déploiement de la fibre optique sur le territoire national (plus de 5600
km de longueur prévu), CAMTEL compte capitaliser sur cette dernière pour réaliser
C

une dorsale nationale de transmission appelée « Backbone » qui sera utilisé par tous
les opérateurs des télécommunications et surtout qui lui facilitera la mise en place de
ses réseaux d’entreprises.
1.2.2 Les services et produits offerts
L’entreprise CAMTEL est l’opérateur public de téléphonie au Cameroun. Au
rang des services qu’il fournit, on peut citer principalement :
La téléphonie fixe (Avec ou sans fil)
La téléphonie mobile type CDMA (Offre « City Phone »)
Internet (par Dial-up, ADSL, VSAT, Wireless …)
Les réseaux d’Entreprises (lignes spécialisées, VSAT, …)
Ces principaux services sont offerts sous deux formes : l’offre aux particuliers
et l’offre aux entreprises.
1.2.2.1 L’Offre aux particuliers
L’offre aux particuliers regroupe principalement trois services : la téléphonie,
l’accès Internet et les services Internet.
La téléphonie
Le service de téléphonie regroupe quatre principales offres :
Le fixe filaire
Le CT Phone
La télécopie (Fax)
Le téléphone de masse
L’accès Internet
Le réseau Internet est accessible par deux nœuds d'accès au Backbone
international à Douala et Yaoundé à travers le câble sous-marin SAT3 pour un débit
total de 933Mb/s (soit 622Mb/s à Douala et 311Mb/s à Yaoundé).
Ce débit est appelé à croître dans un futur proche compte tenu de la demande
sans cesse croissante. Les principaux moyens d’accès à Internet offerts par CAMTEL
aux particuliers sont : le RTC, l’ADSL, le CT Phone, le RNIS et le Wireless.
Les cartes prépayées s'acquièrent par achat direct auprès des distributeurs ou
des Agences Commerciales Camtel. Elles se présentent sous quatre formes : Easy
Recharge, Easy call, E@sy Net et A puce.

Les services Internet
Les services Internet offerts sont de quatre types :
L’allocation des noms de domaine (.tv, .org, .biz, .net, …)
La création des sites Internet
L’hébergement des sites Internet
E-mail perso
Tous ces services constituent les offres proposés aux particuliers.
1.2.2.2 L’Offre aux entreprises
Les offres aux entreprises sont cataloguées comme suit :
Solution Téléphonie fixe
Offres préférentielles
Numéro vert
Solution de Mobilité
Easy Pro
Business Privilege
Solution Internet Pro
LS filaires (Liaisons Spécialisées) Urbaines et Interurbaines
Liaison sans fil
ADSL haut débit
Sites et applications web
Hébergement professionnel
Nom de domaine
Messagerie d'entreprise
E-publicité
Réseaux d'Entreprise
LS Nationales
LS Internationales
Faisceau hertzien (VSAT, …)
1.2.3 Infrastructures et Données Clés
Pour faire face aux nombreux besoins des particuliers comme les
entreprises, la CAMTEL est dotée de :

- 47 centraux téléphoniques entièrement numériques et autant de réseaux locaux
pour un parc de 153.818 lignes téléphoniques en réseau de câble et 140.946 en
commutation. Le programme de modernisation des infrastructures prévoit l'extension
de tous les centraux téléphoniques.
- 76 concentrateurs permettant d'offrir la téléphonie rurale à autant de localités pour
une capacité de 10940 lignes.
- Un réseau national de transmission en numérisation 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 télécommunications par satellite à Bépanda, Zamengoé et Garoua
qui comptent parmi les plus modernes au monde et disposent de stations terriennes
gérées par ordinateurs, de deux autocommutateurs numériques pour le transit
international et un hub pour les systèmes VSAT. Le Cameroun est ainsi relié au reste
du monde par numérotation directe automatique.
- 2 autocommutateurs électroniques qui assurent le trafic télex national et
international, auxquels sont reliés 109 centres d'exploitation télégraphique.
- SAT3
- Fibre optique
Enfin, CAMTEL s'est associée aux organismes INTELSAT et INMARSAT
pour offrir grâce à leurs satellites des solutions de transmission de la voix, des
données, et des images par VSAT ou par petites unités portatives.
Liaisons d’accès
Satellite Fibre Optique SAT-3Année
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

2007 0 310 Mb/s
2008 0 455 Mb/s
2009 0 933Mb/s
Tableau 1: Les capacités d’accès Internet exploitées par Camtel.
Ainsi, le débit d’accès à l’international est passé de 8Mbps à un débit de
933Mbps entre 2003 et 2009, grâce à la Fibre Optique SAT3.
Actuellement, CAMTEL ne dispose pas d'autres systèmes de câble de
réacheminement du trafic en cas de panne sur la liaison SAT-3. Pour éviter des
incidents comme celui vécu 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 (Câble sous-marin de la côte Ouest de l'Afrique).
Pour ce qui est des réseaux d’entreprises, grâce à une infrastructure fortement
déployée à l’échelle nationale (des boucles métropolitaines optiques largement
densifiées notamment dans les villes de Douala et Yaoundé et de grandes boucles
interurbaines) CAMTEL est le principal opérateur au Cameroun actuellement offrant
ce type de services aux entreprises ou organisations ayant des besoins de raccordement
à leurs différents sites. Pour cette offre, son principal client reste l’Etat camerounais
(interconnexion des ministères, délégations régionales, …).
1.2.4 Organigramme Administrative
Placée sous la tutelle du MINPOSTEL (Ministère des Postes et
Télécommunications), CAMTEL est dotée d'un Conseil d'Administration composé
comme suit :
Un président ;
Six membres représentant l'État du Cameroun;
Un membre représentant le personnel ;
Un membre représentant la Commission Technique de Privatisation
et des Liquidations.
Ce conseil se prononce régulièrement (en conseils ordinaires et extraordinaires)
sur les grandes orientations stratégiques de l'entreprise. La gestion quotidienne de la
société est assurée par un Directeur Général assisté de deux Directeurs Généraux
adjoints.

Figure 2: Organigramme de CAMTEL

Problème posé
1.3 Problème posé
Il ressort de la phase d’imprégnation de notre stage un certain nombre de
constats :
La création des services, ou encore l’enregistrement des équipements se
faisait uniquement de façon manuelle dans des registre.
La maintenance dans le centre est essentiellement curative et basée sur
deux principes : la boucle et la réflectométrie.
La boucle
Ce principe consiste à réaliser des boucles de proche en proche à travers les
répartiteurs afin de pouvoir déceler exactement sur qu’elle portion de la liaison il y’a
problème.
La réflectométrie
Par rapport à la réflectométrie, il nous permet de mesurer l’état d’une liaison et
de ressortir des informations telles que le taux d’erreurs, le niveau du signal en
émission et en réception. Cela nous permet également en cas de défaillance
(généralement coupure de la fibre optique) de savoir à quelle distance cela s’est
produit. Son principe est résumé sur la figure 3 suivante.
Figure 3: Principe de réflectométrie

Problème posé
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 d’efficacité dans les interventions. Il faut surtout
préciser un défaut d’archivage des alarmes.
Au vu et su de tous ces constats, notre problématique peut se résumer en cinq
questions fondamentales qui présentent les manquements du système actuel :
Comment automatiser les opérations de gestion des services (création,
modification, visualisation, suppression …)?
Comment rapatrier (protocole) sur un poste d’exploitation les logs (alarmes et
performances) générés depuis les équipements vers le serveur TNMS ?
Comment surveiller de façon automatique l’activité du réseau, analyser sa
performance (équipements et surtout les conduits véhiculant des services
divers) et signaler les dépassements de seuils ?
En d’autres termes comment faire des prévisions sur l’état de fonctionnement
des équipements à partir des statistiques de progression liées aux
performances?
Comment remonter une alarme jusqu’au téléphone portable d’un technicien du
centre ?

Objectifs à atteindre
1.4 Objectifs à atteindre
Les objectifs fixés dans le cadre de ce projet consistent à proposer une solution
logicielle permettant de :
Communiquer de façon journalière et périodique avec le serveur de
supervision TNMS pour rapatrier automatiquement les logs d’alarmes et de
performances.
Analyser de façon périodique les logs rapatriés 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 l’optique de mettre
en place une politique de maintenance préventive et de fournir aux techniciens
des pistes d’optimisation
Fournir des interfaces permettant d’automatiser la gestion des services, des
conduits, des fibres et des équipements via des opérations de création,
modification, suppression, consultation. Ceci dans le but de produire également
des rapports d’état ou d’occupation du réseau et des matrices de trafic qui
actuellement se font manuellement.
Déclencher des alertes SMS vers les techniciens du centre en cas de
défaillances majeures dans le réseau ceci dans l’optique de réduire le temps de
réaction face à un problème, car les problèmes nous sont généralement signalés
par les responsables des services que nous transportons (Cas du BSS qui nous
informe généralement des BTS qui ne fonctionnement pas).
Sauvegarder toutes ces informations dans une base de données pour des
besoins futures.

Approche ou Méthodologie
1.5 Méthodologie
Au vue de tout ce qui a été présenté dans le contexte, la problématique et les
objectifs, nous avons entrepris une démarche méthodologique qui s’étend sur les
quatre grandes étapes résumées comme suit :
Etape 1
• Etudier la politique de maintenance et d’optimisation existante.
Etape 2
• Etudier globalement les réseaux de transmission et particulièrement
ceux a base des technologies à hiérarchie numérique synchrone.
• Etudier les indicateurs de performance dans les réseaux de
transmission numérique.
Etape 3
• Mettre en place un 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 remontée automatique des
alarmes par SMS.
Etape 4
• Effectuer des tests pour la validation de l'application.
• Formuler les perspectives.

Chapitre 2 : Généralités
Conclusion
1.6 Conclusion
Dans ce premier chapitre, nous avons présenté le cadre de ce projet de fin
d’études ainsi que le sujet à traiter qui est le « développement d’un outil pour la
gestion des services et le suivi des performances des liens Optiques SDH ». Dans
le chapitre suivant il sera premièrement question d’étudier le support de transmission
fibre optique. Deuxièmement d’étudier les techniques de multiplexage PDH, SDH.
Troisièmement de passer en revue la topologie, les indicateurs de performances et la
supervision dans un réseau SDH.

Aperçu
Chapitre 2 : Généralités _____________________________________________________ 27
2.1 Introduction _______________________________________________________________ 27
2.2 Les supports de transmission dans les réseaux Métropolitains : 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 hiérarchie numérique plésiochrone_________________________________________________ 30
2.3.1.1 Les insuffisances de la PDH ______________________________________________________ 30
2.3.2 La hiérarchie numérique synchrone ___________________________________________________ 31
2.3.2.1 Définition des éléments de la hiérarchie synchrone________________________________ 33
2.3.3 Architecture et équipements d’un réseau SDH : Cas CAMTEL ____________________________ 36
2.3.3.1 Architecture _______________________________________________________________ 36
2.3.3.2 Les équipements ___________________________________________________________ 37
2.3.3.3 Les services Véhiculés dans la boucle Métropolitaine ______________________________ 41
2.3.4 Les indicateurs de performance d’un réseau de transmission____________________________ 42
2.3.5 Les alarmes dans un réseau SDH ___________________________________________________ 46
2.4 Conclusion_________________________________________________________________ 49
2.1 Introduction
Ce Chapitre décrit les généralités en relation avec notre projet. En effet il sera
tout d’abords question de présenter le support de transmission fibre Optique, en suite
de mettre en évidence les techniques à hiérarchie numérique plésiochrone et
synchrone, enfin de ressortir les indicateurs de performances et les alarmes dans les
réseaux de transmission.
2

Les supports de transmission dans les réseaux Métropolitains : cas de la Fibre Optique
2.2 Les supports de transmission dans les réseaux
Métropolitains : cas de la Fibre Optique
Le réseau 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 données à haut débit grâce à
des rayons optiques. La fibre optique est constituée de trois éléments :
Le cœur, partie de la fibre optique servant à la propagation des rayons
lumineux ;
La gaine optique, entourant le cœur, constitué d’un matériau dont l’indice de
réfraction est inférieur à celui du cœur, de telle manière à confiner la
propagation des rayons lumineux ;
Le revêtement de protection, chargé de protéger la gaine optique des
dégradations physiques.
2.2.1 Les trois types de fibre optique
La fibre à saut d'indice constituée d'un cœur et d'une gaine optique en verre de
différents indices de réfraction. Cette fibre provoque de par l'importante section
du cœur, une grande dispersion des signaux la traversant, ce qui génère une
déformation du signal reçu. Elle est généralement utilisée pour de courtes
distances (LAN et MAN) tout comme la fibre à gradient d’indice. L’émetteur
utilisé ici est la LED.
La fibre à gradient d'indice dont le cœur est constitué de couches de verre
successives ayant un indice de réfraction proche. On s'approche ainsi d'une
égalisation des temps de propagation, ce qui veut dire que l'on a réduit la
dispersion nodale. Bande passante typique 200-1500Mhz par km. C'est ce type
de fibre qui est utilisé à l'intérieur des bâtiments de l'Université (62.5/125) et
entre certains sites desservis par les PTT (50/125).
La fibre monomode dont le cœur est si fin que le chemin de propagation des
différents modes est pratiquement directe. La dispersion nodale devient
quasiment nulle. La bande passante transmise est presque infinie (> 10Ghz/km).
Cette fibre est utilisée essentiellement pour les sites à distance (réseaux MAN et

Les supports de transmission dans les réseaux Métropolitains : cas de la Fibre Optique
WAN). Le petit diamètre du cœur (10um) nécessite une grande puissance
d'émission, donc des diodes au laser qui sont relativement onéreuses.
Figure 4: Propagation de la lumière dans les trois types de fibre
Le réseau de transmission SDH utilise comme support physique pour relier ses
MIE des fibres optiques monomodes, correspondant à la recommandation G.652 de
l’IUTT. La fibre optique utilise les longueurs d’onde autour de 1300nm et 1550nm.

Les techniques de multiplexage
2.3 Les techniques de multiplexage
Le multiplexage consiste à faire passer plusieurs affluents sur un même tronçon
de réseau. On distingue ici deux techniques de multiplexage :
2.3.1 La hiérarchie numérique plésiochrone
La première technique de multiplexage numérique utilisée fut la technique
Plesiochronous Digital Hierarchy (PDH). Dans cette technique, les signaux
élémentaires sont multiplexés sans tenir compte de leur ordre d’arrivée. Le signal haut
débit obtenu est donc un mélange non ordonné de signaux bas débit ; il est impossible
d’identifier directement un signal bas débit dans le train haut débit. Pour retrouver le
signal bas débit, on est donc obligé d’effectuer les étapes inverses du multiplexage
(démultiplexage) ce qui est coûteux en équipement et en probabilité d’erreurs
matérielles. C’est une limitation forte de cette technique.
Dans ce mode, à chaque niveau sont insérés :
Un mot de verrouillage de trame,
Des bits de justification de niveau de multiplexage,
Des signaux de service.
La technique est « transparente », c’est-à-dire qu’elle ne fait pas d’hypothèse
sur la trame et la nature du signal.
2.3.1.1 Les insuffisances de la PDH
Cette technique, par ailleurs éprouvée, comporte cependant les limitations indiquées
par la Figure 5
Figure 5: Les débits plésiochrone définis par l'UIT. Ref.[3]
En ce qui concerne les débits, les débits maxima normalisés se limitent à 140 Mbit/s.

La technique PDH est une technique de point à point, et non une technique de
réseau et qui conduit en outre à démultiplexeur à chaque point de service les
débits élémentaires pour les extraire, ce qui se traduit en des appareillages
compliqués et coûteux,
La technique PDH ne permet pas une organisation du réseau en anneau
permettant d’obtenir des disponibilités de service importantes,
La technique PDH ne prévoit pas l’existence de canaux de gestion et ne permet
pas une centralisation de l’exploitation d’un réseau national
La technique PDH ne permet pas l’interconnexion optique entre interface
provenant de constructeurs différents, car elle est sur 3 normes différentes
(AINSI aux USA, CEPT en EUROPE, et celle du Japon)
2.3.2 La hiérarchie numérique synchrone
Le réseau de transmission numérique actuel était basé sur l’utilisation de la
hiérarchie numérique plésiochrone. Cette technique s’est montrée, au fil des années,
quelque peu limitée. En effet, l’évolution des débits des différents services, les besoins
en flexibilité du réseau de transmission, la nécessité d’améliorer les fonctions
d’exploitation et de maintenance, l’augmentation continue de la capacité de
transmission sur fibre optique et le besoin d’interconnexion entre opérateurs à des
débits élevés et normalisés. Tous ces éléments ont montré les limitations de la
hiérarchie actuelle et ont conduit à la normalisation de la hiérarchie numérique
synchrone (SDH). Celle-ci, fondée sur les concepts de Synchronous Optical NETwork
(SONET), proposés par Bellcore en 1985, constitue une évolution importante des
réseaux de transmission. Les travaux de normalisation ont été lancés en 1986 au
CCITT. En 1988, un premier consensus permettait de définir les grands principes de
base de la norme SDH. Les travaux n’ont pas cessé depuis et se poursuivent
aujourd’hui en particulier sur les architectures du réseau, sa modélisation et sa gestion.
La SDH introduit de nouvelles possibilités dans les réseaux de transmission :
Souplesse accrue par la possibilité d’extraire ou d’insérer directement un signal
constituant du multiplex de ligne.

Facilités d’exploitation et de maintenance : des débits importants sont réservés
à ces fonctions.
Possibilité d’évolution vers des hauts débits : les trames synchrones haut débits
sont construites par multiplexage synchrone de l’entité de base. Cette entité de
base définit implicitement toutes les trames haut débit, la limitation n’est plus
que technologique.
Interconnexion de systèmes à haut débit facilitée par la normalisation de la
trame de ligne et des interfaces optiques correspondantes.
Architectures de réseaux assurant la sécurisation contre les défauts de ligne ou
d’équipement.
La modularité des équipements SDH est plus adaptée aux progrès de la
technologie des équipements plésiochrone.
Les éléments de base du multiplexage SDH
Les trains de signaux incorporés dans la trame synchrone, à savoir 1,5 ou 2
Mbit/s, admis cependant dans cette trame avec des déphasages dus aux temps de
propagation ou aux déphasages entre horloges. La trame comporte 270 colonnes de 9
octets, expédiés toutes les 125s, soit 8000 fois par seconde ou un débit de 155,520
Mbit/s. 9 colonnes d’octets sont réservées à la gestion de la section de multiplexage
qui a donc une « charge utile » (payload) de 2349 octets (9 lignes et 261 colonnes).
L’originalité de la technique SDH est l’utilisation de « pointeurs » et de la
« justification » positive, négative ou nulle, permettant de préserver l’intégralité et la
visibilité des affluents. Le pointeur repère à chaque instant l’adresse de l’information
utile dans la trame STMn.
Figure 6: Principe de Justification dans le SDH

2.3.2.1 Définition des éléments de la hiérarchie synchrone
Le conteneur Cn, le conteneur virtuel VCn
Les signaux plésiochrones sont insérés dans un conteneur désigné selon sa
« charge » comme nous montre le Tableau suivant:
Dénomination Débit (Mbits/s)
C11 1,544
C12 2,048
C2 6
C3 34,368 ou 44,736
C4 139,264
Tableau 2: Les différents containers Cn
Comme illustre la Figure 7, un sur-débit 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é gérée par le réseau SDH comme illustré
dans la figure 8 suivante
Figure 8: Gestion du VCn dans un réseau SDH. Ref [3]

Les VCn d’ordres 11, 12 et 2 sont dits d’ordre inférieur (LOP, Low Ordre Path), les
VCn d’ordre 3 et 4, sont dits d’ordre supérieur (HOP, High OrdrePath).
L’unité affluent (TU), le groupe d’affluents (TUG) et l’unité
d’administration (AU), le Groupe d’AU, trame d’ordre n
L’unité d’affluent, Tributary Unit (TU), se compose d’un conteneur virtuel
d’ordre inférieur et d’un pointeur PTR qui indique l’emplacement du VCn dans le
conteneur d’ordre supérieur. (TUn = VCn + PTR).
Un groupe d’unités d’affluents (TUG) est un multiplex temporel d’unités
d’affluents TU 1,2 ou 3 multiplexés entre eux. Ainsi le TUG 2 regroupe 4 TU 11 ou 3
TU 12 ou 1 TU 2. Un TUG 3 regroupe de même 7 TU 2 ou 1 TU 3.
L’unité d’administration (AU) se compose d’un conteneur virtuel d’ordre
supérieur associé à un pointeur d’AU. La valeur de ce pointeur indique l’emplacement
du début du conteneur dans la trame STMn utilisée.
Un groupe d’unité d’administration n’est pas une nouvelle entité physique, mais
seulement une structure virtuelle de trame. L’AUG correspond à la place que doit
occuper l’AU-4 dans la trame de transport ou à la place de 3 unités d’ordre 3
multiplexées. Les trames de transport STM sont obtenues en multiplexant n AUG et en
ajoutant un sur débit de section SOH (Section Overhead).
Figure 9: Structure du multiplexage Synchrone. Ref [4]

La trame de base du SDH
La trame de base est donc caractérisée par :
Sa longueur 2430 octets,
Sa durée 125 µs,
son débit 155,520 Mbit/s,
Sa capacité utile 2349 octets.
Elle se décompose en trois zones représentées ci-dessous :
Surdébit de section, divisé en surdébit pour la section de régénération
(RSOH) et sur débit de section de multiplexage (MSOH),
RSOH (Regenerator Section Overhead) : elle contient les
informations sur les éléments de liaisons et est utilisée pour
dialoguer avec et entre les régénérateurs. Il s’agit notamment du
mot de verrouillage de trame, la surveillance des erreurs.
MSOH (Multiplex Section Overhead) : La Section de
Multiplexage de l’entête contient les informations nécessaires
pour le dialogue entre les multiplexeurs.
La Figure 10 présente les limites des sections RS, MS et VC sur le réseau SDH
Figure 10: Limite des RS, MS, VC sur le réseau SDH.
RS= Regenerator Section (Section de Régénération)
MS= Multiplex Section (Section de Multiplexage)
VC= Virtual Container (Conteneur Virtuel)
Les pointeurs d’AU,
Les charges utiles VC 4, une pour STM1, 4 pour STM 4 ou 16 pour
STM 16
La Figure 11 présente en détail l’organisation de la trame STM1 :

Figure 11: Organisation de la trame STM1
2.3.3 Architecture et équipements d’un réseau SDH : Cas CAMTEL
2.3.3.1 Architecture
La SDH, en tant que technique de multiplexage, permet d’associer des débits
incidents pour former un débit supérieur, plus facile à transmettre et à gérer dans le
réseau de transmission. Cette hiérarchie numérique synchrone a donc été mise en place
à CAMTEL dans le but d’unifier les structures réseaux sur le plan national et même
international, aussi dans le but de réduire les coûts de management des réseaux et
d’éliminer les inconvénients de la hiérarchie PDH qui ne permettait pas cette
simplification et normalisation.
Le réseau de transmission SDH de CAMTEL est constitué par un réseau
interurbain encore appelé Backbone et de deux réseaux métropolitains dans les deux
grandes villes du Cameroun, Douala et Yaoundé. L’architecture du réseau
métropolitain de Yaoundé est un anneau bidirectionnel à deux fibres permettant le
transport des services divers dans la région du centre. Ce sont des fibres monomodes
répondant à la norme G652 composés d’un câble à 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.

Figure 12: Boucle Métropolitaine SDF/FO Siemens de Camtel Yaoundé
2.3.3.2 Les équipements
Les équipements de la SDH sont de 4 types :
Les régénérateurs ou répéteurs pour amplifier le signal afin qu’il garde un
niveau raisonnable nécessaire à une bonne interprétation à l’arrivée.
Les multiplexeurs, on distingue 2 cas :
Les multiplexeurs terminaux (MTS) ou d’accès qui sont utilisés pour la
projection et le multiplexage des affluents PDH, des affluents produits
par d’autres standards (ADM, …) et des affluents SDH pour produits des
trames STMn
Le hub multiplexeurs pour l’interconnexion des trafics transportés sur
des fibres ou des anneaux
Les ADM (Add and Drop Multiplexer) ou MIE (Multiplexeur à Insertion
ou Extraction) extraient ou injectent aisément un affluent dans un multiplex.
On distingue du côté réseau d'opérateur, les agrégats et du côté réseau d'abonné,
les affluents

Figure 13: Principe d'un ADM
Les DXC (Digital Cross Connect) ou brasseurs numériques sont charge de
réarranger les affluents dans les trames STMn et de commuter les signaux des
multiplex d’entrée dans les multiplex de sortie
La Figure 14 suivante présente une utilisation de ces équipements dans un réseau
complet :
Figure 14: Exemple d'un réseau SDH. Ref [4]

Dans la boucle métropolitaine, le logiciel installé dans les moniteurs de
supervision est le TNMS (Télécommunications Network Management System). Le
TNMS est le système de gestion pour les équipements optiques de nouvelle génération
de la famille SURPASS de l’équipementier Siemens. Il prend en compte tous les
aspects de la gestion des réseaux de la couche élément à la couche business en passant
par les couches réseau et service. En d’autres termes, il assure les fonctionnalités
suivantes :
Gestion des configurations (Cross Connect etc.)
Gestion des alarmes (LOS, AIS, RDI, LOF, LOP …)
Gestion des éléments du réseau
Gestion de la sécurité (Protection)
Gestion des connexions à l’équipement
Le composant central de la famille des produits TNMS est le TNMS-Core qui
fournit une gestion intégrée et centralisée des réseaux optiques multiservices sur les
couches de gestion de l’élément, du réseau, 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 présentent les types de cartes installées dans le système 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)

6 SF10G Carte de commutation bas niveau (ou de cross connect)
7 SF160G Carte de commutation haut niveau
8 LSU Carte d’interruption (en protection)
9 CLU Horloge interne
10 SCOH Carte contrôleur principale
11 LNQ Carte de connexion aux shelfs d’extension
12 FAN Unit Système de ventilation
13 FMX Interface bas débit 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 d’alimentation
6 SC System Controller
7 FAN Tray Système de ventilation
8 FMX Interface bas débit N*64 Kbps ; sortie 2Mbps
Tableau 4: Les Cartes du HIT 7060
Le système SDH de CAMTEL prévoit qu’en cas de coupure de ligne, le signal
est automatiquement réacheminé sur un secours. Nous avons donc deux types de
configuration pour la sécurité du trafic dans nos réseaux métropolitains : une
protection ligne EPS 1+1 et une protection de multiplexage MSP 1+1 (Multiplex
Section Switching 1+1).

2.3.3.3 Les services Véhiculés dans la boucle Métropolitaine
Le réseau SDH/FO de Camtel donne accès à trois types de services :
Les services supports pour le transport d’information de bout en bout entre
deux interfaces, il y a le service téléphonique (transport des circuits vocaux
MIC) et le service numérique (transport des flux variables tels qu’ATM ou
TVHD après conversion)
Les télé-services il s’agit des services tels que la vidéoconférence et la
visiophonie
Les compléments de services correspondent à un enrichissement de l’offre
téléphonique. Ces prestations donnent lieu à facturation.

2.3.4 Les indicateurs de performance d’un réseau de
transmission
La Recommandation UIT-T G.826 définit un ensemble d’événements liés aux
caractéristiques d’erreur basées sur la notion de bloc et des paramètres destinés au
contrôle en service des caractéristiques d’erreur d’un conduit SDH.
Bloc erroné, EB (Errored Block) : Bloc dont un ou plusieurs bits sont erronés.
A savoir qu’un bloc est un ensemble de bits consécutifs associés au conduit,
chaque bit appartenant à un bloc et un seul. Des bits consécutifs peuvent ne pas
être contigus dans le temps.
Seconde erronée, ES (Errored Second) : Période d’une seconde comportant
un ou plusieurs blocs erronée ou au moins un défaut et pendant laquelle une
perte du signal (Loss Of Signal) ou un signal d’indication d’alarme AIS (Alarm
Indication Signal) est détecté.
Seconde gravement erronée, SES (Severely Errored Second) : Période d’une
seconde comportant un taux de blocs erronés supérieur ou égal à 30% ou au
moins un défaut. L’ensemble des secondes gravement erronées est un sous
ensemble des secondes erronées.
Des secondes gravement erronées peuvent conduire à des périodes
d’indisponibilité, en particulier lorsqu’aucune procédure de restauration/protection
n’est pas utilisée. Des périodes de T secondes gravement erronées consécutives 2<=
T<10 (certains opérateurs de réseaux désignent ces événement des pannes) peuvent
affecter gravement le service ; elles peuvent, par exemple, entrainer la déconnexion
des services commutés.
Seconde indisponible, UAS (Unavailable Seconde) : Une UAS est une
seconde qui fait partie d’une période d’indisponibilité.
Bloc erroné résiduel, BBE (Background Block Error) : Bloc erroné
survenant en dehors d’une seconde gravement erronée.

La définition de la taille de bloc et des événements liés aux caractéristiques
d’erreur pour la section multiplex (MS, Multiplex Section) en mode SDH et la section
de régénération (RS, Regenerator Section) est présentée dans la Recommandation
UIT-T G.829. Chaque direction d’un conduit peut se trouver dans l’un des états
suivants : temps de disponibilité et temps d’indisponibilité. Les critères qui
déterminent la transition entre les deux états sont indiqués ci-après. Une période
d’indisponibilité commence au début d’événements de 10 secondes gravement
erronées consécutives. Ces 10 secondes font partie du temps d’indisponibilité.
Une nouvelle période de disponibilité commence au début d’événements de 10
secondes consécutives ne comportant pas de seconde gravement erronée. Ces dix
secondes font partie du temps de disponibilité. Un conduit est disponible si, et
uniquement si, les deux directions sont disponibles. Les paramètres de disponibilité
définis sont le taux de disponibilité (AR, Availability Ratio) et la durée moyenne entre
interruptions de conduit numérique, Mo. Le complément à 1 du taux AR est le taux
d’indisponibilité (UR, Unavailability Ratio). Ainsi, AR+UR = 1. L’inverse de Mo est
défini comme étant la fréquence d’interruption (OI, Outage Intensity). Ainsi, Mo
=1/OI. Mo représente le nombre de périodes d’indisponibilité par an.
De ces évènements caractéristiques d’erreurs, l’UIT –Réf [5]- définit les
paramètres caractéristiques d’erreur comme suit :
Le taux de secondes Erronées ESR (Errored Seconds Ratio), donnée par la
relation :
∑
avec , le temps total de disponibilité de la liaison
durant la période d’observation;
Le taux de Secondes Sévèrement Erronées SESR (Severely Errored Seconds
Ratio), donnée par la relation :
∑
Le taux de blocks de résiduels Erronées BBER (Background Block Error
Ratio), donnée par la relation :
∑
avec le nombre total de
blocks dans la période de disponibilité de la liaison. Ce paramètre s’applique
uniquement aux conduits

Le tableau 6 présente les caractéristiques cibles pour un conduit numérique inférieur
ou égal à 27000 Km tel que défini par l’UIT:
DEBITS NOMBRE DE BITS
PAR BLOC
ESR SESR BBER
64 Kbits/s au débit
primaire
Non applicable 0.4 0.002 Non
applicable
1.5 à 5 Mbits/s 800-5000 0.4 0.002 2x10
5 à 15 Mbits/s 2000-8000 0.5 0.002 2x10
15 à 55 Mbits/s 4000-20000 0.075 0.002 2x10
55 à 160 Mbits/s 6000-20000 0.16 0.002 2x10
160 à 3500 Mbits/s 15000-30000 Pas
spécifié
0.002 10
Tableau 5: Caractéristiques cibles des paramètres d'erreur. Réf [5]
L’IUT –Réf [5]- nous propose également un diagramme illustrant la détection
d'anomalies, de défauts ES et SES. Ce diagramme est expliqué avec les notes
suivantes :
NOTE 1 - La détermination des temps d'indisponibilité introduit un retard de
dix secondes. Ce délai doit être considéré lors du comptage BBE, ES et SES.
NOTE 2 - cES, cSES et cBBE des chiffres de ES, SES, BBE, respectivement.
Ces chiffres sont remis à zéro au début d'une période de mesure.
NOTE 3 - EB est le nombre de blocs défectueux au sein d'une EB% tandis que
ES représente la proportion de blocs erronées au sein d'une ES par rapport au
nombre de blocs par seconde.
NOTE 4 – Les paramètres G.826 peuvent être évalués au cours ou à la fin
d’une période de mesure P comme suit, en tenant compte des secondes
d’indisponibilté (UAS):
BBER = cBBE / [(P - SAMU - cSES) «blocs par seconde »]
ESR = EC / (P - UAS)
SESR = cSES / (P - UAS)

NOTE 5 - Dans le schéma simplifié, aucune mesure n'est prise si le chemin est
dans l'état d'indisponibilité. C'est parce que le schéma ne tient pas compte de la
transition entre les états de disponibilité, alors qu'en réalité, les compteurs
d'événements doit être modifiée de manière rétrospective. Dans la pratique, le
statut de seconde (soit exempt d'erreurs, ES ou SES) doit toujours être
déterminé avant un test qui est effectué sur le statut de disponibilité d'une voie.
En d'autres termes, les événements d'erreur sont toujours détecté
indépendamment du fait que le chemin est disponible ou non - que le comptage
des événements est inhibée pendant des périodes d'indisponibilité pour les fins
de suivi de la performance à long terme. Ce processus se traduit par
l’organigramme bien que les actions qui en découlent sur les changements d'état
de disponibilité n’y sont pas.

Figure 15: diagramme illustrant la détection d'anomalies, de défauts ES et SES. Ref [5]
2.3.5 Les alarmes dans un réseau SDH
Une alarme est toute condition de défaut (défaut logiciel, défaut matériel, défaut
transitoire) qui apparait (disparait) dans un équipement. C’est généralement un
message renvoyé par les ressources réseau qui ont détectés des défaillances concernant
leur état. Une alarme est définit par l’usage d’un certain nombre de paramètres à
savoir :
Le problème spécifique (Specific Problem)

Ce paramètre lorsqu’il est remonté donne de façon un peu plus fine la cause de
l’alarme. Il est soit un ensemble d’entier ou un ensemble d’objets identifiables.
La cause probable (Problem Cause)
Ce paramètre définit la cause probable de l’alarme, sa valeur appartient à un ensemble
de valeur possibles définit dans les recommandations X.721, M3100
Le nom de la ressource (Friendly Name)
Ce paramètre identifie la ressource qui a généré l’alarme
L’instant de l’évènement (Event Time)
Le type de l’évènement (Event Type)
Ce paramètre définit le type de problème référencé par cette alarme.
Le tableau 7 présente les différents types d’évènements et leur description
Type d’évènement Indications
Communication Un problème avec un processus ou une procédure utilisé pour
envoyer de l’information
Qualité de service Dégradation de la qualité de service dans le réseau
Erreur de traitement Un logiciel ou un défaut de traitement
Equipement Un équipement en défaut
environnement Un problème dans l’environnement contenant l’équipement
Tableau 6: Les types d'évènement
La sévérité (severity)
Le niveau de sévérité indique à quel niveau l’objet managé affecte le réseau. Il existe 4
niveaux de sévérité détaillés dans le tableau 8 :
Sévérité Description
Critical Un défaut sérieux qui requiert une action correctrice immédiate.
Exemple : Un objet supervisé est hors service
Major Un défaut qui requiert une action correctrice urgente. Exemple :
sévère dégradation dans les opérations d’un objet supervisé
Minor Un défaut qui n’affecte pas le service mais qui nécessite une action
correctrice pour éviter des dommages plus sérieux
Warning Détection d’une potentielle condition de défaut. Une action doit être

prise pour diagnostiquer et corriger le problème pour éviter des
dommages
Tableau 7: Sévérité des alarmes
Grâce aux octets d'en-tête (MSOH, RSOH et POH) de la trame de base, un
réseau SDH peut transporter un grand nombre d'alarmes. L'exploitant dispose donc de
nombreuses sources de diagnostique. La liste non exhaustive des alarmes est donnée
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 reçue n'est pas celle attendue
Mismatch J1 : l'identifiant reçu n'est pas celui attendu
etc...

Conclusion
2.4 Conclusion
Dans ce chapitre il a été question de passer en revue les généralités relatives à
notre travail, à savoir, la transmission par Fibre Optique, les techniques de
multiplexage SDH et PDH, l’architecture des réseaux SDH avec tout en insistant sur
les indicateurs de performances et les types d’alarmes possibles. Apres avoir présenté
cela, nous pouvons à présent nous intéresser à l’analyse de notre application, c’est ce
qui fera l’objet du chapitre suivant.

Chapitre 3 : Réalisation de l’outil de gestion des services et suivit des performances : Analyse
Chapitre 3 : Réalisation de l’outil de gestion
des services et suivi des performances :
Analyse
Aperçu
Analyse __________________________________________________________________ 50
3.1 Introduction _______________________________________________________________ 50
3.2 Analyse de l’outil 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 d’acquisition des données __________________________________________________ 52
3.2.3 Architecture de la plateforme________________________________________________________ 53
3.2.3.1 Module de rapatriement des données_____________________________________________ 54
3.2.3.2 Module de traitement et mise dans la Base de Données_______________________________ 54
3.2.3.3 Module de remontée des alarmes par SMS _________________________________________ 55
3.2.3.4 Module de présentation des données aux utilisateurs ________________________________ 55
3.3 Conclusion_________________________________________________________________ 56
3.1 Introduction
Apres avoir présenté les généralités sur les réseaux de transmission, les
techniques de multiplexage, les indicateurs de performance, il est à présent 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 l’outil de gestion des services et suivit des performances
3.2 Analyse de l’outil de gestion des services et suivi des
performances
Le TNMS présente à ce jour des limites. La détection et la gestion des
ressources disponibles , telle qu’elle est faite actuellement , passe par la manipulation
d’une multitude de fichiers textes, extrait manuellement sur le TNMS puis traites
manuellement, ceci avec des risques d’erreur.
Par ailleurs le suivi de la qualité des liaisons s’effectue par extraction du TNMS
de la liste des alarmes suivi d’un traitement manuel de ces alarmes et production des
rapports ; vraiment fastidieux et inefficace quand on sait qu’il peut y avoir à un
moment donné près de 10 000 alarmes a traites dans le réseau. A cela il faut ajouter
l’impossibilité de produire efficacement des rapports sur des services et capacités des
équipements car cela jusqu’à ce jour se fait manuellement dans des registres.
Ceci étant le cahier des charges et l’analyse suivante va essayer de répondre au
mieux aux préoccupations suscitées
3.2.1 Rappel du cahier des charges
Plusieurs contraintes posées d’une part par l’entreprise, et d’autre part par
l’application elle-même, ont permis de dégager les besoins fonctionnels et non
fonctionnels suivants :
3.2.1.1 Besoins fonctionnels
L’outil à développer doit répondre à plusieurs exigences dont les plus
importantes sont les suivantes :
Communiquer de façon journalière et périodique avec le serveur pour un souci
de rapatriement automatique des logs d’alarmes et performances.
Analyser de façon quotidienne les logs rapatriés 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
donnés ... Ceci dans l’optique de mettre en place une technique de maintenance
préventive et de fournir aux techniciens des pistes d’optimisation.
Fournir des interfaces qui permettrons d’automatiser la gestion des services,
conduits, fibre et équipements via des opérations de création, modification,

suppression, consultation. Ceci dans le but de produire également des rapports
d’état ou d’occupation du réseau et des matrices de trafic ce qui actuellement se
fait manuellement.
Déclencher une alerte SMS vers les techniciens du centre en cas de défaillances
majeurs dans le réseau ceci dans l’optique de réduire le temps de réaction face à
un problème, car les problèmes nous sont (dans le centre des jonctions
urbaines) généralement signalés par les responsable des services que nous
transportons (Cas du BSC qui nous informe généralement des BTS qui ne
fonctionnement pas car notre transmission n’est pas bonne).
Sauvegarder toutes ces informations dans une base de données pour des besoins
futures.
3.2.1.2 Besoins non fonctionnels
L’application doit être modulaire pour assurer sa maintenance et son
extensibilité afin de pouvoir l’adapter à des besoins futurs. L’utilisation de cet outil
doit être simple et présenter une interface conviviale et compréhensible par les
employés du Centre des Jonctions Urbaine et du centre de supervision des réseaux. Le
temps de réponse aux requêtes des utilisateurs doit être acceptable.
3.2.2 Protocole d’acquisition des données
L’application TNMS Core étant installée sur un serveur Windows Server 2003
doté du SGBDR Microsoft Windows Server SQL, il se présente deux possibilités de
rapatriement automatique.
Transfert par protocole FTP : Il s’agit de configurer le poste qui héberge le
TNMS en serveur FTP. Il sera question via le TNMS coreSysAdmin de
paramétrer les sauvegardes vers un répertoire précis qui servira également de
répertoire principal pour le service FTP. C’est dans ce répertoire que le client
FTP de notre plateforme viendra récupérer les fichiers logs pour rapatriement
Transfert par réplication de la Base de données centrale du TNMS : Cette
solution serait vraiment idéale, mais il s’avère que le constructeur n’a pas donné
l’architecture de sa Base de données et vue la fragilité et la haute importance du
TNMS, il sera judicieux de ne pas attaquer directement sa base de donnée.
Nous proposerons de ce fait, la première solution, celle par protocole FTP.

3.2.3 Architecture de la plateforme
La mise en place de la plateforme a été abordée de façon modulaire suivant un
concept Client-Serveur comme l’illustre l’architecture présentée 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 données.
Un module de traitement et mise dans la Base de Données.
Un module de remontée des alarmes pas SMS.
Du coté Client, METOPERF_CJU_Client :

Un module de présentation des données aux utilisateurs.
L’interface graphique de ce module devra respecter l’organisation suivante :
Figure 17: Organigramme du module Client
3.2.3.1 Module de rapatriement des données
Le module de rapatriement des données consiste à récupérer les données par
FTP à partir du serveur TNMS et les stocker dans le poste d’exploitation qui est
également la machine qui héberge notre base de données. Pour cela nous avons installé
l’application FileZilla Server sur le poste TNMS, créer un utilisateur et orienter le
répertoire de travail de cet utilisateur vers le répertoire ou sont généré les logs par le
module SysAdmin du TNMS. C’est avec les paramètres de ce compte que notre
socket client FTP devra se connecter de façon périodique au serveur TNMS pour
assurer le rapatriement vers un répertoire bien spécifier du poste d’exploitation.
3.2.3.2 Module de traitement et mise dans la Base de Données
La première partie de ce module est de se rendre dans le répertoire ou a été
déposé le fichier récupéré du serveur TNMS et de les mettre en forme afin de mieux
les intégrer dans la base de données. La deuxième partie consiste à stocker dans la base

de données les informations issus de ces fichiers et d’informer au module de remontée
des alarmes par SMS en cas d’alarme de sévérité crittique.
3.2.3.3 Module de remontée des alarmes par SMS
Ce module est chargé principalement de remonter automatiquement les alarmes
qui lui sont envoyés par le module précèdent vers les techniciens du centre. Il
comprend deux parties :
La construction du message à envoyer.
L’envoie du message aux exploitants concernés et marqués dans la base de
données.
L’escalation de l’envoi des SMS selon les temps et les niveaux qui auront été
définis
3.2.3.4 Module de présentation des données aux utilisateurs
Il est question ici de présenter les données stocké dans la base de données sous
forme d’interface java. De permettre également des opérations diverses sur ces
données. Il faut ajouter à cela la gestion des services, des conduits, des fibres, des
équipements et des utilisateurs.

Conclusion
3.3 Conclusion
Dans ce chapitre nous avons présenté le cadre de notre application qui
comprend une étude de l’existant et une spécification des besoins ainsi que les cas
d’utilisation de l’application. Pour illustrer la concrétisation de la spécification, le
chapitre suivant présente la conception et l’implémentation des différentes
fonctionnalités de notre application.

Chapitre 4 : Réalisation de l’outil de gestion des services et suivit des performances : Conception
Chapitre 4 : Réalisation de l’outil de
gestion des services et suivi des
performances : Conception et réalisation
Aperçu
Conception et réalisation ____________________________________________________57
4.1 Introduction _______________________________________________________________ 57
4.2 Conception de l’application ___________________________________________________ 58
4.2.1 Diagrammes des Cas d’utilisation _____________________________________________________ 58
4.2.2 Diagramme des classes _____________________________________________________________ 61
4.2.3 Diagramme de séquences ___________________________________________________________ 64
4.3 Réalisation de l’application ___________________________________________________ 65
4.3.1 L’Environnement de travail__________________________________________________________ 65
4.3.2 Les Choix techniques de réalisation ___________________________________________________ 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 Stratégie de remontée automatique des alarmes par SMS _____________________________ 67
4.4 Conclusion_________________________________________________________________ 69
4.1 Introduction
Cette partie nous permet de présenter les diagrammes UML correspondants et le
choix des outils à utiliser pour l’implémentation effective du travail demandé.
4

Conception de l’application
4.2 Conception de l’application
4.2.1 Diagrammes des Cas d’utilisation
Un cas d'utilisation modélise un dialogue entre un acteur et le système. C'est la
représentation d'une fonctionnalité offerte par le système. L'ensemble des cas
d'utilisation forme toutes les façons possibles d'utilisation du système. Les principaux
objectifs des cas d’utilisation sont :
Permettre de structurer les besoins des utilisateurs et les objectifs
correspondants d’un système.
Centrer l’expression des exigences du système sur ses utilisateurs.
Se limiter aux préoccupations réelles des utilisateurs : ils ne présentent pas de
solutions d’implémentation et ne forment pas un inventaire fonctionnel du
système.
Identifier les utilisateurs du système (acteurs) et leurs interactions avec le
système.
Vu le nombre important des actions du modèle des cas d’utilisation du système
et pour des raisons de simplification de la représentation, le modèle va être divisé en
diagrammes présentant quelques-unes des diverses fonctionnalités offertes par notre
outil. La Figure 18 représente une vue générale sur les différents cas d’utilisation de
notre application en se basant sur la méthodologie UML que l’on a adopté (Voir
Annexe A. Le langage de modélisation UML).

Invité
Administrateur
Gestion des Utilisateurs et
du Serveur
«Include»
«Include»
«Include»
«Include»
Authentification
Consulation des Services,
des Equipements,
des Fibres et des Conduits.
génération des rapports
Consulations de l'état
du réseau,
Alarmes et Performances
Configuration et Suppression
des services, des conduits,
des équipements, des fibres
Figure 18: Diagramme de Cas d'utilisation Générale
L’opération de consultation de l’état du réseau figure parmi les fonctionnalités
principales que l’application doit offrir. La Figure 19 présente en détail ce cas
d’utilisation.

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
Géneration 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 réseau
Pour assurer son évolutivité, le système doit également offrir la possibilité de
sélectionner les différents paramètres de la connexion, d’ajouter et de supprimer des
utilisateurs et de configurer les serveurs de transmission.
Ces différentes opérations nécessitent l’identification de l’utilisateur. Seuls les
utilisateurs connectés avec un compte administrateur ont le droit d’ajouter et de
supprimer des utilisateurs et aussi configurer les serveurs. La Figure 20 présente le cas
d’utilisation «Gestion des Utilisateurs et du Serveur».

Gestion des Utilisateurs et
du Serveur
Administrateur
Authentification
Ajouter Utilisateur
Modifier Utilisateur
Supprimer Utilisateur
Ajouter Serveur
Modifier serveur
«Extend»
«Extend»
«Extend»
«Extend»
«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 l’ensemble 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 déjà été envoyé par SMS
Carte Gérer 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 rencontrées.
Conduit_perf Enregistre les logs de performance sur les conduits
Conduit Enregistrer les conduits avec les infos de départs
(ID_Equipement, PORT, SUBRACK, CARTE…) d'arrivée et
intermédiaire
Equipement_alerte Enregistrement des alertes sur les équipements
Equipement_perf Enregistrements des logs de performance sur les équipements
Equipement Gestion des équipements

Fibre Gérer les fibres et leurs caractéristiques
Brin_Fibre Gérer les brins de chaque fibre
Tube_Fibre Gérer les Tubes de chaque fibre
Port Gérer tous les ports d'une carte
Service Gestion des services
Subrack Gérer tous les Subrack d'un équipement
Type_equipement Enregistrer les types d'équipements disponibles. Donc un
Equipement aura une clé étrangère référençant 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 l’envoi des SMS.
Le diagramme découle de l’analyse réalisé au chapitre précédent.

Figure 21: Diagramme de classe

4.2.3 Diagramme de séquences
A cause du nombre important des scénarios qui peuvent être implémentés dans
ce système et pour des raisons de simplification de la représentation, on va juste
choisir un scénario. La Figure 22 présente le scénario de téléchargement des fichiers à
partir du serveur de transmission et de l’insertion dans la base de données.
Figure 22: Rapatriement des fichiers et insertion dans la BD

Réalisation de l’application
4.3 Réalisation de l’application
4.3.1 L’Environnement 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.
Mémoire 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 réalisation
Le terme choix technique de réalisation veut dire la sélection des différents
supports informatiques qui seront utilisés lors de l’implémentation de l’outil
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 crée l'illusion d'une base
de données orientée objet à partir d'une base de données relationnelle en définissant
des correspondances entre cette base de données et les objets du langage utilisé. On
pourrait le désigner 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 développeurs d'organiser des
données relationnelles dans des applications utilisant la plateforme Java.
L’API JPA est récente. Elle n’a été disponible qu’à partir du JDK 1.5. La
couche JPA à sa place dans une architecture multicouche. Considérons une telle
architecture assez répandue, celle a 3 couches :

Figure 23:Architecture de modélisation sans ORM
La couche [1], appelé ici [ui] (User Interface) est la couche qui dialogue avec
l’utilisateur, via une interface graphique Swing, une interface Web ou une
interface console.
La couche [2], appelé ici [métier] est la couche qui applique les règles dites
métier, ie : la logique spécifique de l’application, sans se préoccuper de savoir
d’où viennent les données qu’on lui donne, ni où vont les résultats qu’elle
produit
La couche [3], appelé ici [dao] (Data Access Object) est la couche qui fournit à
la couche [2] des données préenregistrées (Fichiers, bases de données) et qui
enregistre certains des résultats fournis par la couche [2]
La couche [JDBC] est la couche standard utilisée en Java pour accéder à des
bases de données c’’est ce qu’on appelle habituellement le pilote Jdbc du
SGBD.
De multiples efforts ont été faits pour faciliter l’écriture de ces différentes
couches par le développeur. Parmi ceux-ci, JPA vise à faciliter l’écriture de la couche
[dao]. Une solution sur laquelle nous avons porté notre attention est celle de Toplink.
Figure 24: Architecture de modélisation 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 données et celui
des objets manipulés par Java. Le développeur de la couche [dao] ne voit plus la

couche [Jdbc] ni les tables de la base de données dont il veut exploiter le contenu. Ce
concept nous a permis d’être plus éfficace et rapide dans le développement de notre
plateforme.
4.3.2.2 Choix du SGBD
MySQL est le serveur de base de données le plus utilisé dans le monde. Son
architecture logicielle le rend extrêmement rapide et facile à personnaliser. Ce dernier
possède plusieurs avantages dont les plus importantes sont la rapidité, la robustesse, la
facilité d’utilisation et d’administration. Mais l’avantage le plus majeur de MySQL est
la documentation très complète et bien construite.
4.3.2.3 Choix du langage de programmation
Tout d’abord, java simplifie le processus de développement : quelle que soit la
machine sur laquelle on code, le compilateur fournit le même code. Ensuite, quel que
soit le système utilisé, cet unique code est directement opérationnel :
Fichier Source Compilateur Java Fichier Classe Interpréteur Java.
En effet, la compilation d’une source Java produit du pseudocode Java qui sera
exécuté par tout interpréteur java sans aucune modification à la recompilation. Java
permet également de créer des applications autonomes qui peuvent se substituer à des
applications développés en langage compilé. Pour ces applications l’API Java apporte
un ensemble très riche de classes répondant à de nombreux besoins et pouvant être
étendue, cet unique API simplifie la création et le déploiement des applications, en
effet cette application s’exécutera sur tout système en utilisant l’aspect visuel de ce
système.
4.3.2.4 Stratégie de remontée automatique des alarmes par SMS
Le module d’envoi des SMS a été réalisé dans le but de pouvoir aviser en cas
d’alertes, c’est-à-dire lorsqu’on a une alarme ayant un certain degré de criticité
spécifié, un SMS est envoyé à un groupe d’utilisateurs. Pour effectuer un envoi de
SMS un certain nombre d’outils sont nécessaires à savoir:
Un téléphone portable avec une carte SIM (Subscriber Identification Module)
Un câble de données RS232/USB (Data câble) permettant de connecter le
téléphone Mobile au PC(Ordinateur)

Avoir le nécessaire de crédit pour effectuer l’envoi des SMS.
Une fois que vous disposez de ces équipements, il va falloir maintenant
configurer le logiciel qui assurera l’interface Téléphone–Ordinateur. L’envoi des SMS
au mobile nécessite l’emploi des commandes AT établies par L’ETSI (Europeean
Telecommunications Standards Institute).

Conclusion
4.4 Conclusion
A ce stade de notre travail nous avons présenté les différentes méthodes et
procédures déployées pour l’implémentation de la solution que nous avons adoptée.
Toute la suite du présent document sera donc consacrée à la présentation des divers
résultats obtenus.

Chapitre 5 : Résultats et Commentaires
Aperçu
Chapitre 5 : Résultats et Commentaires ________________________________________70
5.1 Introduction _______________________________________________________________ 70
5.2 Quelques résultats __________________________________________________________ 71
5.2.1 Lot 1 : Rapatriement des fichiers _____________________________________________________ 71
5.2.3 Lot 2 : Acquisition des données et chargement dans la base de données _____________________ 73
5.2.3 Lot 3 : Remontée automatique des alarmes par SMS _____________________________________ 73
5.2.4 Lot 4 : L’interface Client et ses différentes fonctionnalités _________________________________ 75
5.3 Conclusion_________________________________________________________________ 82
5.1 Introduction
Dans cette partie, il est question pour nous, d’illustrer les différents résultats
que nous avons obtenus tout au long de notre travail. Les aboutissements auxquels
nous sommes parvenus peuvent être regroupés en plusieurs lots que nous allons
parcourir tour à tour:
Lot 1 : Rapatriement des fichiers ;
Lot 2 : Acquisition des données et chargement dans la base de données ;
Lot 3 : Remontée automatique des alarmes par SMS ;
Lot 4 : L’interface Client et ses différentes fonctionnalités.
5

Etude de cas
5.2 Quelques résultats
5.2.1 Lot 1 : Rapatriement des fichiers
Avant toute chose il faut au préalable paramétrer ce travail d’automatisation en
informant l’application sur les paramètres du serveur distant (@IP du serveur FTP,
identifiant du client FTP, mot de passe du client FTP et Périodicité de rapatriement),
l’interface de la Figure 25 du module client permet de le faire.
Figure 25: Configuration du serveur
La Figure 26 présente l’interface d’accueil du module serveur
Metro_Perf_CJU-SERVER, c’est à travers ce module que nous allons déclencher
divers processus automatiques. On peut ainsi démarrer et stopper le fonctionnement du
serveur. Cela implique le rapatriement des fichiers logs du serveur de supervision
TNMS vers le répertoire C :ftpClient (répertoire qu’il faudra au préalable créer !) du
poste d’exploitation (Figure 27)
Figure 26: Page d'accueil du serveur lorsqu'il est lancé

Etude de cas
Figure 27: répertoire de Rapatriement et traitement de logs (Alarmes et PM)
Les figues suivantes présentent les formats des fichiers rapatriés. On peut ainsi avoir :
A la Figure 28 un prototype de fichier des alarmes dont la structure d’une
entrée est la suivante,
<sévérité>:<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
Figure 29: Exemple de Fichier de PM
5.2.3 Lot 2 : Acquisition des données et chargement dans la
base de données
Apres avoir rapatrié les fichiers, notre application nous permet également une mise en
forme et un chargement automatique dans la base de données. La Figure 30 nous présente
quelques tuples de la Table « equipement_alerte » dans la base de données
« metroperf_cju ».
Figure 30: Quelques tuples de la table « equipement_alerte »
5.2.3 Lot 3 : Remontée automatique des alarmes par SMS
Ce travail ne peut se faire qu’après paramétrage. Le paramétrage qui consiste à
détecter le modem d’envoi de SMS et enregistrer les informations (Vitesse, Port de

Etude de cas
communication, personnes à contacter) dans la base de données à travers l’interface de
la Figure 31.
Figure 31: Configuration de la remontée des alarmes par SMS/MAIL
Apres ce paramétrage, si le module MetroPerf_CJU__Server est lancé on
pourra en cas de sévérité CRITICAL, recevoir un SMS comme la Figure 32 le
montre.
Figure 32: Une remontée d'alarme par SMS

Etude de cas
Ce SMS informe que le port 1_201_43 de l’ADM de NKOMO à une alarme
critique de nature LOS (Loss of Signal), cela due à la communication et a été généré
le 10-06-2012 à 10h 30 minutes 45 secondes
5.2.4 Lot 4 : L’interface Client et ses différentes fonctionnalités
Chaque utilisateur doit s’authentifier avant de pouvoir effectuer les opérations
diverses. La Figure 33 présente les champs nécessaires (Login et Password) à remplir
pour se connecter à l’application.
Figure 33: Page D'authentification
Une fois l’authentification réussie, l’interface principale suivante apparait. Elle
nous présente l’architecture du réseau en place, elle nous propose également une barre
de menues qui contient les différentes actions que nous pouvons mener.

Etude de cas
Figure 34: interface d'accueil
A partir de cette interface, nous pouvons obtenir des résultats de performances,
alarmes et statistiques sur les équipements, comme le montre les Figures 35, 37, 39
suivantes.
La figure 31 nous présente les indicateurs de performances sur les différents
équipements.

Etude de cas
Figure 35: Performances des équipements
Les différentes options de tri sur la Figure 35 permettent de faire des requêtes :
Suivant le type de l’équipement
Suivant le nom de l’équipement ;
Suivant la période (date inferieure et date supérieure) de recherche;
Suivant les seuils de performances des indicateurs.
Ou en faisant des combinaisons de ces différents critères de filtres
Les Figures 35, 36 et 37 suivantes nous présentent les statistiques sur les
indicateurs de performance (ESR, SESR et DISPONIBILITE) sur le port 1_101_1 de
l’ADM_CTN. Ces statistiques permettront aux techniciens du centre de voir
l’évolution des indicateurs pendant une période, ceci dans l’optique de pouvoir
prévenir les alarmes.

Etude de cas
Figure 36: Courbes de performance ESR du port 1_101_1 de l’ADM_CTN pendant une période
Figure 37: courbes disponibilité d'un port pendant une période

Etude de cas
Figure 38: courbes de performance SESR pendant une période

Etude de cas
Figure 39: Alarmes reçus
Les différentes options de tri sur la Figure 39 permettent de faire des requêtes :
Suivant le type de l’équipement
Suivant le nom de l’équipement ;
Suivant la période (date inferieure et date supérieure) de recherche;
Autre chose que la plateforme nous propose c’est la génération sur demande,
des rapports. Pour le moment l’application ne permet de générer que deux rapports à
savoir, la capacité d’occupation des ADMs et la matrice des trafics véhiculés sur le
réseau entier. Les Figures 40 et 41 nous présentent ces différents rapports. Ces
rapports constituent un réel outil de planification et d’optimisation du réseau.

Etude de cas
Figure 40: Rapport de Capacité des ADMs
Figure 41: Graphe capacité des ADMs du CJUY

Conclusion
5.3 Conclusion
Ce chapitre a mis en exergue les différents aboutissements de nos travaux sur la
maintenance préventive par la gestion des services et le suivi des indicateurs de
performance du réseau SDH/FO. Actuellement, nous allons faire un bilan du travail
accompli ensuite, ouvrir des perspectives sur l’avenir pour des éventuelles
améliorations de ces résultats.

Conclusion et Perspectives
Conclusion et
Perspectives

Bilan du Travail
Nous avions pour objectifs de concevoir et réaliser un outil d’aide à la
maintenance préventive basé sur la gestion des services et le suivi de la performance
du réseau SDH par Fibre Optique. Au terme de ce travail, nous avons développé une
application client-serveur qui prend en charge de façon automatique les fonctions
suivantes dans le réseau :
La gestion (Création, Modification, Suppression, consultations) des services,
des équipements et des conduits qui constituent le réseau SDH/FO du réseau 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 données rapatriées dans une base de
données ;
La mise à la disposition des équipes d’exploitation et de maintenance les
indicateurs de qualité de performance du réseau SDH à travers une application
JAVA Standalone sur le réseau interne.
La remontée automatique des alarmes par SMS,
Tout Ceci dans l’optique de mettre en place une politique de maintenance
rapide et efficace dans la gestion des ressources matérielles
Nous pouvons donc affirmer sans pour autant prétendre à l’exhaustivité que
toute l’analyse et toute la conception du projet ont été faites conformément à notre
cahier de charge. L’implémentation a été amorcée et nécessite d’avantage de temps
pour en arriver à une solution totalement exploitable par les équipes d’exploitation et
maintenance de l’entreprise. Le déploiement d’un tel outil permettra à ces équipes
d’avoir constamment et automatiquement les informations utiles sur l’état et la qualité
de fonctionnement des équipements SDH du réseau. Cette plateforme concoure
également à rendre plus souple l’analyse des indicateurs de qualité de transmission et
donc une maintenance proactive des équipements.

Perspectives
En guise de perspectives ce travail dans le fond et dans la forme peut subir des
améliorations. En effet dans un point de vue conceptuel il serait très utile selon le
responsable de la supervision du réseau national de CAMTEL, d’étendre les
fonctionnalités de supervision et de gestion de cette plateforme à différents types de
réseaux, à savoir CDMA, EWSD et bien d’autres, ceci dans l’optique de faire une
réelle corrélation entre les performances et les alarmes de ces réseaux dans un contexte
d’interopérabilité afin d’offrir une politique convergente et harmonisée d’optimisation.
Une autre perspective est d’associer à cette même plateforme une base de
connaissance sur les actions à mener pour résoudre un incident. Cette base devra être
consultable partout et suivant n’importe quelle plateforme (Web, Console, Standalone
…) et ce de façon sécurisé via VPN. L’objectif principal de cette base de connaissance
est de permettre une maintenance efficace, rapide et objective tout en se basant sur les
actions correctives et préventives qui ont déjà été menés dans le même cas de figure.
Il serait aussi fort intéressant que la plateforme puisse fournir une interface de
communication bidirectionnelle par SMS de telle sorte que les techniciens puissent
envoyer un SMS au système afin d’être informé sur l’état du réseau, d’un équipement,
d’un conduit, ou encore d’un service spécifique.

Bibliographie
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues a
[1] Nazim Agoulmine Omar Cherkaoui ; Pratique de la gestion de réseau [Groupe
Eyrolles, 2003] ; Chapitre 1
[2] Mémoire de fin d’études de l’étudiant NGANYEP NANA Léopold « Conception
et réalisation d’une plateforme de maintenance préventive et performance réseau
de transmission SDH par faisceaux hertziens : Cas du réseau Orange
Cameroun », Ecole National Supérieur Polytechnique de Yaoundé, promotion 2006.
[3] Mémoire de fin d’études de l’étudiant Ahmed KRICHEN, « Conception d’un
outil de suivi des performances des liens radio SDH du réseau GSM de
TUNISIANA », l’école supérieur des communications de Tunis (SUP’COM),
Promotion 2009.
[4] Support de cours, UV TDRN 501, Transmission de données et Réseaux
Numériques, Ecole National Supérieur 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] Benoît de DINECHIN, La SDH ; http://www.epinard.free.fr
Bibliographie

Annexes
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues b
Annexe A : Photos d’équipements d’un réseau SDH et Fibre
Optique
Figure 43: Tiroir Optique
Annexe B : Synoptique d’une liaison BSC-BTS
ADM CTN
Siemens
ADM JAMOT
Siemens
36 -7 2V=
1 - 0 .5A
A
CONSOLE
B
+
-
+
-
Modem Otique/Electrique
Répartiteur ADM JAMOT
Catalyst2950 SER IES
10B aseT/100B aseTX
S YS T RPS
S TA T UTIL DUPLX SP EE D
MODE
1x 8x7x6x5x4x3x2x 12x11x10x9x 16x15x14x13x 22x21x20x19x18x17x 23x 24x 24x 24x
100Base-FX
Tiroir Optique
36 - 7 2V=
1 - 0 .5A
A
C ONSOL E
B
+
-
+
- Modem Otique/Electrique
DDF
Catalyst2950 SERIES
10B aseT/100B aseTX
S YS T RPS
S TA T UTIL DUPLX SP EE D
MODE
1x 8x7x6x5x4x3x2x 12x11x10x9x 16x15x14x13x 22x21x20x19x18x17x 23x 24x 24x 24x
100Base-FX
Tiroir Optique3 6 - 72 V=
1 - 0.5 A
A
CON SOL E
B
+
-
+
- Modem Otique/Electrique
Catalyst 2950 SERI ES
10BaseT/100B aseTX
SY ST RP S
S TA T UTIL DUPLX S P EE D
MODE
1 x 8 x7 x6 x5 x4x3x2x 12 x11 x1 0x9 x 1 6 x15 x1 4x1 3x 22 x21 x2 0x1 9x1 8x17 x 2 3x 2 4x 2 4x 2 4x
100Base-FX
Tiroir Optique
Répartiteur BSC
HEWLETT
PACKARD
COMP AC T
BSC CTN
Re set
HE WLETT
PA CKAR D NetServer 5/100 LH.
1 2
Tape Clean
H EWL ET T
P AC KA R D
J etStore 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
Fibre
optique
Fibreoptique
STM-1
ADM CTN
Huawei
Fibre optique
STM-1
Fibreoptique
STM-1
FO
FO
Figure 44: Liaison BTS-BSC
Annexes
Figure 42: SURPASS hiT 7070

Annexes
Mémoire de fin d’étude d’Ingénieur de conception en Télécommunication Par KWATE KWATE Rodrigues c
Annexe C : Code d’envoi de SMS
Annexe D : Quelques Commandes AT
Nous nous intéresserons exclusivement aux commandes AT qui permettent
l’envoi des SMS.
Commandes Description
Module de Contrôle, d’état et d’identification
AT ATtention
ATI Afficher toutes les informations d’identification du produit
ATZ Régler tous les paramètres courants du profile Utilisateur
SMS (Text /PDU)
AT+CMGF Sélectionner 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 »

Definiifparker88

Contenu connexe

Similaire à Definiifparker88

Definiifparker88