HAJ TAIEB_Mohamed

SUPCOM A-U:2005/2006

République de la TunisieMinistére des Etudes Supérieures

E c o l e S u p é r i e u r e s d e s C o m m u n i c a t i o n s d e T u n i s

Projet de Fin d�Etudes

Présenté pour l�Obtention du Diplôme

d�Ingénieurat en Télécommunications

Réalisé par :

Mohamed Hadj Taïeb

Intitulé du Projet:

Suivi de la Performance du RéseauGSM à partir du Flux des MessagesCaptés au niveau de l�Interface A

Encadreur à Supcom : Mr. Mohamed Taher MissaouiEncadreur à Tunisiana : Mr. Fahmi Kharrat

Mr. Sami Salmouni

Organism : O r a s c o m T u n i s i e T é l é c o mAdresse : Les Jardins du Lac-1053 Les Berges du Lac-Tunis

Téléphone : (216) 22 12 00 00 Télécopie : (216) 22 12 10 09

R a p p o r t E d i t é p a r L A T E X

Dédicace

A mon père Ezzeddine ,pour sa patience et ses considérables sacri�ces.

A ma mère Asmaque nulle dédicace ne puisse exprimer ce que je lui dois.

A mes frères Moujahed et Nader,A ma soeur Imen est ses adorables petits enfants.

A mes amis,A mes enseignants,

A tout ceux que j�aime et tout ceux m�aimentJe dédie ce travail

ii

Remerciments

Au terme de ce projet d�ingénieur, réalisé durant quatre mois à Orascom TunisieTélécom, je tiens à remercier in�niment Mme Valérie Lepilliet, chef département Opérationet maintenance de la Direction Technique ainsi que mes encadrants Monsieur Fahmi Kharrat,chef de l�équipe Qualité de Fonctionnement (QDF), et Monsieur Sami Salmoni ingénieurqualité de fonctionnement pour m�avoir encouragé à entamer mon projet, pour leurs suivis,leurs disponibilités, leurs aides et leurs soutiens lors de l�élaboration de ce travail.

Je tiens à exprimer ma gratitude pour Monsieur Mohamed Taher Missaoui mon encadreur àl�école pour m�avoir soutenu, conseillé, aidé à réaliser mon projet de �n d�étude.

iii

Table des matières

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Chapitre 1. Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . 21.1. Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Cadre Générale de travail : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1. Société d�accueil : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.2. Directions : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Présentation Générale du Projet : . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.1. Intitulé du projet : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.2. Travail Demandé : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.3. Méthodologie utilisée : . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapitre 2. QoS et mesure des performances . . . . . . . . . . . . . . . . . . 82.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. QoS dans les Réseaux Mobiles : . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Dé�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Indicateur de qualité de service . . . . . . . . . . . . . . . . . . . . . . 92.2.3. Problèmes intervenant lors des di¤érentes procédures : . . . . . . . . . 11

2.3. Mesures des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1. Organisation de mesures des performances . . . . . . . . . . . . . . . . 122.3.2. Méthodes de mesures de la QoS . . . . . . . . . . . . . . . . . . . . . . 14

2.4. Etude de l�existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1. Outils Fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.2. Outils Opérateur : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5. Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapitre 3. Etat de l�Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2. Description de l�interface A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1. Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

iv

3.2.2. La signalisation dans l�interface A . . . . . . . . . . . . . . . . . . . . . 213.3. Cigale de Astellia outil de suivi de l�interface A : . . . . . . . . . . . . . . . . . 25

3.3.1. Présentation de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2. Mode de fonctionnement de Cigale : . . . . . . . . . . . . . . . . . . . . 26

3.4. Exploitation des �chiers Cigale pour le suivi des performances du réseau GSM : 293.4.1. Fichier XL2 machine d�état de l�interface A : . . . . . . . . . . . . . . . 293.4.2. Fichier XLT : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.3. Fichier XLF : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.4. Fichier XLU : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.5. Les indicateurs déduits de l�interface A : . . . . . . . . . . . . . . . . . 493.4.6. Indicateurs de qualité de service : . . . . . . . . . . . . . . . . . . . . . 49

3.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Chapitre 4. Conception et réalisation . . . . . . . . . . . . . . . . . . . . . . 544.1. Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2. Environnement informatique : . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3. Cahier de charge : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4. Modèles de cas d�utilisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4.1. Use case " traitement des �chier et insertion dans la base" : . . . . . . 564.4.2. Use case "Con�guration des indicateurs" : . . . . . . . . . . . . . . . . 574.4.3. Use case "Interface de con�guration" : . . . . . . . . . . . . . . . . . . 574.4.4. Use case "courbes statistiques" . . . . . . . . . . . . . . . . . . . . . . 58

4.5. Diagrammes de Séquences : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5.1. Diagramme de séquence "Traitement et insertion dans la base" : . . . . 594.5.2. Diagramme de séquence "Détermination du nombre de transitions" : . 594.5.3. Diagramme de séquence "Détermination du nombre des procédures" : . 604.5.4. Diagramme de séquence "A¢ chage des courbes statistiques" : . . . . . 61

4.6. Réalisation : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.6.1. Interface de con�guration des transitions : . . . . . . . . . . . . . . . . 614.6.2. Interface de personalisation des procédures : . . . . . . . . . . . . . . . 644.6.3. Interface de personnalisation des Anomalies : . . . . . . . . . . . . . . . 644.6.4. Présentation graphique des indicateurs par éléments réseau . . . . . . . 654.6.5. Répartition des causes de HO inter et intra BSC par couple de cellule : 664.6.6. Répartition des Mises à jour de localisation . . . . . . . . . . . . . . . . 68

4.7. Conclusion générale : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Annexe A. Présentation du réseau GSM . . . . . . . . . . . . . . . . . . . . . . 72A.1. Principe du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72A.2. Architecture GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.2.1. La station Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74A.2.2. Le sous-système de station de base . . . . . . . . . . . . . . . . . . . . 74A.2.3. Le sous Réseau Système . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.3. Les interfaces du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

v

A.4. L�interface Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.4.1. Accès radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.4.2. Canaux logiques GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.5. Fonctionnement du réseau GSM : . . . . . . . . . . . . . . . . . . . . . . . . . 81A.5.1. Traitement des appels . . . . . . . . . . . . . . . . . . . . . . . . . . . 81A.5.2. Gestion de la mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Annexe B. Les arcitectures SGBD . . . . . . . . . . . . . . . . . . . . . . . . . 86B.1. L�architecture Client-Serveurs : . . . . . . . . . . . . . . . . . . . . . . . . . . 86B.2. Architectures 3-tiers : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Annexe C. Le language de modélisation UML . . . . . . . . . . . . . . . . . . 89C.1. La syntaxe du langage UML : . . . . . . . . . . . . . . . . . . . . . . . . . . . 89C.2. Les diagrammes UML : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

vi

Table des figures

Figure 1.1. Les actionnaires de Tunsiana . . . . . . . . . . . . . . . . . . . . . . . . 4Figure 1.2. Organisation Générale de Tunisiana . . . . . . . . . . . . . . . . . . . . 4

Figure 2.1. Formalisme des procédures . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 2.2. RNO system (Alcatel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 3.1. Transcodage de la parole au niveau de l�interface A . . . . . . . . . . . . 20Figure 3.2. Echange de Signalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 3.3. Principes d�établissement et de libération d�une connexion SCCP entre

BSC et MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.4. Emplacement de Cigale de Astellia dans le réseau GSM . . . . . . . . . . 26Figure 3.5. Analyseur de protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 3.6. L�environnement de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 3.7. Libération et début de connexion . . . . . . . . . . . . . . . . . . . . . . 29Figure 3.8. Transition lors d�un appel sortant . . . . . . . . . . . . . . . . . . . . . . 32Figure 3.9. Transition de connexion interface A . . . . . . . . . . . . . . . . . . . . . 33Figure 3.10. Transition d�un Appel Sortant . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 3.11. Transition d�un Appel Entrant . . . . . . . . . . . . . . . . . . . . . . . 34Figure 3.12. Transition de Mise à jour de localisation . . . . . . . . . . . . . . . . . . 34Figure 3.13. Les transitions d�un HO intra cellulaire . . . . . . . . . . . . . . . . . . . 35Figure 3.14. Principe d�un handover inter BSC . . . . . . . . . . . . . . . . . . . . . 36Figure 3.15. Transitions d�un HO inter BSC sortant . . . . . . . . . . . . . . . . . . . 37Figure 3.16. Transitions d�un HO inter BSC entrant . . . . . . . . . . . . . . . . . . . 37Figure 3.17. Transitions incrémentant le Drop SD . . . . . . . . . . . . . . . . . . . . 38Figure 3.18. Transition incrémentant la congestion TCH . . . . . . . . . . . . . . . . 39Figure 3.19. Transitions incrémentant le drop TCH . . . . . . . . . . . . . . . . . . . 39Figure 3.20. cellule de transit lors d�un HO . . . . . . . . . . . . . . . . . . . . . . . . 45Figure 3.21. Handover ping pong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Figure 4.1. Use case " traitement des �chier et insertion dans la base" . . . . . . . . 56Figure 4.2. Use case "Interface de con�guration" . . . . . . . . . . . . . . . . . . . . 57Figure 4.3. Use case "courbes statistiques" . . . . . . . . . . . . . . . . . . . . . . . 58Figure 4.4. Diagramme de séquence "Traitement et insertion dans la base" . . . . . 59Figure 4.5. Diagramme de séquence "Détermination du nombre de transitions" . . . 59Figure 4.6. Diagramme de séquence "Détermination du nombre des procédures" . . 60Figure 4.7. Diagramme de séquence "A¢ chage des courbes statistiques" : . . . . . . 61Figure 4.8. Insertion d�une transition . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 4.9. Répartition des causes de Handover . . . . . . . . . . . . . . . . . . . . . 67

vii

Figure 4.10. Répartition des mises à jour de localisation . . . . . . . . . . . . . . . . 69

Figure A.1. Architecture du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . 74Figure A.2. Sous-système Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure A.3. Sous Système Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure A.4. Disposition des Interfaces dans le réseau GSM . . . . . . . . . . . . . . . 78Figure A.5. Canaux physiques simplex . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Figure B.1. Architecture Client Serveur . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure B.2. Architectures 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure C.1. Les régles de modélisation UML . . . . . . . . . . . . . . . . . . . . . . . 91

viii

Liste des tableaux

Table 2.1. Exemples de seuil de quelques indicateurs de QoS . . . . . . . . . . . . . 10

Table 3.1. Fichier XL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Table 3.2. Fichier XLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Table 3.3. Fichier XLF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Table 3.4. Fichier XLU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Table A.1. Caractéristiques de la norme GSM . . . . . . . . . . . . . . . . . . . . . . 73Table A.2. Liste des interfaces dans le réseau GSM . . . . . . . . . . . . . . . . . . . 78Table A.3. Les canaux de commandes . . . . . . . . . . . . . . . . . . . . . . . . . . 81

ix

RésuméCe travail est dans le cadre du projet de �n d�études dans l�école nationale de télé-

communication de tunis.Le but de ce projet est concevoir et développer un outil pour L�évaluation de la qualité

de service du réseau GSM de Orascom Télécom Tunisie et ce en se basant sur la capturedes messages traversant l�interface A. Un moyen qui détient sa �abilité du fait qu�on observedirectement les événements réellement produits au niveau du réseau . Cette solution se basesur l�étude de la machine d�état de l�interface A lieu à partir duquel une vision globale duréseau est possible. Cet outil sert de complémentarité si ce n�est de juge arbitre pour les outilsd�investigation utilisés par l�opérateur GSM.Mots clés: Réseaux GSM, Qualité de Service,machine d�état, Interface A, JAVA, ...

x

Chapitre 1

Introduction Générale

Projet Fin d�Etudes Introduction Générale

1Introduction Générale

1.1 Introduction :

Ces dernières années, la téléphonie mobile a été sans doute le secteur le plus dynamique,

le plus rentable et le plus innovant de toute l�Industrie des Télécommunications. Avec l�essore

rapide qu�elle connaît, elle s�impose de plus en plus comme le moyen le plus privilégié de

communication et conquiert davantage de parts de marché en ciblant tous les pro�les de

consommateurs. Le développement des technologies utilisées et les services et applications

o¤ertes par le mobile ont contribué à la création d�un environnement propice à la concurrence

incitant ainsi les opérateurs à se soucier de la qualité de leurs prestations et des performances

de fonctionnement de leurs réseaux et infrastructures.

Il s�avère donc que la qualité, dans ce domaine comme dans beaucoup d�autres, constitue

une source importante de di¤érenciation, à moyen terme, sans doute 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 l�observation permanente de l�état de fonctionnement du réseau et de toutes les

performances réalisées et par conséquent, l�utilisation d�outils d�ingénierie adaptés.

HADJ TAÏEB Mohamed 2


Dans cette optique, la supervision de la QoS (Quality of Service) au sein du réseau oc-

cupe une importance majeure sur le plan d�optimisation d�un réseau GSM et dans la prise

de décision. Cependant, la supervision de ce réseau est une tâche assez délicate vu l�aspect

dynamique de l�architecture du réseau et de la con�guration de ses di¤érents éléments et l�hé-

térogénéité des outils de supervision et des bases de données des performances du réseau. En

e¤et, la supervision repose sur la suivie de l�historique des performances et la véri�cation des

con�gurations hardware et software des éléments du réseau a�n de dégager les problèmes et

d�en déduire les actions nécessaires à entreprendre.

Le Département d�opération et de maintenance de l�opérateur de la téléphonie mobile

ORASCOM TELECOM TUNISIE a été conscient de cette problématique et s�est investi à

réaliser un système d�information regroupant et centralisant les di¤érentes données de tous

les outils de supervision utilisés et permettant les analyses des performances du réseau et les

détections automatiques des anomalies.

1.2 Cadre Générale de travail :

1.2.1 Société d�accueil :

ORASCOM TELECOM TUNISIE est le premier Opérateur GSM privé en Tunisie, c�est

une société anonyme au capital de 330 millions de dinars ayant acquis en mai 2002 la deuxième

licence tunisienne de téléphonie mobile. Cette licence est de durée de 15 ans et renouvelable

2 fois pour 5 ans.

Grâce à ses valeurs, ORASCOM TELECOM TUNISIE a réalisé son lancement commercial

le 27 décembre 2002, et, six mois plus tard, couvrait déjà 60% de la population. La couverture

s�est étendue à 90% de la population dans le courant de l�année 2004. Actuellement, une fois

que la couverture a atteint son comble l�objectif de l�OTT est de satisfaire les exigences de ses

clients, de plus en plus nombreux, en matière de qualité et de services.

Son action se nourrit de quatre valeurs fondatrices : orientation client, professionnalisme,

transparence et innovation, et, s�inscrit dans sa vision stratégique : «fournir le meilleur, pour

une satisfaction totale et durable de ses clients, et dans le cadre de partenariats solides » .

Acteur essentiel du secteur des nouvelles technologies, ORASCOM TELECOM TUNISIE



s�appuie sur les progrès rapides de la technique pour développer des services adaptés, inno-

vants et de qualité. ORASCOM TELECOM TUNISIE possède à présent deux actionnaires :

Orascom Telecom et Watanya. La �gure 1.1 présente la situation de ces deux actionnaires.

Fig. 1.1. Les actionnaires de Tunsiana

1.2.2 Directions :

Les Directions de Tunisiana sont réparties selon la �gure 1.2 :

Fig. 1.2. Organisation Générale de Tunisiana

Ce projet est réalisé au sein de la Direction Technique (DT). Cette Direction est composée

de trois départements :



� Département d�Architecture et Déploiement ;

� Département d�Ingénierie et Développement ;

� Département d�Opération et de Maintenance.

J�ai intégré dans ce travail l�équipe Qualité de Fonctionnement chargée du suivi de la QOS

du réseau. Ma tâche vise à enrichir les méthodes d�investigation de cette équipe en focalisant

le suivi sur le �ux de messages interceptés au niveau de l�interface A entre les parties BSS et

NSS.

Et ce par la réalisation d�une application permettant une meilleure exploitation des données

contenues dans les �chiers de trace relatifs à cette interface et fournis périodiquement à l�équipe

QDF.

1.3 Présentation Générale du Projet :

1.3.1 Intitulé du projet :

Le présent projet s�intitule : « Suivi des Performances du réseau GSM à partir du �ux de

messages captés au niveau de l�interface A » .

1.3.2 Travail Demandé :

Ce projet consiste à la conception et la réalisation d�une application permettant de déter-

miner la qualité du réseau GSM en investiguant au niveau de l�interface A. Cette application

suit les étapes suivantes :

� Traitement et formatage des �chiers semi brute et stockage dans une base de données.

� Spéci�cations de certains compteurs à partir de ces �chiers.

� Détermination des valeurs de certains KPI tout en gardant un historique pour suivre

leur évolution au cours du temps.

� Interfaçage pour une exploitation conviviale de l�application.

� Réalisation d�un rapport contenant des courbes et des diagrammes.



1.3.3 Méthodologie utilisée :

Le recours à la modélisation est depuis longtemps une pratique indispensable au dévelop-

pement logiciel, car un modèle sert à anticiper les résultats du codage : c�est en e¤et une

représentation abstraite d�un système qui permet d�en faciliter l�étude et de le documenter.

Aujourd�hui, le standard industriel de modélisation est UML (Uni�ed Modeling Lan-

guage). UML se dé�nit comme un langage de modélisation graphique et textuel destiné à

comprendre à décrire les besoins et à esquisser des architectures logicielles et concevoir.

1.4 Conclusion

Ce chapitre constitue une partie introductive dans laquelle le cadre général du projet a

été présenté en premier lieu. Dans un second lieu, les grandes lignes du sujet ainsi que la

méthodologie adoptée ont été précisées. Dans le chapitre suivant on présente l�étude théorique

réalisée sur la notion de la qualité de service de la norme GSM.


Chapitre 2

QoS et mesure des performances

Projet Fin d�Etudes QoS et mesure des performances

2QoS et mesure des performances

2.1 Introduction

L�objectif de ce chapitre est de rattacher le projet à son cadre théorique à rappeler l�éva-

luation de la qualité de service et des performances qui sont des notions fondamentales de la

technologie GSM. En e¤et l�évaluation de l�état du système et la détection des disfonctionne-

ments sont des tâches primordiales pour que l�opérateur puisse avoir une maîtrise sur le réseau

et mener à bien ses actions et interventions de maintenance. Cette section aborde les traits

majeurs de la notion de la QoS avant de présenter la stratégie adoptée par Orascom Télécom

Tunisie pour le suivi de qualité et des performances du système.

2.2 QoS dans les Réseaux Mobiles :

2.2.1 Dé�nition

La Qualité de service est dé�nie dans la recommandation E-800 de l�UIT par un �E¤et glo-

bal produit par la qualité de fonctionnement d�un service qui détermine le degré de satisfaction



de l�usager d�un service �.

Dans le contexte actuel, la Qualité de service est devenue un facteur déterminant pour les

opérateurs de télécommunication qui se sont donc aperçus que la qualité de leurs services et

de leurs prestations doit être constamment contrôlée et suivie d�une part pour connaître l�état

de fonctionnement de leurs infrastructures et d�une autre part pour pouvoir améliorer leurs

compétitivités.

C�est dans ce cadre de concurrence et d�innovation que chaque opérateur s�est doté d�un

ou plusieurs départements de qualité, dont la mission est d�évaluer et de mesurer la qualité

de service dans toutes les parties du réseau.

Critères de la qualité de service :

Les critères sont nombreux mais les critères les plus courants, du côté abonné, sont :

� La couverture : elle est indiquée par les barrettes a¢ chées sur le mobile. La qualité de

la couverture est le critère le plus trivial à partir duquel l�abonné décide ou non de la

bonne qualité du réseau.

� L�établissement d�appel : l�échec d�établissement d�appel ou une longue durée d�établis-

sement d�appel pénalisent le service o¤ert par l�opérateur.

� La qualité vocale : les conditions de propagation radio et les Handover doivent être

transparentes aux abonnés et ne doivent pas in�uer sur la qualité vocale de la commu-

nication.

� La coupure d�appel : c�est un phénomène qui gêne beaucoup les abonnés. En fait, il vaut

mieux échouer à établir un appel que couper l�appel en pleine communication.

2.2.2 Indicateur de qualité de service

Un indicateur est une valeur basée sur un ou plusieurs compteurs et qui est représentatif

des performances du réseau. Les indicateurs de qualité de service BSS ont pour objectifs de :

� Identi�er les défauts dans les éléments du sous système radio et d�établir les actions

correctives pour gérer la qualité de service ;

� Détecter et identi�er les problèmes radio d�une cellule et aider les équipes d�optimisation

radio à analyser la situation et à dé�nir les actions correctives (changement de fréquence,

ajustement d�un paramètre. . .) ;



� Suivre des changements du sous système radio :

� Modèle de tra�c

� Charge du tra�c

� Rendement du réseau

� Gains obtenus en changeant de version software.

� Prévoir le comportement du réseau selon l�évolution du tra�c.

Les indicateurs radio sont établit à partir des compteurs de performance fournit par le

centre d�opération et d�entretient du sous système radio OMC_R. Le OMC_R possède di¤é-

rents types de compteurs qui sont organisés sur 3 classes :

� Compteurs cumulatifs : le compteur est incrémenté à chaque fois où l�évènement compté

aura lieu. Il est réinitialisé quand une nouvelle période est commencée. Il indique juste

le nombre d�évènements qui ont eu lieu dans une période de temps.

� Compteurs statiques : ce sont des données statiques collectées relativement à l�état d�une

ressource spéci�que.

� Evénements d�observations : ce sont des observations sur un événement système. Par

exemple, l�événement channel seizure time for an SDCCH est un compteur d�observation

qui indique le temps et la date quand le SDCCH est mesuré.

Le tableau 2.1 présente un exemple de valeurs seuils pour quelques indicateurs de QoS.

Indicateur Signi�cation SeuilCall Drop Taux de coupure d�appels 2%Call Drop BSS Taux de coupure d�appels pour cause matérielle 1%Call Drop radio Taux de coupure d�appels pour cause radio 2%Call Drop HO Taux de coupure d�appels pendant un HO 1%Congestion TCH Taux de congestion des canaux TCH 2%Congestion SDCCH Taux de congestion des canaux SDCCH 0.5%Succès d�établissement d�appel Taux de succés d�établissemnt d�appels 95%Succès de HO Taux de succès de HO 90%HO sur Better Cell Taux de HO sur Better Cell 50%HO sur qualité Taux de HO sur qualité 30%HO sur niveau Taux de HO sur niveau 20%HO sur intérférence Taux de HO sur interférence 1%

Tab. 2.1. Exemples de seuil de quelques indicateurs de QoS



2.2.3 Problèmes intervenant lors des di¤érentes procédures :

Les di¤érentes procédures (immediate assignment, normal assignment, handover, Directed

retry) ont presque le même formalisme. Le diagrammede la �gure 2.1 décrit les problèmes

intervenants lors de la réalisation de ces procédures.

Début de laprocédure

Demande de canal

Activation du canal

Tentative d’exécution

Succès d’exécution

Phas

e de

prép

arat

ion

Phas

e d’e

xécu

tion

Ressource disponibleau BSC

Succès d’activationdu canal

Le mobile a saisi lecanal

Pas de ressourcedisponible au niveau

BSC

Échec d’activation ducanal

Échec assignementou d’exécution de HO

Échec dans le canalà la phase

d’établissement

Congestion

•Problème BSS•Problème NSS

Fig. 2.1. Formalisme des procédures

a) Problèmes de coupure d�appel :

Ce sont les problèmes les plus gênant du côté de l�abonné. Les di¤érentes causes de ce

problème sont les suivantes :

� Coupure pour cause BSS : Ce genre de problème nécessite l�intervention de l�équipe

OMC pour véri�er si les coupures sont causées par une défaillance matérielle interne au

BSC ou si c�est un problème de transcoder.

� Coupure pour cause Handover : si la tentative de handover échoue et si le mobile ne

réussit pas à reprendre son ancien canal, l�appel est coupé.

� Coupure pour défaillance radio : l�appel est coupé suite à un problème de l�interface air.

Les causes peuvent être :

� � Une mauvaise couverture de la cellule si la plupart des handover se font sur qualité



ou sur niveau ;

� Une ou plusieurs fréquences de la cellule sont interférées ;

� Un problème avec les aériens de la cellule (antenne, câbles feeder. . .), surtout si

le handover se fait pour la plupart du temps sur niveau de champ du lien montant.

b) Problèmes d�échec de handover :

Pour l�échec des handover sortant : Au cas où l�échec est lors de la phase de préparation

les causes peuvent être :

� Les cellules cibles sont congestionnées

� Connexions défectueuses sur les interfaces A au cas d�un handover inter-BSC ;

Dans le cas où l�échec se situe à la phase exécution (échec de handover sur les canaux

alloués) la cause est l�échec radio ou BSS sur la cellule cible. Dans ce cas le mobile retourne

à son ancien canal, l�appel n�est pas coupé mais le handover a échoué.

c) Problèmes d�échec d�établissement d�appel :

Si une cellule présente un échec d�établissement d�appel on doit véri�er un ensemble de

point pour dégager les causes :

� Si la zone est bien couverte, on doit véri�er si la cellule est congestionnée (congestion

TCH ou SDCCH) ;

� Si le taux de coupure de canaux SDCCH est élevé on véri�e les causes du handover ;

� S�il n�y a pas de drop SDCCH, on véri�e le taux d�échec d�établissement du lien TCH

Les causes peuvent être un échec BSS (panne matérielle) ou un échec radio.

2.3 Mesures des performances

2.3.1 Organisation de mesures des performances

Les mesures de performances peuvent être classées sur la base des informations qu�elles ap-

portent en cinq grandes classes bien que nous verrons plus loin d�autres critères de classement.

Ainsi, on relève :

� Mesures relatives à la correction et la détection des erreurs (Error Detection and Correc-

tion measurement) : Pendant la phase de plani�cation, les sources d�erreurs, comme par

exemple les phénomènes d�interférences, sont multiples mais aussi pas évident à prévoir.



Les mesures de performances permettent la détection de ces erreurs. Les indicateurs

suivant sont d�une grande utilité dans ce contexte : Call Setup Failure Rate, Call Drop

Rate, Handover Failure Rate, Immediate Assignment Failure Rate.

� Mesures relatives à la charge de tra�c écoulé (Tra¢ c Load Measurement) : Les mesures

de la charge de tra�c établies dans une cellule ou dans out le réseau o¤rent des données

indispensables pour améliorer l�exploitation des canaux et des ressources radio. Les in-

dicateurs suivant sont d�une grande utilité dans ce contexte : TCH tra¢ c load (tra¢ c

o¤ered, tra¢ c carried, tra¢ c lost), SDCCH tra¢ c load (tra¢ c o¤ered, tra¢ c carried,

tra¢ c lost), Access Grant Channel Congestions, CCS7 Load, Number of call setups,

Number of Handovers, Number of location updates.

� Mesures relatives à la disponibilité des ressources (Resource Availability Measurement) :

Grâce à cette catégorie de mesures, il est possible de gérer et de connaître la disponibilité

des ressources radio et de connaître à tout moment si des ressources sont actives ou

inactives. Les indicateurs relatives aux entités suivantes sont d�une grande utilité dans

ce contexte : Tra¢ c channels (TCH), Slow Dedicated Control Channels (SDCCH), BSC,

BTS, TRX, SS7Links, PCM connections.

� Mesures relatives à la qualité de service (Quality of Service, Grade of Service) : Connaître

la qualité de service permet de fournir aux abonnées de façon instantanée une bonne

qualité de communication. Les mesures de performances permettent donc de trancher

sur la qualité des services fournis par l�opérateur. Les di¤érentes mesures et combinaisons

de mesures mises en ouvre dans l�appréciation de la QoS seront traitées plus loin.

� Mesures à usage statistique (Statistic Data) : Les mesures de performances peuvent

être très utiles pour le service Marketing de l�opérateur. Ainsi, sur la base des données

fournies par les mesures, l�opérateur peut modéliser le comportement de ses abonnées ;

à titre d�exemple, si les mesures présentent des périodes à bas tra�c téléphonique, il

sera intéressant de lancer des promotions incitant les clients à communiquer pendant

ces mêmes périodes. La même procédure peut s�appliquer si on raisonne sur les zones de

couvertures au lieu des périodes.



2.3.2 Méthodes de mesures de la QoS

D�après la perspective de l�opérateur, les méthodes permettant de mesurer la qualité du

service sont :

� L�observation de la qualité de service par des moyens extérieurs : généralement, les

opérateurs mènent des compagnes de mesure de la qualité du lien radio grâce à des

outils spéci�ques parmi lesquelles on cite les Drive test réalisés au moyen du TEMS

d�Ericsson.

� L�utilisation d�appels d�essais (tra�c simulé).

� L�observation automatique interne : L�analyse des performances du réseau GSM se fait

sur la base des �chiers de mesures brutes importés à partir de l�OMC-R. En e¤et, les

mesures sont activées au niveau de l�OMC sous formes de jobs qui créant plusieurs

instances de compteurs correspondant à divers objets de mesures (BTS, BSC, TRX,

SS7 link..) s�incrémentent à chaque nouvel événement (on sous-entend par événement

un message échangé entre deux noeuds du réseau MS, BTS, BSC ou MSC).

2.4 Etude de l�existant

2.4.1 Outils Fournisseurs

OTT dispose d�un ensemble d�outils fournis par les deux constructeurs Alcatel et Siemens

permettant d�explorer les di¤érentes données du réseau. Les principaux outils sont RNO et

SPOTS.

2.4.1.1 RNO d�Alcatel

L�outil RNO (Radio Network Optimisation) est un logiciel de gestion des équipements

ALCATEL qui permet le management en temps réel de tout le réseau. Outre les fonctionnalités

classiques à savoir la gestion des alarmes, le suivi et la con�guration des composants physiques

et logiques du réseau, ce logiciel permet :

� Une analyse totalement informatisée des mesures de performance.

� La visualisation et l�export des données sur la con�guration software et hardware du

réseau.



� La détection des problèmes liés à la qualité de service du réseau et la localisation des

questions les plus urgentes.

� Le choix des actions correctives à entreprendre pour améliorer la QoS.

� L�optimisation de la recherche des ressources radio.

Cependant RNO présente un ensemble de limitation qui se résume dans les points suivants :

� Une limite au niveau du nombre de licence.

� Il est Opérationnel que pour un seul constructeur à savoir Alcatel.

� Il présente un retard au niveau de l�import des données, ce qui oblige parfois les ingé-

nieurs à utiliser d�autres outils.

Le schéma synoptique d�un tel système est donné par la �gure 2.2 :

Fig. 2.2. RNO system (Alcatel)

2.4.1.2 SPOTS :

L�outil SPOTS de SIEMENS permet de :

Traiter les données par famille de compteurs NSS, BSS, BTS.



� Fournir des rapports de QoS.

� Détecter les problèmes du réseau par la con�guration d�alerteur de QoS à temps réel.

Les principaux problèmes à SPOT se résument dans les points suivants :

� Une manipulation di¢ cile de l�interface et des outputs.

� Un outil opérationnel que pour un seul constructeur à savoir SIEMENS.

� Pas de traitement par Heure de Pointe.

� Pas d�édition de zones.

2.4.2 Outils Opérateur :

OTT dispose de plusieurs outils développés au sein de ses di¤érents services techniques.

Les

principales sont les suivantes :

2.4.2.1 OTT PERF SIEMENS et OTT PERF :

Ce sont deux outils séparés mais qui permettent une même représentation graphique des

indicateurs de performance avec une cadence de traitement variable (jour, heure et heure de

pointe).

L�interface présente une facilité d�interprétation mais une limite au niveau de la richesse

d�information puisque seul quelques indicateurs sont utilisés. Ces outils ne permettent pas

d�exporter les données ni d�alerter en cas de défaillance en matière de QoS.

2.4.2.2 Outil Suivie cellule :

C�est un outil développé pour combler �a une partie des inconvénients de OTT PERF

SIEMENS et OTT PERF à savoir l�import de données, la présentation des graphes sur la même

interface et l�alerte quotidienne mais cet outil ne permet pas une exploitation de données avec

une cadence par heure et manque aussi le traitement de certains indicateurs de performances.

2.4.2.3 OTT Parm :

C�est un outil permettant de donner à l�utilisateur les di¤érents paramètres de design et

les paramètres logiques des cellules et les di¤érentes relations d�adjacences.



2.5 Conclusion :

Les outils utilisés par l�équipe qualité présentent des fonctionnalités di¤érentes. Cette di-

versité permet certes d�apporter une richesse au niveau des informations nécessaires aux in-

génieurs qualité pour e¤ectuer les suivis journaliers. Mais elle ne permet pas de présenter une

vision objective de ce qui se passe réellement dans le réseau vue que les résultats présentés

sont fortement in�uencés par la perception du fournisseur et par sa dé�nition propre pour

les indicateurs. A�n d�avoir une idée plus rationnelle, plus globale et surtout plus objective

et de véri�er la cohérence entre les rapports fournisseurs et les performances du réseau on se

propose de redé�nir nos propres indicateurs et ce à partir de ce qui se passe réellement dans le

réseau et pouvant bien sûr être perçu au niveau de l�interface A. Donc notre solution se base

comme nous l�avons mentionné sur le �ux de message intercepté au niveau de l�interface A. De

ce fait il est judicieux de faire une approche théorique sur cette interface tout en spéci�ant les

couches protocolaires mises en jeu. Cette étude nous servira après, c�est-à-dire lors de l�analyse

des messages captés à ce niveau du réseau GSM, et lors de la spéci�cation certains indicateurs

à partir de ce �ux.


Chapitre 3

Etat de l�Art

Projet Fin d�Etudes Etat de l�Art

3Etat de l�Art

3.1 Introduction

Durant le cycle de vie d�un réseau de communication mobile, la notion de qualité de service

et la notion de performance sont vitales. Il est donc essentiel à l�opérateur de mesurer et de

prévoir un mécanisme lui permettant l�évaluation de la qualité et des performances de son

réseau. C�est pour cette raison que dans ce chapitre nous avons dé�ni la notion de la QoS

dans les réseaux mobiles en se basant sur la recommandation de l�IUT avant de présenter les

principales méthodes et les di¤érents moyens de mesures de ce facteur à Tunisiana.

Ces outils se basent principalement sur les messages échangés au niveau de l�interface radio

par conséquent ils ne permettent pas de fournir une observation globale sur tout le BSS. En

plus ces dispositifs sont conçus par les fournisseurs soit SIEMENS soit ALCATEL et par

conséquents les indicateurs conçus dépendent fortement de leur vision.

Pour cette raison un moyen plus �able d�investigation serait de déterminer la QoS en

observant directement �ux intercepté au niveau de l�interface A ce qui permettra d�avoir une

visibilité globale sur le réseau que ce soit coté réseau que coté radio.



3.2 Description de l�interface A

3.2.1 Présentation

Du point de vue physique, l�interface A est une interface terrestre constituer d�une ou

plusieurs liaisons MIC entre le BSC et le MSC, chacune d�entre elle supporte une capacité de

transmission de 2 Mbps. Le transcodeur (TRAU), situé bien évidement entre le MSC et le BSC

pour l�adaptation en capacité des canaux de transmission, doit être pris en considération lors

de l�examen de cette interface. Par conséquent, l�interface A peut être séparé en 2 parties : la

première partie est entre le BTS et le TRAU, où les données transmises sont encore compressées

(canaux de 16 Kbps). La seconde partie est entre le TRAU et le MSC. Le tra�c de données

occupe toutes les 64 Kbps du canal. La �gure 3.1 montre comment se fait le transcodage au

niveau de l�interface A.[AST02b]

Fig. 3.1. Transcodage de la parole au niveau de l�interface A



3.2.2 La signalisation dans l�interface A

L�interface A se situe entre le sous-système radio (BSS) et le sous-système réseau (NSS).

A travers cette interface transitent de nombreux messages de signalisation. Cette signalisation

s�appuie sur les protocoles des couches MTP et SCCP du système de signalisation n�7 du

CCITT, et aussi sur les protocoles BSSMAP et DTAP pour les couches les plus hautes qui

sont propres à la norme GSM.

Par conséquent, le MSC n�est pas seulement relié aux di¤érents BSC par des circuits de

parole mais également par des canaux sémaphores directs : des Intervalles de Temps (Time

Slot) sont donc réservés à la signalisation. Dans la �gure 3.2 on présente les piles protocolaires

des di¤érents composants du réseau GSM y compris bien sûr celle qui régit le �ux de message

au niveau de l�interface A.

Fig. 3.2. Echange de Signalisation

3.2.2.1 Le réseau de signalisation N�7

Ce système de signalisation par canal sémaphore normalisé par le CCITT permet de séparer

la signalisation de la transmission en faisant transiter la signalisation sur un canal spéci�que.

De ce fait, on peut échanger des messages de signalisation sans établissement réel de circuit

de communication.



Les avantages de la signalisation sémaphore sont :

� La possibilité de transférer de la signalisation pure indépendamment de l�établissement

d�un circuit.

� La réduction des délais de transfert de la signalisation et diminution du temps d�occu-

pation ine¢ cace des circuits.

� La possibilité de transférer la signalisation à fort débit pendant une communication sans

que l�utilisateur soit gêné.

� La possibilité de réserver les circuits pour un appel seulement lorsque le correspondant

demandé est réellement joignable.

3.2.2.2 Message Transfert Part (MTP) :

Le MTP o¤re un service de transfert �able des messages de signalisation. Il est divisé en

trois niveaux (MTP1, MTP2, MTP3) proches des trois premières couches du modèle OSI :

� MTP1 couche physique : dé�nit les caractéristiques physiques, électriques et fonction-

nelles d�une liaison physique (liaison sémaphore de données dans le vocabulaire SS7) et

les moyens d�y accéder. On utilise le plus souvent des conduits numériques à 64 kbit / s.

� MTP2 procédures d�acheminement des données sur une liaison : dé�nit les fonctions et

les procédures de transfert des messages de signalisation de façon à fournir un transfert

�able entre deux points. Ce niveau est comparable à la couche liaison de données du

modèle OSI. Les données échangées sont des "trames sémaphores". Le protocole utilisé

contient un mécanisme de contrôle du �ux, de détection d�erreur et de correction par

retransmission. Par conséquent, le MTP2 comporte un mécanisme de surveillance du

taux d�erreur sur la liaison sémaphore.

� MTP3 routage et contrôle : dé�nit les fonctions et les procédures de transfert de mes-

sages entre les n�uds du réseau sémaphore (PS ou PTS). Il comprend deux fonctions :

orientation des messages de signalisation et gestion du réseau sémaphore.

3.2.2.3 Signaling Connection Control Part (SCCP) :

A l�encontre du MTP avec ses 3 couches, qui est responsable du transport et l�achemine-

ment entre 2 n�uds du réseau, le SCCP o¤re un adressage de bout en bout, même à travers



les n�uds et les pays du réseau. Il faut aussi noter que une connexion SCCP par MS est

nécessaire pour toute procédure sur le réseau. Et en voici les étapes �gure 3.3 :

Fig. 3.3. Principes d�établissement et de libération d�une connexion SCCP entre BSC et MSC

3.2.2.4 BSS Application Part :

Au dessus des couches MTP et SCCP, on trouve le BSSAP (BSS Application Part). Cette

couche est formée de deux sous-couches : la sous-couche BSSMAP et la sous-couche DTAP.

Entre le BSC et le MSC transitent deux types de messages :

� les messages interprétés par le BSC qui ont trait à la gestion des ressources radio (sous-

couche BSSMAP)

� et les autres messages qui sont en fait échangés entre le mobile et le MSC (sous-couche

DTAP) : dans ce deuxième cas, le BSC joue le rôle de répéteur. Une "fonction de

distribution" permet d�orienter les messages vers la couche BSSMAP ou DTAP.

a) Le BSSMAP (BSS Management Application Part)



Le protocole BSSMAP spéci�e le dialogue pour les messages véritablement générés ou inter-

prétés par le BSC. Ses messages peuvent être classés en deux catégories : ceux qui concernent

un BSC et ceux qui sont liés à un canal radio dédié particulier.

Pour la première catégorie, les messages générés utilisent le SCCP en mode non connecté

et concernent :

- la mise hors service de circuits de parole entre le BSC et le MSC

- l�interrogation des ressources disponibles au BSC

- la réinitialisation du MSC ou du BSC

- l�appel en di¤usion d�un mobile sur une zone de localisation donnée

- la suggestion faite au BSC de transférer si possible des communications depuis une cellule

désignée vers une liste donnée de cellules.

Pour la seconde catégorie, les messages envoyés utilisent le SCCP en mode connecté et

concernent :

- la remise au MSC du message initial du mobile émis sur canal radio dédié

- l�allocation d�un canal radio TCH

- l�exécution d�un handover

- le passage en mode chi¤ré

- la libération du canal radio dédié[Hei99]

b) Le DTAP (Direct transfert Application Part) :

Le protocole DTAP gère des échanges de messages entre le mobile et le MSC passant par le

BSC. Ce dernier réémet tous les messages reçus sans aucune interprétation. Le DTAP utilise

le SCCP en mode connecté.

Un message DTAP appartient à l�une des classes suivantes :

- RR (Radio Ressource management) : La couche RR permet l�établissement, le maintien

et la libération de canaux radio dédiés. Elle gère également le handover et le chi¤rement.

Cette couche est présente au niveau du mobile et du BSC. Toutefois, deux messages peuvent

apparaître au MSC (transitant à l�interface A) :

- MM (Mobility Management) : La couche MM permet de remplir les fonctions suivantes :

la localisation de l�abonné, l�authenti�cation, l�allocation de TMSI (identi�ant temporaire de

l�abonné mobile), l�établissement d�une transaction CM d�origine MS, la synchronisation pour



les niveaux supérieurs, la surveillance de l�activité de l�infrastructure, le rétablissement de

communication

- CM (Call Management). Cette couche est découpée en trois sous-couches : CC (Call

Control), SMS (Short Message Service) et SS (Supplementary Services).

3.3 Cigale de Astellia outil de suivi de l�interface A :

3.3.1 Présentation de Cigale

Une opération rationnelle et e¢ cace pour réseau radio cellulaire type GSM nécessite un

certain nombre d�outil de surveillance et de diagnostic. Ces outils permettent d�identi�er

rapidement les problèmes qui puissent a¤ecter la qualité globale du réseau donc une solution

peut être trouvée.

Les outils d�opération et de maintenance fournis avec les équipements dans le but de

répondre aux exigences du standard GSM en matière de supervision se sont avérés insu¢ sants

dans certains cas où une analyse doit être réalisée avec degré de détail élevé.Dans ce cadre se

rattache l�avènement de Cigale un outil de capture protocolaire dans l�interface A.

L�outil Cigale conçu par Astellia, une société spécialisée dans la conception de solutions

matérielles et logicielles dédiées à l�optimisation des performances des réseaux de téléphonie

mobile. Elle a signé un contrat avec la compagnie de communication Tunisiana qui stipule

de livrer de nouveaux matériels de mesure à cette entreprise. En plus elle lui apporte des

plates-formes de capture ainsi que sa licence Cigale GSM, logiciel d�analyse de la qualité de

services.

Cigale a été développé dans l�objectif de compléter et améliorer le potentiel d�investigation

dans le réseau GSM. Il est insérer dans le réseau GSM en se plaçant au niveau de l�interface

A. La �gure 3.4 montre son emplacement dans le réseau GSM :[AST02a]

L�outil cigale peut être décrit comme étant un « espion » in�ltré dans le réseau GSM

au niveau de l�interface A qui permet d�analyser en mode « store and forward » les trames

protocolaires stocké par un enregistreur placé dans les canaux de signalisation. Les plateformes

de capture actuellement utilisées sont SIEMENS K1103 et OCEAN de Edixia. Cigale se résume

à un analyseur de protocole, un équipement de mesure qui se connecte entre 2 dispositifs



Fig. 3.4. Emplacement de Cigale de Astellia dans le réseau GSM

système pour intercepter le tra�c de données numériques entre ces deux derniers comme c�est

indiqué dans la �gure 3.5 .

Fig. 3.5. Analyseur de protocole

3.3.2 Mode de fonctionnement de Cigale :

Cigale a été implémenté dans le but de permettre l�amélioration des di¤érents compo-

sants qu�il traite : analyseurs, protocoles, messages, etc., et la paramétrisation des résultats

statistiques. Cigale assure entre autres les fonctions suivantes :



� Détection automatique des interfaces A sans avoir à con�gurer la connexion de l�analy-

seur.

� La gestion de di¤érents types d�analyseurs par le biais de �chiers DLL externes.

� Paramétrisation des transitions de la machine d�état et des statistiques associées.

� Génération des statistiques XL3 dans un format BL3 qui est moins pénalisante en terme

de volume.

� Génération des statistiques relatives au procédures réseau : MOC, MTC, LU, SS, SMS...

� Génération des statistiques associées aux ressources SCCP, CIC et TCH.

� Génération des �chiers (*_R.txt) pour l�application Cigale View.

Le diagramme block de Cigale prend la forme suivante de la �gure 3.6 :

Fig. 3.6. L�environnement de Cigale

L�organisation de traitement de Cigale est la suivante : Cigale décode les �chiers enregistré

(REC �les) dans le but d�extraire les di¤érents messages et les informations associées. Ces

messages sont décodés par couches protocolaires (les niveaux MTP2 et 3, SCCP, BSSAP,

couche 3, SMS, SS..).

Les di¤érents messages permettent d�extraire certaines informations comme : les connexions

SCCP, le types de la connexion courante (MTC, MOC, LU, SMS...).



En outre, dans le but de tracer les changements de connexions, chaque message est en-

voyé à la machine d�état décrite dans 3 �chiers externes (EVENTS.BDT, CAUSES.BDT et

AUTOMAT.BDT). Ainsi chaque message constitue un message qui incrémente une transition

entre l�état courant associé au message et l�état de destination dé�nie pour cette transition

dans le �chier de con�guration de la machine d�état. Ces transitions sont comptées dans le

but de générer des statistiques.

Après avoir détecté la transition de la machine d�état, CIGALE accède au �chier TIMES.BDT.

Ce �chier permet de délimiter les di¤érentes transitions dans le but de généré des statistiques

sur la durée de ces transitions. Pour la mise à jour de localisation, le �chier NETWORK.BDT

contient des informations sur les di¤érents Location Area. Le �chier PHONES.BDT est utilisé

pour déclarer les numéros pour lesquels on veut générer des statistiques particulières.

Le �chier CIGALE.INI contient les di¤érents paramètres et option de l�application comme

par exemple la spéci�cation des �chiers à générer.

Durant le traitement des �chiers enregistrés il est possible de générer les �chiers suivants :

� XL3 : informations de chaque connexion et leur historique ;

� TIM : informations sur les timers associés aux cellules et au BSC ;

� SS : informations associées à chaque message relatif aux services supplémentaires ;

� SMS : informations pour chaque message court ;

� LHO : informations sur les liens HO qui n�ont pas pu être établis ;

A la �n du traitement, les statistiques suivantes peuvent être générées :

� XL2 : Statistiques sur la machine d�état ;

� XLH et XLF : Statistiques sur le �ux de handovers ;

� XLU : Statistiques sur les mises à jour de localisation ;

� XLT : Statistiques sur les ressources SCCP, CIC et TCH.

Et pour �nir le �chier LOG contient les di¤érents messages d�erreurs et d�alertes générés

durant le traitement.



3.4 Exploitation des �chiers Cigale pour le suivi des performancesdu réseau GSM :

3.4.1 Fichier XL2 machine d�état de l�interface A :

3.4.1.1 Dé�nition de la machine d�état :

En général, la machine d�état est un outil qui enregistre le statut d�un certain objet et

qui trace ses changements en spéci�ant l�événement qui en est responsable. Par conséquent

l�étude de la machine d�état est un moyen e¢ cace quand il s�agit de faire le suivi de l�évolution

d�un certain élément. Concernant le projet qui traite l�évaluation de la performance à partir

de l�étude de l�interface A on peut se baser sur le �chier qui stocke toutes les transitions

observées.

Ce �chier se charge de la comptabilisation des changements de la machine d�état en dis-

tinguant entre les di¤érents types de connections (originating calls, terminating calls, location

updates, handovers, etc.) sous forme de transition. Cette dernière est caractérisée par deux

états (origine et destination), un message ou encore un événement, et optionnellement une

cause.

Le �gure 3.7 décrit l�ensemble des transitions possibles en partant de l�état vide du système,

il traite les di¤érents types de connections :

Fig. 3.7. Libération et début de connexion

Ainsi on constate que tout ce qui puisse se produire dans le réseau en partant de l�état

initial « VIDE » est traduit dans le �chier de la machine d�état sous forme de transitions. Et



ce de même pour les di¤érents états pris par le système. Ce qui nous amène à dire que l�étude

de ce �chier est un moyen �able et perspicace quant il s�agit de faire le suivi de la qualité du

réseau. En plus on peut exploiter ces transitions pour déterminer les valeurs des indicateurs de

qualité juste en en spéci�ant la formule. C�est le principe de l�application qu�on va présenter

ultérieurement. Mais avant tout montrant comment on peut exploiter les transitions de la

machine d�état pour l�extraction de certains compteurs.

3.4.1.2 Présentation du �chier XL2 :

Le �chier XL2 est un �chier qui stocke les transitions de la machine d�état. Il traite tout

les BSC du moteur Cigale placé au niveau de l�interface A et leurs cellules. Ces transitions

sont ordonnées séquentiellement de telle façon qu�ils décrivent certaines procédures du réseau

GSM tel que l�établissement d�appels sortants et entrants, les mises à jour de localisation, les

Handovers, l�envoi de messages courts, les services supplémentaires.

Le �chier XL2 est classé par BSC. Ça s�explique par le fait que le MSC et chaque BSC qui

lui est lié dé�nissent une interface A.

Le contenu de ce �chier colonne par colonne est décrit ci-dessus :

� L�état de la connexion au moment où le message traduisant l�événement est reçu ;

� L�événement contenant une extension si le cas le permet ;

� La cause associée à l�événement si elle existe ;

� L�état de la connexion après que le message ne soit reçu ;

� Le nombre total des occurrences de ces événements pour l�état courant.

� Les colonnes suivantes contiennent le nombre d�occurrence de ces événements par cellules

relative au BSC courant.

Ce �chier Trace l�évolution des connexions d�une façon extrêmement détaillée pour chaque

cellule. Voici un exemple du �chier XL2 de la machine d�état de l�interface A voir la table 3.1 :



Tab. 3.1. Fichier XL2

Les données de ce �chier ne sont que la traduction de ce qui vient de se passer dans le

réseau et ce par le biais d�une comptabilisation des messages captés au niveau de l�interface

A. Il permet donc une supervision coté réseau des performances du système car on y trouve

presque toutes les procédures et les actions observées au réseau avec leur cas d�échec de

coupures d�e¢ cacité et de succès.

Voici l�exemple d�un appel sortant établi avec succès comme on peut le déduire à partir

du �chier XL2 �gure 3.8.



Fig. 3.8. Transition lors d�un appel sortant



3.4.1.3 Extraction de certains compteurs à partir du �chier XL2 :

Procédures :

a) Connexion à l�interface A :

La connexion à l�interface A ici veut dire qu�il y a un message qui vient d�être capté au

niveau de cette interface. Cette procédure se produit dans le cas où le mobile qui était en état

de veille va demander (ou recevoir) un service au réseau donc il s�y prépare en établissant

une connexion couche 3 par le message CL3I (Complete Layer 3 information) et ainsi son état

devient CL3I_Sig. L�assignation d�un canal SD est réalisée pour se charger du �ux de signa-

lisation préalable à la procédure GSM. Voici la transition de la machine d�état de l�interface

A qui incrémente cette procédure �gure 3.9 :

Fig. 3.9. Transition de connexion interface A

b) Spéci�cation du service demandé :

Après l�allocation d�un canal SD le mobile demande au réseau un service et spéci�e sa na-

ture que ce soit un appel sortant, entrant, envoi de messages courts, services supplémentaires.

Voici la transition incrémentant le compteur du nombre des tentatives d�établissement d�appel

voir �gure 3.10 . Le même esprit s�applique aux appels entrants voir �gure 3.11 , à l�envoi de

messages courts, aux services supplémentaires.



Fig. 3.10. Transition d�un Appel Sortant

Fig. 3.11. Transition d�un Appel Entrant

c) Mise à jour de localisation :

Il y a 3 cas de mise à jour de localisation dont la transition est décrite par �gure 3.12 :

Normal LU : Chaque fois que le mobile change de zone de localisation.

Periodic LU : Si au bout d�un certain temps le mobile n�e¤ectue pas de mise à jour de

localisation normale.

IMSI Attach : Si le mobile est sous tension tout en se trouvant dans la même ancienne

LAC. S�il trouve un nouveau LAC il s�agit d�une mise à jour de localisation normale.

Fig. 3.12. Transition de Mise à jour de localisation

d) Handover intra cellulaire :

Généralement un handover n�arrive que dans l�une des phase suivante de la procédure d�ap-

pel : assignation, sonnerie, connexion, communication, appel en attente. Ce type de handover

est détectable depuis l�interface A et ce en par l�événement HOPER_IN_CEL �gure 3.13.



Fig. 3.13. Les transitions d�un HO intra cellulaire

On remarque que le statut de la machine d�état de l�interface A reste inchangé. Ceci

s�explique par le fait que ce type de HO se passe d�une façon transparente vis-à-vis de l�interface

A puisque il est contrôlé par le BSC et non par le MSC. Par conséquent cette interface ne

se rend compte que du résultat de la procédure de HO sans y intervenir en voyant passer le

message HO_PERformed. C�est le cas aussi du HO inter cellulaire intra BSC.

e) Handover inter cellulaire intra BSC :

Les transitions sont une copie conforme du cas précédent sauf que l�événement est HO-

PER_IN, inutile de rappeler que pour les HO sortant le message devient HOPER_OUT.

f) Handover inter BSC :

Un handover inter BSC est contrôlé par le MSC donc le �ux de message échangés fait

intervenir 2 interfaces A. Le principe de ce type de HO se résume dans la �gure 3.14 :



MSC(1

) Han

dove

r requ

ired

(4) H

ando

ver re

quire

d

(7) C

lear c

omm

and

(HoS

) (2) Handover request

(3) Handover Request Ack

(5) Handover Detect

(2) Handover complete

BSSOrigine

BSSCible

Response rate

Succes rate

Sortant Entrant

(4)/(1) (3)/(2)

(7)/(4) (6)/(3)

Fig. 3.14. Principe d�un handover inter BSC

Voici les transitions relatives aux di¤érentes phases d�un HO inter BSC sortant �gure 3.15

et d�un handover inter BSC entrant �gure 3.16.



Fig. 3.15. Transitions d�un HO inter BSC sortant

Fig. 3.16. Transitions d�un HO inter BSC entrant

Détection des alertes :

a) Drop SD :

Il faut tout d�abord signaler que la congestion SD n�est pas détectable depuis l�interface

A tout simplement parce que le premier message intercepté au niveau de cette interface est le

CMSREQ qui implique que le canal SD est déjà activé et alloué.

Le drop SD concerne l�interruption de l�état du mobile dédié durant la phase de signali-

sation. Cette phase s�étend depuis l�assignation du canal SD jusqu�à l�assignation du canal



TCH.

Ci-dessous les transitions qui incrémente le compteur du Drop SD �gure 3.17 :

Fig. 3.17. Transitions incrémentant le Drop SD

b) Congestion TCH :

Ce compteur traduit la l�indisponibilité de ressources que ce soit coté radio (Time Slot)

ou coté réseau (MIC). La congestion TCH est détectable. La congestion TCH est détectable

dans la phase d�assignation comme le montre la �gure 3.18.



Fig. 3.18. Transition incrémentant la congestion TCH

c) Drop TCH :

Ce compteur comptabilise le nombre de coupure du canal TCH donc tout disfonctionne-

ment à partir de l�allocation du canal physique TCH (ou les canaux logiques TCH et FACCH).

Voici les transtions qui l�incrémente �gure 3.19 .

Fig. 3.19. Transitions incrémentant le drop TCH



d) Call Drop :

Le Call Drop le problème peut être déduit des transitions précédemment spéci�ées pour

le Drop TCH mais en ne tenant compte que de la phase de communication. Il faut noter que

la coupure d�appel est le problème le plus gênant coté client et ça in�ue intensément sur son

degré de satisfaction.

Le �chier XL2 englobe d�une façon précise tout le �ux de message écoulé coté interface A

donc il permet une vision détaillée et une investigation rigoureuse sur la qualité du réseau.

Cela dit l�extraction d�indicateur de qualité à partir de ce �chier est une tâche fastidieuse car

on doit démêler décompter toutes les transitions pour élire celles qui incrémente le compteur

voulu. C�est pour ça qu�on va étudier dans ce qui suit d�autre types de �chier qui contienne

des données plus ou moins �nalisées : XLT, XLU et XLH.

3.4.2 Fichier XLT :

Ce �chier permet de générer les statistiques sur les ressources à savoir ressources SCCP,

TCH et CIC.

Il comptabilise le nombre d�Erlang supporté par le BSC et par les cellules qui lui sont

liés durant la période d�observation toute en spéci�ant le nombre de ressources maximales

simultanément occupée pendant cette période. Ces ressources sont soit CIC (lien au niveau

de l�interface A) pour les BSC soit TCH pour les cellules.

La seconde Série d�information contient les détails statistiques pour chaque BSC. On y

trouve une première table listant les di¤érents CIC utilisés et pour chacun la durée minimale

maximale et moyenne en spéci�ant le nombre d�allocation et de conversation.

Une deuxième table concerne tout les CIC utilisés par le BSC courant. Elle liste la durée

par nombre d�allocation simultanée (c�est-à-dire pour 20 ressources allouées en même temps

on spéci�e la durée pendant la quelle ces 20 ressources ni plus ni moins reste alloués) ainsi

que la durée totale d�allocation. Cette table �nit par la moyenne du nombre d�allocation de

ressources.

Ensuite on trouve une table similaire relative aux ressources SCCP de ce même BSC. En�n

pour chaque cellule de ce dernier encore une table similaire relative aux ressources TCH.

Voici un exemple du �chier XLT montrant les di¤érentes tables citées ci-dessus table 3.2 .





Tab. 3.2. Fichier XLT



3.4.3 Fichier XLF :

Ce �chier décrit le �ux de handovers. Il consiste en une série de tables relatives à chaque

cellule. Chaque table indique les �ux de handover entrant et sortant pour la cellule désignée

dans la première ligne. La ligne suivante présente les cellules avoisinantes et dans les quelles

un HO a été observé.

Chaque table se compose de 3 parties, une concernant le �ux de HO sortant, une 2ème

pour les entrants et la 3ème pour le �ux de HO ping pong..

3.4.3.1 Le �ux de handovers sortant :

Les colonnes contenus dans cette première partie :

� ULQ : ça correspond au message Handover Performed et Handover Request (cause :

Uplink Quality) : ces handovers sont déclenchés à cause d�une faible qualité dans le sens

montant. Ces HO sont parmi les handovers intra BSC qui ont réussi et inter BSC.

� ULS : Ces HO sont déclenchés à cause d�une faible puissance du signal dans le sens

montant.

� DLQ

� DLS

� D : ça correspond au message Handover Performed et Handover Request (cause Dis-

tance) : Handovers déclenchés quand la distance séparant le mobile à la source devient

importante.

� BC : ça correspond au message Handover Performed et Handover Request (cause :Better

Cell) : déclenché lorsqu�il y a une meilleure cellulede point de vue radio.

� DR : ça correspond au message Handover Performed et Handover Request (cause : Direct

Retry) : déclenché lorsqu�il y a un manque de ressources dans la cellule d�origine.

� XX : ça correspond au message Handover Performed et Handover Request (cause : other

causes : déclenché pour autres raisons que celle présentées ci-dessus.

� Tx rep : ça correspond au pourcentage du nombre des handovers inter BSC à exécuté

(message HOCMD : HO CoMmanD ) par rapport au nombre des HO sortants demandés

(message HORQD : HO ReQuireD). C�est le taux de réponse de la part de la cellule



cible au demande de HO inter BSC de la part de la cellule étudiée. Voir la �gure 4.14

qui montre le �ux de messages échangés lors d�un HO inter BSC.

� Tx failed : indique le complément à 100% du pourcentage des handovers exécutés avec

succès (message Clear Command avec la cause Handover Successful) par rapport au

nombre des handovers à exécuter : cette colonne spéci�e le taux d�échec durant la phase

d�exécution.

Les colonnes suivantes concernent les durées d�exécution des HO inter-BSC. La durés

mesurées est entre l�envoi du message handover command (HOCMD :du MSC vers le BSC)

et le message Clear Command cause Handover successful (CLCMD (HoS) : du MSC vers le

BSC). Ça correspond à la durée durant laquelle le mobile peut accéder au nouveau canal de

tra�c qui lui est alloué.

� Avg duration : durée moyenne ;

� Max duration : durée maximale ;

� Min duration : durée minimale ;

� Num HO : représente le nombre de handovers pour lesquels il est possible de mesurer le

temps d�exécution.

3.4.3.2 Flux de messages des handovers entrants :

Cette deuxième partie, relative au �ux de handover entrant à la cellule examinée, comprend

des colonnes similaires à ceux de la première partie. La seule di¤érence à noter réside dans les

mesures de la durée d�exécution de handover. Pour les HO entrants la durée est mesurée entre

le message Handover Request acknowledge (HOREQ ack du BSC vers le MSC) et le message

Handover Complete(HOCMP du BSC vers le MSC). Ça correspond à la durée nécessaire pour

que le mobile accède au nouveau canal de tra�c alloué.

3.4.3.3 Flux de message des handovers ping pong :

� HO-HO Out : représente le nombre de handovers sortants de la cellule à examiner pour

des connexions qui ont déjà eu un handover indépendamment de ce qu�est l�ancienne

cellule. Donc ça représente le nombre de fois qu�une connexion ait transité (entrant et



sortant par HO) en ayant la cellule à examiner comme cellule de transit. Voir la �gure

suivante 3.20.

Fig. 3.20. cellule de transit lors d�un HO

� HOPPG : ce sont les HO-HO(<NN s) pour lesquels la cellule cible est la même que

la cellule source du handover précédent. Ce sont les handovers « ping pong » . Les

colonnes ULQ, ULS, DLQ, DLS, D, BC, DR et XX indique les pourcentages de chaque

cause handover ping pong par rapport au total au nombre de HO ping pong pour le

couple de cellules concernées. Voir la �gure 3.21 :

Fig. 3.21. Handover ping pong

Voici un exemple du �chier XLF présentant les di¤érents champs spéci�és ci-dessus Table

3.3.



Tab. 3.3. Fichier XLF



3.4.4 Fichier XLU :

Le �chier XLU contient les détails sur les mises à jour normales et périodiques et les causes

des rejets des mises à jour de localisation.

Ce �chier contient 2 tables : la première est classée par réseau de l�abonnée et la deuxième

par ancien LAC. Pour chaque ligne on trouve les champs suivants :

� Le LAC de l�ancienne zone de localisation ;

� Le réseau origine de l�abonné (quand le IMSI est demandé durant la mise à jour de

localisation) ;

� Le nombre des mises à jour de localisation normales demandées ;

� Le nombre de mises à jour de localisation normales demandées réussies ;

� Le nombre des mises à jour de localisation rejetées ensuite détaillées en spéci�ant la

cause ;

� Le nombre des mises à jour de localisation demandées ;

� Le nombre des mises à jour de localisation qui ont été interrompus suite à un problème

radio ;

� Le nombre des mises à jour de localisation rejetées avec la cause : PLMN Not Allowed,

Network Failure, Invalid Mandatory Inforamion, Other Causes ;

� Le nombre de demande de mise à jour de localisation périodique ;

� Nombre de mises à jour de localisation périodiques réussies

� Nombre de mises à jour de localisation périodiques rejetées.

Et voici un exemple du �chier XLU table :



Tab. 3.4. Fichier XLU



3.4.5 Les indicateurs déduits de l�interface A :

3.4.5.1 Tra�c et Occupation des ressources :

� Nombre d�Erlang pour chaque BSC et le nombre maximum de ressources occupées. De

même pour chaque cellules de ce BSC.

� Durée moyenne, maximale et minimale d�allocation et de conversation avec leurs nombres

respectifs pour chaque CIC, PCM et Atermux.

� Durée cumulée d�occupation des ressources CIC et SCCP ainsi que nombre maximal de

prise et le nombre moyen de ressource occupé.

� Durée d�occupation des ressources TCH par nombre de prise ainsi le nombre moyen

d�occupation de ces ressources. Et ce pour chaque cellule du BSC.

3.4.6 Indicateurs de qualité de service :

a) Canaux SDCCH et TCH :

� Taux de coupure SDCCH : un canal SDCCH doit être établi avant toutes transactions

OC, TC, LU,...

� Taux d�échec d�assignation pour congestion : taux de TCH non alloué durant la phase

d�assignation pour congestion soit coté interface radio soit coté réseau.



� Taux d�échec assignation de TCH : taux d�échec d�obtention d�un canal TCH (congestion,

HO et radio Failures)

� Taux de coupure TCH : Taux des TCH coupés pour les problème système, radio, han-

dover, préemption parmi le nombre d�appel établi dans la cellule.

b) Statistiques sur les appels :

� Taux de coupure d�appel : le rapport des appels coupés par rapport aux appels qui ont

réussi à s�établir.

� Taux d�appels établis avec succès : taux des appels qui aboutissent à l�assignation d�un

canal TCH avec succès c�est-à-dire non interrompu ni par un SDDCH Drop ni par un

Assignement failures.

� Taux d�appel réussis : taux des appels qui se termine normalement (Normale Release)

qui ne sont interrompu ni par un SDDCH DROP ni par un Assignment Failures et ni

par une coupure d�appel.



c) Statistiques sur les Handovers :

� Les causes des Handovers : présenter la distribution des tentatives des handovers par

causes UL/DL Qualité, UL/DL niveau, UL/DL Interférence, Distance, Better Cell.

� Taux de réponse de HO sortant : taux de handovers sortant à exécuter par rapport au

handovers requis dans la cellule.

� Taux de succès de HO sortant : taux de handovers sortants terminés avec succès c�est à

dire il y a une libération du lien par rapport au handovers sortants à éxécuter.

� Taux de réponse de HO entrant : taux de handovers entrants à exécuter par rapport au

handovers demandés de la part d�une autre cellule.

� Taux de succès de HO entrant : taux de handovers entrants terminés avec succès au

niveau de la cellule par rapport au handovers entrants à éxécuter.

d) Statistiques sur les mises à jour de localisation :

� Taux de mise à jour de localisation normale/périodique rejetée, réussi, ayant des pro-

blèmes radio.

� Distributions des causes de rejet des mises à jour de localisation normale :

PLMNNA : Public Land Mobile Network Not Allowed ;

IUH : IMSI Unknown HLR ;

LANA : Location Area Not Allowed ;

INF : Invalid Number Format ;

IMEINA : IMEI not Allowed ;



IMI : Invalid Mandatory Inforamtion ;[Alc03]

3.5 Conclusion

Dans ce chapitre nous avons étudié les spéci�cités de l�interface A. On a précisé son empla-

cement, son rôle dans le réseau, la couche protocolaire qui la régisse et en�n le �ux de messages

qui la traverse. Cette étude nous a permis de d�exploiter les �chiers de capture décrivant les

échanges de données au niveau de cette interface qui permet une vision globale du réseau.

Dans une étape ultérieure de ce chapitre nous avons étudié avec précision le contenu de

ces �chiers avant d�en extraire certains indicateurs de qualité.

Dans le chapitre suivant on va mettre en pratique cette étude en concevant et en réalisant

un outil de traitement de ces �chiers et d�exploitation de leur contenu.


Chapitre 4

Conception et réalisation

Projet Fin d�Etudes Conception et réalisation

4Conception et réalisation

4.1 Introduction :

La phase de conception est sans doute la phase la plus délicate du projet puisqu�elle in�uera

directement les performances et le bon fonctionnement de l�outil développé qui se doit êre

robuste, e¢ cace et �able. En e¤et durant cette phase les éventuelles solutions sont étudiées

et les algorithmes et les traitements à accomplir par l�outil sont �xés ceci permettra de bien

comprendre le but de l�application et les résultants qu�on souhaite avoir.

4.2 Environnement informatique :

�Oracle JDeveloper 10g : C�est un IDE (Integrated Development Environment) Java pro-

duit par la corporation Oracle. Il dispose d�une interface de manipulation simple et

permet la création des interfaces graphiques via Java/Swing. Oracle JDdeveloper sup-

porte aussi le cycle de vie complet du développement avec des moyens de modélisation,

de codage, de debug et de déploiement des applications.



�Microsoft SQL Server 2000 : Microsoft SQL Server 2000 est serveur de base de données

il a la capacité de contenir des base de grande taille.

� Rational Rose Entreprise : Ce logiciel supporte les outils de la modélisation UML. Nous

l�avons utilisé pour tracer les diagrammes des cas d�utilisation et les diagrammes de

séquence. Il o¤re aussi beaucoup des composantes pour la construction des schémas

explicatifs comme les diagrammes de la machine d�état.

� Scienti�c Workplace 5.0 : cet un éditeur Latex qui permet de générer automatiquement

un document sous le format PDF. Nous l�avons utilisé pour la rédaction du rapport.

� Microsoft SQL Server JDBC Driver : JDBC est une API dé�nie par Sun pour permettre

un accès aux bases de données avec Java. Pour pouvoir utiliser JDBC, il faut un pilote

qui est spéci�que à la base de données à la quelle nous voulons accéder. Une fois que

nous avons chargé le nom de la pilote, nous spéci�ons l�adresse du serveur de base de

données, le numéro de port (par défaut 1433) et le nom de la base de données.

� JFreeCharts 1.0.1 : c�est une bibliothèque libre de traçage des courbes destinée pour les

applications Java. Elle peut être utilisée avec Java/Swing (c�est notre cas), les applets

et les servlets. JFreeCharts permet de construire divers types de courbes : courbes de

répartition, courbes combinées, courbes à axes multiples, courbes dynamiques . . . etc.

4.3 Cahier de charge :

� Le cahier de charges prévoit les traitements que doivent accomplir les di¤érents modules

de l�application. Les tâches à réaliser sont :

� Formatage et traitement des �chiers fournis par cigale et leur insertion dans la base de

données.

� Exploitation du �chier XL2 pour la détermination du nombre d�occurrence des transi-

tions de la machine d�état voulues.

� Etude détatillée de ces transitions et de leurs signi�cations

� Dé�nitions des procédures et anomalies communément utilisées pour la supervision du

réseau GSM.

� Convivialiser l�exploitation de ces manipulations en mettant en �uvre une interface

utilisateur par l�objet Swing de Java Developer.



� Présenter les résultats des indicateurs par des courbes statistiques grâce à la librairie

JFreecharts.

4.4 Modèles de cas d�utilisation :

4.4.1 Use case " traitement des �chier et insertion dans la base" :

L�utilisateur grâce à une interface graphique va pouvoir choisir un �chier pour le traiter et

le stocker dans une base de donnée comme le montre le diagramme suivant.

Fig. 4.1. Use case " traitement des �chier et insertion dans la base"



4.4.2 Use case "Con�guration des indicateurs" :

Les indicateurs sont déterminer grâce au transitions de la machine d�état de l�interface A

ou en d�autre terme grâce au mesage et événements perçu à ce niveau.

4.4.3 Use case "Interface de con�guration" :

Fig. 4.2. Use case "Interface de con�guration"



4.4.4 Use case "courbes statistiques"

A¢ chage des résultats statistiques

Fig. 4.3. Use case "courbes statistiques"



4.5 Diagrammes de Séquences :

4.5.1 Diagramme de séquence "Traitement et insertion dans la base" :

Fig. 4.4. Diagramme de séquence "Traitement et insertion dans la base"

4.5.2 Diagramme de séquence "Détermination du nombre de transitions" :

Fig. 4.5. Diagramme de séquence "Détermination du nombre de transitions"



4.5.3 Diagramme de séquence "Détermination du nombre des procédures" :

Fig. 4.6. Diagramme de séquence "Détermination du nombre des procédures"



4.5.4 Diagramme de séquence "A¢ chage des courbes statistiques" :

Fig. 4.7. Diagramme de séquence "A¢ chage des courbes statistiques" :

4.6 Réalisation :

4.6.1 Interface de con�guration des transitions :

La con�guration d�une transition consiste à spéci�er les di¤érents élément de la transition

de la machine d�état : etat initial, événement, cause, état �nal. La dé�ntion de la transition sera

spéci�ée par l�utilisateur selon les indictauers qu�il souhaite calculer. Cette interface permet

de visualiser en premier lieu les transitions déja dé�nies dans la table en dessus et permet

l�insertion, la modi�cation et la suppression des transitions.



Interface de con�guration des transitions



Fig. 4.8. Insertion d�une transition



4.6.2 Interface de personalisation des procédures :

Cette interface permet à l�utilisateur de personnaliser lui même la dé�nition d�une procé-

dure parmi celle présentée et qui sont généralement tout ce qu�il ya de plus commun dans le

réseau GSM.

La dé�nition de cette procédure se fait par la sommation de certaines transitions spéci�ées

dans la première partie. Il faut rappeler que les indicateurs de qualité peuvent être déduites

de ces transitions puisque ces dernières peuvent être assimilées à des compteurs élémentaires.

Interface de personnalisation des procédure

4.6.3 Interface de personnalisation des Anomalies :

Cette le principe de cette interface est le même que celui de la précédente sauf que la

formule qu�on peut dé�nir ne se résume pas à une somme d�occurence de transition mais

on dé�nit ici en plus des transitions incréméntantes de l�anomalie mais aussi des transitions

décrémentantes. En validant la formule spéci�ée est insérée dans la table des anomalies.



Interface de personnalisation des anomalies

4.6.4 Présentation graphique des indicateurs par éléments réseau

Cette interface permet de faire le choix de l�indicateur et la durée pendant la quelle on

souhaite voir son évolution :



En validant une nouvelle interface s�ouvre pour le choix de l�élément réseau :

Statistique sur les di¤érentes cellules

4.6.5 Répartition des causes de HO inter et intra BSC par couple de cellule :

Ce graphe montre la répartition des causes des handovers par couple de cellules. Les

données sont extraites du �chier XLH qu�on a présenté dans la chapitre précédent :



Fig. 4.9. Répartition des causes de Handover



4.6.6 Répartition des Mises à jour de localisation

Ce graphes montre la répartition des mises à jour de localisation en spéci�ant le réseau de

l�abonné, l�ancien lac, et la lac destination. On y trouve en plus du nombre des mises à jour

de localisation normale et celui des échecs radio les détails sur les causes du rejets.

4.7 Conclusion générale :

L�apport de ce stage a été d�une importance considérable, en e¤et il nous a permis de :

� S�intégrer au sein de l�entreprise Orascom Tunisie Télécom (OTT) et de collaborer

avec les di¤érents membres concernés par le projet.

� Approfondir mes connaissance sur le réseau GSM : fonctionnement, norme, ingénie-

rie vue que j�ai côtoyé durant les quatre mois de mon PFE des ingénieurs de télécom-

munications.

� Adopter les concepts et les principes de la méthodologie UML aux besoins de l�ap-

plication.

D�autre part l�étude réalisée sur les transitions de la machine d�état de l�interface A m�a

permis de voir de plus prêt ce passe dans le réseau lors des di¤érentes procédures. En plus

l�étude des performances et le suivi de qualité m�ont permis de mieux comprendre la signi�-

cation de certains indicateurs de qualité du réseau. Le plus béné�que dans tout ça c�est que

j�ai eu l�occasion à maintes reprises de voir et d�apprendre sur les méthodes et les démarches

prises par l�équipe, que j�ai intégrée, pour l�évaluation de la qualité de service et le suivi des

performances du réseau.

Parallèlement à l�approfondissement de mes savoirs en réseaux mobiles j�ai eu une opportu-

nité consistante pour me familiariser avec certains outils de développement surtout le langage

de programmation JAVA et les méthodologies SGBD.

En�n nous voulons signaler que ce stage nous a été vraiment d�un grand apport du fait

qu�il nous a o¤ert l�occasion d�améliorer notre formation acquise à Supcom.



Fig. 4.10. Répartition des mises à jour de localisation



Bibliographie

[Alc03] Alcatel. Bss-de�nition of quality of service indicator. Technical Report, Alcatel

(2003).

[AST02a] ASTELLIA. �Cigale USER MANUAL�. ASTELLIA (2002).

[AST02b] ASTELLIA. �Protocol automate module 3�, volume 802p. Astellia, v 12 edition

(October 2002).

[Hei99] Gunnar Heine. �GSM Networks : Protocols, Terminology, and Implementation�.

Artech House, Boston and London (1999).


AnnexeA

Présentation du réseau GSM

Projet Fin d�Etudes Présentation du réseau GSM

APrésentation du réseau GSM

A.1 Principe du réseau GSM

Le GSM est un système cellulaire qui a été développé dans le but de permettre aux utilisa-

teurs, où qu�ils soient, stationnaires ou mobiles, de communiquer entre eux et avec les abonnés

du réseau �xe (RTC, Réseau Téléphonique Commuté), par l�intermédiaire d�un terminal por-

tatif émettant à faible puissance (de 0.25 à 8W)[AST02a].

Pour cela, le territoire est découpé en "cellules" couvertes par des émetteurs récepteurs de

base (BTS, Base Transceiver Station). Pour éviter les interférences, deux cellules contiguës ne

peuvent utiliser les mêmes fréquences ; par contre les mêmes fréquences peuvent être réutilisées

pour des cellules su¢ samment éloignées.

Les réseaux GSM utilisent le format numérique pour la transmission des informations,

qu�elles soient de type voix, données ou signalisation. Les équipements spéci�ques constituant

le squelette matériel d�un réseau GSM (BTS, BSC, MSC, VLR et HLR) dialoguent entre eux

en mettant en oeuvre les mêmes principes que ceux utilisés dans le RNIS (Réseau Numérique

à Intégration de Service) :



� Architecture en couche (couches 1 à 3 du modèle OSI),

� Utilisation des liaisons sémaphores (signalisation),

� Caractéristiques des liaisons : codage MIC (Modulation par Impulsion et Codage).

La norme GSM fonctionne sur des largeurs de bandes comprises entre 890 et 915 MHz pour

l�émission du mobile 935 et 960 MHz pour la réception, soit une disponibilité en fréquences

de 25 MHz. La bande de fréquences utilisée par un portable GSM (900 MHz) ainsi que la

puissance développée par celui-ci (2 watts) permet à un relais de couvrir une surface plus

importante qu�avec un portable DCS 1800 (Digital Cellular System 1800 : transposition de

la norme GSM dans la bande de fréquence des 1800Mhz) (1800 MHz - 1 watt), la distance

maximale à laquelle un portable peut accrocher un relais est donc moins importante ce qui le

désavantage en milieu rural par rapport au GSM. De ce fait pour couvrir une même surface

on estime qu�il est nécessaire d�avoir une fois et demi plus de relais DCS 1800 que de relais

GSM. Les principales caractéristiques de la norme GSM sont données dans le tableau A.1 :

GSM DCSFréquence d�émission du terminal vers la station de base 890-915 MHz 1710-1785Fréquence d�émission de la station de base vers le terminal 935-960 MHz 1805-1880Bande de fréquence disponible 25+25 MHz 75+75 MHzMode d�accès TDMA TDMAEspacement des canaux radio 200kHz 200 kHzEspacement du duplex 45 MHz 95 MHzNombre de canaux radio par sens 124 374Nombre de canaux de parole plein débit 8 8Débit d�un codec à plein débit 13 kbit/s 13 kbits/sType de Modulation GSMK GMSKDébit maximal de transmission de données 9.6 kbit/s 9.6 kbit/s

Tab. A.1. Caractéristiques de la norme GSM

A.2 Architecture GSM

Un réseau GSM est constitué de deux sous parties essentielles qui sont le BSS (Base

station Sub-System) qui gère les ressources radio, et le NSS (Network Sub-System) qui assure



l�établissement des appels et la mobilité. Les principaux composants d�un réseau GSM sont

illustrés dans la �gure A.1 :

Fig. A.1. Architecture du réseau GSM

A.2.1 La station Mobile

La station mobile est composée d�une part du terminal mobile, et d�autre part du module

d�identité d�abonné (SIM �Subscriber Indentity Module). Le terminal mobile est l�appareil

utilisé par l�abonné. Di¤érents types de terminal sont prescrits par la norme en fonction de

leur application et de leur puissance (de 0.8W à 20W).

Chaque terminal mobile est identi�é par un code unique IMEI (International Mobile Equip-

ment Identity). La carte SIM est une carte à puces qui contient dans sa mémoire le code IMSI

(International Mobile Subscriber Indentity) qui identi�e l�abonné de même que les renseigne-

ments relatifs à l�abonnement (services auxquels l�abonné a droit).

A.2.2 Le sous-système de station de base

Le sous-système radio, représenté par la �gure A.2, comprend deux parties. La première,

appelée station de base (BTS, Base Transceiver Station). Une BTS est le point d�accès au

PLMN. Elle est composée d�un ensemble d�émetteur récepteur appelés TRX, Transceiver. Elle

a la charge de la transmission radio, la modulation, la démodulation et le codage correcteur

d�erreur. La BTS gère la couche physique en assurant le multiplexage TDMA, le saut de

fréquence et le chi¤rement. Elle réalise aussi les mesures radio nécessaires.



La seconde partie est le contrôleur de station de base (BSC, Base Station Controller)

organe intelligent du BSS dont le rôle est de gérer les ressources radio (con�guration des

canaux, transfert intercellulaire) d�une ou plusieurs stations de base (BTS), de contrôler les

puissances émises par la BTS et la MS et de décider l�exécution du handover, en plus d�établir

le lien physique (via l�interface A) entre les BTS et le commutateur de service mobile (MSC).



Fig. A.2. Sous-système Radio

A.2.3 Le sous Réseau Système

Le rôle principal de ce sous-système est de gérer les communications entre les abonnés et

les autres usagers qui peuvent être d�autres abonnés ou des usagers du réseau téléphonique

�xe. Comme l�illustre la �gure A:3, ce sous-système est composé de :

� Commutateur de service mobile (MSC - Mobile Switching Center) : est un commutateur

numérique en mode circuit. Cet élément s�occupe de la gestion des appels, gère la trans-

mission des messages courts ((Short Message Service SMS)) et l�exécution du handover

inter BSC. Il dialogue avec le VLR pour gérer la mobilité des usagers et tout ce qui est

lié à l�identité des abonnés, à leur enregistrement et à leur localisation.

� Commutateur d�entrée de service mobile (GMSC �Gateway MSC) : Ce commutateur

est l�interface entre le réseau cellulaire et le réseau téléphonique publique. Le GMSC est

chargé d�acheminer les appels entre le réseau �xe et le réseau GSM.

� Registre des abonnés locaux (HLR �Home Location Register) : Le HLR est une base

de données dans laquelle sont stockées les informations de tous les abonnés à un PLMN.

Ces données regroupent l�IMSI, le numéro de l�abonné et le pro�l de l�abonnement. Le

HLR mémorise pour chaque abonné le VLR où il est enregistré.

� Registre des abonnés visiteurs (VLR �Visitor Location Register) : C�est une base de

données contenant les informations relatives aux abonnés présents dans une zone géo-

graphique. Ces données regroupent principalement l�identité temporelle et la zone de

localisation. En général il y a un seul VLR pour chaque MSC.



� Centre d�authenticité (AuC �Authentication Center) : Le AuC est une base de données

protégée qui contient une copie de la clé secrète inscrite sur la carte SIM de chaque

abonné. Cette clé est utilisée pour véri�er l�authenticité de l�abonné et pour l�encryptage

des données envoyées.

� Registre d�identi�cation d�équipement (EIR�Equipement Identity Register) : Le registre

EIR contient la liste de tous les terminaux valides, chaque terminal étant identi�é par

un code IMEI.

Fig. A.3. Sous Système Réseau

A.3 Les interfaces du réseau GSM

Les di¤érents éléments du réseau GSM assurent des fonctions complémentaires et cha-

cun obéit à des normes spéci�ques. En e¤et, chaque lien entre deux équipements adjacents

forme une interface. Les interfaces sont des composantes importantes du réseau GSM car

elles assurent le dialogue entre les équipements et permettent leur inter-fonctionnement. Ces

interfaces sont présentées dans le tableau A.2 .



Nom Localisation UtilisationUm MS� BTS Interface radioAbis BTS� BSC DiversA BSC�MSC DiversC GMSC� HLR Interrogation HLR pour appel entrantD VLR� HLR Gestion des inforamtions d�abonnées et de localisationE MSC�MSC Exécution des handoversG VLR� VLR Gestion des informations abonnéesF MSC� EIR Véri�cation de l�identité du terminalB MSC� VLR DiversH HLR� AUC Echange des données d�authenti�cation

Tab. A.2. Liste des interfaces dans le réseau GSM

La disposition des interfaces dans le réseau GSM est présentée dans la �gure A.4.

Fig. A.4. Disposition des Interfaces dans le réseau GSM

A.4 L�interface Radio

Bien que l�objet du projet se rapporte essentiellement sur l�interface A et l�analyse des

messages passants par elle, il est préférable de présenter en premier lieu l�interface radio. En

e¤et c�est l�une des interfaces les plus importantes d�un système GSM puisque c�est elle qui

permet la connexion sans �l du terminal au PLMN et c�est sur elle que le système doit faire face

aux di¤érents problèmes que pose le medium radio. Et d�ailleurs la visualisation de l�interface

A est en quelque sorte un moyen supplémentaire pour la véri�cation des mesures radio.



Pour remédier aux di¤érents problèmes au niveau de cette interface, plusieurs fonctions de

contrôle de natures variées ont été dé�nies. Ces fonctions engendrent des transferts de données

(informations système, relevés de mesures, messages de contrôle) acheminées sur plusieurs

canaux logiques.

A.4.1 Accès radio

La méthode d�accès à l�interface radio est la méthode d�accès mixte F-TDMA qui est

la combinaison du mode FDMA (Frequency Division Multiple Access) et du mode TDMA

(Temporary Division Multiple Access ) La bande de fréquence dédiée à la norme GSM est

subdivisée en sous bandes de 200KHz puis chaque spectre est réparti dans le temps par la

méthode d�accès TDMA :

Chaque porteuse est divisée dans le temps en 8 TS (time slot= intervalle de temps). Les

slots sont numérotés par un indice qui varie de 0 à 7. Un canal physique est donc constitué

par la répétition périodique d�un slot dans la trame TDMA sur une fréquence particulière. Les

concepteurs de GSM ont prévus la possibilité de n�allouer à un utilisateur qu�un slot toutes les

2 trames TDMA. Cette allocation constitue un canal physique demi débit par opposition au

canal plein. Le saut de fréquence lent permet de lutter contre les évanouissements sélectifs et

accroît les performances du réseau en cas de charge importante. Dans ce cas, le canal physique

ne siège pas sur une seule porteuse mais utilise un ensemble de porteuses parcourues selon un

certain ordre dé�ni par une séquence de saut qui peut être cyclique ou pseudo aléatoire.

La �gure A.5 présente des canaux physiques plein débit et demi débit avec ou sans saut

de fréquence.



Fig. A.5. Canaux physiques simplex

A.4.2 Canaux logiques GSM

Les canaux de tra�c sont bidirectionnels. Ils permettent de transmettre la parole en plein-

débit (à13 kbits/s) ou en demi débit (à 5,6 kbits/s) et les données jusqu��a 12 kbits/s.

Les canaux de commande véhiculent le tra�c de signalisation et se subdivisent en 3 caté-

gories : les canaux de di¤usion, les canaux communs et les canaux dédiés.

Le tableau A.3 présente l�ensemble des canaux de commandes.



Tab. A.3. Les canaux de commandes

A.5 Fonctionnement du réseau GSM :

A.5.1 Traitement des appels

A.5.1.1 L�établissement d�une communication

Lorsqu�un mobile désire faire un appel :

� Il transmet son identité et le numéro à appeler sur un canal d�accès.

� Le BSC reçoit le message et prévient le MSC.



� Le MSC cherche un canal libre et le transmet au mobile.

� Le mobile se met sur le nouveau canal et attend la réponse

Lorsqu�un mobile est appelé :

� Le mobile est toujours à l�écoute du canal de paging, attendant qu�un message lui soit

envoyé.

� Lorsqu�un MSC doit diriger un appel vers sa destination, il demande au MSC d�attache

du téléphone appelé qui l�informe de la position de celui-ci.

� Il achemine l�appel au MSC responsable de la zone de l�appelé, qui peut transmettre sur

le canal de paging la requête d�appel.

� Le téléphone qui se reconnaît répond et reçoit alors le canal à utiliser pour la communi-

cation. Il se met alors à sonner.

A.5.1.2 Authenti�cation et sécurité

L�emploi d�un canal radio rend les communications vulnérables aux écoutes et aux utilisa-

tions frauduleuses, le système GSM a donc recours aux procédés suivants :

� Authenti�cation de chaque abonné avant de lui autoriser l�accès à un service,

� Utilisation d�une identité temporaire,

� Chi¤rement (ou cryptage) des communications.

A.5.2 Gestion de la mobilité

A.5.2.1 La mise à jour de localisation :

La fonction de mise à jour de localisation permet de localiser en permanence les abonnés

du réseau et de mettre à jour les informations de localisation. Pour faciliter cette localisation,

les cellules sont regroupées en " zones de localisation " et à chaque changement de zone, le

mobile doit s�authenti�er au réseau pour indiquer sa nouvelle position.

Dans le cas habituel, un message de mise à jour de la localisation est envoyé au nouveau

MSC/VLR s�il y a changement de zone de localisation de l�abonné. Le VLR procède par la suite

à la récupération du pro�l de l�abonné auprès de l�ancien VLR qui enregistre les informations



et les envoie au HLR de l�abonné. Le HLR demande alors à l�ancien VLR d�e¤acer les données

relatives à l�abonné.

A.5.2.2 Le Handover :

Dans un réseau cellulaire, la liaison radio entre un mobile et une station de base n�est pas

allouée dé�nitivement pour toute la conversation. Le " Handover " représente la commutation

d�un appel en cours vers un autre canal ou une autre cellule.

Les problèmes liés à la mobilité d�un terminal en communication, sont réglés conjointe-

ment par la structure �xe et le mobile. La décision d�e¤ectuer un basculement de fréquence

nécessaire au traitement d�un transfert intercellulaire (Handover) reste toutefois à la charge

des équipements �xes (MSC + BSC). Cette décision découle des traitements liés aux mesures

sur le niveau de réception du mobile e¤ectué par ce dernier (sur les fréquences balises envi-

ronnantes) et transmises à la BTS nominale relayant la communication en cours.

Le principe repose sur :

� Les mesures faites par le terminal mobile et transmises au BSC courant ;

� La décision prise par le BSC d�e¤ectuer un Handover après identi�cation d�une ou

plusieurs cellules utilisables ; si plusieurs cellules sont éligibles, le MSC détermine, en

fonction des charges de tra�c, la cellule la plus judicieuse à e¤ectuer la communication ;

� La réservation d�un deuxième canal de tra�c entre la nouvelle BTS et le mobile ;

� Un basculement e¤ectué par le mobile sur réception d�une commande émise par le BSC.

Dans le GSM, le Handover s�e¤ectue avec coupure de la communication imperceptible pour

l�utilisateur.On peut di¤érencier deux classes standard de Handovers :

� Better cell Handovers qui sont déclenchés a�n d�améliorer la performance du réseau en

minimisant l�interférence et la charge de signalisation.

� Emergency Handovers qui sont déclenchés lors de la détection d�un problème dans la

cellule de service (une mauvaise qualité du signal, un niveau faible du signal, des inter-

férences,. . . ).



A.5.2.3 La sélection/re-sélection des cellules :

Contrairement au Handover qui se déroule lorsque le mobile est en mode dédié, le processus

de sélection ou de re-sélection de cellules s�e¤ectue lorsque le mobile est en mode de veille.

La fonction de sélection de cellule est réalisée uniquement à la mise sous tension du mobile,

elle permet à ce dernier de choisir à quelle cellule se connecter a�n de communiquer avec le

réseau et d�être prêt à tout instant à émettre ou recevoir des appels.

La fonction de re-sélection n�est e¤ectuée qu�après une première sélection et est réalisée lors

du déplacement du mobile. Cette fonction est activée si la cellule précédemment sélectionnée

ne permet plus au mobile de communiquer correctement avec le réseau pour une raison ou

une autre.


AnnexeB

Les arcitectures SGBD

Projet Fin d�Etudes Les arcitectures SGBD

BLes arcitectures SGBD

B.1 L�architecture Client-Serveurs :

Cette architecture permet de subdiviser un processus informatisé en au moins deux taches

client et serveur avec un mécanisme de coopération qui permet à ces sous processus de coopérer

entre eux.

Ces processus sont des applications communiquant via des requêtes avec réponses Ils per-

mettent la gestion des données sur le serveur partagé entre plusieurs utilisateurs, la gestion

des interfaces graphiques, la communication par des protocoles standardisés et la distribution

des programmes applicatifs à �n de minimiser les coûts.

L�architecture Client-Serveur possède cependant des inconvénients. Dans cette architec-

ture le client se charge de la grande majorité des traitements applicatifs. En plus, ce type

d�architecture est grandement rigidi�é par les coûts et la complexité de sa maintenance.

Mais le majeur problème c�est l�absorption complète des ressources du serveur de données,

en fait chaque session ouverte nécessite une connexion de base de données distincte.


Projet Fin d�Etudes Les arcitectures SGBD

Fig. B.1. Architecture Client Serveur

B.2 Architectures 3-tiers :

L�architecture 3-tiers a été pensée pour pallier aux limitations des architectures Client-

Serveur et concevoir des applications puissantes et simples à maintenir. Ce type d�architecture

permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la

charge entre tous les niveaux.

Cette évolution des architectures Client-Serveur met en oeuvre une approche objet pour

o¤rir une plus grande souplesse d�implémentation et faciliter la réutilisation des développe-

ments.

Théoriquement, ce type d�architecture élimine tous les inconvénients des architectures

précédentes :

Elle permet l�utilisation d�interfaces utilisateurs riches,

Elle sépare nettement tous les niveaux de l�application,

Elle o¤re de grandes capacités d�extension.

Fig. B.2. Architectures 3-tiers


AnnexeC

Le language de modélisation UML

Projet Fin d�Etudes Le language de modélisation UML

CLe language de modélisation UML

UML (Uni�ed Modeling Language) se dé�nit comme un langage de modélisation

graphique et textuelle destiné à comprendre et décrire des besoins, spéci�er et documenter

des systémes, esquisser des architectures logicielles, concevoir et communiquer

à travers divers points de vue. Nous essayerons dans ce qui suit de donner

une brève présentation sur ce langage conceptuel.

C.1 La syntaxe du langage UML :

La modélisation du systéme commence par l�identi�cation des acteurs et des

use cases et se poursuit par la description des use cases. Pour une bonne

compréhension du modèle, il paraît nécessaire de dé�nir certains termes propres

au langage UML.

� Les acteurs : Ils n�appartiennent pas au système, mais ils interagissent avec



celui ci. Ils fournissent de l�information en entrée et/ou reçoivent de l�information

en sortie. Le nom de l�acteur correspond au rôle joué par la personne.

� Les scénarios ou use cases : Un use case modélise un dialogue entre un acteur

et le système. C�est la représentation d�une fonctionnalité o¤erte par le

système. L�ensemble des uses forme toutes les façons possibles d�utilisation

du système.

� Les relations dans les uses cases : UML propose di¤érents types de liens [UML

en Action] entre les acteurs et les use cases : la relation de communication,

la relation d�utilisation et la relation d�extension. �La relation de communication

: indique la participation d�un acteur et est représentée par une ligne

solide entre l�acteur et le use case. C�est la seule relation possible entre un

acteur et les use cases.

� La relation d�utilisation ou �includes �entre use cases signi�e qu�une instance

du use case source inclut aussi le comportement décrit dans le use

case destination. Cette relation lie l�exécution d�un use case à un autre. Dans

l�exemple qui suit, la consultation de la bibliothèque ne pourra être e¤ectuée

que si l�opération d�authenti�cation a été réalisée avec succès.

� La relation d�extension ou �extends �entre deux use cases signi�e que le

use case source étend le comportement du use case destination. L�exécution

d�une fonction peut s�e¤ectuer indépendamment d�une autre. L�exemple qui

suit illustre la relation entre la consultation de la bibliothèque et l�analyse du

�chier.

C.2 Les diagrammes UML :

La notation uni�ée dé�nit 9 diagrammes pour représenter les di¤érents points de

vue de modélisation. Ces diagrammes permettent de visualiser et de manipuler

les éléments de modélisation. Les diagrammes dé�nis par UML sont

les suivants :

� Les diagrammes des use cases : représentation des fonctions du système du



Fig. C.1. Les régles de modélisation UML



point de vue de l�utilisateur. Les diagrammes de séquence : représentation

temporelle des objets et de leurs interactions.

� Les diagrammes d�activités : représentation du comportement d�une opération

en terme d�actions.

� Les diagrammes de composants : représentation du code en termes de modules,

de composants et surtout des concepts du langage ou de l�environnement

d�implémentation.

� Les diagrammes de classes : représentation de la structure statique en terme

de classes et de relations.

� Les diagrammes de collaboration : représentation spatiale des objets, des liens

et des interactions.

� Les diagrammes de déploiement : représentation du déploiement des composants

sur les dispositifs matériels.

� Les diagrammes d�́ etats transitions : représentation du comportement d�une

classe en terme d�́ etat.

� Les diagrammes d�objets :représentation des objets et de leurs relations, correspond

à un diagramme de collaboration simpli�é, sans représentation des

envois de messages.

D�une façon plus générale, UML permet de modéliser les utilisations de cas

et les scénarios (spéci�cations, architecture fonctionnelle), les classes et les objets

(analyse technique détaillée), les composants (architecture logicielle) et la

distribution et le déploiement (architecture technique).


Documents

HAJ TAIEB_Mohamed