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

http://www.bricozor.com/transmetteur.html


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



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



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





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

1. Connexion à Base de données


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

1. Connexion à Base de données

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



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



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



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.

http://fr.wikipedia.org/wiki/Serveur_d%27applications

http://fr.wikipedia.org/wiki/Open_source

http://fr.wikipedia.org/wiki/Java_(technologie)

http://fr.wikipedia.org/wiki/Java_Enterprise_Edition


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

http://www.cdiscount.com/transmetteur.html

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

69

Annexe B : La technologie AJAX

I. Présentation de la technologie

AJAX, ou Asynchronous JavaScript And XML (« XML et Javascript asynchrones »), est un

acronyme désignant une méthode informatique de développement d'applications Web.À

l'image de DHTML ou de LAMP, AJAX n'est pas une technologie en elle-même, mais un

terme qui évoque l'utilisation conjointe d'un ensemble de technologies couramment utilisées

sur le Web :

HTML (ou XHTML) pour la structure sémantique des informations ;

CSS pour la présentation des informations ;

DOM et JavaScript pour afficher et interagir dynamiquement avec l'information

présentée ;

l'objet XMLHttpRequest pour échanger et manipuler les données de manière

asynchrone avec le serveur Web.

XML et XSLT

En alternative au couple XML/XSLT, les applications AJAX peuvent utiliser d'autres

technologies: le HTML préformante, et les fichiers texte plats par exemple.Les applications

AJAX peuvent être utilisées au sein des navigateurs Web qui supportent les technologies

décrites précédemment. Parmi eux, nous trouvons Mozilla, Firefox, Internet Explorer,

Konqueror, Safari ou encore Opera. Toutefois, ce dernier ne supporte pas les transformations

XSLT nativement pour les versions antérieures à la 9.0.

II. Comparaison avec les applications Web traditionnelles :

Les applications Web permettent aux utilisateurs d'effectuer des choix (suivre un lien, remplir

et valider un formulaire). Une requête est alors envoyée au serveur HTTP, qui agit en

fonction de l'action et des données reçues, et renvoie une nouvelle page. Ce fonctionnement

consomme inutilement une partie de la bande passante, une grande partie du code (X) HTML

étant commune aux différentes pages de l'application. Et parce qu'une requête au serveur

HTTP doit être réalisée à chaque interaction avec l'application, le temps de réponse de

l'application dépend fortement du temps de réponse du serveur HTTP. Cela conduit à des

interfaces utilisateurs plus lentes que leurs équivalents natives. Les navigateurs actuels

70

mettent les éléments communs en cache, donc le chargement de pages nouvelles n'oblige pas

le serveur à redonner les mêmes éléments à chaque fois. Les applications utilisant les

techniques AJAX quant à elles peuvent envoyer des requêtes au serveur HTTP pour

récupérer uniquement les données nécessaires en utilisant la requête HTTP

XMLHttpRequest, et en utilisant la puissance des feuilles de style (CSS) ainsi que le langage

Javascript côté client pour interpréter la réponse du serveur HTTP. Les applications sont alors

plus réactives, la quantité de données échangées entre le navigateur et le serveur HTTP étant

fortement réduite. Le temps de traitement de la requête côté serveur est également légèrement

réduit, une partie du traitement étant réalisé sur l'ordinateur d'où provient la requête. En

contrepartie, le chargement de la première page peut être pénalisé si l'application utilise une

bibliothèque AJAX volumineuse.

Documents

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