pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

TABLE DES MATIÈRES
Liste des figures .................................................................................................................................................................... i
Liste des tableaux.................................................................................................................................................................ii
Introduction Générale .......................................................................................................................................................... 1
Chapitre 1 Présentation du cadre de travail et du sujet....................................................................................................... 2
Introduction.......................................................................................................................................................................... 3
1 Cadre du projet........................................................................................................................................................... 3
1.1 Présentation de l’entreprise............................................................................................................................... 3
1.2 Rôle de la Division Supervision ....................................................................................................................... 4
1.3 Le concept « Incident »..................................................................................................................................... 5
2 Présentation de sujet :................................................................................................................................................. 6
3 Conduite du projet...................................................................................................................................................... 6
3.1 Processus de développement............................................................................................................................. 6
3.2 Méthodologie Agile.......................................................................................................................................... 7
3.3 Scrum................................................................................................................................................................ 8
Conclusion ......................................................................................................................................................................... 13
Chapitre 2 Etat de l'Art des Réseaux Cellulaires............................................................................................................... 14
Introduction........................................................................................................................................................................ 15
1 Concept Cellulaire.................................................................................................................................................... 15
2 Evolution des réseaux cellulaires.............................................................................................................................. 16
2.1 Norme GSM ................................................................................................................................................... 16
2.2 Le standard GPRS........................................................................................................................................... 19
2.3 Téléphonie à mode paquet à haut débit : UMTS............................................................................................. 21
2.4 HSPDA........................................................................................................................................................... 23
2.5 HSUPA........................................................................................................................................................... 23
3 Concept de la qualité de service ............................................................................................................................... 23
3.1 Définition........................................................................................................................................................ 23
3.2 Critères de performances des réseaux 2G/3G ................................................................................................. 23
Conclusion ......................................................................................................................................................................... 25
Chapitre 3 Analyse des Besoins et Spécifications .............................................................................................................. 26
Introduction........................................................................................................................................................................ 27
1 Objectifs ................................................................................................................................................................... 27
2 Spécification des exigences...................................................................................................................................... 27
2.1 Les acteurs système ........................................................................................................................................ 27
2.2 Le Backlog du produit :.................................................................................................................................. 28
2.3 Diagramme des cas d’utilisation globale : ...................................................................................................... 29
2.4 Sprint .............................................................................................................................................................. 29
2.5 Besoins Non Fonctionnels .............................................................................................................................. 39
Conclusion ......................................................................................................................................................................... 39
Chapitre 4 Conception....................................................................................................................................................... 40

Introduction........................................................................................................................................................................ 41
3 Architecture du système : Modèle multi couches ..................................................................................................... 41
4 Conception ............................................................................................................................................................... 42
4.1 Conception détaillé......................................................................................................................................... 42
4.2 Sprint 1 ........................................................................................................................................................... 42
4.3 Sprint 2 ........................................................................................................................................................... 44
4.4 Sprint 3 ........................................................................................................................................................... 46
4.5 Sprint 4 ........................................................................................................................................................... 49
4.6 Diagramme de classes..................................................................................................................................... 50
Conclusion ......................................................................................................................................................................... 51
Chapitre 5 Réalisation ....................................................................................................................................................... 52
Introduction........................................................................................................................................................................ 53
1 Environnement de travail ......................................................................................................................................... 53
1.1 Environnement matériel.................................................................................................................................. 53
1.2 Environnement logiciel................................................................................................................................... 53
2 Choix techniques...................................................................................................................................................... 53
2.1 Choix du standard de développement ............................................................................................................. 53
2.2 Choix du Framework pour la couche de présentation..................................................................................... 54
2.3 EJB3.1 ............................................................................................................................................................ 55
2.4 Choix du conteneur de la couche de persistance de données .......................................................................... 56
2.5 Choix du SGBD MySQL................................................................................................................................ 57
2.6 Choix du serveur d’application JBOSS AS 7.1 : ............................................................................................ 57
3 Phase d’implémentation ........................................................................................................................................... 57
3.1 Géolocalisation site 2G................................................................................................................................... 58
3.2 Géolocalisation site 3G................................................................................................................................... 58
3.3 Géolocalisation des Site HS............................................................................................................................ 60
3.4 Affichage des sites en voisinage d’un site HS ............................................................................................... 61
3.5 Test ................................................................................................................................................................. 62
4 Chronogramme de réalisation................................................................................................................................... 62
Conclusion ......................................................................................................................................................................... 62
Conclusion et Perspective ................................................................................................................................................. 63
Bibliographie...................................................................................................................................................................... 64
Acronymes......................................................................................................................................................................... 65
Annexe A : JBOSS AS 7.................................................................................................................................................... 67
Annexe B : La technologie AJAX...................................................................................................................................... 69

i
Liste des figures
Figure 1 : Organisation de la division Supervision au sein de TUNISIANA .................................................... 4
Figure 2:Types d’incidents BTS........................................................................................................................ 6
Figure 3: Méthodologie Agile ........................................................................................................................... 8
Figure 4:Sprint Scrum ....................................................................................................................................... 9
Figure 5 : Processus Scrum ............................................................................................................................. 13
Figure 6 Concept cellulaire ............................................................................................................................. 15
Figure 7 Le Sous-système Radio..................................................................................................................... 16
Figure 8:Le Sous-système d'Acheminement ................................................................................................... 17
Figure 9 : Le Sous-système d'Exploitation et de Maintenance........................................................................ 18
Figure 10 : Architecture du Réseau GPRS ...................................................................................................... 20
Figure 11 : Architecture de l'UMTS................................................................................................................ 21
Figure 12 : UTRAN......................................................................................................................................... 22
Figure 13: diagramme cas d'utilisation globale ............................................................................................... 29
Figure 14 : Diagramme cas d'utilisation traitement des fichiers...................................................................... 31
Figure 15 : Cas d'utlisation de sprint 2 ............................................................................................................ 33
Figure 16 : Cas d'utilisation Déterminer les sites HS ...................................................................................... 35
Figure 17 Afficher Availibility 2G RAN......................................................................................................... 35
Figure 18 Gestion BTS.................................................................................................................................... 37
Figure 19 Cas d'utilisations Afficher cellules................................................................................................. 38
Figure 20 : Cas d'utilisations Gestion Utilisateur ............................................................................................ 38
Figure 21 modèle MVC................................................................................................................................... 41
Figure 22 : Diagramme séquence objet authentification ................................................................................. 43
Figure 23 : Diagramme de séquence de user story traitement des fichiersde données BTS........................... 43
Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS ................................................ 44
Figure 25 : Diagramme séquence objet Map 2G............................................................................................. 45
Figure 26: Diagramme d'activité « Géolocalisation des sites BTS »............................................................... 46
Figure 27 : Diagramme séquence géolocalisation des incidents ..................................................................... 47
Figure 28 : diagramme de séquence « l’Availibility 2G »............................................................................... 48
Figure 29 : Diagramme d'activité « géolocalisation des incidents »................................................................ 49
Figure 30 : Diagramme de séquence « ajouter utilisateur »............................................................................. 49
Figure 31: Diagramme d'activité « ajouter utilisateurs »................................................................................ 50
Figure 32:Diagramme de classe ...................................................................................................................... 51
Figure 33 : JSF ................................................................................................................................................ 55
Figure 34 EJB3.1............................................................................................................................................. 55
Figure 35 : Architecture de la spécification JPA ............................................................................................. 57
Figure 36 : MAP 2G........................................................................................................................................ 58
Figure 37 : MAP 3G........................................................................................................................................ 58
Figure 38 Recherche par LAC......................................................................................................................... 59
Figure 39: courbe 2G RAN ............................................................................................................................. 59
Figure 40: géo localisation des incidents......................................................................................................... 60
Figure 41 : Exemple de fichiers incidents ....................................................................................................... 60
Figure 42 : voisinage d'un incident.................................................................................................................. 61
Figure 43 : Chronogramme de Réalisation...................................................................................................... 62

ii
Liste des tableaux
Tableau 1: Les seuils des KPIs........................................................................................................................ 25
Tableau 2 Tableau 1 Backlog du Produit ........................................................................................................ 28
Tableau 3: user story traitements des fichiers de données BTS....................................................................... 30
Tableau 4 : User Story Traitements des fichiers des incidents ........................................................................ 30
Tableau 5:user story Géo-localisation des sites BTS....................................................................................... 31
Tableau 6:User Story “rechercher site ” .......................................................................................................... 32
Tableau 7 : User Story “Afficher les voisinage ” ............................................................................................ 32
Tableau 8:User Story “geolocalisation des incident ” ..................................................................................... 34
Tableau 9:User Story “ KPI du réseau ”........................................................................................................ 34
Tableau 10: User Story “Availibilite 2G/3G RAN ” ..................................................................................... 34
Tableau 11: User Story gestion des cellules.................................................................................................... 36
Tableau 12: User Story gestion des Utilisateurs.............................................................................................. 36
Tableau 13: User Story gestion des BTS......................................................................................................... 37

1
Introduction Générale
Les réseaux mobiles ont connu un large succès avec l’apparition de la norme de deuxième
génération qui a permis essentiellement d’obtenir une meilleure qualité de voix. Afin de
permettre la création de nouveaux services et d’offrir aux usagers une véritable itinérance à
l’échelle mondiale, il était devenu nécessaire d’effectuer un saut technologique et de
franchir le pas vers les réseaux cellulaires de troisième et de quatrième génération.
Il s'avère donc que la qualité de service, dans ce domaine comme dans beaucoup d'autres,
constitue une source fondamentale de différenciation, aussi déterminante que le prix du
service fourni ou l'étendue de la couverture. Le maintien et le suivi de cette qualité
nécessitent le contrôle continu de l'état de fonctionnement du réseau et de toutes
les performances réalisées et par conséquent, l'intérêt d'outils d'ingénierie adaptés. L’un des
moyens de contrôle et de supervision qui s’offrent aux opérateurs téléphoniques est
l’utilisation d’outils ou applications qui rendraient facile la gestion des équipements
constituant leurs réseaux, entre autres les équipements BTS dont le contrôle ainsi la gestion
des incidents est le sujet de ce projet.
C’est dans cet ordre d’idées que s’inscrit ce projet de fin d'études qui a pour objectif
la conception et la réalisation d’un portail web pour l’évaluation des performances du
réseau de l’opérateur Tunisiana.
Le présent rapport se décompose en cinq chapitres, nous présentons le contenu de chaque
chapitre. Dans le premier chapitre, nous présentons l'environnement du travail ainsi que le
sujet à traiter. Le second chapitre est consacré à la présentation des architectures des
réseaux cellulaires tels que GSM, GPRS, et UMTS et les étapes de l'évolution de ces
réseaux. Nous traitons aussi dans ce chapitre le concept et les critères de la qualité de
service (QoS). Le troisième chapitre traite l’analyse des besoins et des spécifications de
l’application à développer. La conception globale et détaillée de l’outil que nous avons
réalisé fait l’objet du quatrième chapitre .Enfin, le dernier chapitre de ce rapport illustrera
les réalisations effectuées au cours de ce projet.

Chapitre 1 : Présentation du cadre de travail et du sujet
2
Chapitre 1
Présentation du cadre de travail et du
sujet

3
Introduction
Avant de traiter le sujet du présent projet de fin d’études, il convient de présenter
l’environnement dans lequel il a été mené à bien. En effet, c’est de l’environnement que
dépend, en grande partie, l’efficacité et la qualité d’un travail.
Nous avons effectué notre projet de fin d’études au sein de l’entreprise TUNISIANA
premier opérateur privé de télécommunications en Tunisie.
1 Cadre du projet
1.1 Présentation de l’entreprise
Orascom Telecom a octroyé, le 11 mai 2002, la deuxième licence de téléphonie mobile en
Tunisie (OTT) et devient ainsi le premier operateur GSM privé en Tunisie.
Cette licence a permis la mise en place d’un réseau de transmission GSM et d’une
passerelle internationale, d’une durée de quinze ans, renouvelable deux fois tous les cinq
ans et une exclusivité jusqu’au 30 juin 2004. Ainsi TUNISIANA a réalisé son lancement
commercial le 27 décembre 2002 pour atteindre jusqu’à aujourd’hui 100% de couverture
de la population Tunisienne.
Depuis son lancement, grâce à la qualité des ressources humaines et aux performances
techniques qui ne sont plus à démontrer et une qualité du réseau reconnue à l’échelle
nationale et internationale, Tunisiana a su arracher la première place sur le marché
Tunisien et devenir ainsi fin 2010 le leader National en GSM avec presque 52% de part de
marché.
Tunisisana a pour objectifs de :
 Satisfaire sa clientèle en assurant un bon niveau de service.
 Maximiser et maintenir les objectifs en termes de parts de marché sur la base d’un
programme à trois dimensions : Acquisition, Fidélisation, Consommation.
TUNISIANA est une entreprise en plein essor, l’hiérarchie interne est conçue pour faciliter
les promotions et garantir ainsi un maximum de motivation pour le personnel. La Division
Supervision dans laquelle nous avons effectué notre Projet est ainsi conçue comme suit :

4
Division Supervision
Service supervision front
Office Service supervision back
Office
Figure 1 : Organisation de la division Supervision au sein de TUNISIANA
1.2 Rôle de la Division Supervision
Le service supervision Back Office se charge de détecter les dysfonctionnements qui n’ont
pas un impact direct ou immédiat, majeur ou critique sur la qualité de service offerte au
client. Les tâches principales consistent à :
 faire des statistiques quotidiennes, hebdomadaires ou mensuelles sur les différents
équipements BSS
 identifier les quels est défectueux,
 alerter les concernés,
 suivre les problèmes récurrents impactant le client.
Comme son nom l’indique, le service Front Office a la charge :
 détecter immédiatement les incidents majeurs et critiques, les classifier par criticité.
 identifier l’impact.
 alerter les concernés, support niveau 1 et escalade en cas de besoin.
Les incidents traités sont ceux qui ont un impact direct sur la qualité de service offerte.

5
1.3 Le concept « Incident »
Apres sept ans et plus depuis son lancement commercial, TUNISIANA est devenue mature
en terme de prestataire de service de téléphonie mobile, la clientèle est devenu assez
grande et diversifiée, l’environnement est de plus en plus concurrentiel avec l’arrivée d’un
troisième opérateur sur le marché, en plus l’abonné est devenu de plus en plus exigeant.
Tous ces facteurs obligent Tunisiana à être compétitive, innovatrice et surtout très vigilante
concernant l’état de son réseau. Pour garder son image de marque, elle est appelée à
superviser tout son réseau en temps réel ainsi que tous ses services et promotions.
Donc, si on se réfère au service front Office, un incident est un événement qui peut
provoquer un dysfonctionnement ou qui a un impact immédiat sur le client pour pouvoir
gérer les incidents il est primordial d’implémenter tout un processus de détection,
d’investigation, d’alerte, de support niveau 1, et d’enregistrement dans une Base.
Dans ce qui suit on se penchera seulement sur les incidents qui touchent la partie BSS du
réseau GSM, c'est-à-dire les BTS et les BSC
Les types des incidents :
 Système : ce sont des incidents dus à un élément défectueux dans un équipement
réseau (carte électronique, capteur, câble…..)
 Transmission: Tous les équipements réseau sont connectés les uns par rapport aux
autres selon un routage bien spécifique, la mise Hors Service de l’une de ces routes
impacte directement un équipement, c’est pour cela que le réseau de transmission
est supervisé
 Environnement : un incident peut se déclencher par un facteur externe au réseau qui
peut être une coupure courant, un facteur climatique, un défaut de climatisation

6
Figure 2:Types d’incidents BTS
2 Présentation de sujet :
Ce projet de fin d’étude porte sur la réalisation d’un outil de suivi de performance du
réseau de TUNISIANA et à présenter L’impact de disfonctionnement d’un site sur la QOS
de réseaux 2G/3G.
3 Conduite du projet
3.1 Processus de développement
Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui
concoure à l’obtention d’un système logiciel nouveau ou à l’évolution d’un système
existant. Ce processus a pour objectif de produire des solutions informatiques de qualité
répondant aux besoins des utilisateurs dans des temps et des coûts prévisibles. De ce fait,

7
l’adéquation du projet au processus de développement peut largement affecter le sort d’un
projet informatique.
3.2 Méthodologie Agile
Méthode de développement informatique tournée vers le client. Le développement agile
tire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17
personnalités dont Kent Beck, Ward Cunnigham, Martin Fowler ou Dave Thomas. Douze
principes ont été définis. Parmi les principaux:
 Parvenir à la satisfaction du client par le biais d'un cycle de développement rapide,
récurrent et incrémental de versions fonctionnelles;
 Se montrer apte à prendre en compte les changements de dernière minute à tout
moment du projet;
 Mettre en place une coopération quotidienne entre développeurs et
décideurs/commerciaux;
 Motiver les développeurs par un environnement, un soutien et une confiance
solides;
 Faire simple, mais pas simpliste;
 Laisser l'équipe s'organiser au mieux de ses possibilités.
Il existe une dizaine de méthodologies "officielles" s'adaptant chacune à des
besoins différents. Certaines sont plus adaptées aux petites équipes, comme Crystal,
XP, Scrum, tandis que d'autres sont prévues pour des groupes conséquents, par
exemple RAD, RUP et ASD.
Nous avons opté pour la méthode de développement agile Scrum, car elle est très adaptée
aux projets comme le mien et dont les besoins sont constamment redéfinis.

8
Figure 3: Méthodologie Agile
3.3 Scrum
Davantage qu’une méthode formelle, Scrum peut être vu comme un framework
méthodologique – ses fondateurs parlent d’organisationnel pattern – dont l’implémentation
doit être ajustée en fonction des caractéristiques techniques, organisationnelles et
culturelles des projets qui souhaitent la mettre en œuvre (Scrum, au demeurant, ne limite
pas son champ d’application aux seuls projets informatiques : ses principes sont
applicables pour toute activité visant à produire un résultat).
Dans ses grandes lignes, Scrum définit un jeu minimal d’acteurs, de cérémonies et
d’artefacts qui permettent de relever les défis principaux du développement incrémental :
la planification, la gestion du temps et la gestion des obstacles. Scrum est entièrement
piloté par la Valeur Métier – la gestion des risques, en particulier, est réalisée au travers de
ce prisme. Scrum identifie trois acteurs :

9
 le Product Owner (Directeur de Produit), qui possède l’expertise fonctionnelle et
est à même de réaliser les arbitrages nécessaires à la priorisation des
développements. Son rôle est absolument essentiel, et son respect des règles du jeu
est la pierre angulaire du succès d’un projet agile. Dans notre cas il s’agit d’Imed
Hamza.
 le Scrum Master, membre de l’Equipe, et dont la tâche principale est d’optimiser la
capacité de production de l’Equipe en l’aidant à travailler de façon autonome et à
s’améliorer constamment. Il est également le garant de la bonne implémentation de
Scrum. Dans notre cas il s’agit de Md Jihéne ben Abderazek
 l’Equipe, dont la taille doit être réduite (7 à 9 personnes est généralement admis
comme une borne supérieure), et qui prend en charge le développement du produit
(planification, conception, codage, tests, documentation) sans spécialisation des
rôles. La particularité d’une Equipe Scrum est d’être « auto-organisée », et donc
dépourvue de hiérarchie. Cet aspect constitue une rupture radicale avec les
approches managériales traditionnelles, qui privilégient un contrôle centralisé
généralement incarné par le Chef de Projet. Dans notre cas il s’agit de moi.
L’unité de temps, dans Scrum, est le Sprint. Un sprint est une itération courte (de l’ordre de
2 à 4 semaines) dont le périmètre est garanti et défini lors d’une cérémonie de planification
initiale.
Le schéma suivant décrit l’articulation générale de Scrum :
Figure 4:Sprint Scrum

10
Scrum définit également trois artefacts :
 le Product Backlog,
 le Sprint Backlog
 le Burndown Chart, qui est une représentation graphique très simple de
l’avancement du projet (un Burndown Chart est produit pour chaque Sprint, un
autre pour la version du produit
Le Product Backlog est la liste des fonctionnalités du logiciel. Les éléments du backlog
sont rédigés sous forme de « User Stories » (une User Story est une forme simplifiée et
faiblement détaillée de cas d’utilisation), et doivent se focaliser sur les objectifs métiers du
produit. A minima, un élément du backlog (ou une histoire) comporte typiquement les
informations suivantes :
 un identifiant – unique, il permet de tracer l’élément quand on le renomme
 un nom – court et descriptif, suffisamment clair pour que le Directeur de Produit et
l’Equipe comprennent approximativement de quoi il est question
 l’importance – un chiffre permettant de hiérarchiser l’importance de l’élément aux
yeux du Directeur de Produit. Sa valeur absolue ne signifie rien, seule la valeur
relative compte
 l’estimation initiale – exprimée en points de complexité, et dont la valeur est
déterminée par l’Equipe.
 comment faire la démo ? – cela correspond globalement à la spécification d’un test
fonctionnel simple.
 des notes – aussi brèves que possible, visant à clarifier certains points ou à renvoyer
vers d’autres
Le Product Backlog peut également contenir des éléments techniques – mais il est
indispensable alors qu’ils soient libellés selon un angle métier, afin que le Directeur de
Produit puisse lui affecter une valeur. Il peut être conservé sous différentes formes, la plus
fréquente – et probablement la plus efficace – étant un simple tableau Excel partagé.Le
Product Backlog n’est pas un document figé : tout au long du projet, les histoires peuvent
être modifiées, fusionnées ou segmentées (celles bien sûr qui ne sont pas encore achevées)

11
de nouvelles histoires peuvent être ajoutées, d’autres supprimées ; l’importance et
l’estimation initiale peuvent être revues, à la hausse ou à la baisse.
Au début de chaque Sprint a lieu la cérémonie qui est probablement la plus importante de
Scrum : le Sprint Planning (planification du Sprint). Le Sprint Planning réunit l’Equipe et
le Directeur de Produit pour déterminer l’objectif et le contenu du Sprint à venir. C’est
durant cette cérémonie que l’estimation fine de la charge de développement de chaque
histoire est déterminée. Ces histoires sont découpées en tâches dont chacune fait l’objet
d’une estimation de charge –exprimée en heures ou en jours. Il est important de noter que
c’est l’Equipe qui détermine la charge afférente à chaque tâche. Le principal résultat de
cette cérémonie est le Sprint Backlog, qui regroupe l’ensemble des fonctionnalités que
l’Equipe s’engage à produire durant l’itération naissante, et liste les tâches
correspondantes.
La charge totale du Sprint Backlog ne doit pas excéder la capacité de production de
l’Equipe (il existe plusieurs techniques que nous n’aborderons pas ici pour établir cette
capacité de production, ou vélocité estimée).
Au terme de chaque sprint, le produit partiel est livré avec le niveau de qualité attendu pour
son exploitation en production – cette caractéristique est à l’origine du qualificatif «
incrémental » souvent associé aux méthodes agiles. Les histoires implémentées font l’objet
d’une démonstration publique.
Les méthodes agiles sont inspirées des pratiques industrielles de la production en flux
tendus et du zéro-défaut – un ensemble de pratiques désignées dans l’industrie par le
terme Lean. L’une des caractéristiques de cette approche est de ne jamais figer les
méthodes de travail, mais d’intégrer dans l’activité une introspection permanente sous-
tendue par la recherche systématique d’axes d’amélioration. Une autre caractéristique est
de ne jamais utiliser la qualité comme variable d’ajustement. Dans Scrum (et d’une façon
générale pour toutes les méthodes agiles), la qualité du produit est de la responsabilité de
l’Equipe, et ne fait pas l’objet de négociations
Afin de faciliter cette démarche, Scrum intègre un certain nombre de cérémonies
additionnelles – une cérémonie est une réunion dont la durée est fixée et dont les produits

12
en entrée et en sortie sont définis. La limite de temps pour chacune des cérémonies fait
partie de l’ADN de Scrum (on parle de time boxing).
Voici les principales cérémonies préconisées par Scrum :
 le Sprint planning, que nous avons déjà abordé
 la mêlée quotidienne (Daily Scrum), courte cérémonie (de l’ordre de 15 minutes)
menée chaque jour avec les membres de l’Equipe et le Directeur de Produit, et
dont l’objectif est de maintenir chacun au courant de l’activité de tous, de
déterminer les tâches de la journée et d’identifier les éventuels obstacles qui
ralentissent ou empêchent la progression du sprint la revue de sprint (Sprint
Review), qui consiste pour l’essentiel, au terme de chaque itération, à faire une
démonstration publique du résultat du sprint ; cette cérémonie permet de garantir le
caractère incrémental du développement (pour être démontré, le produit doit être
utilisable) mais aussi de recueillir un retour régulier des commanditaires aux fins
d’ajuster le contenu du backlog de produit
 la rétrospective (au moins 1 heure), qui réunit l’équipe et le Product Owner au
terme de chaque sprint afin d’identifier les erreurs commises lors du sprint
précédent et de définir un plan d’actions (concret et affecté) en vue d’améliorer le
processus ; la rétrospective est une cérémonie capitale qui incarne l’un des
principes fondamentaux énoncés par le Manifeste Agile : « A intervalles réguliers,
l’équipe réfléchit sur les moyens de devenir plus efficace, puis adapte et ajuste son
comportement en conséquence ».

13
Figure 5 : Processus Scrum
Conclusion
Dans ce chapitre, nous avons essayé de définir le cadre de notre projet en termes
organisationnel et professionnel. Ensuite nous avons présenté la notion d’incident tout en
insistant sur l’importance du processus de résolution des incidents. Ainsi le sujet à traiter
qui est le développement d’un outil pour le suivi des performances du réseau Tunisiana
2G/3G. A ce stade, on va étudier et présenter les architectures des réseaux 2G /3G et
définir aussi les concepts liés à la qualité de service, ce qui fera l'objet du deuxième
chapitre

Chapitre 2 : Etat de l’art des réseaux cellulaires
14
Chapitre 2
Etat de l'Art des Réseaux Cellulaires

15
Introduction
Ce chapitre est un état de l'art de la téléphonie radio mobile dans lequel nous présenterons le
contexte dans lequel s'inscrit le présent projet afin de pouvoir se focaliser sur les composantes
de notre sujet. Nous étudierons successivement les interfaces radio mobiles mises en jeu,
ensuite, nous traiterons le concept de qualité de service.
1 Concept Cellulaire
Le concept cellulaire constitue le principe de base des réseaux radio mobiles. La zone
desservie par un opérateur est divisée en cellules alimentées à partir d'une station de base.
Une cellule représente l'ensemble des points du territoire couvert par une même BTS (Base
Transceiver Station) et oïl le signal transmis par cette BTS est le plus fort .Chaque cellule est
identifiée par un BSIC (Base Station Identity Code). Le mobile est toujours connecté à la BTS
la plus proche de point de vue radio. [1]
Figure 6 : Concept cellulaire
L’utilisation du concept cellulaire permet d'ajuster les ressources radio à la demande en trafic.
Le principe se traduit par des zones à forte concentration de BTS couvrant de petites cellules
et des zones rurales à faible concentration de BTS couvrant des cellules.

16
2 Evolution des réseaux cellulaires
2.1 Norme GSM
La norme GSM est un système cellulaire de transmission numérique. Le réseau GSM a pour
rôle essentiellement de permettre des communications entre abonnés mobiles (GSM) et
abonnés du réseau téléphonique commuté (RTC ou réseau fixe). Le GSM qui a fait une
rupture avec les systèmes cellulaires analogiques, utilise les bandes de fréquences 900 MHz
1800 MHz et utilise la technique de multiplexage F-TDMA ce qui offre un multiplexage
temporel et fréquentiel à la fois.
2.1.1 Architecture Générale et Equipements
Le réseau GSM comporte les 3 sous-ensembles :
 Le Sous-système Radio BSS : responsable d'assurer et gérer les transmissions radios.
Une station mobile est un terminal de données qui transmet et reçoit des messages du
réseau. La «Base Transceiver Station» ou (BTS)»représente l'ensemble d'émetteurs et
de récepteurs fixes. Elle a pour rôle d'échanger des messages avec les stations mobiles
présentes dans la cellule qu'elle contrôle. Nous trouvons aussi le contrôleur de station
de base nommé «Base Station Controller » ou (BSC). Il communique avec une ou
plusieurs BTS.
Figure 7 Le Sous-système Radio
Le Sous-système Réseau NSS : comporte l'ensemble des fonctions nécessaires pour
les appels et la gestion de la mobilité .On trouve le commutateur du réseau «Mobile
Switching Centre» ou (MSC) qui a pour rôle le contrôle de la BSC .D'une part, il
permet l'interconnexion entre un réseau GSM et une réseau téléphonique public
interconnecte un réseau GSM avec le réseau téléphonique public RTCP/RNIS, D'autre
part, il présente l'interface des bases de données du réseau GSM avec le sous-système

17
radio. Ces bases de données enregistrent la localisation des abonnés. A ce niveau, on
trouve les entités :
 VLR «Visitor Location Register» : Une base de données représentant l'enregistreur
des visiteurs.
 HLR «Home Location Register» : Une base de données contenant les informations
relatives à chaque utilisateur (abonné) à savoir l'IMSI et l'IMEI.
 AUC «Authentification Centre» : Une base de données qui permet
l'authentification des demandes de services En effet, quand cet abonné demande
l'accès à un service, un équipement du réseau qui veut contrôler la validité des
privilèges du demandeur interroge le HLR de l'abonné. Le HLR d'un abonné
contient des informations permanentes. En revanche, un VLR enregistre les
informations temporaires, relatives à une station mobile.
Figure 8:Le Sous-système d'Acheminement
 Le Sous-système d'Exploitation et de Maintenance OSS : permet à l'opérateur
d'exploiter et de contrôler son réseau. Les équipements (OMC, EIR et AUC) assurent
ensemble l'administration du réseau. L'OMC est responsable de la gestion du
rendement, la gestion de la sécurité, et les opérations de maintenance. L'EIR est une
base de données qui peut être consultée lors des demandes de services d'un abonné
pour vérifier que le terminal utilisé est autorisé à fonctionner sur le réseau. L'AUC est
une base de données qui permet l'authentification des demandes de services.

18
Figure 9 : Le Sous-système d'Exploitation et de Maintenance
2.1.2 Identités dans un réseau GSM
Nous s'intéresse dans cette partie aux paramètres d'identification des clients dans le réseau.
 IMSI
IMSI (International Mobile Subscriber Identity) est l'identifiant unique affecté à un abonné
qui souscrit à un abonnement mobile auprès d'un opérateur. Ce numéro d'IMSI a été
préalablement stocké sur la carte SIM (Subcriber Identity Module). Le numéro d'IMSI n'est
pas connu de la part de l'abonné mobile et n'est utilisé que par le réseau GSM. LIMSI est
constitué de trois sous-champs :
 MCC (Mobile Country Code) : Il présente le code du pays du réseau.
 MNC (Mobile Network Code) : Il s'agit du code du réseau mobile. Il identifie de
manière unique le réseau GSM à l'intérieur d'un pays.
 MSIN (Mobile Subscriber Identification Number) : il s'agit du numéro d'identification
du mobile. Il identifie l'abonné mobile à l'intérieur du réseau mobile.
 MSISDN
MSISDN (Mobile Station ISDN Number) est le numéro de téléphone associé à la station
mobile .Il contient les trois sous-champs suivantes :
 CC (Country Code) : présente le code du pays dans lequel l'abonné mobile a
inscrit son abonnement.
 NDC (National Destination Code) : Il s'agit du numéro national du réseau GSM
dans lequel un client a souscrit un abonnement.
 SN (Subscriber Number) : Il s'agit du numéro d’abonné
 IMEI
L'IMEI, (International Mobile Equipment Identity) permet d'identifier de façon unique un
terminal mobile au niveau international. Ce numéro est donné par le constructeur du terminal

19
mobile. L'IMEI est utilisé par les opérateurs GSM pour lutter et défendre contre les vols de
terminaux ou pour empêcher l'accès au réseau à des terminaux.
2.1.3 Les limites de la Norme GSM
Le GSM offre un débit maximal de 9,6 Kbit/s ce qui permet de transmettre en plus de la voix,
des données de faible volume comme le SMS ou le MMS. Il est apparu vers le milieu des
années 1990 que cette norme atteindrait rapidement ses limites en termes de support d'un
service de transmission de données à haut débit. De plus et avec le progrès dans les services
proposés par l'internet, il parait nécessaire de coupler la mobilité avec l'accès à l'internet. Pour
cela les opérateurs ont pensé à migrer de la norme GSM à une autre norme qui évite les
lacunes et les défauts du système de seconde génération et qui répond aussi au défi de la
transmission de données à haut débit. Cette évolution débute par la phase de l'introduction du
GPRS avec la transmission en mode paquet sur la voie radio.
2.2 Le standard GPRS
2.2.1 L'apport de la technologie GPRS
Cette technologie étend l'architecture de la norme GSM et permet un transfert de données à un
débit plus élevé tout en optimisant l'utilisation des ressources. La technologie GPRS donne la
possibilité d'atteindre un débit maximal théorique de 171,2 Kbit/s ce qui correspond pour
l'utilisateur à un débit maximal de 114 Kbit/s dans les conditions optimales.
Donc la mise en place d'un réseau GPRS permet à un opérateur de proposer de nouveaux
services de type data avec un débit de données 5 à 10 fois supérieur au débit maximum
théorique d'un réseau GSM.
Le GPRS spécifie une technique de transmission en mode paquet qui immobilise le canal de
communication. Cet action donne la possibilité d'avoir une connexion permanente et une
facturation à la donnée ce qui présente un avantage non négligeable pour l'utilisateur qui peut
rester connecté sans surcoût et ne paye que le coût du volume échangé de données le contraire
de GSM où l'utilisateur est facturé par le temps de connexion ainsi il paye même s'il ne
consomme pas la capacité du réseau.
2.2.2 Architecture Matérielle du GPRS
L'intégration du GPRS nécessite l'ajout de quelques équipements et des mises à jour aux
entités du réseau GSM pour que l'ancien réseau accepte l'intégration de la nouvelle

20
technologie tout en conservant ses fonctionnalités. La figure ci-dessous présente une
architecture de la norme GPRS.
Figure 10 : Architecture du Réseau GPRS
Comme la figure 9 le présente, il existe coté NSS un réseau de commutation de paquets en
parallèle du réseau de commutation de circuit. Pour cela on ajoute deux entités (SGSN et
GGSN). Le SGSN est le dual paquet du MSC/VLR circuit. Il est connecté au BSS et à des
SGSN et GGSN voisins. Le SGSN joue le même rôle réalisé par le VLR dans la gestion de
mobilité. En effet, il s'occupe aussi de la compression et cryptage des données. Pour le GGSN
il s'agit d'un nœud d'interfonctionnement entre le réseau de données extérieur et le réseau
mobile de transfert de paquets.
2.2.3 La technologie EDGE
L'EDGE peut être considéré comme une amélioration du GPRS. Les opérateurs font le
recours à cette technologie car la norme UMTS les oblige à déployer un autre réseau physique
et donc des investissements très lourdes. L'EDGE présente l'avantage de pouvoir utiliser les
infrastructures déjà déployées contrairement à l'UMTS.
L'EDGE est mis en place afin d'accroître la capacité des données par rapport au GPRS. La
vitesse de transfert de données pour un réseau EDGE peut théoriquement atteindre un débit
maximum de 384 Kbps contre seulement 114 Kbps pour un réseau GPRS.

21
Même avec l'introduction du GPRS et EDGE, le débit pratique dans des conditions optimales
ne passe pas les 120 Kbit/s ce qui ne pas correspond aux attentes des utilisateurs .Pour cela les
opérateurs se trouvent obligés à sacrifier financièrement et installer le réseau de troisième
génération.
2.3 Téléphonie à mode paquet à haut débit : UMTS
L'UMTS ou 3G est une norme pour les réseaux mobiles permettant de fournir aux utilisateurs
une meilleure qualité de service. L'UMTS est capable d'offrir de nouvelles applications
multimédias et des services à valeur ajoutée telle que la visiophonie et internet à haut débit.
L'UMTS utilise des fréquences plus élevées que le standard 2G. L'UMTS occupe les bandes
passantes : 1885-2025MHz et2110-2200MHz.
2.3.1 Architecture de l'UMTS
Le réseau UMTS possède une architecture flexible et modulaire. L'architecture illustrée à la
figure 10, est composée de trois entités qui sont l'équipement de l'usager(UE), le réseau
d'accès radio (UTRAN) et le réseau cœur (CN). En effet, chaque équipement doit réaliser une
fonction bien déterminée dans le réseau, alors que des interfaces d'échange, notés
par Uu et Iu, assurent les échanges et la communication entre les différentes entités du réseau.
[6]
Figure 11 : Architecture de l'UMTS

22
2.3.2 Le domaine UE (User Equipement)
Il comprend tous les équipements terminaux et permet l'accès à l'infrastructure du réseau et à
ses services par le biais de l'interface Uu. [2]
2.3.3 UTRAN (UMTS Terrestrial Radio Access Network)
Il fournit les ressources radio et les mécanismes nécessaires à l'UE pour accéder au CN. Il
permet la maintenance et la libération des canaux radio entre le terminal et le réseau coeur CN
et la gestion de ressources radio. L'UTRAN est composé d'un ensemble de sous-systèmes
nommés RNC et de plusieurs stations de base appelé NodeB.
 NodeB : il a comme rôle la transmission et la réception d'informations entre
l'UTRAN et un ou plusieurs équipements usagers. Les UEs sont connectés au
Node B via l'interface Uu, qui assure la connexion radio. Le Node B s'occupe de la
transmission et de la réception du signal radio, de la modulation/démodulation, du
codage de canal et l'adaptation du débit de transmission.
 RNC: Il assure essentiellement le routage des communications entre les Nodes B
et le réseau coeur d'une part et le contrôle et la supervision des Noeuds B d'autre
part par le biais de l'interface IuB.
Figure 12 : UTRAN
2.3.4 Riau Cœur CN (Core Network)
Le CN assure la connexion entre les différents réseaux d'accès radio d'une part et les autres
réseaux externes d'autre part tels que RTCP et les réseaux Internet. Sa principale
fonctionnalité est la commutation et le routage des données utilisateurs vers la destination
correspondante, la gestion de la mobilité, de l'authentification, de la sécurité des échanges, de
la taxation et de signalisation entre les terminaux mobiles et les réseaux distants via l'interface

23
radio. Dans le rôle d'acheminement, le réseau coeur se compose de serveurs et de passerelles
qui se divisent entre deux sous-systèmes principaux: le domaine CS et le domaine PS.
2.4 HSPDA
HSPDA (High Speed Downlink Packet Access) ou encore 3.5G ou le 3G+ présente une norme
évoluée du standard UMTS. En effet, ce protocole pour la téléphonie mobile offre des
performances dix fois supérieures à la 3G.Cette évolution basée essentiellement sur la
technologie WCDMA permet à un utilisateur de télécharger à des débits théoriques de 1,8
Mbit/s ; 3,6 Mbit/s ; 7,2 Mbit/s et 14,4 Mbit/s. Donc, il s'agit d'une amélioration qui offre des
occasions de téléchargement à des très hauts débits de telle façon qu'on peut atteindre un débit
de téléchargement qui dépasse 7,2 Mbit/s avec la Release7.
2.5 HSUPA
HSUPA (High Speed Uplink Packet Access) est une norme de haut-débit mobile de troisième
génération dont les standards ont été définies et diffusés par le 3GPP dans la sixième édition
du référentiel UMTS (Release 6 de l'UMTS). HSUPA présenté comme un successeur de la
technologie HSPDA, vient d'améliorer le débit sur la voie montante (Uplink) qui peut
atteindre à ce niveau 5,8 Mbit/s alors que le débit descendant (Downlink) reste le même que
celui de son prédécesseur (HSPDA) qui atteint 14 Mbit/s.
3 Concept de la qualité de service
3.1 Définition
Généralement, la qualité de service ou Quality of Service (QoS) est la capacité de transférer
dans les bonnes conditions un type de trafic donné, en termes de disponibilité, débit, et délai
de transition. La qualité de service pour le réseau détermine le degré de satisfaction de
l'utilisateur aux services offerts.
3.2 Critères de performances des réseaux 2G/3G
Afin de permettre aux opérateurs d'obtenir des informations sur la qualité du service offert par
leur réseau et de l'optimiser, des indicateurs de performance appelés KPIs
(Key Performance Indicators) qui spécifient le fonctionnement radio des cellules ont été
également définis. [4]
En effet, un KPI est une valeur représentative permettant d'évaluer la performance de
système. Cette valeur est obtenue à partir d'une ou de plusieurs mesures brutes relevées par

24
des compteurs spécifiques. Ces indicateurs permettent la localisation des anomalies de réseau
et par suite, l'identification et le diagnostic des causes de ces problèmes afin de réagir avec
des actions correctives adéquates.
Dans le but d'offrir une qualité de service acceptable il faut que certains problèmes doivent
être résolus. Ces problèmes sont principalement liés à :
3.2.1 La couverture :
Ce problème ne peut pas être détecté par le système mais évalué par les plaintes des abonnées
et par les mesures radio. Les causes probables de ce problème sont les suivants :
 Mauvaise configuration du réseau c'est-à-dire problème lié à la position des sites, ou
les types d'antennes.
 Problème d'installation qui peut être due à la perte des puissances dans les câbles.
 Problème de maintenance.
3.2.2 La disponibilité du réseau :
C'est la probabilité d'obtention d'un nouvel appel. La diminution de taux d'appel aboutis
implique que les abonnées ne peuvent pas établir une communication. Les actions de l'échec
d'établissement d'appel s'expliquent par :
 Le niveau d'accès minimum dans la cellule.
 L'interférence et la mauvaise couverture radio.
3.2.3 La qualité de voix :
L'opérateur agit contre le problème de la mauvaise qualité de communication, par les mesures
système et par les analyseurs de la qualité vocale. Les causes de dégradation de la qualité de
la voix sont :
 La hors couverture.
 La mauvaise installation.
 La qualité des terminaux.
3.2.4 Les coupures d'appels :
La coupure de communication peut être engendré par :
 La mauvaise couverture.
 Les interférences.

25
Si un des KPI excède les seuils fixés par l'opérateur, le superviseur du réseau vient de signaler
un problème détecté au niveau de la fonctionnalité qu'assure cet indicateur. Généralement, ce
problème est généré à partir d'un problème ou une anomalie de couverture, d'insuffisance de
capacité, d'interférence, ou d'un problème mauvais paramétrage du réseau.
A titre d'exemple, si nous enregistrons un taux de coupure de l'appel supérieur à 2%, alors
nous avons un problème de maintien d'appel qui peut 1tre causé par la mauvaise couverture,
l'interférence, problème lors du handover (dans ce cas on consultera les taux de succès de
handover) ou un mauvais paramétrage du réseau. De plus, si le taux de succès de
l'établissement d'un service est inférieur à 95%, dans ce cas nous avons un problème d'accès
au réseau causé par la capacité, l'interférence ou un problème de paramétrage du réseau.On
présente ci-dessous un tableau qui illustre les seuils de quelques KPI :
Tableau 1: Les seuils des KPIs
Conclusion
Après avoir traité tout le long de ce deuxième chapitre les architectures des réseaux cellulaires
ainsi que le concept de la qualité de service(QoS), en présentant les différents paramètres et
critères de performance de la QoS, nous présentons passer à l’analyse des besoins à travers le
chapitre suivant.

Chapitre 3 : Analyse des besoins et spécifications
26
Chapitre 3
Analyse des Besoins et Spécifications

27
Introduction
Nous allons maintenant nous consacrer à la phase d’analyse et de spécification. Elle consiste à
identifier les différentes fonctionnalités de l’application et à décrire les différents cas
d’utilisation posés par le sujet de point de vue utilisateur.
Dans cette optique nous allons tout d’abord définir les fonctionnalités offertes par le système
répondant aux besoins de TUNISIANA ensuite spécifier les acteurs pour arriver à la fin à la
présentation des cas d’utilisation.
1 Objectifs
L'objet de ce projet est la conception et la réalisation d'un outil destiné à gérer et à présenter
L’impact de disfonctionnement d’un site sur la QOS de réseaux Tunisiana.
Pour répondre à ces objectifs, différents volets d’analyse seront menés dans le cadre de ce lot,
à savoir la définition des besoins fonctionnels, l’analyse de l’existant et la conception de la
cible globale, pour avoir le dossier fonctionnel des besoins (fonctionnels et techniques).
2 Spécification des exigences
Dans cette section nous identifions une liste d’exigences fonctionnelles et non fonctionnelles
du système à concevoir. Certaines exigences sont ajoutées pour clarifier d’avantage les
besoins des utilisateurs.
2.1 Les acteurs système
Cette application est destinée à l’équipe de supervision de Tunisiana. La structure de cette
application ainsi que tous les services proposés par l’application, seront détaillés dans les
chapitres suivants.
2.1.1 Administrateur :
L’administrateur de cette application sera en charge de la création des différents Utilisateur.
L’administrateur est le seul à pouvoir créer et supprimer des fiches de personne en tant
qu’administrateur, il n’a pas le droit de modifier les données des fiches. Cependant, il aura la
possibilité de prendre l’identité d’une personne pour avoir accès à ses droits, et effectuer ainsi
des modifications.

28
2.1.2 Utilisateur :
C’est l'équipe de supervision qui a le droit de manipuler l'application.
2.2 Le Backlog du produit :
Tout dans Scrum tourne autour du backlog produit. Ce backlog contient, sous forme de liste,
les choses que le client veut que l'équipe réalise. C'est en quelque sorte une « liste priorisée
d'exigences, d'histoires, de caractéristiques, ou autre ». Le backlog produit est maintenu par
le product owner.
Nous avons choisi d’intégrer dans notre système les fonctionnalités les plus importantes qui
sont les suivantes:
 Traitement Des Informations.
 L’analyse des données.
 Déterminer l’Availability de 2 G RAN/ 3G RAN de réseaux Tunisiana.
 Déterminées l’emplacement des tous les sites de réseaux Tunisiana.
 Déterminer le voisinage d’un site sur une distance bien déterminé.
 Déterminer L’impact de disfonctionnement d’un site sur le QOS de réseau Tunisiana
sur cette zone.
Story
ID
Story name Status Sprint Priority Estimation
(j)
1 analyse et traitement des données Done 1 1 18
2 Géolocalisation des sites 2G/3G sur google maps Done 2 1 18
3 calculer et afficher l'avaibility 2G/3GRAN Done 3 1 10
4 traitement des incidents et déterminer les sites HS
et l'impact sur le reseau
Done 3 2 20
5 afficher tous les cellules du réseau Tunisiana Done 4 2 7
6 gestion d’utilisateur Done 4 3 7
7 gestion BTS Done 4 3 7
Tableau 2 Tableau 1 Backlog du Produit

29
2.3 Diagramme des cas d’utilisation globale :
L’approche consiste à regarder le système à construire de l’extérieur, du point de vue de
l’utilisateur et des fonctionnalités qu’il attend. Chaque cas d’utilisation sera une spécification
de ce qu’il sera possible de demander de l’extérieur à l’entité ainsi représentée.
Figure 13: diagramme cas d'utilisation globale
Cette figure nous donne une vue globale sur les différents besoins fonctionnels ainsi les
acteurs qui interagissent avec notre application.
2.4 Sprint
Après avoir spécifié les besoins avec le « Product Owner », nous avons organisé les tâches
sous la forme de « Sprints » où chaque sprint aura une durée de vingt jours ou plus avec pour
objectif avoir un produit fonctionnel et livrable à la fin de chaque sprint. Nous avons organisé
notre produit backlog sous la forme de cinq sprints selon l’ordre de priorité des tâches à
réaliser et la durée que nécessite l’accomplissement de chaque tâche. Nos sprints serons
composés comme suit :
2.4.1 Sprint 1
Le sprint 1 est Généralement de criticité élevée. Ce sprint est composé de Deux User Stories
décrits ci-dessous.

30
User Story 1
Tableau récapitulatif du première User Story “ Traitements des fichiers de données BTS ”
Id 1 Projet Portail Web d’Evaluation de Performances
du Réseau Tunisiana.
Nom Traitements des fichiers des données BTS
Valeur/criticité 1 Criticité élevée
Estimation 10j
Acteurs Les utilisateurs cible sont les consultants et les managers
Sujet
1. Connexion à Serveur des fichiers
2. Sélections des fichiers
3. Sélections de données
4. organisation et gestion des données BTS
Pourquoi ? Déterminées l’équipement du réseau
Tableau 3: User Story traitements des fichiers de données BTS
User Story 2
Tableau récapitulatif du première User Story “ Traitements des fichiers des incidents ”
Id 2 Projet Portail Web d’Evaluation de Performances du
Réseau Tunisiana.
Nom Traitements des fichiers des incidents
Estimation 8j
Sujet
1. Connexion à Serveur des fichiers
2. Sélections des fichiers
3. Sélections de données
4. Sélections des BTS HS
Pourquoi ? Suivre l’état des équipements réseaux
Tableau 4 : User Story Traitements des fichiers des incidents

31
Figure 14 : Diagramme cas d'utilisation traitement des fichiers
2.4.2 Sprint 2
Ce sprint est composé de trois User Stories suivants :
User Story 3
Tableau récapitulatif du première User Story “Géolocalisation des sites BTS ”
Nom Géo-localisation des sites BTS
Estimation 6j
Sujet
1. Connexion à Base de données
2. Sélections des Bts 2G/3G
3. Sélections des cordonnées GPS
4. géo-localisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites
Tableau 5:User story Géolocalisation des sites BTS

32
User Story 5
Tableau récapitulatif du première User Story “rechercher site ”
Nom Rechercher site
Estimation 6j
Sujet
2. Sélections des BTS 2G/3G
4. rechercher in site
5. géo-localisation sur google MAPS
Pourquoi ? Déterminer les emplacements d’un site bien déterminé
Tableau 6:User Story “rechercher site ”
User Story 6
Tableau récapitulatif du première User Story “Afficher les voisinage ”
du Réseau Tunisiana..
Nom Afficher les voisinages
Estimation 6j
Sujet
2. Sélections des Bts 2G/3G
5. déterminer la distance des voisinages
4. géolocalisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites voisinage d’un site choisi
Tableau 7 : User Story “Afficher les voisinage ”

33
La figure suivante présente le digramme de cas d’utilisation résultant du Sprint 2
Figure 15 : Cas d'utlisation de sprint 2
2.4.3
2.4.4 Sprint 3
User Story 7
Tableau récapitulatif du première User Story “géolocalisation des incident ”
Nom géolocalisation des incidents
Estimation 10j
Sujet
5. sélections des incidents
6. déterminer les sites HS
4. géolocalisation sur google MAPS
Pourquoi ? Déterminer les emplacements des sites HS

34
Tableau 8:User Story “géolocalisation des incident ”
User Story 8
Tableau récapitulatif du première User Story “KPI du réseau ”
du Réseau Tunisiana..
Nom Mesure QOS du réseau
Estimation 10j
Sujet
3. choix des KPI
4. afficher KPI
Pourquoi ? Déterminer les QOS de réseau
Tableau 9:User Story “ KPI du réseau ”
User Story 9
Tableau récapitulatif du première User Story “ Availibility 2G/3G RAN ”
Id 9 Projet d’Evaluation de Performances du Réseau
Tunisiana.
Nom Mesure 2G/3G RAN
Estimation 5j
Sujet
2. déterminer la liste des incidents
3. calculer 2G/3G RAN
4. afficher courbe
Pourquoi ? Déterminer les QOS du réseau
Tableau 10: User Story “Availibilite 2G/3G RAN ”

35
Figure 16 : Cas d'utilisation Déterminer les sites HS
Figure 17 Afficher Availibility 2G RAN

36
2.4.5 Sprint 4
User Story 8
Tableau récapitulatif du première User Story “gestion des cellules”
Nom Gestion des cellules
Estimation 7j
Sujet
2. déterminer la liste des cellules
3. afficher tous les cellules
4. recherche par plusieurs critères
5. modifier/ supprimer/ ajouter des cellules
Pourquoi ? Gestion des cellules
Tableau 11: User Story gestion des cellules
User Story 9
Tableau récapitulatif du première User Story “gestion des Utilisateurs”
Nom Gestion des Utilisateurs
Estimation 7j
Sujet
2. déterminer la liste des utilisateurs
3. afficher tous les utilisateurs
4. modifier / supprimer / ajouter des utilisateurs
Pourquoi ? Gestion des utilisateurs
Tableau 12: User Story gestion des Utilisateurs

37
User Story 10
Tableau récapitulatif du première User Story “gestion des BTS”
Nom Gestion des cellules
Estimation 7j
Sujet
2. déterminer la liste des cellules
3. afficher tous les cellules
4. recherche par plusieurs critères
5. modifier / supprimer / ajouter des cellules
Pourquoi ? Gestion des BTS
Tableau 13: User Story gestion des BTS
Les figures suivantes présentes les digrammes de cas d’utilisation résultant du Sprint3
Figure 18 : Gestion BTS

38
Figure 19 : Cas d'utilisations Afficher cellules
Figure 20 : Cas d'utilisations Gestion Utilisateur

39
2.5 Besoins Non Fonctionnels
S’agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner les
contraintes d'implémentation (langage de programmation, type SGBD, de système
d'Exploitation...)
Dans le cadre de ce travail, l'application devra être extensible, c'est-à-dire qu'il pourra y avoir
une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.
L'application devra être capable de :
 Rapidité : l’application traite souvent un grand volume de données, elle doit alors
effectuer ces traitements d’une façon rapide et optimale afin d’éviter une longue durée
d’attente.
 Robustesse : l’application doit pouvoir gérer un très grand volume de données sans se
bloquer.
 Fidélité : la comparaison de paie est une étape cruciale qui manipule des données
sensible ainsi les résultats de calcul doivent être justes.
 Portabilité : l’application doit être facilement utilisable et ne doit pas nécessiter des
étapes de configuration ou d’installation.
 Evolutivité : l’outil doit être facilement modifié afin d’ajouter des nouveaux modules
répondant à des nouveaux besoins.
Conclusion
Ce chapitre a permis de détailler les spécifications du projet, d’identifier les cas d’utilisation
et d’élaborer les diagrammes correspondants. A présent nous sommes prêts à passer à l’étape
de conception dans le chapitre suivant.

Chapitre 4 : Conception
40
Chapitre 4
Conception

41
Introduction
A la fin du chapitre précédent, nous avons présenté l’aspect architectural de la solution. Dans
la section suivante, nous présentons l’aspect conceptuel de notre application ; une
étape primordiale avant l’implémentation.
3 Architecture du système : Modèle multi couches
Les choix architecturaux d’une application sont décisifs dès lors qu’ils interviennent sur
les performances, l’évolutivité, le temps de développement, et bien sûr le coût. Aujourd’hui
nous parlons d’une séparation des applications en différentes couches, et nous parlons alors
d’applications multi niveaux.
L’architecture de notre système est une architecture multi niveaux à base de composants
respectant le paradigme JEE. Elle est constituée des couches suivantes modélisées dans la
figure ci-dessous. Nous notons la délimitation des couches de conception du modèle MVC2
des autres couches constituant notre système.
Figure 21 : modèle MVC
 Couche de présentation : Chargée de gérer les interactions entre l’utilisateur et
l’application (Navigateur Internet).
 Couche web : Permet de définir ce que doit afficher l’interface utilisateur et la manière
de gérer les requêtes.
 Couche métier : Contient le traitement à exécuter, qui sera appelé via la couche de
présentation faisant intervenir en général l’extraction et le traitement du contenu de la
couche de données via la couche d’accès aux données.
 Couche d’accès aux données : Prend en charge toutes les interactions entre la couche
logique et la couche de données. Si une telle couche n’existait pas, nous serions
contraints de réécrire les mêmes lignes de code à différents endroits de l’application.

42
 Couche de données : Ce niveau contient les données de l’application (Base de
données, fichiers XML,).
Grâce à cette séparation en couches la souplesse, la maintenance et le développement de
l’application se trouveront grandement améliorés.
Par la suite, nous intéresserons aux détails des couches de la partie MVC2 qui contiendra
toute notre logique applicative.
4 Conception
Dans cette section nous présentons en premier lieu l’architecture logicielle de notre
application via un diagramme décrivant les dépendances entre les différents packages. En
second lieu nous présentons chacun de ces modules.
4.1 Conception détaillé
La conception détaillée consiste à concevoir et documenter précisément le code qui va être
produit. Dans cette phase, toutes les questions concernant la manière de réaliser le système à
développer doivent être élucidées. Le produit d'une conception détaillée consiste en
l'obtention d'un modèle prêt à coder. Lorsque l'on utilise des langages orientés objet le
concept de classe UML correspond exactement au concept de classe du langage concerné.
Cette propriété facilite la compréhension des modèles de conception et donne encore plus
d'intérêt à la réalisation d'une conception détaillée avec UML.
Dans cette partie, nous présentons la conception de l’application réalisée à chaque sprint à l’aide
de quelques diagrammes de séquence et d’activité des user stories les plus importants.
4.2 Sprint 1
4.2.1 Diagramme de séquence
La figure suivante décrit le scénario d’authentification.Il commence l’lorsque un utilisateur
demande l’accès a l’application :

43
Figure 22 : Diagramme séquence objet authentification
La figure suivante décrit le user story ‘ Traitements des fichiers de données BTS ‘, chaque
heurs le serveur ftp envoie des fichiers des données des incidents ainsi la mise à jour des BTS.
le scenario suivant décrit le traitement de ces fichiers :
Figure 23 : Diagramme de séquence de user story traitement des fichiersde données
BTS

44
4.2.2 Diagramme d’activité :
Le diagramme d'activité permet de modéliser le comportement du système, dont la séquence
des actions et leurs conditions d'exécution. Les actions sont les unités de base du
comportement du système.
La figure suivante résume le processus de traitement des fichiers de données BTS.
Figure 24 : Diagramme d'activité de traitement des fichiers de données BTS
4.3 Sprint 2
Ce scénario est décrit par la figure suivante il commence lorsque l’utilisateur demande la
carte des sites 2G. En effet l’utilisateur a le choix de la géolocalisation les sites selon plusieurs
critères.

45
Figure 25 : Diagramme séquence objet Map 2G
4.3.2 Diagramme d’activité :
Le processus de création de Géolocalisation des sites BTS peut être résumé dans le diagramme
d’activités suivant :

46
Figure 26: Diagramme d'activité « Géolocalisation des sites BTS »
4.4 Sprint 3
Le scénario suivant décrit le user story « géolocalisation des incident » par la figure suivante
d’après ce dernier on peut géolocaliser les incident ainsi les sites hors service a chaque
moment données et définit les KPI des sites voisinage.

47
Figure 27 : Diagramme séquence géolocalisation des incidents

48
Le scénario suivant décrit les étapes à suivre pour afficher la courbe de l’Availibility 2G
ainsi les déférentes actions qui peuvent les établir.
Figure 28 : diagramme de séquence « l’Availibility 2G »
4.4.2 Diagramme d’activité
Le diagramme d’activité suivant représente le scenario relatif au user story « géolocalisation
des incident »

49
Figure 29 : Diagramme d'activité « géolocalisation des incidents »
4.5 Sprint 4
Le scénario suivant décrit les étapes à suivre pour ajouter un utilisateur après les vérifications
des champs de formulaire qu'on doit remplir. Nous vérifions au niveau de base de données
l’unicité de cet utilisateur.
Figure 30 : Diagramme de séquence « ajouter utilisateur »

50
4.5.2 Diagramme d’activité
Le diagramme d’activité suivant représente le scenario relatif cas d’utilisation « ajouter
utilisateurs »
Figure 31: Diagramme d'activité « ajouter utilisateurs »
4.6 Diagramme de classes
L'approche objet prône le rapprochement des données et des opérations dans une seule entité :
l'objet. Les traitements sont ainsi répartis entre les déférents objets qui incarnent les données
manipulées par le programme.
Le concept des objets est fondamental dans l'approche objet. Les objets sont des entités
atomiques formées par l'union d'un état et d'un comportement et qui communiquent par
échange de messages. Afin de réduire la complexité des objets du monde réel, la notion
d'abstraction a permis de regrouper les objets en classes. Parmi les relations les plus
importantes entre les classes, les associations (relations sémantiques bidirectionnelles) et
l'héritage. Les classes et leurs relations sont regroupées dans un diagramme (diagramme de
classes) représentant une vue statique des interactions entre les objets.

51
Figure 32:Diagramme de classe
Conclusion
Nous finissons ainsi l'étape de conception, élaborée dans ce chapitre et dans laquelle nous
avons préparé tout ce qu'il fallait pour présenter et réaliser cette application. La réalisation est
Le sujet du chapitre suivant

Chapitre 5 : Réalisation
52
Chapitre 5
Réalisation

53
Introduction
Cette partie contient le dernier volet de ce rapport, elle a pour objectif d’exposer le travail
achevé. Nous allons commencer, tout d’abord, par la présentation de l’environnement
matériel et logiciel utilisé pour développer l’application demandée. Ensuite, nous présentons
le travail accompli tout au long de la période du stage. Enfin, nous montrons
le chronogramme de la réalisation du projet.
1 Environnement de travail
Nous présentons dans cette section l’environnement matériel ainsi que celui logiciel utilisés
pour le développement de notre application.
1.1 Environnement matériel
Un PC avec les configurations suivantes :
 un processeur Intel Core I5
 une RAM de 4 Go.
1.2 Environnement logiciel
Le long de la phase de développement, nous avons utilisé l’environnement logiciel suivant :
– Système d’exploitation : Microsoft Windows Seven pour la PC de développement.
Linux fedora Serveur de Tunisiana ou le déploiement de l’application.
– Outils de développement : Eclipse 3.7
– Serveur d’application : JBoss AS 7.1.1
– MySQL Server 5 : utilisé pour la gestion de la base de données.
– Paradigm for UML 10.1 et ArgoUML : pour la conception UML.
2 Choix techniques
Dans cette partie, nous justifions les choix techniques du langage de programmation, de la
plateforme de développement et des frameworks utilisés.
2.1 Choix du standard de développement
Java EE 6 est une version importante. Non seulement elle marche dans les pas de Java EE 5
pour fournir un modèle de développement simplifie, mais elle ajoute également de nouvelles
spécifications et apporte des profils et de l’élagage pour alléger ce modèle. La sortie de Java
EE 6 coïncide avec le dixième anniversaire de la plate-forme entreprise : elle combine donc
les avantages du langage Java avec l’expérience accumulée au cours de ces dix dernières

54
années. En outre, elle tire profit du dynamisme de la communauté open-source et de la rigueur
du JCP. Désormais, Java EE est une plate-forme bien documentée, avec des développeurs
expérimentes, une communauté d’utilisateurs importante et de nombreuses applications
déployées sur les serveurs d’entreprises. C’est un ensemble d’API permettant de construire
des applications multi-tiers reposant sur des composants logiciels standard ; ces composants
sont déployés dans différents conteneurs offrant un ensemble de services.
2.2 Choix du Framework pour la couche de présentation
JSF2.0 (Java Server Faces) permet de développer des application web en bénéficiant des
concepts déjà approuvés par Java et Java EE composants graphiques Swing, JSP, Servelts,
JSTL…)et par les apports d’autres Framework Open source tel que Struts.
JSF est un standard, donc est supporté par l’industrie. Face à la multitude des frameworks
MVC (Model-View-Controller) disponibles sur le marché, il s’agit là d’un argument non
négligeable.JSF apporte plusieurs fonctionnalités destinées à résoudre les problèmes inhérents
à la programmation web. JSF se compose d’un ensemble d’API fournissant notamment :
 Une séparation entre la couche présentation et les autres couches
 Une librairie de composants graphiques
 La navigation entre pages
 Le traitement des formulaires et leur validation
JSF ne remplace pas les autres technologies web, il les utilise et les complète. Son architecture
est basée sur le design pattern MVC. Pour rendre le développement d’une application web
plus modulaire et plus souple, JSF décore le tous ces éléments (traitement, présentation,
navigation) et enrichit le pattern MVC. Le modèle est toujours représenté par les Entity
Beans. Le contrôleur intercepte les requêtes http, la navigation entre les pages web est
configurable par un fichier XML dit faces-config.xml

55
Figure 33 : JSF
2.3 EJB3.1
Figure 34 : EJB3.1

56
Au sein d'une architecture Java EE, les EJB sont utilisés pour créer les services. Cette
technologie ne s'arrête cependant pas à cette couche, mais permet aussi de créer l'abstraction
de l'accès aux données. Ce sont les entités qui remplissent cette fonction.
Tout comme les beans sessions, entre le client et le logique métier, les beans entités forment
la passerelle entre la logique applicative et les sources de données. Ils offrent une abstraction
quasi complète du stockage des données, permettant à l'application de rendre persistantes ou
de charger des données de manière totalement transparente.
2.4 Choix du conteneur de la couche de persistance de données
Depuis les débuts de J2EE, le modèle de persistance ne cesse d’évoluer et de s’engluer de
version en version. Les entity beans 1.0 ont été complètement ré architecturés pour laisser
place aux entity beans 2.1. Bien que cette évolution ait apporté beaucoup d’améliorations, ce
modèle de composants persistants continuait à faire des détracteurs parmi la communauté.
Ce mécontentement a donné naissance à une nouvelle spécification (JDO, Java Data Object)
ainsi qu’à différents outils de mapping objet/relationnel payants ou libres (Top Link,
Hibernante...). Java EE 5, et son lot de nouveautés, nous apporte un nouveau modèle de
persistance : JPA (Java Persistence API). Fortement inspirés par des outils Open Source tels
qu’Hibernante ou par JDO, le mapping objet/relationnel et le langage de requête sont
totalement différents de l’ancêtre entity bean 2.1. JPA, ou JSR-220, réconcilie ainsi les
utilisateurs de la plate-forme JEE avec les composants persistants. Java Persistent API
s’appuie sur JDBC pour communiquer avec la base de données. En revanche, grâce à
l’abstraction apportée par JPA, nous n’aurons nul besoin d’utiliser directement JDBC dans le
code Java.
La couche [dao] dialogue maintenant avec la spécification JPA, un ensemble d'interfaces. Le
développeur y a gagné en standardisation. Avant, s'il changeait sa couche ORM, il devait
également changer sa couche [dao] qui avait été écrite pour dialoguer avec un ORM
spécifique. Maintenant, il va écrire une couche [dao] qui va dialoguer avec une couche JPA.
Quelque soit le produit qui implémente celle-ci, l'interface de la couche JPA présentée à la
couche [dao] reste la même.
Dans notre projet la spécification JPA a été implémentée par le produit Hibernate.

57
Figure 35 : Architecture de la spécification JPA
2.5 Choix du SGBD MySQL
Notre application ne dispose pas d’un grand volume de données à gérer, donc MYSQL suffira
comme étant une solution open source. En plus ce SGBD 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. Il faut aussi noter sa rapidité, sa robustesse, et sa facilité d’utilisation et
d’administration. Enfin sa documentation complète et bien construite
2.6 Choix du serveur d’application JBOSS AS 7.1 :
Alors que Tomcat est un conteneur web, JBOSS est un serveur d'applications qui embarque
Tomcat (ou un équivalent) et qui propose en plus un hébergeur des EJB, des transactions, de
la persistance...
Côté performance, administration et connecteurs sont des raisons à considérer pour justifier le
choix d’un serveur d'applications fiable.
Tomcat est largement utilisé car c’est plus "léger" (empreinte mémoire, temps de
démarrage...). Ceci dit, les serveurs d'applications en général font des progrès dans ce coté là.
Avec l'arrivée dans les entreprises de Java EE 6, il y a un réel regain d'intérêt pour les
serveurs d'application.
JBOSS est le nom du serveur d'applications Open Source Java 6, il est entièrement écrit en
Java.
3 Phase d’implémentation
Les interfaces Homme/Machine constituent un élément important dans la réussite d’une
application. Cette contribution est d’autant plus importante lorsqu’il s’agit d’une application
Web. Ces interfaces doivent obéir à des chartes graphiques et aux règles d’ergonomie pour
que l’utilisateur s’adapte le plus rapidement possible à la logique de l’application.
Afin d’atteindre ces objectifs, nous avons choisi d’adopter un style commun pour toutes les
interfaces à l’aide d’une feuille de style.

58
3.1 Géolocalisation site 2G
Figure 36 : MAP 2G
Description :
Nous utilisons le Technique de localisations Global Positioning System(GPS) pour obtenir
cette interface qui permet à l’utilisateur d’avoir une vue globale sur le réseau 2G de
Tunisiana ainsi la géolocalisation des sites 2G. Cette résultat c’est la récolte de traitement des
fichiers BTS sous format Excel ce derniers contient plus que seize mille ligne ainsi
l’enregistré dans la base de données a fin de les affichées sur l’API de google MAPS.
3.2 Géolocalisation site 3G
Figure 37 : MAP 3G

59
Description :
Il s’agit de la même interface de géolocalosation 2G mais pour le cas de 3G.
3.2.1 Recherche par lac
Figure 38 : Recherche par LAC
Description :
L’exemple présenté par la figure 38 montre l’affichage d’un ensemble des sites qui sont de
même local area code (LAC) 1119.
3.2.2 L'Availability 2G RAN :
Figure 39: courbe 2G RAN

60
Description :
Cette interface permette à l’utilisateur d’avoir une vue globale sur les performances du
réseau de Tunisiana. En effet Cette courbe est la résulta de la formule suivante :
3.3 Géolocalisation des Site HS
Figure 40: géolocalisation des incidents
Description :
Notre application est basée sur la récupération les fichiers incidents sur un serveur FTP.
Après le traitement de ces fichiers par la technologie EJB Timer nous obtenons cette interface
d’où via ce dernier l’utilisateur est capable de visualiser l’ensemble de site hors service (HS)
ainsi de déterminer la cause de l’incident.
Figure 41 : Exemple de fichiers incidents

61
3.4 Affichage des sites en voisinage d’un site HS
Figure 42 : voisinage d'un incident
Description :
Cette Interface permet de définir les voisinages des sites HS ainsi leur KPI. Après le choix de
distance de voisinage ou par LAC d’un site HS un ensemble des sites sera affiché sur la carte
chaque de ces site on peut présenter ces KPI et déterminer si il y a un impacte sur cette suite à
la dysfonction de ce site ou non.
Figure 43 : Voisinage Site HS par LAC

62
3.5 Test
La phase de test est l’une des plus coûteuses et des plus importantes pour un cycle de vie d’un
logiciel. A la fin de cette phase qu’on peut juger la qualité d’un logiciel. Dans notre projet on
a mené les tests suivants :
Les tests unitaires qui sont faits par le programmeur afin que chaque module puisse
fonctionner sans erreur de programmation.
Le test du système afin de vérifier si le logiciel fonctionne sur la machine cible (avec les
logiciels et matériel du client).
Le test de validation qui est fait par le client pour vérifier le niveau de qualité : c’est un test
assez lourd pour adopter le logiciel aux attentes de client.
4 Chronogramme de réalisation
Le diagramme de GANTT est un outil permettant de modéliser la planification de tâches
nécessaires à la réalisation d'un projet dans le temps.
Figure 44 : Chronogramme de Réalisation
Conclusion
Au cours de ce dernier chapitre nous avons précisé notre choix technique et montré quelques
interfaces de notre application. A la fin nous avons présenté notre chronogramme modélisant
les étapes de notre travail. A présent nous passerons dans la partie suivante à la conclusion
globale de notre projet.

63
Conclusion et Perspective
Aujourd’hui, le souci majeur des opérateurs de téléphonie mobile consiste à assurer une
qualité de service suffisamment bonne afin de permettre le bon fonctionnement des services
offerts à leurs abonnés. La nécessité d’améliorer le service rendu au niveau des réseaux
mobiles s’est largement manifestée. Ainsi, l’utilisation des techniques d’optimisation
appropriées est essentielle afin de qualifier les performances de réseaux.
Le but principal de ce projet était de créer une plateforme qui facilite la tâche de suivi et de
monitoring de la qualité de service de l'opérateur Tunisiana. Ce travail a suivi plusieurs étapes
qui ont été très importantes pour la phase de réalisation et le développement. La première
étape était de mettre le sujet dans son contexte général, ce qui a permis de dégager les
différentes besoins dont l'application est chargée d'y répondre. Ces besoins ont été bien traités
et analysés dans la phase de spécification.
L'étape suivante, était la conception, durant toute cette phase, une étude globale et détaillée
des fonctionnalités du système était réalisée à l'aide de langage de modélisation UML pour
aboutir enfin à l'application opérateur qui vise à aider l'opérateur à améliorer la qualité de
service offert.
Ce projet présente une occasion pour s'améliorer dans le développement Java/Jee sur plusieurs
niveaux appliquées les nouvelle technologie JEE6, communication client/serveur,
communication réseaux avec les serveurs FTP, conception et interaction avec les bases de
données, aussi, il m'a permis d'acquérir des connaissances importantes surtout au niveau de la
qualité de service des réseaux mobiles 2 G et 3 G. Le travail présenté répond au cahier de
charge déjà posé, mais il ne représente pas la version finale qu'on peut atteindre. En effet, ce
travail peut s'améliorer certainement dans le futur, avec des nouvelles idées.
Enfin, l’application que nous avons développée pourrait être enrichie par des fonctionnalités
avancées telles que l’intégration d’partie mobile.
Pour conclure, ce stage était très important, dans la mesure où il m'a permis d'appliquer mes
connaissances acquises lors de mon cursus éducatifs et des maitriser des nouvelles
technologies de développement. Finalement, il était une occasion pour s'introduire et
s'intégrer dans le milieu professionnel.

64
Bibliographie
[1] Pierre Lescuyer UMTS Les origines, l’architecture, la norme
[2] Jean CELLMER, « Réseaux cellulaires, Système GSM»
[3] Michel Thériault, "Étude des performances d’un système DS-CDMA avec récepteur Rake
dans le contexte UWB".
[4] http://www-igm.univ-mlv.fr/~dr/XPOSE2006/eric_meurisse/umts.php
[5] Thierry Lucidarme, "Principes de radiocommunication de troisième génération",
Vuilbert,Paris, 2002
[6] T. Okumura, E. Ohmor, and K. Fukada, "Field Strength and its variability in VHF and
UHF Land mobile Service", Review Electrical Communication Laboratory, pp. 825-873,
1968
[7] J. Walfisch and H. Bertoni, "A theoretical model of UHFpropagation in urban
environment", IEEE Transactions on antennas and propagation, vol. 36, pp. 1788-1796,
December 1988
[8] Maciej J. Nawrocki, Mischa Dohler and A. Hamid Aghvami, "Understanding UMTS
Radio network"

65
Acronymes
0-9
1G First Generation of wireless communication technology
2G Second Generation of wireless communication technology
3G Third Generation of wireless communication technology
A
API Application Programming Interface
B
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
C
Cell ID CDMA CN
E
EDGE
F
FDD FTP
G
GPRS GSM
H
HSPA HSDPA
J
JVM J2EE
Cellule Identity
Code Division Multiple Access Core Network

66
Frequency Division Duplex File Transfert Protocol
Global System for Mobile communication
High-Speed Packet Access High-Speed Downlink Packet Access
Java Virtuel Machine Java2 Enterprise Edition
LAC Location Area code
M
MCC Mobile Country Code
MMS Multimedia Message Service Mobile Network Code
MSC Mobile Switching Center
N
NSS Network and Switching Subsystem
O
OSS Operation and Support Subsystem
Q
QoS Quality of Service
R
RAN Radio Access Network
T
TDD TDMA
U
UMTS UTRAN
Time Division Multiple Access
Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network
W
W-CDMA Wideband Code Division Multiple Access

67
Annexe A : JBOSS AS 7
JBoss Application Server est un serveur d'applications J2EE libre entièrement écrit en Java.
Les développeurs du cœur de JBoss ont tous été employés par une société de services appelée
« JBoss Inc. ». Le projet est sponsorisé par un réseau mondial de partenaires et utilise un
business model fondé sur le service. En effet, JBoss est maintenu par le Groupe JBoss
gratuitement, mais toute customisation et tous services consultants sont facturés. Ce groupe
est une division de RedHat depuis avril 2006. La DGI (Direction Générale des Impôts) utilise
JBoss.
JBoss est similaire à Weblogic de BEA ou à WebSphere d’IBM dans sa complexité.
Compatible avec les standards :
• CORBA OTS (Object Transaction Service),
• JTA/JTS (Java API Transaction/Service),
• WebServices
Caractéristiques :
• Supporte les Sun JDK 1.6 et 1.7
• Version 5as 7est en passe d’être certifiée 1.7
• Clustering: Failover (including sessions) / Load balancing
• Distributed caching (using JBoss Cache, a standalone product)
• Distributed deployment (farming)
• Deployment API
• Management API
• Aspect-Oriented Programming (AOP)-support
• JSP/Servlet 2.1/2.5 (Tomcat)

68
• JavaServer Faces 2.1 (Mojarra)
• Enterprise Java Beans version 3 and 3.1
• JNDI (Java Naming and Directory Interface)
• Hibernate-integration (for persistence programming; JPA)
• JDBC
• JTA (Java Transaction API)
• Support for Java EE-Web Services like JAX-RPC (Java API for XML for Remote Procedure
Call), JAX-WS, JAXB
• SAAJ (soap with Attachments API for Java)
• JMS (Java Message Service) integration / JavaMail
• RMI-IIOP (JacORB, alias Java and CORBA)
• JAAS (Java Authentication and Authorization Service)
• JCA (Java Connector Architecture)-integration
• JACC (Java Authorization Contract for Containers)-integration
• Java Management Extensions
Figure 45 : JBOSS AS7

pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana

Similaire à pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana (20)

pfe Conception et Réalisation d’un Portail WEB D’Evaluation Des Performance du Réseau Tunisiana