République Tunisienne Ecole Supérieure

Privée de Technologie
Ministère de
et de Management
l'Enseignement
SUPTECH
Supérieur et de la
Recherche Scientifique Agrément N° :09-2001

Projet de Fin d’Etudes en vue

de l’obtention du diplôme de
Licence fondamentale
Spécialité : sciences de
l’informatique

Sujet :
Etude, conception et réalisation d’un outil
de suivi des dérangements des équipements
radio 4G de la Tunisie Telecom

Présenté par : Encadré par :

Mohamed Wajih El Ouaer Monsieur Nizar Ferjani

Année Universitaire 2016-2017
 Résumé

Afin de garantir une meilleure qualité de services de son réseau 4G, la Tunisie Tele-
com se doit d’effectuer une maintenance adéquate et rigoureuse de ses équipements
couteux, afin d’éviter un affaiblissement de sa compétitivité et un déficit énorme
sur le plan économique. L’objectif principal de ce projet de fin d’études, consiste à
concevoir et à développer un outil de suivi des dérangements des équipements radio
de réseau LTE, pour l’opérateur Tunisie Telecom. Dans le cadres de ce projet, une
étude bibliographie sur le réseau LTE et les différents équipements LTE installés
chez la Tunisie Telecom est à mener. Ensuite, et avant d’entamer la réalisation de
l’outil, il est essentiel d’en présenter un modèle conceptuel détaillé.

page i
page ii
 Abstract

In order to guarantee a better quality of services on its 4G network, Tunisie Telecom

must carry out adequate and rigorous maintenance of its expensive equipment, in
order to avoid a weakening of its competitiveness and a huge economic deficit. The
main objective of this end-of-study project is to design and develop a tool for mon-
itoring the disturbances of LTE radio equipment, for the Tunisie Telecom operator.
Within the framework of this project, a bibliography study on the LTE network and
the various LTE equipment installed at Tunisie Telecom is to be carried out. Then,
before starting to implement the tool, it is essential to present a detailed conceptual
model.

page iii
page iv
 Remerciements

Je tiens à remercier toutes les personnes qui ont contribué au succès de mon
projet de fin d’études et qui m’ont aidé lors de la rédaction de ce rapport. Tout
d’abord, j’adresse mes remerciements à mon encadreur, Monsieur Nizar Ferjani,
de la Tunisie Telecom et enseignant à la Suptech, qui a accepté de m’encadrer
. Son écoute et ses conseils m’ont permis de bien organiser mon travail et de le
guider dans la bonne direction. Je tiens à remercier vivement tous les membres de
notre université pour tout le support qu’ils nous ont apporté, à commencer par
Monsieur Mahdi Hamzaoui pour son support administratif et académique, ensuite
à tous les enseignants pour leurs conseils et leur écoute, enfin à tous les membres de
l’administration de l’université pour leur assistance et leur disponibilité.

page v
page vi
 A mes chers parents, à mon frère et à ma sœr pour tous leurs sacrifices, leur
amour, leur tendresse, leur soutien et leurs prières tout au long de mon année
d’études Que ce travail soit l’accomplissement de vos vœux tant allégués, et le fuit
de votre soutien infaillible, Merci d’être toujours là pour moi.

page vii
page viii
Table des matières

Résumé i

Remerciements iii

Dédicaces vii

Table des matières xii

Table des figures xiv

Liste des tableaux xv

Liste des abréviations xv

Introduction générale 1

1 Cadre du projet 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation de la Tunisie Telecom . . . . . . . . . . . . . . . . . . . 3
1.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Organisation structurelle de la Tunisie Telecom . . . . . . . . 4
1.2.3 Capital social . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.5 Filiales et partenariats . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet et cahier des charges . . . . . . . . . . . . . . 5
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

ix
 1.3.2 Travail demandé . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Plan de travail . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.4 Rôle de l’application . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.5 Processus de développement . . . . . . . . . . . . . . . . . . . 7
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Introduction aux réseaux LTE 9

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Présentation de la norme LTE . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 La norme LTE . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Aperçu des performances LTE . . . . . . . . . . . . . . . . . . 10
2.3 Architecture du réseau LTE . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 E-UTRAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 EPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Architecture IP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4 Canaux LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Technologies radio LTE . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Techniques de multiplexage . . . . . . . . . . . . . . . . . . . 15
2.4.2 Techniques de modulation des données . . . . . . . . . . . . . 16
2.4.3 Duplexage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Equipement radio de la Tunisie Telecom 21

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Modules de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 eBBU530 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.2 RRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Equipements auxiliaires . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1 Cabinet BTS3900 . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Module APM30H . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Module TMC11H . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 Module IBBS200 . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5 Modules IMB et OMB . . . . . . . . . . . . . . . . . . . . . . 27
3.3.6 Exemples de déploiement . . . . . . . . . . . . . . . . . . . . . 28

page x
 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Conception de l’outil 31
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . 32
4.3 Diagrammes de cas d’utilisations . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 Cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 Cas d’utilisation "s’authentifier" . . . . . . . . . . . . . . . . . 36
4.3.4 Tâches de l’administrateur . . . . . . . . . . . . . . . . . . . . 37
4.3.5 Tâches de l’employé . . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Diagramme d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.6.2 Création d’un compte d’utilisateur . . . . . . . . . . . . . . . 44
4.6.3 Gestion des éléments du réseau LTE . . . . . . . . . . . . . . 45
4.6.4 Consultation de données . . . . . . . . . . . . . . . . . . . . . 46
4.6.5 Insertion de rapports . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Réalisation du projet 49
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . 49
5.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . 50
5.3 Présentation de l’application . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.1 Modèle Client/Serveur . . . . . . . . . . . . . . . . . . . . . . 51
5.3.2 Modèle MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 Interfaces de l’application . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.1 Interface d’authentification . . . . . . . . . . . . . . . . . . . . 54
5.4.2 Interface d’enregistrement . . . . . . . . . . . . . . . . . . . . 54
5.4.3 Interface des historiques . . . . . . . . . . . . . . . . . . . . . 55

page xi
 5.4.4 Interface des alertes . . . . . . . . . . . . . . . . . . . . . . . . 55
5.4.5 Interface des rapports . . . . . . . . . . . . . . . . . . . . . . 55
5.4.6 Outil de signalisation d’erreur . . . . . . . . . . . . . . . . . . 56
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Conclusion générale 57

Bibliographie 60

page xii
Table des figures

1.1 Organisation structurelle de la Tunisie Telecom . . . . . . . . . . . . 4

1.2 Processus 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Architecture d’un réseau LTE . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Pile de protocoles plan contrôle . . . . . . . . . . . . . . . . . . . . . 13
2.3 Pile de protocoles plan utilisateur . . . . . . . . . . . . . . . . . . . . 13
2.4 Example de sous porteuses . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Constellations de modulation des données binaires . . . . . . . . . . . 17
2.6 FDD et TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.7 Représentation de la technique MIMO . . . . . . . . . . . . . . . . . 18

3.1 Apparence de l’unité eBBU530 . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Installation des cartes LTE . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Carte LMPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Carte LBBP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Carte UPEU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Module Cabinet BTS3900 . . . . . . . . . . . . . . . . . . . . . . . . 26
3.8 Module APM30H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Module TMC11H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Module IBBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.11 Modules IMB et OMB . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.12 Déploiement interne et externe dans une zone urbaine . . . . . . . . . 28
3.13 Déploiement long des autoroutes et des voies ferrées . . . . . . . . . . 29

xiii
4.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . 34
4.2 Diagramme de cas d’utilisation "s’authentifier" . . . . . . . . . . . . . 36
4.3 Diagramme de cas d’utilisation "Tâches de l’administrateur" . . . . . 37
4.4 Diagramme de cas d’utilisation "Utilisation de l’outil" . . . . . . . . . 38
4.5 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.6 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.7 Diagramme de séquences s’authentifier . . . . . . . . . . . . . . . . . 43
4.8 Diagramme de séquence s’enregistrer . . . . . . . . . . . . . . . . . . 44
4.9 Diagramme de séquences gérer réseaux . . . . . . . . . . . . . . . . . 45
4.10 Diagramme de séquence consulter données . . . . . . . . . . . . . . . 46
4.11 Diagramme d’activités . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Modèle Client/Serveur simplifié . . . . . . . . . . . . . . . . . . . . . 52

5.2 Architecture d’une application Java EE . . . . . . . . . . . . . . . . . 53
5.3 Formulaire d’authentification . . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Formulaire d’enregistrement . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Menu des historiques . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6 Menu des alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 Formulaire des rapports d’interventions . . . . . . . . . . . . . . . . . 56
5.8 Programme d’alertes . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

page xiv
Liste des tableaux

2.1 Méthodes de modulation des données . . . . . . . . . . . . . . . . . . 16

3.1 Modules LTE installées dans une eBBU530 . . . . . . . . . . . . . . . 23

3.2 Ports des cartes LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Ports de la RRU3232 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Ports de la RRU3253 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Description textuelle des cas d’utilisations . . . . . . . . . . . . . . . 35

4.2 Analyse du cas d’utilisation "s’authentifier" . . . . . . . . . . . . . . 36
4.3 Analyse du cas d’utilisation de l’administrateur . . . . . . . . . . . . 38
4.4 Analyse du cas d’utilisation des employés . . . . . . . . . . . . . . . . 39
4.5 Description des classes . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Configuration de l’environnement matériel de travail . . . . . . . . . . 50

5.2 Technologies disponibles pour chaque Tier . . . . . . . . . . . . . . . 54

xv
page xvi
Liste des abréviations

2TUP 2 tracks unified process

3GPP 3rd Generation Partnership Project
3G Réseaux cellulaires de troisième génération
4G Réseaux cellulaires de quatrième génération
APM Advanced Power Module
BBU Baseband Unit
BTS Base Transceiver Station
CSS3 Cascading Style Sheet 3
E-NodeB Evolved Node B
EPC Evolved Packet Core
E-UTRAN Evolved Universal Terrestrial Radio Access Network
FDD Frequency Division Duplexing
GW Gateway
HSS Subscriber Home
HTML HyperText Mark-Up Language
IBBS Intergrated Battery Backup System
IP Internet Protocol
LTE Long Term evolution
MAC Media Access Control
MIMO Multiple Input Multiple Output
MME Mobility Manager Entity
MVC Model-View-Conroller
OFDM Orthogonal Frequency Division Multiplex
OFDMA Orthogonal Frequency Division Multiplex Access
PDCP Packet Data Convergence Control
PGW Packet Data Network Gateway
QOS Quality of service
RLC Radio Link Control
RRC Radio Resource Control
RRU Remote Radio Unit
SGBD Système de gestion de bases de données
S1-C S1- Control plane interface
TDD Time Division Duplexing
TMC Transmission Cabinet

xv
page xvi
Introduction générale

Les innovations réalisées en matière de technologies de télécommunication, et

l’émergence des nouvelles tendances internet ont profondément changé nos modes
de vies. Avec l’apparition de la technologie mobile LTE qui permet une transmission
de données à haut débit, et les services internet tels que les vidéoconférences, les
outils de collaboration, ou encore les jeux vidéo en ligne, il est désormais assez fa-
cile pour un individu ou une organisation, d’accéder en mobilité à des ressources au
contenu très riche, ou de garder contact avec d’autres individus, à condition d’avoir
un appareil adéquat et un réseau fiable.

Afin de garantir la fiabilité de son réseau LTE et rester compétitif face à la

concurrence, la Tunisie Telecom doit veiller à ce que ses équipements soient fonc-
tionnels et disponibles pour une meilleure qualité de service. Dans ce but, la Tunisie
Telecom doit pouvoir suivre les dérangements qui surviennent au niveau de ses équi-
pements LTE et réagir en conséquence.

Dans le cadre de ce projet, une solution de gestion et de suivi des dérangements

des réseaux LTE de la Tunisie Telecom est à développer. Ce document décrit toutes
les étapes à entreprendre pour atteindre cet objectif.

Chapitre 1 est consacré à la présentation de l’établissement d’accueil et à une

étude de l’existant.

Chapitre 2 a pour objectif de donner une vue d’ensemble sur les notions de base
des réseaux LTE.

1
 Introduction générale

Chapitre 3 est dédié à la présentation de l’équipement radio LTE déployé par la

Tunisie Telecom.

Chapitre 4 contient la représentation conceptuelle de la solution à développer.

Chapitre 5 est consacré à la réalisation et les ressources mis en œvre pour déve-
lopper la solution.

page 2 Projet de fin d’études

Chapitre 1
Cadre du projet

1.1 Introduction
Les objectifs de ce chapitre sont la présentation de l’établissement d’accueil afin
de lier le projet à son cadre théorique, et la présentation du cahier des charges afin
d’exposer la problématique ainsi que le travail demandé. L’organisation du chapitre
est comme suit :

• Historique, structure organisationnelle et activités de la Tunisie Telecom

• Cahier des charges, problématique et objectifs

• Processus de développement

1.2 Présentation de la Tunisie Telecom

1.2.1 Historique
Jusqu’en 1995, les activités liées au secteur des télécommunications en Tunisie
étaient gérées par l’office tunisien des Postes et Télégraphes, qui était administré par
le Ministère des Télécommunications. En date du 17 avril 1995, par la loi numéro
95-36, les activités des postes et des télécommunications ont été dissociées, créant
ainsi l’office national des télécommunications sous la forme d’établissement public
à caractère industriel et commercial doté de la personnalité civile et de l’autonomie
financière [14]. En date du 5 avril 2004, par la loi numéro 2004-30, l’office national des

3
1.2 Présentation de la Tunisie Telecom Chapitre 1. Cadre du projet

télécommunications s’est transformé en société anonyme, dont le nom commercial

est Tunisie Telecom [14].

1.2.2 Organisation structurelle de la Tunisie Telecom

L’organigramme administratif de la Tunisie Telecom se compose de six direc-
tions centrales qui gèrent l’ensemble des tâches au sein de la société. Chaque direc-
tion centrale se compose elle-même de départements. La figure suivante 1 présente
l’organisation structurelle de la Tunisie Telecom

Figure 1.1: Organisation structurelle de la Tunisie Telecom

1.2.3 Capital social

Le capital de Tunisie Telecom a été fixé à 1.400.000.000 Dinars constitué par un
apport en nature égal à la valeur de l’ensemble du patrimoine apporté par l’Etat à
l’Office National des Télécommunications en application de la loi numéro 95-36 en
date du 17 avril 1995 et un apport en numéraire[14]. En 2006, dans le cadre de la
libéralisation du secteur, Tunisie Telecom a fait l’objet d’une privatisation partielle
avec l’entrée dans son capital à hauteur de 35% du consortium formé par Dubai
Investment Group et le consortium Emirates International Telecommunications[14].
1. source https ://www.tunisietelecom.tn

page 4 Projet de fin d’études

Chapitre 1. Cadre du projet 1.3 Présentation du projet et cahier des charges

1.2.4 Activités
La Tunisie Telecom fournit au public et aux entreprises des services dans les
secteurs de la téléphonie fixe, mobile et de l’Internet[14] :

• Accès Internet pour les privés et les entreprises

• Services d’interconnexion nationale et services roaming in

• Accès aux réseaux mobiles 2G, 3G et 4G

1.2.5 Filiales et partenariats

La Tunisie Telecom est détentrice des filiales suivantes[14] :

• Topnet fournisseur d’accès à internet

• Société tunisienne des télécommunications

• Société Mauritano-Tunisienne de Telecom

• Société d’investissement DIVA SICAR

• Go Malta

En plus de ses filiales, la Tunisie Telecom entretient des relations avec plusieurs
partenaires nationaux et internationaux, dans le but de renforcer sa présence sur le
marché des télécommunications[14] :

• Partenaires en Tunisie : Agence tunisienne de l’Internet, Banque de l’habitat,

Groupe khechine 2

• Groupe THURAYA, L’organisation RASCOM et Réseau SEA-ME-WE4

1.3 Présentation du projet et cahier des charges

Cette partie est consacrée à la présentation du projet, sa problématique et à
présenter le cahier des charges ainsi que le processus adopté, pour modéliser et
réaliser la solution proposée.

2. http ://www.leaders.com.tn/article/15478-le-groupe-khechine-et-tunisie-telecom-signent-un-
partenariat-commercial-global

Projet de fin d’études page 5

1.3 Présentation du projet et cahier des charges Chapitre 1. Cadre du projet

1.3.1 Problématique
Pour un opérateur la maintenance inadéquate ou absente entraine la dégradation
de qualité de service voire la coupure d’une liaison n’échappe pas à la norme. Ses
équipements sont couteux et engendrer un déficit énorme sur le plan économique
pour l’opérateur. Le processus de suivi des alertes et des performances doit être très
rigoureux pour garantir une meilleure qualité de service.

1.3.2 Travail demandé

Le travail demandé est réparti sur trois tâches. La première tâche consiste à me-
ner une étude bibliographique sur le réseau LTE, afin de comprendre son architecture
et son principe de fonctionnement. Ensuite, l’inventaire des différents équipements
LTE installés chez la Tunisie Telecom sera donné. Enfin, la troisième tâche consiste à
concevoir et à développer un outil de suivi des dérangements des équipements radio
pour le réseau LTE.

1.3.3 Plan de travail

1. Etude bibliographique sur les réseaux LTE et les équipements radio de la
Tunisie Telecom.
2. Spécification des besoins fonctionnels et non fonctionnels de l’application.
3. Conception et modélisation de l’application.
4. Développement de l’application.
5. Test et validation de l’application.

1.3.4 Rôle de l’application

Afin de dépasser les problèmes énumérés précédemment, l’outil de suivi des dé-
rangements des équipements radio pour le réseau LTE devra permettre :
• assurer un enregistrement de l’historique des interventions,
• assurer des statistiques des dérangements,
• suivre les dérangements,
• rapporter les taches effectuées et générer des alertes

page 6 Projet de fin d’études

Chapitre 1. Cadre du projet 1.3 Présentation du projet et cahier des charges

1.3.5 Processus de développement

Le processus de développement adopté pour ce projet est la méthode 2TUP qui
se base sur la méthode du processus unifié. Avant de présenter la méthode 2TUP, il
est souhaitable de donner une description du processus unifié.

Processus unifié La méthode du processus unifié est un processus de développe-

ment de logiciel de logiciels 3 qui axé sur quatre phases : [9][7].
1. Incéption consiste à fixer un objectif clair, à capturer les besoins fonctionnels,
et à identifier les risques
2. Elaboration consiste à définir des cas d’utilisations du logiciel, un prototype
d’architecture ainsi que les étapes de développement
3. Construction consiste à concrétiser le modèle conceptuel du logiciel en im-
plémentant son architecture
4. Transition consiste à passer de l’étape de développement à la phase d’utili-
sation en rendant le logiciel accessible à l’utilisateur final
Les caractéristiques du processus unifié sont :
• itératif et incrémental, c’est à dire permet de définir une série de tâches qui
seront reprises sur chaque nouveau résultat obtenu afin de le raffiner.[9]
• permet d’identifier les risques d’échec d’un projet et de les éliminer
• se base sur le développement d’un prototype de base et de son développement
à travers plusieurs itérations
• construit à partir des besoins fonctionnels pour atteindre un logiciel qui répond
le mieux aux besoins de l’utilisateur

Processus 2TUP Les pricipales étapes du processus 2TUP sont illustrées dans
la figure suivante :

3. source www.wikipedia.org

Projet de fin d’études page 7

1.4 Conclusion Chapitre 1. Cadre du projet

Figure 1.2: Processus 2TUP

Les contraintes imposées au cycle de développement d’un logiciel sont d’ordre

fonctionnel et technique. Sur la figure 1.2, ces deux types de contraintes peuvent être
vues comme deux branches qui, durant le cycle de développement seront fusionnées.

1.4 Conclusion
Le but de ce chapitre, a été de définir le cadre du projet. En exposant la problé-
matique, l’importance de l’outil de suivi des dérangement des équipements de réseau
LTE a été mis évidence. Pour spécifier le travail à faire, le cahier des charges ainsi
que la méthode de développement ont été présentés. Avant de présenter un modèle
conceptuel de l’outil, il est souhaitable de donner les notions de bases des réseaux
LTE ainsi qu’une description de l’équipement radio installé chez l’opérateur Tunisie
Telecom.

page 8 Projet de fin d’études

Chapitre 2
Introduction aux réseaux LTE

2.1 Introduction
La première étape de la réalisation du projet consiste à faire une étude biblio-
graphique sur les réseaux LTE. Ce chapitre dont le but est de présenter la norme
LTE constitue la première partie de cette étude. Le chapitre commence par définir
la norme LTE, ensuite donne une vue d’ensemble sur l’architecture d’un réseau LTE
et de ses éléments, enfin traite les technologies sur lesquelles la norme LTE se base.
Ce chapitre est organisé comme suit :
• Présentation générale de la norme LTE
• Architecture d’un réseau LT
• Caractéristiques techniques

2.2 Présentation de la norme LTE

2.2.1 La norme LTE
La norme Long Term Evolution (LTE) est une norme de téléphonie mobile de
quatrième génération, communément appelée 4G. La norme LTE a été créée dans le
cadre d’un projet lancé en 2004 par un Consortium de télécommunications appelé
Third Generation Partnership Project 1 (3GPP) pour répondre aux exigences des
utilisateurs mobiles en matière de connexion à haut débit, en vue de la convergence
1. source : http ://www.3gpp.org/technologies/keywords-acronyms/98-lte

9
2.3 Architecture du réseau LTE Chapitre 2. Introduction aux réseaux LTE

de l’Internet et les réseaux mobiles ainsi que l’émergence des nouvelles tendances
des TIC comme les vidéoconférences, les outils de collaboration en ligne ou encore,
les jeux vidéo en ligne. En plus des exigences des utilisateurs, LTE a été conçu pour
satisfaire le besoin des opérateurs, notamment grâce à un déploiement facile et moins
couteux. La LTE désigne la partie radio d’un réseau mobile 4G. Le cœur du réseau
d’un réseau 4G porte le nom de System Architecture Evolution (SAE). L’évolution
que ce dernier apporte par rapport aux réseaux des générations précédentes, est une
architecture entièrement basée sur le protocole IP. La LTE et le SAE constituent un
Evolved Packet System (EPS) [12] [2]. Ce rapport traite la partie LTE.

2.2.2 Aperçu des performances LTE

Les performances réalisables avec LTE sont[2] :

• Débit crête ascendant de 50 Mbits/s

• Débit descendant pic théorique allant de 100 Mbits/s jusqu’à 300Mbits/s

• Temps d’accès radio de 10ms

• Operant sur des largeurs de bandes LTE de 2x20 MHz

• Support du duplexage temporel (TDD) ou fréquentiel (FDD)

• Couverture de cellules sur 5 km pour des performances optimales

2.3 Architecture du réseau LTE

Un réseau LTE est composé des éléments suivants :

• Les appareils utilisateurs mobiles

• La partie accès radio Evolved Universal Terrestrial Radio Access Network (E-
UTRAN)

• Le noyau du réseau Evolved Packet Core (EPC)

La figure suivante donne une vue d’ensemble sur un réseau LTE avec toutes ses
composantes interfaces. Les éléments du réseau LTE seront traitées dans les sections
qui suivent[13] :

page 10 Projet de fin d’études

Chapitre 2. Introduction aux réseaux LTE 2.3 Architecture du réseau LTE

Figure 2.1: Architecture d’un réseau LTE

2.3.1 E-UTRAN
La partie d’accès radio e-UTRAN est l’évolution de la partie radio 3G connue
sous le nom de UTRAN. Il s’agit est un réseau composé de stations de base appe-
lées eNodeB. Les stations eNodeB sont interconnectées via des interfaces logiques
X2, et sont connectées au EPC via des interfaces logiques S1. Contrairement aux
réseaux des anciennes générations, un réseau LTE est constitué uniquement de eN-
odeB comme nœud. Cette centralisation des tâches a pour avantage d’améliorer les
performances au niveau de la connexion d’appareils mobiles ainsi qu’aux fonctions
de changement intercellulaires, lorsque les utilisateurs du réseau se déplacent.

2.3.2 EPC
Le cœur du réseau est la partie chargée de faire passer le trafic de données entre
les utilisateurs du réseau mobile et les réseaux externes comme le réseau internet ou
encore les réseaux mobiles d’autres opérateurs. Il existe deux types d’éléments dans
un EPC, selon le type de trafic données à gérer. Les ressources destinées aux utilisa-
teurs sont transportées au niveau plan utilisateur, quant aux données relatives à la

Projet de fin d’études page 11

2.3 Architecture du réseau LTE Chapitre 2. Introduction aux réseaux LTE

gestion de la communication, elles sont transportées au niveau plan de contrôle. Les

nœuds chargés du trafic de données des utilisateurs tels que les contenus téléchargés
sont les S-GW et P-GW, et les nœuds de contrôle sont les MME et HSS.

HHS Le HSS est une base de données qui contient les informations relatives aux
profiles des abonnés de l’opérateur du réseau.

MME La Mobility Management Enity (MME) est l’entité responsable du plan

contrôle. Le terme plan contrôle englobe toutes les tâches relatives à la signalisation
entre les appareils utilisateurs et le noyau tels que :
• Etablissement de sessions de communication entre un émetteur et un récepteur
• Gestion et contrôle de la connexion des appareils utilisateur
• Liaison avec le HSS pour garantir l’accès sécurisé au réseau

S-GW et PDN-GW sont des passerelles dédiées à l’acheminement du trafic de

données utilisateurs. Les passerelle de type S-GW jouent le rôle d’un routeur entre
les eNodeB du réseau, tandis que les PDN-GW connectent le réseau avec les réseaux
externes comme Internet.

PCRF La partie Policy Control and Charging Rules (PCRF) est la partie respon-
sable de la politique de la qualité des services et de facturation en temps réel.

2.3.3 Architecture IP
Les réseaux LTE sont entièrement basés sur un modèle conceptuel appelé pile
de protocoles IP. La pile de protocoles IP est une représentation en couches des
fonctions qui servent à traiter les données qui circulent entre un émetteur et un
récepteur. L’idée de grouper ces fonctions en couches est de permettre la compré-
hension des différents mécanisme d’envoi et de réception des données. Les données
transmises entre appareils mobiles, eNodeB et cœur du réseau sont acheminés sous
forme de paquets, y compris la voix. Pour qu’un paquet puisse arriver à destination,
les paquets utilisent des entêtes contenant les adresses de l’émetteur ainsi que du
destinataire. Pour permettre une communication entre deux entités, il est essentiel
que ces deux entités possèdent la même interface et utilisent les mêmes règles de

page 12 Projet de fin d’études

Chapitre 2. Introduction aux réseaux LTE 2.3 Architecture du réseau LTE

communication. Dans ce qui suit la notion de règle de communication est représentée

par des protocoles. Les figures suivantes illustrent les protocoles de la partie radio.
2.2 illustre la pile de protocoles du plan de contrôle, et 2.3 illustre les protocoles du
plan utilisateur [11]. Les protocoles résidant dans la partie non-radio ne seront pas
concernés, mais seront illustrées sans couleur dans les figures suivantes :

Figure 2.2: Pile de protocoles plan contrôle

Figure 2.3: Pile de protocoles plan utilisateur

Au niveau plan utilisateur, les applications créent des paquets de données qui
sont traités par des protocoles tels que TCP, UDP et IP, tandis qu’au niveau plan
de contrôle, le protocole Radio Resource Control (RRC) écrit les messages de signa-
lisation échangés entre la station de base et l’appareil mobile. Sur les deux plans,
les informations sont traitées par le protocole packet data convergence protocol
(PDCP), le protocole de Radio Link Control (RLC) et le protocole de contrôle d’ac-
cès au support physique, la couche Medium Access Control (MAC), avant d’être
transmis à la couche physique pour la transmission. Ci-dessous, la description de
chaque protocole. La pile du plan contrôle est constituée des mêmes protocoles que
la pile plan utilisateur mais contient en plus la couche RRC.

Projet de fin d’études page 13

2.3 Architecture du réseau LTE Chapitre 2. Introduction aux réseaux LTE

Couche physique L1 Fournit les mécanismes pour transporter les données d’un
émetteur vers un destinataire sur le support physique que sont les ondes radio. Ces
mécanismes décrivent comment le support physique est exploité, et comment les
données sont adaptées dans le but de les transporter sur le support physique. Ces
mécanismes sont implémentées avec des techniques comme le codage, le multiplexage
de la bande de fréquences et le mode de communication.

Couche MAC joue le rôle d’intermédiaire entre les couches supérieures et la

couche physique. Elle est responsable du mappage entre les canaux logiques et les
canaux de transport, le multiplexage des paquets reçus et envoyées entre les couches
supérieures et la couche physique. Parmi les fonctions de cette couche, il y a l’al-
location dynamique des ressources spectrales entre appareils mobiles, connue sous
le nom de scheduling dynamique, et aussi la correction des paquets par un procédé
appelé HARQ.

Couche RLC La couche RLC est utilisée pour formater et transporter des don-
nées entre les appareils mobiles et les eNodeB. Pour le transport des données, la
couche RLC fournit trois modes, à savoir le mode sans demande de retransmission
utilisé dans des applications qui demandent un débit constant comme le visionnage
de vidéos, c’est dire que les paquets erronés ne sont pas retransmis, le mode avec
demande de retransmission, ou les paquets erronées sont retransmis, pour des appli-
cations comme le téléchargement de fichiers ou tous les paquets de données doivent
être intacts, et enfin le mode transparent utilisé pour la diffusion d’informations
système.

Couche PDPC La couche PDCP est responsable de la compression et de la

décompression de l’en-tête des données IP, du transfert de données (plan utilisateur
ou plan de contrôle), maintenance des numéros de séquence PDCP (SNs), envoi en
séquence des paquets de données de la couche supérieure vers les couches inférieures.

Couche RRC Cette couche contient les fonctions relatives au plan contrôle. Les
fonctions de cette couche sont la gestion des appareils mobiles dans le réseau. Une
des fonctionnalités fournies par cette couche est la signalisation de messages d’éta-
blissement de session de communications entre deux appareils mobiles, et la clôture

page 14 Projet de fin d’études

Chapitre 2. Introduction aux réseaux LTE 2.4 Technologies radio LTE

de cette session quand celle ci n’est plus utilisée.

2.3.4 Canaux LTE

Les protocoles présentés dans les paragraphes précédents décrivent les fonctions
nécessaires pour établir le transport des données d’un émetteur vers un récepteur.
Les canaux présentés dans cette section décrivent les voies que les données em-
pruntent afin d’être transportées. Il existe trois types de canaux :

• Canaux logiques définissent quel type de données sont transportées sur le sup-
port physique, comme les messages de signalisation de contrôle ou les données
d’utilisateurs.
• Canaux physiques définissent à quel niveau de la couche physique les données
sont transportées, tels que les données se trouvant les trames de la liaison
montante ou descendante.
• Canaux de transport définissent les paramètres de la transmission sur les ca-
naux logiques tel que le codage à appliquer pour la transmission radio.

2.4 Technologies radio LTE

Pour assurer un transfert de données a à hauts débit, la norme LTE se base sur
les technologies suivantes :

2.4.1 Techniques de multiplexage

Le terme multiplexage décrit l’utilisation d’un même support physique pour la
transmission de plusieurs flux d’informations simultanément. Dans le cas de la norme
LTE, le multiplexage est réalisé avec les methodes OFDMA pour la transmission
descendante et SC-FDMA pour la transmission montante. Le principe dont les deux
techniques sont dérivées est Orthogonal Frequency Division Multiplexing (OFDM)
et qui consiste à utiliser non pas toute une bande de fréquence pour la transmission
d’un seul type de flux, mais d’utiliser plusieurs sous-porteuses au sein de cette même
bande, pour transmettre les données. Pour éviter les interférences, les sous-porteuses
sont orthogonales entre elles. La figure suivante montre la forme des sous-porteuses

Projet de fin d’études page 15

2.4 Technologies radio LTE Chapitre 2. Introduction aux réseaux LTE

orthogonales. La propriété de l’orthogonalité est réalisée en gardant une différence

de phase de 90◦ entre les sous porteuses :[lte1]

Figure 2.4: Example de sous porteuses

2.4.2 Techniques de modulation des données

Avant la transmission, les données binaires sont adaptées pour être transportées
par des ondes radio. La technique utilisée pour cette tâche est appelée Quadrature
Amplitude Modulation (QAM). Selon plusieurs facteurs[electronics site], comme la
distance entre [hanen hrizi] un terminal et une station eNodeB, un des schémas
suivants est appliqué :

QPSM (4QAM) 2 Bits par symbole

16QAM 4 Bits par symbole
64QAM 6 Bits par symbole

Table 2.1: Méthodes de modulation des données

Pour un fragment d’information en format binaire, chaque groupe de bits, est

associé à un ongle qui sera utilisé pour le changement de l’amplitude et la phase de
la porteuse. La figure 2 suivante illustre comment des données binaires sont codées :

2. source : http ://rfmw.em.keysight.com/wireless/helpfiles/89600B/WebHelp/Subsystems/teds/content/teds

symbolsconstellations.htm

page 16 Projet de fin d’études

Chapitre 2. Introduction aux réseaux LTE 2.4 Technologies radio LTE

Figure 2.5: Constellations de modulation des données binaires

2.4.3 Duplexage

LTE utilise deux techniques de duplexgae qui consistent à utiliser un même

support de communication pour faire circuler des données entre un émetteur et un
récepteur dans les deux sens :

• Frequency Division Duplex (FDD) consite à utiliser deux fréquences différentes

pour le transfert montant et le transfert descendant.

• Time Division Duplex (TDD) consiste a utiliser une seule bande de fréquence
en réservant un intervalle temporel pour la transmission et un intervalle tem-
porel pour la réception. La courte durée de ces intervalles qui sont de l’ordre
de quelque millisecondes, donnent l’impression que la communication est si-
multanée. Pour éviter les interférences, ces deux bandes de fréquences sont
séparées par une fréquence de garde.

La figure suivante 3 illustre les deux Formats de trame LTE selon le schéma de
duplexage utilisé :

3. source : http ://blog.3g4g.co.uk/2011/11/interoperability-between-lte-fddtdd.html

Projet de fin d’études page 17

2.4 Technologies radio LTE Chapitre 2. Introduction aux réseaux LTE

Figure 2.6: FDD et TDD

2.4.4 MIMO
La technique Multiple Input Multiple Output (MIMO) consiste à utiliser plu-
sieurs chemins de propagations entre un émetteur et un récepteur. Cette technique
permet de garder une bonne qualité de signal en utilisant plusieurs plusieurs an-
tennes aussi bien chez la source que chez la destination. Il existe plusieurs combinai-
sons quant au nombre d’antennes chez l’émetteur et le récepteur. la figure suivante
illustre un example avec un transmetteur à quatre antennes, et un récepteur à deux
antennes comme il est à voir dans la figue suivante 4 :

Figure 2.7: Représentation de la technique MIMO

4. source http ://www.unwiredinsight.com/tag/mimo

page 18 Projet de fin d’études

Chapitre 2. Introduction aux réseaux LTE 2.5 Conclusion

2.5 Conclusion
Dans ce chapitre, nous avons parcouru l’architecture du réseau LTE, Nous avons
détaillé les interfaces de cette technologie. Dans le chapitre suivant nous allons les
présenter Infrastructure Radio E-UTRAN installé chez Tunisie Telecom.

Projet de fin d’études page 19

2.5 Conclusion Chapitre 2. Introduction aux réseaux LTE

page 20 Projet de fin d’études

Chapitre 3
Equipement radio de la Tunisie Telecom

3.1 Introduction

Le chapitre précédant a servi à donner une vue d’ensemble sur les notions théo-
riques et le caractéristiques des réseaux LTE. Ce chapitre a pour objectif de donner
une description de l’équipement radio LTE installé par la Tunisie Telecom. Ce cha-
pitre est organisé comme suit :

• Description des modules de base

• Description des équipements auxiliaires

• Exemple de déploiement

3.2 Modules de base

L’E-UTRAN installé par la Tunisie Telecom se compose de stations appelées les

Distributed Base Stations DBS3900, construites par Huawei. Une station DBS3900
se compose de deux éléments de bases que sont les eBBU530 et les RRU. Ces deux
modules sont interconnectés à l’aide de câbles en fibre optique via une interface
dédiée. Afin de garantir une grande flexibilité d’installation, les eBBU530 et les
RRU peuvent être combinée avec d’autres composantes auxiliaires pour répondre
aux contraintes du site à couvrir.

21
3.2 Modules de base Chapitre 3. Equipement radio de la Tunisie Telecom

3.2.1 eBBU530
La eBBU530 est l’unité de bande de base dont les fonctionnalités sont :
• Fournit les interfaces vers les parties MME et S-GW du cœur du réseau
• Fournit l’interface CPRI pour la liaison avec les RRU
• Fournit les fonctions de gestion et maintenance
• Fournit les ports de synchronisation des horloges systèmes
• Fournit les ports pour les équipements se surveillance de l’environnement la
station
• Traite les signaux ascendants et descendants
La figure suivante montre l’apparence de l’unité eBBU530 :

Figure 3.1: Apparence de l’unité eBBU530

Les unités eBBU530 peuvent être utilisées pour fonctionner sous plusieurs modes.
Dans le cadre de ce projet, la configuration LTE sera considérée. La figures3.9 montre
la configuration d’une eBBU530 pour fonctionner en mode LTE, les figures 3.3, 3.4
et 3.5 montrent les différents ports de chaque carte illustrée dans la figure 3.9, Le
tableau 3.1 décrit les modules illustrés dans la figure 3.9, le tableau 3.2 donne une
description des ports de chaque module :

Figure 3.2: Installation des cartes LTE

page 22 Projet de fin d’études

Chapitre 3. Equipement radio de la Tunisie Telecom 3.2 Modules de base

Figure 3.3: Carte LMPT

Figure 3.4: Carte LBBP

Figure 3.5: Carte UPEU

Carte Description

LMPT Gestion des d’exploitation et de maintenance des eNodeB,

du processus de signalisation et de signaux d’horloge
LBBP Fournit l’interface CPRI pour la communication avec les unités
RRU
FAN Gestion des unités de ventilation, traite les problèmes de surchauffe
de la eBBU530
UPEU Unité d’alimentation de la eBBU530

Table 3.1: Modules LTE installées dans une eBBU530

Projet de fin d’études page 23

3.2 Modules de base Chapitre 3. Equipement radio de la Tunisie Telecom

Carte Ports

LMPT • 2 Ports SFP pour câbles optiques, transmissions S1 et X2

• 2 Ports FE/GE pour câbles RJ45, transmissions S1 et X2
• 2 Ports USB de tests, mise en marche et gestion logicielle
• 1 Port Ethernet de connexion avec un LMT
• 1 Port de connexion avec une antenne GPS
LBBP • 6 Ports CPRI de connexion avec l’interface radio
UPEU • 2 Ports RJ45 pour dispositifs d’alertes
• 2 Ports RJ45 pour dispositifs de surveillance
• 1 Port d’alimentation

Table 3.2: Ports des cartes LTE

3.2.2 RRU
Les unités RRU représentent l’interface radio d’une station DBS3900. l’interface
radio a pour rôle principal de moduler et démoduler les signaux radio et bande de
bases. La figure 3.6a montre une unité RRU3232 avec et sans boîtier, tandis que la
figure 3.6b montre une RRU3253 sans boîtier avec ses ports :

(a) Unité RRU3232

(b) Unité RRU3253

page 24 Projet de fin d’études

Chapitre 3. Equipement radio de la Tunisie Telecom 3.3 Equipements auxiliaires

Les ports des RRU illustrées sont décrites dans les tableaux suivants :

Ports Description

2 Ports CPRT Connexion avec les eBBU530

4 Ports radio Connexion avec l’antenne
1 Port Ground Relie la RRU avec la masse
2 Ports d’alimentation Alimentation de la RRU
1 Port Tilt Connexion avec une unité de contrôle

Table 3.3: Ports de la RRU3232

Ports Description

2 Ports IR Transmission de données et synchronisation

8 Ports radio Connexion avec l’antenne
1 Port radio Port de calibrage
1 Ports d’alimentation Alimentation de la RRU
1 Port RS485 Liaison avec des dispositifs d’alarmes et de suivi

Table 3.4: Ports de la RRU3253

3.3 Equipements auxiliaires

Les équipements auxiliaires sont des dispositifs de déploiement des stations DBS3900
dans divers sites . L’objectif de cette section est de donner un descriptif de ces dispo-
sitifs, et de montrer la façon avec laquelle ils permettent l’installation d’une DBS3900
selon plusieurs scénarios.

3.3.1 Cabinet BTS3900

Le cabinet BTS3900 est une station de base macro dont l’installation requière
un espace à l’intérieur d’un bâtiment ou d’un site dédié. La figure suivante montre
un cabinet BTS3900, avec des unités BBU et des unités radio :

Projet de fin d’études page 25

3.3 Equipements auxiliaires Chapitre 3. Equipement radio de la Tunisie Telecom

Figure 3.7: Module Cabinet BTS3900

3.3.2 Module APM30H

Le module APM30H est utilisé pour alimenter des stations en courant continu
dans des installations à l’extérieur des bâtiments.Il offre un espace pour installer
l’équipement de transmission de l’opérateur, des batteries de secours ainsi qu’un
système de ventilation pour contrôler la température de tout le système installé. La
figure suivante montre l’intérieur d’un module APM30H, et l’espace réservé pour
l’équipement l’équipement de transmission de l’opérateur :

Figure 3.8: Module APM30H

page 26 Projet de fin d’études

Chapitre 3. Equipement radio de la Tunisie Telecom 3.3 Equipements auxiliaires

3.3.3 Module TMC11H

Pour étendre les capacités de transmission d’une station DBS3900, il est possible
d’utiliser un dispositif TMC11H. Ce dispositif offre un espace pour l’installation de
plusieurs unités BBU comme le montre la figure suivante :

Figure 3.9: Module TMC11H

3.3.4 Module IBBS200

Les dispositifs IBBS200 sont des dispositifs dont le rôle principal est de fournir
une source d’alimentation de secours, lorsque la source principale est indisponible
pour une longue période. La figure suivante montre l’intérieur d’une unité IBBS200
et la manière dont les batteries sources d’alimentation y sont installées :

Figure 3.10: Module IBBS

3.3.5 Modules IMB et OMB

Tout comme les APM30h, les modules IMB et OMB sont des équipements pour
installer et mettre en service des BBU. L’utilité de ces modules réside dans le fait
qu’ils permettent une installation sans demander un grand espace. Le module IMB
est destiné à une installation à l’intérieur des bâtiments, tandis que le OMB est

Projet de fin d’études page 27

3.3 Equipements auxiliaires Chapitre 3. Equipement radio de la Tunisie Telecom

conçu pour installation externe. la figure suivante montre l’apparence des deux mo-
dules :

(a) Unité IMB (b) Unité OMB

Figure 3.11: Modules IMB et OMB

3.3.6 Exemples de déploiement

L’architecture modulaire et les dispositifs auxiliaires, permettent un déploiement

facile et flexible des stations DBS3900 tout en respectant les exigences en matière
de protection de l’environnement, et malgré la difficulté d’acquisition de nouveaux
sites. Pour une installation dans les zones urbaines, il est possible d’installer une
DBS3900 avec un module IMB, OMB ou BTS, si un espace dédié est disponible. La
figure suivante montre des différents scénarios de déploiement des stations DBS3900
aussi bien à l’intérieur qu’à l’extérieur des zones urbaines :

Figure 3.12: Déploiement interne et externe dans une zone urbaine

page 28 Projet de fin d’études

Chapitre 3. Equipement radio de la Tunisie Telecom 3.4 Conclusion

Figure 3.13: Déploiement long des autoroutes et des voies ferrées

3.4 Conclusion
Ce chapitre a été consacré à la description de l’équipement radio installé par la
Tunisie Telecom. L’identification des entités du système, ainsi que leurs spécificités,
va faciliter la conception de l’outil, qui aura pour rôle de surveiller le réseau LTE,
en permettant un suivi des tous les dérangements qui surviennent au niveau des
stations. Dans le prochain chapitre, ces informations seront utilisées afin de donner
un modèle conceptuel de l’outil.

Projet de fin d’études page 29

3.4 Conclusion Chapitre 3. Equipement radio de la Tunisie Telecom

page 30 Projet de fin d’études

Chapitre 4
Conception de l’outil

4.1 Introduction
La conception joue un rôle crucial dans le développement logiciel. Il s’agit de
donner un modèle abstrait qui décrit la structure et le comportement du système à
développer avec un langage simple et clair. Le langage pour produire ce modèle est
le Unified Modeling Language (UML). Outre sa popularité et sa simplicité, ce lan-
gage a l’avantage d’être assez complet pour décrire tout système logiciel. Il permet
de représenter graphiquement un aspect d’un système tel que la structure interne
ou la chronologie de déroulement de l’interaction entre un utilisateur et une com-
posante internet du système telle qu’une base de données. Pour chaque aspect d’un
système logiciel, il existe un diagramme avec une notation bien précise. Ce chapitre
est consacré à la modélisation de l’outil avec le langage UML et est organisé comme
suit :
• Capture des besoins fonctionnels et non fonctionnels
• Identification des acteurs
• Description des fonctionnalités et de la structure internet du système
• Description de la dynamique ainsi que le déroulement des processus du système

4.2 Spécification des besoins

L’identification des besoins de l’application cible est la première étape du pro-
cessus de conception. Il existe deux catégories de besoins, à savoir, les besoins fonc-

31
4.2 Spécification des besoins Chapitre 4. Conception de l’outil

tionnels et non-fonctionnels.

4.2.1 Besoins fonctionnels

Les besoins fonctionnels sont les fonctionnalités de l’application. Ce sont des
besoins spécifiant un comportement d’entrée / sortie du système :
• Réaliser des rapports
• Consulter des rapports
• Consulter les historiques
• Faire des statistiques
• Générer des alertes

4.2.2 Besoins non fonctionnels

Les besoin non fonctionnels décrivent des propriétés de l’application. Ce sont des
besoins en matière de performance, d’ergonomie ou de prise en main du système.
Ces besoins peuvent aussi impliquer des contraintes lors de la réalisation telles que
le choix du langage de programmation, et les outils à utiliser ainsi que la plateforme
cible sur laquelle le système devra fonctionner.

Performance L’outil à développer doit s’exécuter d’une façon rapide et sans char-
gements, et ce grâce à un traitement rapide des tâches à implémenter ainsi qu’un
temps de réponse minimal lors d’accès à des sources d’informations externes comme
les bases de données et les fichiers.

Evolutivité L’architecture de l’outil à développer doit pouvoir laisser la possibilité

d’ajouter de nouvelles fonctionnalités ainsi qu’une mise à jour des fonctionnalités
déjà implémentées

Ergonomie L’outil à développer doit être facile à utiliser et à prendre en main.

Portabilité L’outil doit être accessible indépendamment du système d’exploita-

tion utilisé. Après avoir identifié les besoins et les acteurs, la description de l’outil
avec UML sera traitée dans cette section.

page 32 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.3 Diagrammes de cas d’utilisations

Cette section est organisée comme suit :

• Description des fonctionnalités de l’outil du point de vue des acteurs avec les
cas d’utilisation
• Description des composantes du système avec le diagramme de classes
• Description des déroulement des cas d’utilisations avec le diagramme d’activi-
tés
• Description de la chronologie des processus du système avec le diagramme de
séquences

4.3 Diagrammes de cas d’utilisations

La capture des besoins fonctionnels permet de définir les fonctionnalités du sys-
tème à implémenter. La représentation de ces fonctionnalités est réalisée avec le
diagramme de cas d’utilisation. Ce diagramme décrit ce que l’utilisateur peut faire
avec l’outil, pour réaliser son objectif. Dans ce diagramme, le ou les utilisateurs du
système sont les acteurs, et les fonctionnalités du système sont des cas d’utilisations.

4.3.1 Acteurs
Les acteurs à qui l’outil est destiné sont des employés chargés de la maintenance
et du suivi des équipements du réseau LTE. Il existe deux classes d’employés
• Administrateur est une classe d’utilisateurs qui ont accès aux fonctionnali-
tés de base de l’outil à développer, mais peuvent aussi accomplir des tâches
sensibles telles que la gestion des données d’utilisateurs et des équipements.
• Utilisateur la classe utilisateur représente tous employés concernés par la
tâche de maintenance et de suivi de l’équipement radio LTE.
Dans ce qui suit, les différents cas d’utilisations vont être analysés.

Projet de fin d’études page 33

4.3 Diagrammes de cas d’utilisations Chapitre 4. Conception de l’outil

4.3.2 Cas d’utilisation global

La figure suivante montre le diagramme ainsi que tous les acteurs avec toutes les
fonctionnalités du système à développer.

Figure 4.1: Diagramme de cas d’utilisation global

le tableau suivant contient la description des cas d’utilisations illustrés dans le

diagramme ci-dessus :

page 34 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.3 Diagrammes de cas d’utilisations

Cas d’utilisation Acteur Description

L’administrateur ajoute, modifie ou
Gérer les utilisateurs Administrateur supprime les données
relatives à un utilisateur.
L’administrateur ajoute, modifie ou
Gérer les zones Administrateur supprime les données relatives
à une zone servie par une eNodeB
L’administrateur ajoute, modifie
Gérer les stations Administrateur ou supprime les données relatives
à une une eNodeB.
L’administrateur ajoute, modifie
Gérer les modules Administrateur ou supprime les données relatives
à un module installé dans une eNodeB.
L’administrateur utilise ses
Administrateur
s’authentifier données pour accéder aux
et Utilisateur
fonctionnalités du système.
Les acteurs peuvent accéder à
Consulter Administrateur
la liste des dérangements survenus
dérangement et Utilisateur
durant une période donnée.
Les acteurs décrivent une
Administrateur
Insérer un rapport intervention effectuée sur une
et Utilisateur
source dérangement.
Consulter Administrateur les acteurs peuvent accéder
les rapports et Utilisateur à une liste des rapports insérés.
Les acteurs peuvent visualiser
Visualiser Administrateur
des données statistiques relatives
des statistiques et Utilisateur
aux dérangements des équipements.
Les acteurs peuvent consulter
Consulter Administrateur
les données relatives aux
l’historique et Utilisateur
opérations de maintenance réalisées.

Table 4.1: Description textuelle des cas d’utilisations

Projet de fin d’études page 35

4.3 Diagrammes de cas d’utilisations Chapitre 4. Conception de l’outil

4.3.3 Cas d’utilisation "s’authentifier"

La figure suivante donne une représentation plus détaillée du cas d’utilisation

"s’authentifier" :

Figure 4.2: Diagramme de cas d’utilisation "s’authentifier"

Le tableau suivant donne une analyse du cas d’utilisation illustré ci-dessus :

Titre s’authentifier

But Obtenir le droit d’accès au contenu de l’outil

L’acteur saisit son login et son mot de passe sur
Résumé
l’interface graphique de l’outil.
Acteur principal Administrateur, Utilisateur

Pré-condition L’acteur authentifié accède aux fonctions de l’outil.

L’acteur demande la page de Login.
Le système affiche la page demandée.
Scénario de base L’acteur entre les données requises.
Une vérification des données a lieu. Si l’acteur est authentifié, la
page est affichée.
Post-condition Authentification réussie, affichage de la page principale
Echec de l’authentification
Scénario alternatif
affichage d’un message d’erreur

Table 4.2: Analyse du cas d’utilisation "s’authentifier"

page 36 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.3 Diagrammes de cas d’utilisations

4.3.4 Tâches de l’administrateur

L’administrateur effectue les même opérations sur les utilisateurs, zones, eNobeB
et modules. Pour analyser le cas d’utilisation de l’administrateur, le terme ressource
sera employé pour désigner un utilisateur, une zone, une eNodeB ou un module.
Dans cette partie, les tâches que l’acteur Administrateur peut effecteur, vont être
analysées : :

Figure 4.3: Diagramme de cas d’utilisation "Tâches de l’administrateur"

Le tableau suivant décrit le cas d’utilisation de l’administrateur :

Projet de fin d’études page 37

4.3 Diagrammes de cas d’utilisations Chapitre 4. Conception de l’outil

Titre Tâches de l’administrateur

But Ajout, modification ou suppression d’une ressource

L’administrateur demande l’interface dédiée à l’ajout,
Résumé
la modification ou la suppression de la ressource.
Acteur principal Administrateur
L’administrateur doit être authentifié
Pré-condition
pour pouvoir effectuer ces tâches.
L’administrateur appelle l’interface de gestion des ressources.
Le système affiche la page demandée.
Scénario de base L’administrateur peut consulter, modifier ou supprimer une
ressource existante, ou bien peut en ajouter une nouvelle.

Post-condition L’ajout, la modification ou la suppression est réussie.

Echec de l’authentification
Scénario alternatif Echec de de l’ajout d’une ressource qui existe déjà
affichage d’un message d’erreur

Table 4.3: Analyse du cas d’utilisation de l’administrateur

4.3.5 Tâches de l’employé

Le diagramme suivant contient les fonctionnalités accessibles à tous les employés :

Figure 4.4: Diagramme de cas d’utilisation "Utilisation de l’outil"

L’analyse des cas d’utilisations est donnée par le tableau suivante :

page 38 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.3 Diagrammes de cas d’utilisations

Titre Tâches des Utilisateur

But Insertion de rapports et consultations

Les employés authentifiés accèdent à l’interface principale qui
Résumé contient les
liens vers les données à consulter ou insérer des rapports.
Acteur principal Administrateur et utilisateurs
L’employé doit être authentifié
Pré-condition
pour pouvoir effectuer ces tâches.
L’employé donne son login et mot de passe.
Après l’authentification, le système affiche la page demandée.
Scénario de base A partir de cette page, l’employé peut consulter des historiques
rapports, ou en insérer.

Post-condition La consultation ou l’insertion de rapports est réussie.

Echec de l’authentification
Scénario alternatif Echec des tâches de consultations
affichage d’un message d’erreur

Table 4.4: Analyse du cas d’utilisation des employés

Projet de fin d’études page 39

4.4 Diagramme de classes Chapitre 4. Conception de l’outil

4.4 Diagramme de classes

Le diagramme de classes donne une vue sur la structure interne de l’outil à déve-
lopper, ce qui permet d’illustrer la façon avec laquelle, les composantes du système
à développer interagissent ensemble. Chaque composante du système est représen-
tée par un entité abstraite appelée classe qui possède des propritétés ainsi qu’un
comportement bien défini, et qui entretient une relation avec d’autres classes du
système[1]. Le diagramme de classes qui sert à modéliser l’outil est montré dans la
figure suivante :

Figure 4.5: Diagramme de classes

page 40 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.5 Diagramme d’activité

Le tableau suivant décrit le rôle de chaque classe :

Classe Description
Classe générale représentant
Employé
les utilisateurs de l’outil
Classe spéciale d’employé qui peut
Administrateur effectuer des tâches de gestion
en plus de l’utilisation de l’outil
Classe spéciale d’employé destiné
Utilisateur
à utiliser l’outil
Classe dont le rôle est la représentation
e-UTRAN
d’un e-UTRAN
Classe qui représente
Zone la zone d’emplacement
des eNodeB
Classe qui représente les entités
eNodeB
qui seront surveillées par l’outil
Classe qui représente la source
Module
des dérangements d’une eNodeB
Classe qui représente l’action interven-
Intervention tion
exécutée par un employé
Classe spéciale qui représente l’action
Intervention sur Module/eNodeB intervention
sur un module/eNodeB
Classe qui représente une
Alerte
alerte générée par une eNodeB

Table 4.5: Description des classes

4.5 Diagramme d’activité

Avec le diagramme de cas d’utilisation, il est possible d’exprimer les besoins
des utilisateurs de l’outil, en fonctionnalités. Chaque fonctionnalité est représentée
avec un cas d’utilisation. Le diagramme d’activité décrit le déroulement au sein de

Projet de fin d’études page 41

4.5 Diagramme d’activité Chapitre 4. Conception de l’outil

chaque cas d’utilisation, ce qui facilite la description du comportement de l’outil à

développer[1].

Figure 4.6: Diagramme d’activités

page 42 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.6 Diagramme de séquences

4.6 Diagramme de séquences

Dans la section précédente, le déroulement de l’interaction de l’acteur avec le sys-
tème a été représentée avec le diagramme d’activités. Dans cette section, les mêmes
interactions seront représentées en respectant leurs successions chronologiques. Le
diagramme qui permet une telle représentation est le diagramme de séquences. Dans
ce qui suit, les tâches à modéliser sont :
• L’authentification
• La création d’un compte utilisateur
• La gestion de zones, de stations, ou de modules
• La consultation de données d’historiques ou statistiques
• L’insertion de rapports

4.6.1 Authentification
Le diagramme suivant montre le déroulement chronologique de l’authentifica-
tion :

Figure 4.7: Diagramme de séquences s’authentifier

Projet de fin d’études page 43

4.6 Diagramme de séquences Chapitre 4. Conception de l’outil

4.6.2 Création d’un compte d’utilisateur

Le diagramme suivant décrit le déroulement de l’ajout d’un utilisateur au sys-
tème :

Figure 4.8: Diagramme de séquence s’enregistrer

page 44 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.6 Diagramme de séquences

4.6.3 Gestion des éléments du réseau LTE

Le diagramme suivant illustre le déroulement de l’ajout, modification et de la
suppression d’une zone, d’une station eNodeB ou d’un module. Etant donné qu’elles
ont la même chronologie, ces tâches seront représentées par le même diagramme :

Figure 4.9: Diagramme de séquences gérer réseaux

Projet de fin d’études page 45

4.6 Diagramme de séquences Chapitre 4. Conception de l’outil

4.6.4 Consultation de données

Les tâches "consultation de rapports et consultations d’historique" peuvent être
illustrées à l’aide du diagramme suivant :

Figure 4.10: Diagramme de séquence consulter données

page 46 Projet de fin d’études

Chapitre 4. Conception de l’outil 4.7 Conclusion

4.6.5 Insertion de rapports

Lorsqu’une alerte est détectée, l’employé chargé de résoudre le problème doit
impérativement enregistrer les données de l’intervention. Le déroulement de cette
tâche est décrit dans le diagramme suivant :

Figure 4.11: Diagramme d’activités

4.7 Conclusion
Ce chapitre a servi à donner une étude de l’application, grâce au UML. Avec
UML il a été possible de donner deux modèles statiques, que sont le diagramme de
cas d’utilisation et le diagramme de classes, et deux modèles dynamiques que sont
les diagrammes d’activités et de séquences. En se basant sur les modèles présentés
dans ce chapitre, la réalisation sera traitée dans le prochain chapitre.

Projet de fin d’études page 47

4.7 Conclusion Chapitre 4. Conception de l’outil

page 48 Projet de fin d’études

Chapitre 5
Réalisation du projet

5.1 Introduction
Le chapitre précédent a été consacré à la conception de l’application. Dans ce
chapitre le modèle conceptuel sera implémenté à l’aide d’un environnement de déve-
loppement. Avant de procéder à la programmation, il est essentiel de bien choisir les
outils de l’environnement de travail y compris le langage de programmation afin de
garantir les meilleures performances de l’application. Ce chapitre contient les deux
parties suivantes :
• Présentation de l’environnement de travail
• Présentation de l’application
• Présentation des fonctionnalités de l’application

5.2 Environnement de travail

Dans cette section, l’environnement de travail ayant servi à développer l’appli-
cation sera présenté. L’environnement de travail se compose d’un environnement
matériel et d’un ensemble d’outils logiciels.

5.2.1 Environnement matériel

La réalisation du projet a été faite avec un PC portable du fabriquant Dell Inc.
modèle INSPIRON 3521 qui possède les configuration suivante :

49
5.2 Environnement de travail Chapitre 5. Réalisation du projet

2 Processeurs Intel(R) Pentium(R) CPU 977 @ 1.60GHz

Mémoire Installée (RAM) 4096 MB
Taille du disque dur 300 Go
Carte graphique Intel(R) HD Graphics
Système d’exploitation Windows 7 64 Bits

Table 5.1: Configuration de l’environnement matériel de travail

5.2.2 Environnement logiciel

Le développement de l’application a été réalisée avec les logiciels suivant :

Plateforme Java EE La plateforme Java Entreprise Edition est un ensemble de

bibliothèques conçus pour le développement d’application d’entreprises, qui étendent
les capacités de la bibliothèque standard de Java. Les concepts d’entreprise que cette
extension apporte sont :
• Mapping Objet-Relationnel : Concept utilisé pour palier à l’incompatibilité des
types de données entre bases de données relationnelles et programmes orientés
objet.
• Support des architectures distribuées : Dans un environnement entreprise, les
ressources ne sont pas localisées au même endroit. Java EE permet le dévelop-
pement en prenant compte de cette distribution.
Le choix du langage langage Java a été fait en prenant compte des facteurs
suivants :
• Facilité : Java est dépourvu des concepts abstraits et virtuels tels les poin-
teurs dans les langages C et C++ ou la gestion dynamique de la mémoire. La
machine virtuelle gère les tâches de bas niveau.
• Portabilité : une application Java fonctionne sur différents systèmes sans prendre
en compte l’architecture matérielle
• Robustesse des programmes : Java permet de créer des programmes très stables
en utilisant des mécanismes des "Exceptions" ou encore les généricité qui per-
mettent un meilleur traitement des erreurs.
• Gratuité : La plateforme est disponible sans coûts

page 50 Projet de fin d’études

Chapitre 5. Réalisation du projet 5.3 Présentation de l’application

• Langage orienté objet : Le paradigme orienté objet permet de créer un pro-

gramme avec un code très organisé ce qui en facilite la maintenance, la mise à
jour et l’extension.
• Disponibilité d’outils : Pour enrichir l’environnement de base qui offre des
outils pour les besoins communs, il existe plusieurs projets et outils destinés à
améliorer le travail avec Java.

Eclipse Entreprise Edition Eclipse Entreprise Edition est un environnement

de développement intégré (IDE) pour la plateforme Java EE. Ce IDE est issu du
projet Eclipse qui regroupe plusieurs versions du IDE de base Eclipse Standard
Edition. La disponibilité de ces versions est rendue possible grâce a la capacité
d’extension d’Eclipe avec Plug-ins. Eclipse EE fournit tous les outils de base pour
le développement comme l’éditeur de programmation, le compilateur, l’interpréteur,
le deboggage, et l’organisation des projets en plusieurs répertoires.

Serveur Apache Tomcat Le serveur Apache Tomcat est un Conteneur de JSP

et de Servlet, c’est à dire que c’est un environnement virtuel dans lesquels les JSP
et les Servlet sont exécutées. Ce serveur représente le Tier Web et contient la partie
métier de l’application.

MYSQL Pour une application Web ou entreprise, il est essentiel de stocker et gérer
les données. Pour cette tâche, le logiciel MYSQL est utilisé. MYSQL est un système
de bases de données qui offre la possibilité de stocker et gérer des informations grâce
au langage SQL.

5.3 Présentation de l’application

5.3.1 Modèle Client/Serveur

Dans le cadre du projet, une application Web est à développer. Une application
Web est une application accessible avec un navigateur Web à travers un réseau
informatique comme l’Internet, ou l’Intranet. L’avantage principal de ce choix est
que l’application est accessible aussi par un poste de travail qu’un appareil mobile.
Le modèle sur lequel une telle application se base est le modèle Client/Serveur. La

Projet de fin d’études page 51

5.3 Présentation de l’application Chapitre 5. Réalisation du projet

partie client désigne le navigateur Web de l’utilisateur qui demande des données ou
des tâches ou calculs à effectuer au serveur, qui est en général un logiciel installé sur
un ordinateur local ou distant. La figure 1 suivante donne une image simplifiée du
modèle client / serveur :

Figure 5.1: Modèle Client/Serveur simplifié

Les éléments de cette figure seront discutées dans ce qui suit.

5.3.2 Modèle MVC

Le développement d’une application de grande envergure nécessite l’application
de méthodes spéciales afin d’en faciliter la gestion et la maintenance. La méthode
appliquée ici est un patron de conception (eng. Design pattern) appelée le modèle
Model-View-Contoller (MVC) qui consiste à diviser le code source de l’application
en trois couches distinctes. La principale caractéristique de ce modèle est qu’une
technique appliquée dans une couche ne peut être appliquée dans une autre couche.
Le résultat est un code très bien organisé et facile à gérer et à maintenir. Pour
ce projet, Java Entreprise Edition (EE) a été choisi. Avec Java EE il est facile de
travailler selon le modèle MVC et de répartir l’application sur trois couches appelées
tiers :
1. http ://t-boutefara-ens.blogspot.com/2016/03/architecture-clientserveur-un-petit-mot.html

page 52 Projet de fin d’études

Chapitre 5. Réalisation du projet 5.3 Présentation de l’application

• Tier de présentation : ou Tier client qui représente la Vue ou View du modèle

MVC et qui contient la partie accessible par l’utilisateur de l’application, qui
le navigateur web,

• Tier Web : contient la partie métier, représente le contrôleur du modèle MVC

et traite les demandes et requêtes des clients et au besoin, passe la demande
au troisième Tier

• Tier de données : représente la partie Model du modèle MVC et contient le

système de gestion de données (SGDB).

La figure 2 suivante illustre la répartition des couches dans la plateforme Java EE :

Figure 5.2: Architecture d’une application Java EE

Pour chaque Tier, il existe plusieurs technologies pour le développement des

applications Web. Les technologies utilisées dans ce projet sont listées dans le tableau
suivant :

2. source http ://docs.oracle.com/javaee/5/tutorial/doc/bnaay.html

Projet de fin d’études page 53

5.4 Interfaces de l’application Chapitre 5. Réalisation du projet

Tier Client HTML, CSS3, Javascript

Tier Web JSP, Servlets,Beans
Tier Données SGBD MySQL

Table 5.2: Technologies disponibles pour chaque Tier

5.4 Interfaces de l’application

Dans cette section, les différentes interfaces de l’application seront présentées.

5.4.1 Interface d’authentification

L’interface présentée ici est l’interface de connexion au système. Pour l’authenti-
fication, un employé de maintenance doit entrer un login et un mot de passe corrects
dans les champs respectifs et cliquer sur le bouton login.

Figure 5.3: Formulaire d’authentification

5.4.2 Interface d’enregistrement

Ce formulaire illustré ci-dessous est celui d’enregistrement d’utilisateurs au sys-
tème. Avant de pouvoir utiliser l’outil, un employé doit entrer les informations de-
mandées par le formulaire puis valider l’enregistrement.

Figure 5.4: Formulaire d’enregistrement

page 54 Projet de fin d’études

Chapitre 5. Réalisation du projet 5.4 Interfaces de l’application

5.4.3 Interface des historiques

Après une authentification réussie, l’utilisateur peut consulter la liste des inter-
ventions menées qui sont affichées dans le tableau suivant. Pour actualiser la liste
qui peut être modifiée à tout moment, l’utilisateur clique sur le bouton report :

Figure 5.5: Menu des historiques

5.4.4 Interface des alertes

Sur la même interface, un utilisateur authentifié peut consulter la liste des er-
reurs après avoir reçu une notification par courrier électronique du système. Pour
actualiser la liste il suffit de faire un clic sur le bouton alert :

Figure 5.6: Menu des alertes

5.4.5 Interface des rapports

Après avoir été informé par courrier électronique des problèmes au niveau de
l’équipement radio, un employé de maintenance se déplace sur place pour faire son
intervention. Une fois cette tâche accomplie, l’employé envoie un rapport au système
avec les données nécessaires grâce a au formulaire de la figure suivante :

Projet de fin d’études page 55

5.5 Conclusion Chapitre 5. Réalisation du projet

Figure 5.7: Formulaire des rapports d’interventions

5.4.6 Outil de signalisation d’erreur

Pour tester le fonctionnement de l’outil, un petit programme en Java avec inter-
face graphique a été écrit pour imiter le comportement des alertes. Le programme
dont l’interface est montrée dans la figure suivante génère une alerte qui sera cap-
turée par le système.

Figure 5.8: Programme d’alertes

5.5 Conclusion
Ce chapitre a été consacré à la dernière étape du développement de l’outil qu’est
la réalisation. Avant de décrire l’application finale, l’environnement matériel et lo-
giciel ainsi que les technologies utilisées ont été présentés. Ensuite l’architecture du
code de l’application a été traitée afin d’en comprendre la structure afin de justifier le
choix des outils de développement. Pour donner un visuel du résultat final, plusieurs
captures d’écran ont été utilisées pour montrer les fonctionnalités de l’outil.

page 56 Projet de fin d’études

Conclusion générale

Pour un opérateur comme la Tunisie Telecom, il est essentiel d’avoir un système

d’informations efficace qui permet de suivre l’état de fonctionnement de ses équipe-
ments radio. Le rôle d’un tel système peut être déterminant pour la compétitivité, et
son absence peut avoir des répercussions sur sa qualité de services et par conséquent,
sur le plan économique de la société.

Dans le cadre de ce projet, le travail a consisté à développer un outil de suivi

des dérangements qui surviennent au niveau des équipements radio 4G. Avant la
phase de réalisation, une étude bibliographique sur les spécificités techniques, ainsi
que de l’architecture des réseaux 4G a été menée. Pour compléter cette étude, les
équipements radio de la Tunisie Telecom ont été aussi présentés. Après avoir mené
cette étude bibliographique, il a été possible d’entamer la phase de conception. Le
but principal de la conception a été de donner un modèle conceptuel de l’applica-
tion afin d’en décrire la structure et le comportement et ceci, à l’aide d’un langage
appelé UML. L’avantage du langage UML est le nombre de diagrammes qu’il offre
pour tous les aspects d’un système logiciel. Première étape de la conception a été
de capturer les besoins fonctionnels et non fonctionnels ainsi que les acteurs, à qui
le futur système est destiné avec le diagramme de cas d’utilisations. Ensuite, pour
décrire la structurer interne de la solution, un diagramme de classes avec les entités
impliquées au système a été présenté. Enfin, pour illustrer la dynamique du système,
un diagrammes d’activités et des diagramme de séquences ont été données.

La réalisation et l’implémentation de la solution a été réalisée avec la plateforme

Java EE. Les outils nécessaires pour créer des applications Java EE qui ont été utili-

57
 Conclusion

sés sont : l’environnement de développement intégré Eclipse, le serveur Web Tomcat

et le SGBD MYSQL. Comme il a été illustré par les figures, l’application permet
de capturer et consulter les dérangements, ainsi que l’historique des interventions
menés par les employés chargées de la maintenance.

En perspective, le système développé offre la possibilité d’ajouter d’améliora-

tions, surtout au niveau de l’intégration d’autres fonctionnalités et mécanismes de
sécurité.

page 58 Projet de fin d’études

Bibliographie

[1] Laurent Audibert. UML2, de l’apprentissage à la pratique. Ellipse, 2009.

[2] Imen BEN CHAABANE. 4G LTE. Rapp. tech. Agence nationale des fré-
quences, 2012.
[3] Salma Saidane Hanen Hrizi. Dimensionnement des réseaux Radio 3G et 4G.
Rapp. tech. Institut supérieur des études technologiques en communications
de Tunis, 2013.
[4] Huawei. DBS3900 product description. Rapp. tech. Huawei technologies co.,
LTD, 2011.
[5] Huawei. eLTE3.1 DBS3900 LTE FDD product description. Rapp. tech. Hua-
wei technologies co., LTD, 2013.
[6] Huawei. eWBB TDD 3.0 DBS3900 Product Description. Rapp. tech. Huawei
technologies co., LTD, 2012.
[7] Rumbaugh Jacobson Booch. The Unified Software development process. Addison-
Wesley Professional, 1999.
[8] Ali Lassoued. Outil de planification et de dimensionnement dans l’E-UTRAN
LTE-Advanced. Rapp. tech. Ecole supérieure des communications de Tunis,
2012.
[9] Frank Vallée Pascal Roques. Uml en action, de l’analyse des besoins à la
conception en java. Eyrolles, 2003.
[10] Frank Rayal. LTE in a nutshell : Physical Layer. Rapp. tech. Telesystems
Innovations, jan. 2013.

59
[11] Frank Rayal. LTE in a nutshell : Protocol Architecture. Rapp. tech. Telesys-
tems Innovations, jan. 2013.
[12] Frank Rayal. LTE in a nutshell : System overview. Rapp. tech. Telesystems
Innovations, jan. 2013.
[13] Geovanny Mauricio ITURRALDE RUIZ. Performances des réseaux LTE. Rapp.
tech. Université de Toulouse, 2012.
[14] Banque d’affaires de Tunisie. « Présentation résumée de la Tunisie Telecom ».
In : Document de référence de la Tunisie Telecom (2010), p. 3–10.
[15] François-Xavier Wolff Yannick Bouguen Eric Hardouin. LTE et les réseaux
4G. Groupe Eyrolles, 2012, p. 60–98.

page 60