Kallel mehdi

République Tunisienne

Ministère de l�enseignement supérieur et Ministère destélécommunications

U n i v e r s i t é d e C a r t h a g e

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

Rapportde mémoire de �n d�études

Présenté en vue de l�obtention du titred�ingénieur en Télécommunications

Thème:

Conception et implémentationd�indicateurs clefs de performancedu réseau GSM à partir de captures

effectuées sur l�interface A

Elaboré par : Mahdi KALLEL

Encadré par : M. Fahmi KHARRAT

Supervisé par : Dr. Mohamed Tahar MISSAOUI

Organisme : O r a s c o m T e l e c o m T u n i s i eAdresse : Les jardins du Lac - Les Berges du Lac - 1053 TunisTel : (216) 22 12 00 00 Fax : (216)22 12 17 09

Remerciements

Mes remerciements les plus chaleureux vont particulièrement aux gens qui, sans leursaide inestimable, ce projet n�aurait jamais été mené à bien.J�exprime ma gratitude en premier lieu, à Mme Valérie Lépillet pour m�avoir accueilli

au sein de son département et pour ses multiples conseils. À M. Fahmi KHARRAT, auDr. Mohammed Taher MISSAOUI pour la qualité de l�encadrement qu�ils m�ont fourni etpour leurs multiples conseils et orientations tout au long de ce projet. Je tiens également àremercier les membres de l�équipe QDF pour les conditions de travail qu�ils m�ont fournies.Je remercie aussi tous les enseignants qui m�ont enseigné tout au long de mes étudeset particulièrement les enseignants de SUP�COM. Pour �nir, je remercie les membres dejury qui ont accepté d�évaluer mon projet. Je leurs présente toute mes gratitudes et mesprofonds respects.

Dédicaces

ÀMon cher père Habib et ma chère mère Zeineb

pour leur tendresse, leur a¤ection,leur amour, leur patience, leurs considérables sacri�ces pour

me parvenir à ce niveau, et leur soutien moralà

ma chère �eur Mahapour son amour in�ni

àmon cher frère Seddik, et sa femme Manel

àmon cher frère Ferouk, et sa �ancé Hejer

àSi Nejib, Malika, Anis et Inès

àmes collocaters Mohammed et So�en

àtoute ma famille

àmes chers amis

àtous mes enseignants

àtous ceux qui m�aiment et que j�aime.

je dédie ce travailQu�Allah vous protège tous, vous préserve la santé et le bonheur

Mahdi Kallel

RésuméLe présent travail, e¤ectué au sein de l�entreprise TUNISIANA, entre dans le cadre du

projet de �n d�études pour l�obtention du diplôme national d�ingénieur en télécommunications. Ils�intéresse au suivi de la performance du réseau GSM à partir des �ux de messages sur l�interfaceA. A cet e¤et, nous proposons une approche de conception d�indicateurs clefs de performanceà l�aide de capture sur cette interface. Par ailleurs, nous mettons en �uvre un outil supportantl�approche proposée en impléméntant ces indicateurs. Finalement, nous validons quelques résul-tats obtenus et nous menons quelques études de cas réelsMots clés: réseau GSM, interface A, procédures GSM, KPI, windev, QoS. . .

AbstractThis present work is carried out, within TUNISIANA as the graduated project to obtain thenational diploma of Telecom Engineer.The aim of this project is to follow the GSM networkperformance by using the message �ow over A interface. In fact, we disign keys performanceindicators needing capture over this interface. In addition, we make a program that shows thesesindicators. Finally, we ratify several obtained results and we show some real case study.Key words: GSM Network, A interface, KPI, windev, QoS. . .

Table des matières

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Chapitre 1. Contexte et problématique . . . . . . . . . . . . . . . . . . . . . . . . 41.1. Dé�nition de la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2. Méthodes de mesures de QoS à TUNISIANA . . . . . . . . . . . . . . . . . . . . 5

1.2.1. Mesures Drive Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. suivi des indicateurs de performance . . . . . . . . . . . . . . . . . . . . . 51.2.3. Dispositifs de capture sur les interfaces . . . . . . . . . . . . . . . . . . . . 61.2.4. Comparaison entre les di¤érentes méthodes de mesure de QoS . . . . . . . 6

1.3. Spéci�cation du besoin et description du projet . . . . . . . . . . . . . . . . . . . 6

Chapitre 2. Etat de l�art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1. Description de l�interface A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2. La signalisation sur l�interface A . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1. Le réseau de signalisation N�7 (SS7) . . . . . . . . . . . . . . . . . . . . . 112.2.2. Message Transfert Part (MTP) : . . . . . . . . . . . . . . . . . . . . . . . 122.2.3. Signaling Connection Control Part (SCCP) . . . . . . . . . . . . . . . . . 122.2.4. BSS Application Part (BSSAP) . . . . . . . . . . . . . . . . . . . . . . . . 122.2.5. Les couches applicatives MM et CM . . . . . . . . . . . . . . . . . . . . . 13

2.3. Les procédures GSM et les principaux messages sur l�interface A . . . . . . . . . 132.3.1. Appel entrant (Mobile Terminated Call MTC) . . . . . . . . . . . . . . . 142.3.2. Appel sortant (Mobile Originating Call MOC) . . . . . . . . . . . . . . . 142.3.3. Mise à jour de localisation (Location UpdateLU) intra-VLR . . . . . . . . 152.3.4. Mise à jour de localisation (Location UpdateLU) inter-VLR . . . . . . . . 162.3.5. Le handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.6. Le transfert de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4. La méthode ASTELLIA : explication des notions Etat, transition, event . . . . . 19

Chapitre 3. Conception des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . 223.1. Démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2. Les indicateurs MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1. Etablissement d�appel (Call SETUP) . . . . . . . . . . . . . . . . . . . . . 243.2.2. Echec d�appel sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.3. La Conversation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3. Les indicateurs MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4. Les indicateurs d�appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5. Mise à jour de localisation (Location Update) . . . . . . . . . . . . . . . . . . . . 39

3.5.1. Etablissement de la connexion radio . . . . . . . . . . . . . . . . . . . . . 393.5.2. Indication de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.3. Allocation Numéro temporaire . . . . . . . . . . . . . . . . . . . . . . . . 40

vi

3.5.4. Echec LU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6. Les indicateurs Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.6.1. Handover interBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6.2. Handover intraBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.7. Les indicateurs SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.8. Des indicateurs Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.8.1. Le double appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.8.2. Connexion SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.8.3. Indicateur de tra�c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Chapitre 4. Implémentation logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 544.1. Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.1. Entrée/sortie et architecture de l�application . . . . . . . . . . . . . . . . 544.1.2. Choix de l�environnement de développement . . . . . . . . . . . . . . . . . 554.1.3. Conception opérationnelle de l�application . . . . . . . . . . . . . . . . . . 57

4.2. Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapitre 5. Validation et étude de cas . . . . . . . . . . . . . . . . . . . . . . . . 675.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.1.1. Choix des indicateurs à valider . . . . . . . . . . . . . . . . . . . . . . . . 675.1.2. Aperçu sur les outils utilisés pour la validation . . . . . . . . . . . . . . . 685.1.3. Validation de Succès_établissement_MOC _Tech . . . . . . . . . . . . . 695.1.4. Validation de Succès_établissement_MTC _Tech . . . . . . . . . . . . . 715.1.5. Validation de coupure_Appel . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.6. Validation de l�indicateur Taux_Succès_LU_Tot . . . . . . . . . . . . . . 735.1.7. Validation du TauxHOInterBSCSortantSuccès et TauxHOInterBSCEntrant-

Succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.1.8. Validation du Taux_Succès_SMS_OC . . . . . . . . . . . . . . . . . . . 76

5.2. Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2.1. Etude d�une congestion sur l�interface A . . . . . . . . . . . . . . . . . . . 775.2.2. Etude d�échec SMS Sortant . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.3. Etude de détection d�un problème de croisement . . . . . . . . . . . . . . 84

Annexe A. Présentation du système GSM . . . . . . . . . . . . . . . . . . . . . . . 90A.1. Principe du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A.2. Architecture GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.2.1. La station Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.2.2. Le sous-système radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.2.3. Le sous Système Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

A.3. Les interfaces du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.4. Fonctionnement du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.4.1. Traitement des appels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94A.4.2. Gestion de la mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Annexe B. Le langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . 98B.1. La syntaxe du langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98B.2. Les diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

vii

Table des figures

Figure 1.1. L�emplacement de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Figure 1.2. Schéma fonctionnel de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Figure 2.1. Pile protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 2.2. Principes d�établissement et de libération d�une connexion SCCP entre BSC

et MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 2.3. procédure MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 2.4. Procédure MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 2.5. LU intra -VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 2.6. LU inter �VLR avec IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 2.7. Handover inter-BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2.8. Le transfert d�un SMS sortant . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2.9. Table des transitions et les compteurs relatifs . . . . . . . . . . . . . . . . . 19

Figure 3.1. Exemple de �chier .EFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.2. �chier «Automate.BDT » . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.3. Les étapes de la procédure MOC . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 3.4. Demande d�un canal SDCCH . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 3.5. Demande de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 3.6. authenti�cation et passage en mode chi¤ré . . . . . . . . . . . . . . . . . . 27Figure 3.7. Début d�appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 3.8. A¤ectation d�un canal de tra�c . . . . . . . . . . . . . . . . . . . . . . . . . 29Figure 3.9. Sonnerie et connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 3.10. Echec radio lors de l�authenti�cation . . . . . . . . . . . . . . . . . . . . . 33Figure 3.11. Recherche du mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 3.12. Réponse au paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 3.13. Demande de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 3.14. Allocation TMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figure 3.15. Handover sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 3.16. suite Handover sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 3.17. Handover entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figure 3.18. Suite handover entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 3.19. SMS Sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 3.20. Répartition du tra�c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 4.1. Architecture client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figure 4.2. Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 4.3. Diagramme de cas d�utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 57Figure 4.4. Diagramme de séquences d�insertion des données dans la base . . . . . . . 58Figure 4.5. Diagramme de séquence de génération des courbes . . . . . . . . . . . . . . 59

Figure 5.1. RNO system (Alcatel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Figure 5.2. le compteur SIEMENS de CM_SERVICE_REQUEST . . . . . . . . . . . 70Figure 5.3. Résultat de la comparaison CSSR_MOC . . . . . . . . . . . . . . . . . . . 71

viii

Figure 5.4. Résultat de la comparaison CSSR_MTC . . . . . . . . . . . . . . . . . . . 72Figure 5.5. Résultat de la comparaison Call drop . . . . . . . . . . . . . . . . . . . . . 73Figure 5.6. Résultat de la comparaison LU_SUCC . . . . . . . . . . . . . . . . . . . . 74Figure 5.7. Résultat de lacomparaison SUCC_HO_Out . . . . . . . . . . . . . . . . . 75Figure 5.8. Résultat de la comparaison SUCC_HO_Out pour une cellule . . . . . . . 75Figure 5.9. Résultat de comparaison SUCC_HO_In . . . . . . . . . . . . . . . . . . . 76Figure 5.10. Résultat de la comparaison SUCC_HO_In pour une cellule . . . . . . . . 76Figure 5.11. Comparaison du MOSMS SUCC . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 5.12. Les échec MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 5.13. Répartition des causes d�échec . . . . . . . . . . . . . . . . . . . . . . . . . 78Figure 5.14. Répartition des états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 5.15. Les échecs MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 5.16. Répartition des causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 5.17. Répartition des états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 5.18. Tra�c par BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 5.19. Distribution des causes pour le BSC . . . . . . . . . . . . . . . . . . . . . . 82Figure 5.20. Résultat de l�analyse de l�indicateur Taux_Succès_SMS_OC . . . . . . . 82Figure 5.21. MOSMS% sur SPOTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figure 5.22. Echec SMS par numéro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figure 5.23. Résultat d�analyse de l�indicateur Succès_Etablissement_Appel_Tech . . 84Figure 5.24. Tra�c sur le secteur 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Figure 5.25. Tra�c sur le secteur 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figure 5.26. Positions GIS des secteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figure 5.27. Performances HO pour le couple 4-x . . . . . . . . . . . . . . . . . . . . . . 87Figure 5.28. Performances HO pour le couple 3-x� . . . . . . . . . . . . . . . . . . . . . 87

Figure A.1. Architecture du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure A.2. Le sous système Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Figure A.3. Le sous système réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

ix

Liste des tableaux

Tableau 3.1. dé�nition des causes de rejet . . . . . . . . . . . . . . . . . . . . . . . . . 32

Tableau A.1. Caractéristiques de la norme GSM . . . . . . . . . . . . . . . . . . . . . . 91Tableau A.2. Liste des interfaces dans le réseau GSM . . . . . . . . . . . . . . . . . . . 94

x

Introduction générale

La téléphonie mobile connaît dès le début des années 90 une croissance explosive dépassant

les prévisions les plus optimistes des opérateurs de télécommunication. Elle s�impose de plusen plus comme le moyen le plus e¢ cace pour conquérir d�avantage des parts du marché destélécommunications.

Le GSM est le système de téléphonie mobile qui a connu un succès sans appel. Il a étécommercialisé depuis l�année 1992 en Europe.

Le développement des technologies utilisées et les services et les applications o¤ertes par leGSM ont contribué à la création d�un environnement propice à la concurrence incitant ainsi lesopérateurs à se soucier de la qualité de leurs prestations et des performances de fonctionnementde leurs réseaux et leurs infrastructures.

Il s�avère donc que la qualité, dans ce domaine comme dans beaucoup d�autres, constitueune source importante de di¤érenciation déterminante entre les opérateurs en concurrence. Laprise à la légère de la qualité de service du réseau est une erreur stratégique puisqu�elle constituel�élément qui stimule le choix �nal du consommateur d�où la conquête du marché, d�où le pro�t.

Dans ce contexte, après la phase de déploiement d�un réseau cellulaire, l�opérateur commenceà analyser et améliorer les performances de son réseau pour garantir une qualité de serviceacceptable.

Le maintien et le suivi de cette qualité nécessitent l�observation permanente de l�état defonctionnement du réseau et de toutes les actions réalisées et par conséquent, l�utilisation d�outilsd�ingénierie adaptés.

Cependant, la supervision de ce réseau est une tâche assez délicate vu l�aspect dynamique deson architecture et de la con�guration de ses di¤érents éléments et l�hétérogénéité des outils desupervision et des bases de données des performances existantes.

Dans cette optique se manifeste le cadre général de notre projet de �n d�étude. En e¤et, parmiles méthodes adoptées pour l�évaluation de la qualité de service du réseau GSM, on distingue lesuivi de l�évolution d�indicateurs clefs de performance (KPI). La signi�cation de chaque indicateurest spéci�que, il en résulte que la conception de ces indicateurs est la phase la plus importante.

Dans un premier chapitre, nous allons évoquer le contexte général du projet ainsi que laproblématique écoulée. Le second chapitre sera consacré à la conception des indicateurs de per-formance. La phase d�implémentation logicielle et de réalisation sera rassemblée dans un troisièmechapitre. En�n le dernier chapitre contient une étude de cas réels pour interpréter et valider desrésultats obtenus.

2

Chapitre 1

Contexte et problématique

Projet de �n d�études Contexte et problématique

1Contexte et problématique

L�objectif de ce chapitre est de rattacher le projet à son cadre théorique. Nous allons dé�nir la

notion de QoS (Quality Of Service) dans les réseaux mobiles en présentant ses méthodes et moyens

de mesures. Cette notion étant assez globale, nous dégagerons celle rattachée à TUNISIANA et

ses diverses perspectives d�évaluation. Nous allons en�n dégager la problématique originelle du

projet.

Il est à noter que ce chapitre sera mieux compris avec une lecture parallèle de l�annexe A

portant sur l�architecture et des notions globale sur le GSM.

1.1 Dé�nition de la QoS

Selon la recommandation UIT E-800, la qualité de service est dé�nie en terminologie comme

étant «L�e¤et global produit par la qualité de fonctionnement d�un service qui détermine le degré

de satisfaction de l�usager du service» . Il faut donc distinguer entre la qualité de fonctionnement

QDF et la qualité de service QoS.[1]

En e¤et la qualité de fonctionnement est le guide général des facteurs qui contribuent collecti-

vement à la qualité de service. De point de vue fournisseur de service, la qualité de fonctionnement

du réseau est un concept qui traduit la manière dont les caractéristiques du réseau sont établies,

mesurées et contrôlées pour atteindre un niveau satisfaisant de qualité de service.

Dans l�utilisation d�un service, l�utilisateur d�un service ne distingue généralement que le

fournisseur de service. Le degré de satisfaction que l�utilisateur retire du service fourni dépend

de la qualité de service, c�est-à-dire de la perception qu�il a des aspects suivants :

- L�accessibilité au service,

Mahdi Kallel 4


- La continuabilité du service,

- L�intégrité du service.

Dans le contexte actuel, la qualité de service est devenue un facteur déterminant pour TUNI-

SIANA qui s�est donc aperçu que la qualité de ses services et de ses prestations doit être constam-

ment contrôlée et suivie, d�une part pour connaître l�état de fonctionnement de son infrastructure

et d�autre part pour pouvoir améliorer sa compétitivités. C�est dans ce cadre de concurrence et

d�innovation qu�elle s�est dotée d�un service de qualité, dont la mission est d�évaluer et de mesurer

la qualité de service dans toutes les parties du réseau.

TUNISIANA utilise plusieurs méthodes pour évaluer la qualité du service du réseau. Le

paragraphe suivant va les décrire.

1.2 Méthodes de mesures de QoS à TUNISIANA

Pour mesurer la performance de son réseau, TUNISIANA utilise un ensemble de méthodes et

d�outils qui aident à l�investigation. Les mesures Drive Test, le suivi des indicateurs de performance

et les dispositifs de capture sur les interfaces du réseau, sont des méthodes et approches qui

contribuent toutes à l�évaluation de la qualité de service. Une analyse rigoureuse des facteurs de

la qualité de service, doit impérativement utiliser l�ensemble de ces méthodes.

1.2.1 Mesures Drive Test

Il s�agit d�équipes qui font des parcours sur les routes et les zones couvertes par le réseau, pour

mesurer des paramètres en downlink (DL). Ils utilisent un mobile à trace pour l�acquisition des

mesures radio. Ce mobile est attaché à un récepteur spéci�que qui est attaché à son tour à un PC

portable. Un logiciel spécial est installé dans le PC portable sert à l�acquisition, l�enregistrement

et le traitement des mesures récupérées.

Pour la localisation géographique des points de mesures, Un GPS (Global position system)

est Utilisé.[2]

1.2.2 suivi des indicateurs de performance

Ce sont des indicateurs permettant de disposer d�une vue globale sur le réseau, notamment

sur les performances des procédures GSM. Généralement on distingue :

- Des indicateurs relatifs à l�établissement d�appel ;

- Des indicateurs de coupure d�appel ;

- Des indicateurs relatifs aux handovers ;

- Des indicateurs relatifs à la mise à jour de localisation ;

- Des indicateurs relatifs au transfert de SMS.

Ces indicateurs sont calculés à partir de compteurs sous forme « brutes » qui s�incrémentent à

chaque fois qu�un événement surviens sur le réseau (on entend par événement un message échangé

entre deux équipements du réseau). Les indicateurs, dits KPI (Key Performance Indicators), sont

calculés de la façon :

KPI = f(Compteurs)

La récolte et le rassemblement des compteurs peuvent s�e¤ectuer par le biais de l�OMC (Opé-

ration and Maintenance center) qui est un serveur générant des �chiers de compteurs.

Mahdi Kallel 5


1.2.3 Dispositifs de capture sur les interfaces

Les dispositifs de capture sur les interfaces permettent d�examiner les trames échangées entre

deux équipements du réseau à des �ns d�investigation. Il sont des systèmes qui se caractérisent

par :

- Un Hardware (analyseur de protocole) sur lequel est implémenté un Software spéci�que

pour détecter et adapter les caractéristiques de l�interface sur laquelle il est implémenté ;

- Un logiciel qui permet le décodage des trames ;

- Un écran pour a¢ cher le résultat des mesures ;

- Une mémoire de stockage importante.

Ils peuvent intercepter, décoder et analyser les trames et savoir de quel protocole elle relève.[4]

1.2.4 Comparaison entre les di¤érentes méthodes de mesure de QoS

Le Drive Test et les indicateurs de performance sont indispensables pour la détermination de

la qualité de service du réseau GSM. Ils représentent néanmoins quelques insu¢ sances.

Le drive Test donne l�idée sur la qualité de service comme l�aperçoit l�utilisateur, il est in-

su¢ sant dans la mesure où il n�o¤re pas une vision complète sur le réseau, il fait des mesures

«Snapshot » à un instant donné et dans un lieu donné.

En ce qui concerne la méthode d�évaluation par KPI, elle évalue globalement la qualité. Il

est donc un peu di¢ cile de déterminer la cause exacte d�un disfonctionnement. D�autre part, ces

indicateurs dépendent étroitement du constructeur dans la mesure ou chacun dé�ni et implémente

ses indicateurs d�une façon propre. Ceci stimule l�hétérogénéité entre les systèmes des fournisseurs

d�équipements.

L�importance du suivi de la QoS en se basant sur les captures sur les interfaces découle grâce

aux caractéristiques suivantes :

- La capture sur les interfaces ne dépend pas du fournisseur des équipements GSM. Elle

compense le problème du manque d�interopérabilité entre di¤érents constructeurs.

- Elle permet de faire une analyse bas niveau et de suivre la totalité des traces de signa-

lisation.

1.3 Spéci�cation du besoin et description du projet

L�opérateur « Orascom Télécom Tunisie » a été conscient de l�importance du suivi de la

qualité de service du réseau GSM par des captures à travers l�interface A du réseau.

L�interface A a été choisie vu qu�elle est totalement normalisée par la recommandation GSM

08.08 et qu�elle ne dépend en aucun cas du fournisseur des équipements. D�autre part, l�interface

A constitue la limite entre le sous système radio BSS et le sous système réseau NSS. Il s�agit

d�une fenêtre qui s�ouvre sur les deux systèmes à la fois, elle pouvait détecter les problèmes BSS

et les problèmes NSS. La quasi-totalité des procédures GSM font transiter des messages à travers

l�interface A, il est donc possible de tirer les informations utiles qui renseignent sur la qualité de

service du réseau.

Du coté de chez TUNISIANA, La plateforme de capture sur l�interface A est fournie par

ASTELLIA : une société spécialisée dans la conception de solutions matérielles et logicielles

Mahdi Kallel 6


dédiées à l�optimisation des performances des réseaux de la téléphonie mobile. Cette plateforme

est appelée CIGALE.

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 placé au niveau de l�interface A [11] (Voir �gure 1.1)

Fig. 1.1. L�emplacement de Cigale

Cigale prend comme input des �chiers de con�gurations. Par exemple, 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 options

de l�application [11] (Voir �gure 1.2 ).

Fig. 1.2. Schéma fonctionnel de Cigale

Comme output, Cigale génère quotidiennement des �chiers bruts ou semi bruts. Durant le

traitement il est possible de générer les �chiers _Ref.txt bruts suivants (qui seront une base pour

un outil appelé Cigale View) :

Mahdi Kallel 7


- 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 ;

- EFF : Des compteurs e¢ caces pour chaque cellule.

A la �n du traitement, les statistiques semi bruts suivantes peuvent être générées (Statistical

�le) :

- XL2 : Statistiques sur la machine d�état (à voir la dé�nition dans le chapitre suivant) ;

- XL3 : informations de chaque connexion et leur historique ;

- 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.

Quoique intéressante, l�analyse exhaustive des �chiers générés est délicate voir très di¢ cile vu

leurs tailles volumineuses. Il faudra en outre une longue durée d�analyse pour pouvoir s�en sortir.

D�où l�idée qui a donné naissance à ce projet.

L�idée était d�essayer de compenser la durée d�analyse exhaustive des �chiers en faisant la

conception d�indicateurs clefs de performances à partir de ces �chiers. Puis de les faire implémenter

dans une application logicielle complète qui représente un tableau de bord de l�évolution de ces

indicateurs en générant des courbes et des statistiques.

En�n pour valider les résultats obtenus, une étude de cas doit être menée pour comparer les

résultats découlés des indicateurs calculés avec ceux des indicateurs OMC.

Mahdi Kallel 8

Chapitre 2

Etat de l�art

Projet de �n d�études Etat de l�art

2Etat de l�art

Dans ce chapitre, nous allons mettre l�accent sur quelques notions qui seront utiles pour

comprendre la conception des indicateurs clefs de performances à partir des messages échangés à

travers l�interface A.

Dans un premier lieu, nous présenterons l�interface A globalement en évoquant les protocoles

de signalisation rattachés, ensuite nous mettrons les di¤érents messages transités sur l�interface A

dans leur contexte de procédure GSM. En�n, nous donnerons une brève description de la méthode

Astellia en expliquant les notions : état automate, transition et événement.

2.1 Description de l�interface A

NB : Ce paragraphe sera mieux compris en regardant parallèlement l�annexe n�1 portant sur

des notions générales sur le réseau GSM.

Du point de vue physique, l�interface A est constituée de 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é typiquement 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ée en 2 parties :

- La première partie est située entre le BSC et le TRAU, où l�information utile est encore

compressée. Dans quelques nomenclatures, cette interface est appelée interface Ater. Comme c�est

le cas pour l�interface Abis, un seul canal de tra�c occupe seulement deux bits des huit bits de

l�IT MIC. C�est pourquoi il, est possible de transporter quatre canaux de tra�c simultanément

Mahdi Kallel 10


dans un seul IT MIC. Mais l�information de signalisation sur cette interface nécessite un IT entier

MIC de 64 Kbps.

- La deuxième partie est située entre le TRAU et le MSC. L�information utile est main-

tenant décompressée. Pour cette raison, chaque canal de tra�c nécessite la totalité des huit bits

de l�IT MIC soit 64 Kbps par canal. En outre, la position du canal de signalisation peut être

di¤érente avant et après le transcodage[4].

2.2 La signalisation sur 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. La �gure 2.1 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. 2.1. Pile protocolaire

2.2.1 Le réseau de signalisation N�7 (SS7)

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.

Mahdi Kallel 11


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.[7]

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 des erreurs 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 messages

entre les noeuds du réseau sémaphore (PS ou PTS). Il comprend deux fonctions : orientation des

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

2.2.3 Signaling Connection Control Part (SCCP)

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

entre 2 noeuds du réseau, le SCCP o¤re un adressage de bout en bout, même à travers les noeuds

et les pays du réseau.

Il faut aussi noter qu�une connexion SCCP par mobile est nécessaire au niveau de l�interface

A pour toute procédure sur le réseau pour le cas GSM. Ces étapes sont illustrées par la �gure

2.2[4].

2.2.4 BSS Application Part (BSSAP)

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 :

Mahdi Kallel 12


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

- Les messages interprétés par le BSC qui traitent à la gestion des ressources radio et

l�exécution du Handover (sous-couche BSSMAP)

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

DTAP).

2.2.5 Les couches applicatives MM et CM

- MM inclus les messages relatifs à la mobilité

- CM inclus le traitement d�appel (CC), les services supplémentaires (SS) et le service des

messages courts (SMS)

Après avoir comprendre les di¤érents protocoles qui régissent le transfert de messages sur

l�interface A, il faut donner un aperçu sur ces messages en les mettant dans leurs contextes vis-

à-vis des procédures GSM correspondantes. Le paragraphe suivant présente les procédures GSM

les plus commodes et le résumé interface A relatif.

2.3 Les procédures GSM et les principaux messages sur l�inter-face A

Pour évaluer la qualité de service du réseau GSM, il faut comprendre les di¤érents processus

qui gèrent son fonctionnement. Les processus les plus commodes sont : l�établissement d�appel

entrant et sortant (resp MTC et MOC), la mise à jour de localisation (LU), le Handover (HO)

et le SMS.

Mahdi Kallel 13


2.3.1 Appel entrant (Mobile Terminated Call MTC)

Une fois le roaming number MSRN fourni, le MSC lance un avis de recherche aux BSCs des

cellules qui appartiennent au LAC (Location Area Code) spéci�é par le VLR (Visiter Location

Register). Le mobile étant trouvé, la connexion radio s�établit. Et dés lors, la réponse au PAGING

est envoyée au BSC correspondant qui, à son tour, la transmet au MSC a travers l�interface A.

Ensuite le système authenti�e le mobile puis ordonne le passage en mode chi¤ré. Le BSC alloue

ensuite un canal de tra�c TCH au mobile (Les messages précédents étant sur un canal SDCCH).

Après la con�rmation d�appel, la sonnerie est envoyée à l�appelé. Si le mobile décroche, la

conversation commence.

En�n, après raccrochage, les ressources sont libérées. Voir �gure 2.3 [5].

MS BSS MSC/VLR HLR GMSC PSTN

AIM (MSISDN)Send routing info

Provide roaming number

Provide roaming number ACKMSRN Send routing info ACK

AIM (MSRN)

PagingPaging_Req

Ch_Req

ImmAss

Paging_RespPaging_Resp + SCCP Connection

Auth_Req

Auth_Resp

Chiph_Mod_Cmd

Chiph_Mod_Cmd _complete

Setup

Call_Confirmed

Sonnerie

AlertingACM

ACM

Décroché

ConnectAnswer

Answer

CONVERSATION

Raccroché

DisconnectRelease

ReleaseRelsead

Release_completeRelease_complete

Clr_CommCh_Release

Clr_Complete

Interface A

Fig. 2.3. procédure MTC

2.3.2 Appel sortant (Mobile Originating Call MOC)

Il s�agit presque de la même procédure MTC sauf que cette fois-ci, c�est le mobile qui initie

l�appel, il fait la connexion radio SDCCH avec sa station de base puis il transmet une demande

Mahdi Kallel 14


de service (SERVICE REQUEST). Ensuite, les étapes qui suivent sont identiques à celle décrites

en MTC. Voir la �gure 3.4[5].

MS BSS MSC VLR PSTN

Ch_Req

ImmAss

SABM + Serv_Req

UAConn_ Req

Process Access_Req

AuthenticateAuth_Req

Auth_Req

Auth_Resp Auth_Resp

Authenticate.Res

Set_Ciph_ModChiph_Mod_Cmd

Chiph_Mod_Cmd

Chiph_Mod_Cmd _completeChiph_Mod_Cmd _complete


Réallocation TMSI Optionnelle

Process Access_Req_Accept

SETUPSETUP

Complete_CallCall_Proceeding

Call_Proceeding

AIM (numéro demandé)

ACM

Ass_ReqAss_Req

Ass_CompleteAss_Complete

AlertingAlerting Answer

ConnectConnect

Connect_AckConnect_Ack

CONVERSATION

RaccrochéDisconnect

Release

Relsead

Release_complete

Release

Release_complete

Clr_CommCh_Release

Clr_Complete

Interface A

Fig. 2.4. Procédure MOC

2.3.3 Mise à jour de localisation (Location UpdateLU) intra-VLR

En GSM la mise à jour de localisation se fait lorsque le mobile passe de l�état éteint à l�état

Idle, ou bien elle se fait d�une façon périodique.

Si la nouvelle localisation du mobile appartient au même VLR que la localisation précédente,

alors il s�agit d�un LU intra VLR. Les principales étapes sont : la connexion radio SDCCH, la

demande de LU, l�authenti�cation et en�n l�exécution de la mise à jour au niveau de VLR. Voir

la �gure 2.5[5].

Mahdi Kallel 15


MS BSS MSC/VLRInterface A

Ch_Req

Imm_Ass

Loc_Upd_ReqLoc_Upd_Req

Auth_Req

Auth_Req

Auth_RespAuth_Resp

Loc_Upd_AccLoc_Upd_Acc

Clr_Comm

Clr_CompleteCh_Release

Fig. 2.5. LU intra -VLR

2.3.4 Mise à jour de localisation (Location UpdateLU) inter-VLR

La mise à jour de localisation inter-VLR se passe si la nouvelle localisation du mobile n�ap-

partient pas au même VLR de l�ancienne localisation.

Cette fois-ci, la mise à jour de localisation passe par le HLR qui con�rme la nouvelle connexion

et annule l�ancienne.

La mise à jour de localisation peut se faire ou bien avec TMSI seulement (voir �gure 2.4 [5]),

ou bien avec IMSI Attach avant la phase d�authenti�cation.

Mahdi Kallel 16


MS BSS MSC VLR2 HLR VLR1

Ch_Req

Imm_Ass

Loc_Upd_ReqLoc_Upd_Req

Loc_Upd.Area

Provide IMSIIMSI_Req

Identity_Req

Identity_Resp

IMSI_AckSend Param (Req_Authent_set)

Send Param.Result (Rand, Sres, Kc)

IMSI_Resp

AuthenticateAuth_Req

Auth_Req

Auth_Resp Auth_Resp

Authenticate.ResUpdate_Loc

Insert Subscriber data

Insert Subscriber data.ACKCancel_Loc

Cancel_Loc_ACKUpdate_Loc_ACK

Set_Ciph_ModChiph_Mod_Cmd

Chiph_Mod_Cmd

Chiph_Mod_Cmd _completeChiph_Mod_Cmd _complete


Forword_New_TMSITMSI Realloc_Cmd

TMSI Realloc_Cmd

TMSI Realloc_completeTMSI Realloc_complete

Forword_New_TMSI.Res

Loc_Upd.Area_ACKLoc_Upd_Accept

Loc_Upd_Accept

Clr_Comm

Clr_CompleteCh_Release

Interface A

Fig. 2.6. LU inter �VLR avec IMSI

2.3.5 Le handover

Un rapport de mesures radio est échangé entre le mobile et sa station de base, Le handover

se déclenche suite à un algorithme spéci�que qui met en vigueur les critères de déclenchement

suivants : le niveau de champs, la qualité du lien radio, le niveau d�interférence, l�éloignement du

mobile de sa station de base et le tra�c.

Les handovers peuvent être par ordre hiérarchique intra ou inter cellulaires, intra ou inter

BSC, intra ou inter MSC.

Vu sa position, l�interface A ne pouvait être utile que pour la détermination de la performance

du HO inter BSC. Pour le handover intra-BSC, seul le messager HANDOVER-PERFORMED

transite à traver l�interface A vers la �n de la procédure.

Mahdi Kallel 17


La procédure du handover inter-BSC est donnée par la �gure2.7.

Fig. 2.7. Handover inter-BSC

2.3.6 Le transfert de SMS

Le transfert de SMS se fait sur la voie de signalisation SDCCH. Après les phases rituelles

de connexion radio Sur SDCCH et l�authenti�cation, le mobile envoie son SMS sur la voie de

signalisation. Si ce message parvient au centre d�SMS (SMSC), le mobile reçoit un acquittement

positif.

Cette procédure est illustrée par la �gure 2.8 [6]. (On a pris le cas d�un SMS sortant).

Fig. 2.8. Le transfert d�un SMS sortant

Pour intercepter ces di¤érents messages transités a travers l�interface A, TUNISIANA a im-

plémenté un analyseur de protocole «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 la

téléphonie mobile. Le paragraphe suivant explique la méthode Astellia de capture.

Mahdi Kallel 18


2.4 La méthode ASTELLIA : explication des notions Etat, tran-sition, event

Le dispositif de capture intercepte les messages qui transitent à travers l�interface A. Pour

qu�il réussisse à décoder et comprendre chaque message, l�enchaînement de chaque procédure

GSM doit être pris en compte lors de sa con�guration initiale.

Cette con�guration dé�nit un ensemble d�états de telle façon que chaque message intercepté

fait changer un état donné de l�automate de l�analyseur.

Par dé�nition, Une transition est constituée de :

- Un état original ;

- Un état �nal

- Un message (event) avec parfois une cause associée. Ce message est le message propre-

ment dit, connu, dé�nit par la norme et capté au niveau de l�interface A.

Les event sont parfois accompagnés d�une extension permettant :

- d�indiquer le sens du message ;

- d�ajouter une information supplémentaire.

La �gure 2.9 montre un extrait la table du �chier «Automate.BDT » (Un �chier input de

Cigale voir �gure 1.2 ) qui rassemble les di¤érentes transitions implémentées sur l�automate et

qui est fournis lors de la livraison du produit et mis à jour si nécessaire [6].

Fig. 2.9. Table des transitions et les compteurs relatifs

Chaque connexion passe une succession ordonnée d�états de l�automate selon la procédure

GSM (MOC, MTC, LU, SMS, HO. . . ). Dans la procédure MOC, par exemple, le premier mes-

sage qui passe par l�interface A est le message SERVICE_REQUEQST noté dans le tableau CM-

SRQ. Ce message fait donc changer l�état de l�automate de l�état VIDE à l�état OC_CMSREQ.

Le deuxième message est AUTHENTICATION_REQUEST. Ce message fait passer l�état de

l�automate de OC_CMSREQ à OC_AUTHRQ.

Ainsi de suite on peut tirer l�ensemble des transitions par lesquels la procédure MOC doit

passer. Par conséquent, la classi�cation des transitions par procédure et leur organisation par

ordre d�enchaînement de chaque procédure est indispensable pour tirer les compteurs associés qui

seront par la suite la base de la phase de la conception des indicateurs clefs de performance.

Chaque transition fait incrémenter un ou plusieurs ces compteurs dits «e¢ caces» qui �gurent

dans le �chier .EFF généré par Cigale.

Mahdi Kallel 19


L�étude des spéci�tés de l�interface A dans ce chapitre, ainsi que la description de la méthode

Astellia vont être des éléments clefs pour la compréhension de la conception des indicateurs de

performance. Dans le chapitre suivant nous mettrons en pratique cette étude en concevant des

indicateurs clefs de performances qui re�ètent la qualité du réseau.

Mahdi Kallel 20

Chapitre 3

Conception des indicateurs

Projet de �n d�études Conception des indicateurs

3Conception des indicateurs

3.1 Démarche

La conception des indicateurs nécessite une connaissance des procédures que dé�nit la norme

GSM. Puisqu�en e¤et, les messages de ces procédures qui transitent à travers l�interface A consti-

tuent la base des indicateurs conçus. L�analyse et la distinction entre les messages sur l�interface

A des di¤érentes procédures s�avèrent donc indispensables dans la mesure où il s�agit de l�étape

préliminaire de la conception des indicateurs.

Après l�identi�cation des messages déterminant sur l�interface A, il faut trouver un moyen

de comptage de leurs occurrences sur un objet donné (MSC, BSC, Cellule, LAC). Dans cette

optique et après la documentation et analyse des di¤érents �chiers générés par Cigale, il s�est

avéré que le �chier .EFF, généré chaque jour par capture, est le plus intéressant vu qu�il donne

un ensemble de compteurs qui s�incrémentent suite aux transitions de l�état de l�automate donc

suite aux messages qu�on désire calculer l�occurrence. Ces compteurs sont classi�és par cellules.

La �gure 3.1 montre la structure d�un �chier .EFF.

Mahdi Kallel 22


Fig. 3.1. Exemple de �chier .EFF

Il n�existe pas encore une documentation qui donne la dé�nition des compteurs que le �chier

.EFF calcule. On ne peut savoir leurs signi�cations que si on passe par une analyse exhaustive du

�chier «Automate.BDT» qui donne l�ensemble de toutes les transitions con�gurées sur l�analyseur

de protocole avec les compteurs qui s�incrémentent suite à chaque transition. La �gure 3.2 montre

le �chier « Automate.BDT » .

Fig. 3.2. �chier «Automate.BDT »

Chaque ligne est une transition formée par un état initial, le message, l�état suivant et,

optionnellement, les extensions et les causes (les causes des rejets si c�est une transition de rejet).

A la �n de la ligne on trouve les compteurs qui s�incrémentent suite à chaque transitions. Un

compteur peut correspondre à une ou plusieurs transitions et une transition peut incrémenter un

Mahdi Kallel 23


ou plusieurs compteurs selon le cas et selon les extensions où les causes.

Par conséquent, pour la conception d�un indicateur il faut paser par les étapes suivantes :

- S�inspirer des indicateurs de performances OMC des fournisseurs d�équipements ;

- Identi�cation des messages cruciaux qui transitent à travers l�interface A pour chaque

procédure GSM selon le critère de qualité de service et les critères techniques ;

- Réorganiser les transitions qui se trouvent dans le �chier « Automate.BDT » selon le

déroulement de chaque procédure ;

- Identi�er la transition qui correspond à ces messages ;

- Tirer les compteurs associés ;

- Dé�nition de la formule.

3.2 Les indicateurs MOC

Lors de ce pargraphe, nous allons essayer de parcourir toute la procédure en commençant par

l�établissement d�appel sortant puis la converstion.

3.2.1 Etablissement d�appel (Call SETUP)

L�établissement d�un appel sortant passe par 3 étapes :

Fig. 3.3. Les étapes de la procédure MOC

- Etape 1 : Elle Commence avec le message initial sur l�interface A (CM SERVICE RE-

QUEST) et se termine avec la demande du canal de tra�c TCH (ASSIGNEMENT REQUEST)

- Etape 2 : Elle commence avec la demande du canal TCH (ASSIGNEMENT REQUEUST)

et se termine par le message de succès d�allocation d�un canal TCH (ASSIGNEMENT COM-

PLETE).

- Etape 3 : Elle commence avec le message de succès d�allocation d�un canal TCH (ASSI-

GNEMENT COMPLETE) et se termine par la connexion directe (DIRECT CONNECT).

Nous allons établir les indicateurs relatifs à chaque étape en distinguant les scénarios d�échec

et de succès correspondants.

3.2.1.1 L�établissement de la connexion radio (Demande de canal SDCCH)

L�établissement de la connexion radio est l�étape préliminaire pour toute procédure GSM.

Elle n�est pas spéci�que à la procédure de l�appel sortant. Néanmoins, il n�y a aucun message qui

transite sur l�interface A pour cette étape (voir �gure 3.4 [6])

Mahdi Kallel 24


Fig. 3.4. Demande d�un canal SDCCH

Il en résulte que l�analyseur de protocole ne va pas détecter cette étape ce qui n�est pas le cas

des étapes suivantes. . .

3.2.1.2 Déclenchement :

Le déclenchement de toute la procédure de l�appel sortant MOC au niveau de l�interface A

est donné par le message SERVICE_REQUEST envoyé par le BSS au MSC. Ce message est

encapsulé dans un message de la couche BSSMAP et accompagné d�une demande de connexion

SCCP entre le BSC et le MSC. (Voir �gure 3.5 [6])

Fig. 3.5. Demande de service

L�état de l�automate passe alors de l�état vide (VIDE) à l�état demande de service (OCCM-

Mahdi Kallel 25


SREQ) selon la transition suivante : (CMSRQ étant le message SERVICE_REQUEST selon la

nomenclature d�Astellia)

VIDECMSRQ

BSC MSCOC_CMS_REQ

Nous pouvons ainsi dé�nir le nombre total de demande MOC (initiation d�appel) sur l�interface

A comme étant la somme de l�occurrence de ce message.

Mais les captures sur l�interface A ont un début et une �n. Il se peut que la capture se

ferme alors que la procédure n�a pas encore terminée. Il en résulte qu�on peut trouver quelques

incohérences dans les �chiers générés par ces captures : c�est ce qu�on appelle les « Purges » .

Pour être plus concis, et pour que ce phénomène n�a¤ecte pas nos calculs, il faut retrancher le

nombre de purges du nombre total de tentatives MOC.

La transition mentionnée ci-dessus fait incrémenter le compteurNb_OC qui �gure dans le �-chier .EFF . Le nombre de purges de l�appel sortant est donné par le compteurNbPURGE_E1_OCpour les purges de la phase1 de l�établissement d�appel, NbPURGE_E2_OC pour les purges

de la phase2 de l�établissement d�appel et NbPURGE_E3_OC pour les purges de la phase3

de l�établissement d�appel. Ainsi on obtient la formule générique suivante :

Nombre_Appels_MOC=NbOC-NbPURGE_E1_OC-NbPURGE_E2_OC-

NbPURGE_E3_OC

3.2.1.3 Authenti�cation et passage en mode chi¤ré

Si tout se passe bien, l�état de l�automate passe de l�état demande de service (OC_CMS_REQ)

à l�état de la première tentative de l�authenti�cation (OC_AUT_REQ_1) selon la transition sui-

vante :

MSC BSCOC_CMS_REQ OC_AUT_REQ_1

AUTRQ

Cette transition correspond au message AUTHENTICATION_REQUEST. (Voir �gure 3.6)

Mahdi Kallel 26


Fig. 3.6. authenti�cation et passage en mode chi¤ré

Si le mobile répond, le BSC envoi le SRES calculé par le mobile au MSC dans un message

AUTHENTICATION RESPONSE (AUTRP). L�automate fait alors la transition suivante :

BSC MSC

AUTRPOC_AUT_REQ_1 OC_AUT_RP

Une fois le mobile est authenti�é, le MSC envoi une commande de chi¤rement de la couche

BSSMAP CMCMD (Cipher Mode CoMmanD). Ceci correspond à la transition suivante :

MSC BSCOC_AUT_RP OC_CIM_CMD

CMCMD

Le mobile répond alors positivement si tout est bien passé. Il envoi le message CMCMP

(Cipher Mode CoMPlete). Ce message fait changer l�état de l�automate comme suit :

BSC MSCOC_CIM_CMP

CMCMPOC_CIM_CMD

Mahdi Kallel 27


3.2.1.4 Début d�appel

Après la phase de l�authenti�cation et du passage en mode chi¤ré, vient la phase de début

d�appel ( On ne parle pas encore du début de la conversation). Dans cette phase les données

nécessaires pour l�établissement d�appel sont envoyées par le mobile (voir �gure 3.7)

Fig. 3.7. Début d�appel

Le passage à cette étape correspond à la transition suivante :

BSC MSCOC_SETUP

SETUPOC_CIM_CMP

Selon le numéro demandé, le MSC route l�appel. Il informe dans ce cas le mobile que l�appel

est en cours. Ceci Correspond à un message CPROC (Call PROCeeding) qui change l�état de

l�automate selon cette transition :

MSC BSCMSC

OC_SETUPCPROC

OC_PROC

3.2.1.5 A¤ectation d�un canal de tra�c

Si le MSC a alloué un circuit, il ordonne le BSC d�attribuer au mobile un canal de tra�c TCH

dans un message ASREQ (ASsignment REQuest). La procédure est illustrée par la �gure 3.8 [6]

Ce message fait changer l�état de l�automate comme suit :

Mahdi Kallel 28


Fig. 3.8. A¤ectation d�un canal de tra�c

MSC BSCMSC

OC_PROCASREQ

OC_ASS_REQ_1

Cette transition fait incrémenter le compteur NbASREQ_OC.Si toute la procédure de l�a¤ectation de canal TCH est terminée avec succès, le BSC envoi le

message ASCMP (ASsignment CoMPlete) au MSC. L�automate change alors d�état :

BSC MSCMSC

OC_ASS_REQ_1ASCMP

OC_ASS_CMP

Cette transition fait incrémenter le compteur NbASCMP_OC.Ainsi on peut dé�nir un indicateur qui caractérise le taux de succès de l�attribution d�un canal

TCH dans la procédure MOC. Cet indicateur est de type Succès/Demandes. Il est donné par la

formule suivante :

Taux_succ�es_attribution_TCH_MOC =NbASCMP_OCNbASREQ_OC

(3.1)

Mahdi Kallel 29


3.2.1.6 Con�rmation d�appel

Si l�appelé est trouvé, le MSC envoie une sonnerie à l�appelant. Le message correspondant est

ALERT (ALERTing) Voir �gure 3.9.

Fig. 3.9. Sonnerie et connexion

La transition correspondante à ce message est la suivante :

MSC BSCMSC

ALERTOC_ASS_CMP OC_SONN

Si l�appelé décroche, MSC fait la connexion avec le mobile par la commande CON (CONnect).

La transition correspondante est la suivante :

MSC BSCMSC

CONOC_SONN OC_CON

S�il est connecté, le mobile envoi un acquittement positif dans un message CONACK

(CONnect ACKnowledge). La transition est la suivante :

BSC MSCMSC

CONACKOC_CON OC_COMM

Mahdi Kallel 30


Cette transition résume le succès de l�établissement d�appel MOC. Elle fait incrémenter le

compteur NbCONACK_OC.Nous pouvons dé�nir l�indicateur de succès d�établissement MOC comme étant succès/demandes,

soit :

Succ�es_�etablissement_MOC_User =Nb_CONACK_OCNombre_Appel_MOC

(3.2)

Cet indicateur re�ète la performance de la procédure MOC comme l�aperçoit l�utilisateur.

En e¤et, un établissement d�appel qui a commencé par SERVICE REQUEST et qui n�est pas

terminé par CONNECT Ack sera considéré comme échoué même si les causes sont normales et

ne représentant pas de problèmes techniques. Nous donnons des exemples de ces causes :

- Appelé occupé ;

- Appelant ou appelé raccroche intentionnellement avant la connexion CONNECT Ack.

Cet indicateur est utile dans la mesure où il permet de mettre en relief les plaintes des

clients et d�analyser le taux d�appels aboutis dans une zone donnée pour voir si les abonnées

communiquent ou non. Mais son insu¢ sance est qu�il induit à l�erreur s�il s�agit d�un problème

purement technique.

Dans ce contexte, notre idée était d�ajouter l�extension USER à cet indicateur pour montrer

sa signi�cation réelle. En outre, il a été indispensable de concevoir un indicateur qui re�ète la

performance de la procédure MOC techniquement.

Pour se faire, nous avons constaté que les causes normales d�abondant d�appel se produisent en

général pendant la phase de con�rmation d�appel, c�est-à-dire pendant la phase de sonnerie. Il en

résulte que le message qui re�ète le succès de la procédure d�établissement d�appel techniquement

est ASSIGNEMENT_COMPLETE : le message qui, suite auquel, un canal TCH est alloué. Ce

message fait incrémenter le compteur NbASCMP_OC.

Ainsi, le taux de succès de l�établissement d�appel sortant MOC techniquement est dé�nit

par :

Succ�es_�etablissement_MOC_Tech =NbASCMP_OC

Nombre_Appel_MOC(3.3)

3.2.2 Echec d�appel sortant

Lors de notre étude des di¤érents scénarios d�échec de l�appel sortant, on a pu identi�er les

messages d�échecs qui transitent à travers l�interface A, et de voir les causes correspondantes. Le

tableau ci-après illustre bien ces messages.

Mahdi Kallel 31


Message/ Sens Causes Description des causesSERVICE_REJECT (MSC-BSC) SONS Service Option Not Supported , serv ice demandé n�est pas valab le.

IUH IMSI Unknown in the HLR

IUV IMSI Unknown in the VLR

NF Network Failure : échec NSS

IMEINA IMEI Not Accepted (Equip em ent volé)

CLEAR REQUEST(BSC -MSC) RIF Radio Interface Failure : le m obile p erd la connexion rad io avec sa BTS

EF Equip em ent Failure : un équip em ent de la partie BSS ne fonctionne pas

R IMF Radio Interface M essage Failure : erreur de m essage sur l�interface rad io .

AUTH REJECT (MSC-BSC) Le mobile donne un SRES erroné

CONNECTIO REFUFED (MSC-BSC) CR Connection SCCP est refusée entre le BSC et le MSC

NC Normal C learing : le m obile qu itte l�app el volontairem ent

INF Invalid Number Format : le m obile compose un format de numéro invalide

UN Unassigned Number : le numéro demandé est invalide

NUR No User Resp onding : l�app elé ne rép ond pas

UB User Busy : app elé o ccup é

NCCA No C ircu it Channel Availab le : pas de circu its valab les au niveau MSC .

NOOO Network Out O f order : le réseau ne rép ond pas

ASSEIGNMENT FAIL (BSC -MSC) NRRA No Radio Resource Availab le : pas de ressources TCH valab les.

R IF EF Même sign i�cation que le m essage C lear request

Tab. 3.1. dé�nition des causes de rejet

L�automate Cigale regroupe les scénarios d�échec de l�appel sortant par le couple (partie,

étape). On distingue :

- Le couple (NSS, étape x) regroupe les scénarios d�échec coté NSS pendent l�étape 1

de l�appel sortant. Il correspond au compteur OCx_AfNSS (x dans {1, 2, 3}). Ce compteurs�incrémente à chaque foi que l�automate détecte un échec d�établissement d�appel sortant pendant

l�étape 1 du à un problème du c�ur du réseau par une transition bien spéci�que. Les causes

Associés à ce compteur sont : NF, NOO, NCCA (voir la dé�nition de ces causes dans le tableau

précédant)

- Le couple (BSS, étape x) regroupe les scénarios d�échec coté BSS de l�appel sortant. Il

correspond au compteur OCx_AfBSS (x dans {1, 2, 3}). Ce compteur s�incrémente à chaquefois que l�automate détecte un échec d�établissement d�appel sortant pendant l�étape 1 du à un

problème dans les équipements de la partie BSS. Les causes associées à ce compteur sont : EF,

NRRA (Voir la dé�nition de ces causes dans le tableaux précédant).

- Le couple (MS, étape x) regroupe les scénarios d�échec de l�appel sortant du côté de

utilisateur. Il correspond au compteur OCx_AfMS : Ce compteur comptabilise l�échec de laprocédure MOC dans sa phase 1 à cause du mobile. Les causes associées à ce compteur sont :

SONS, UIH, UIV, IMEINA, NC, INF, UN, NUR, UB.

- Le couple (BSSMS, étape x) regroupe les scénarios d�échec de l�appel sortant sur l�in-

terface radio. Il correspond au compteur OCx_AfBSSMS : ce compteur est incrémenté s�il ya un échec au niveau de l�interface radio dans la première étape du MOC, par exemple lors de

l�authenti�cation (Voir �gure 3.10). Les causes associées à ce compteur sont : RIF, RIMF.

Mahdi Kallel 32


Fig. 3.10. Echec radio lors de l�authenti�cation

- Le couple (NSSMS, étape x) regroupe les scénarios d�échec de l�appel sortant du à

un problème dans les protocole des couches hautes (CM, RR) qui régissent le dialogue direct

entre la partie NSS et le mobile. Il correspond au compteur OCx_AfNSSMS. Ce compteur estincrémenté s�il y a un problème dans le dialogue du mobile avec les bases de donnés du réseau

au court de la procédure MOC. Les causes associés à ce compteur sont : IUH et IUV.

- Le couple (NSSBS, étape x) regroupe les scénarios d�échec de l�appel sortant du à un

problème de connexion entre le BSC et le MSC. Il correspond au compteur OCx_AfNSSBS.Ce compteur est incrémenté s�il y a un problème de connexion SCCP entre le BSC et le MSC.

La cause associée à ce compteur est CR.

Nous avons pu identi�er ces compteurs en identi�ant les transitions correspondantes aux

messages d�échecs. Ainsi, nous pouvons rassembler des indicateurs de l�échec de l�établissement

de la procédure MOC par cause.

3.2.2.1 Le taux d�échec d�établissement MOC relié à un problème NSS

C�est la somme des échecs cause NSS des trois étapes ensembles divisée par le nombre total

des tentatives MOC, soit :

Echec_MOC_NSS =

3Px=1(OCx_AfNSS +OCx_AfNSSMS +OCx_AfNSSBS)


3.2.2.2 Le taux d�échec d�établissemnt MOC relié à un problème BSS

C�est la somme des échecs cause BSS des trois étapes ensembles divisée par le nombre total

de tentatives MOC, soit :

Mahdi Kallel 33


Echec_MOC_BSS =

3Px=1(OCx_AfBSS +OCx_AfBSSMS)


3.2.2.3 Le taux d�échec d�établissemnt MOC relié à un problème utilisateur

C�est la somme des échecs cause utilisateur des trois étapes ensembles divisée par le nombre

total de tentatives MOC, soit :

Echec_MOC_User =

3Px=1

OCx_AfMS


Nous pouvons ainsi en déduire le taux d�échec de la procédure MOC techniquement, c�est-

à-dire que nous éliminons l�échec de la procédure causé par l�utilisateur car il n�entre pas en

jeux pour la détermination de la performance du réseau. Il en résulte que le taux d�échec de

l�établissement MOC est la somme des indicateurs Echec_MOC_NSS et Echec_MOC_BSS,

soit :

Echec_CALL_SETUP_MOC = Echec_MOC_NSS + Echec_MOC_BSS (3.7)

A partir de là, nous pouvons dégager une autre approche di¤érente de celle citée précédemment

concernant la formule du « Succès_établissement_MOC _Tech » , ce n�est d�autre que :

Succ�es_�etablissement_MOC_Tech = 1� Echec_CALL_SETUP_MOC (3.8)

3.2.3 La Conversation

La phase de la conversation commence après le message de connexion CONNECT ACK. La

chose qui peut le plus gêner l�utilisateur c�est lorsque son appel est coupé involontairement au

cour d�une communication, c�est ce qu�on appelle le « call drop » ou coupure d�appel.

C�est un indicateur crucial pour la détermination de la qualité de service du réseau techni-

quement mais, aussi du côté de l�utilisateur, car ce phénomène engendre en général les plaintes

des clients. Pour la coupure d�appel l�automate Cigale change d�état selon la transition suivante :

OC_COMM OC_COMM_FIN<Message i>

Avec <message i> dans {CLCMD (CLear CoMmanD), CLREQ (CLear REQuest), DISC

(DISConnect), REL (RELease)}

Ces messages varient selon la cause de la coupure. Les causes qui engendrent un call drop

sont : RIF, RIMF, EF, NOOO, CR (Voir la dé�nition de ces causes dans le tableau 4.1). On peut

ainsi dé�nir des indicateurs de performances relatifs à la coupure d�appel par cause.

Mahdi Kallel 34


3.2.3.1 La Coupure d�appel due à un problème BSS

Deux paramètres entrent en jeux, les coupures au niveau des équipements BSS et les coupures

sur l�interface radio. Nous allons donc prendre en compte les compteurs OCcom_AfBSS etOCcom_AfBSSMS, et nous allons les diviser sur le nombre total des conversations sortantesqui est le nombre d�occurrence du dernier message de l�établissement d�appel CONNECT ACK,

Soit :

Coupure_MOC_BSS =OCcom_AfBSS +OCcom_AfBSSMS

NbCONACK_OC(3.9)

3.2.3.2 La Coupure d�appel due à un problème NSS

Les compteurs à prendre en compte sont OCcom_AfNSS, OCcom_AfNSSBS et OC-com_AfNSSMS. Et nous allons les diviser sur le nombre total des conversations sortantes.Soit :

Coupure_MOC_NSS =OCcom_AfNSS +OCcom_AfNSSMS +OCcom_AfNSSBS

NbCONACK_OC(3.10)

3.2.3.3 La Coupure totale d�appel MOC

C�est la somme des deux indicateurs précédents :

Coupure_MOC = Coupure_MOC_BSS + Coupure_MOC_NSS (3.11)

3.3 Les indicateurs MTC

La procédure MTC est identique à la procédure MOC sauf pour la phase d�initiation d�appel.

En e¤et, contrairement à la procédure MOC, celle-ci est initiée par le réseau et non pas par le

mobile. Pour le reste de la procédure tous les indicateurs auront la même dé�nition que leurs

homologues de la procédure MOC. Le réseau lance un avis de recherche du mobile (BSSMAP

PAGING) sur l�ensemble des BSC du LAC du mobile. Si le mobile reçoit cet avis de recherche

de la part de sa BTS, il établit la connexion radio (voir �gure 3.11) :

Mahdi Kallel 35


Fig. 3.11. Recherche du mobile

Le message PAGING ne pouvait pas être le message déclencheur de la procédure MTC pour la

simple raison qu�il est envoyé pour tout les BSC du LAC du mobile recherché, donc sur l�ensemble

des interfaces A relatifs à ces BSC. Si le mobile est trouvé, il envoi au réseau sa réponse à la

recherche (PAGING RESPONSE). (Voir �gure 3.12) :

Mahdi Kallel 36


Fig. 3.12. Réponse au paging

Le déclenchement de toute la procédure de l�appel entrant MTC au niveau de l�interface A

est donné par le message PAGING RESPONSE envoyé par le BSS au MSC. Ce message est

encapsulé dans un message de la couche BSSMAP et accompagné d�une demande de connexion

SCCP entre le BSC et le MSC. L�état de l�automate passe alors de l�état vide (VIDE) à l�état

réponse à la recherche (TC_PAG_RP) selon la transition :

VIDEBSC MSC

PAGRPTC_PAG_RP

PAGRP étant le message PAGING selon la nomenclature Astellia. On peut ainsi dé�nir le

nombre total de demande MTC (initiation d�appel) par la somme de l�occurrence de ce message.

Cependant, les captures sur l�interface A ont un début et une �n. Il se peut que la capture se

ferme alors que la procédure n�est pas encore terminée. Il en résulte qu�on peut trouver quelques

incohérences dans les �chiers générés par ces captures : c�est ce qu�on appelle les « Purges» . Pour

être plus concis, et pour que ce phénomène n�a¤ecte pas nos calculs, il faut retrancher le nombre

de purges du nombre total de tentatives MTC.

Or, la transition mentionnée ci-dessus fait incrémenter le compteur Nb_TC qui �gure dans

le �chier .EFF . Et le nombre de purges de l�appel entrant est donné par le compteur Nb-PURGE_E1_TC pour les Purges de la phase1 de l�établissement d�appel,NbPURGE_E2_TCpour les Purges de la phase2 de l�établissement d�appel et NbPURGE_E3TC pour les Purges

de la phase3 de l�établissement d�appel. Ainsi on obtient la formule générique suivante :

Nombre_tentatives_MTC=Nb_TC-NbPURGE_E1_TC-NbPURGE_E2_TC

Mahdi Kallel 37


-NbPURGE_E3_TC

Pour tout le reste des indicateurs MTC, il s�agit de la même démarche adoptée pour les

indicateurs MOC puisqu�il s�agit quasiment de la même procédure. En conséquence de quoi, on

peut donner la dé�nition des indicateurs suivants :

Taux_succ�es_attribution_TCH_MTC =NbASCMP_TCNbASREQ_TC

(3.12)

Succ�es_�etablissement_MTC_User =Nb_CONACK_TCNombre_Appel_MTC

(3.13)

Succ�es_�etablissement_MTC_Tech =NbASCMP_TC

Nombre_Appel_MTC(3.14)

Echec_MTC_NSS =

3Px=1(TCx_AfNSS + TCx_AfNSSMS + TCx_AfNSSBS)


Echec_MTC_BSS =

3Px=1(TCx_AfBSS + TCx_AfBSSMS)


Echec_MTC_User =

3Px=1

TCx_AfMS


Echec_CALL_SETUP_MTC = Echec_MTC_NSS + Echec_MTC_BSS (3.18)

Succ�es_�etablissement_MTC_Tech = 1� Echec_CALL_SETUP_MTC (3.19)

Coupure_MTC_BSS =TCcom_AfBSS + TCcom_AfBSSMS

NbCONACK_TC(3.20)

Coupure_MTC_NSS =TCcom_AfNSS + TCcom_AfNSSMS + TCcom_AfNSSBS

NbCONACK_TC(3.21)

Coupure_MTC = Coupure_MTC_BSS + Coupure_MTC_NSS (3.22)

3.4 Les indicateurs d�appel

Ces sont des indicateurs hybrides MTC/MOC. Ils sont déduit à partir des indicateurs MOC

et MTC de la façon suivante :

Si indicateurMOC = x1y1et indicateurMTC = x2

y2

Alors indicateurAppel = x1+x2y1+y2

Mahdi Kallel 38


3.5 Mise à jour de localisation (Location Update)

Comme nous avons fait pour la procédure MOC, nous allons parcourir toute la procédure

de mise à jour de localisation, tirer les messages cruciaux et identi�er les transitions automate

correspondantes. Nous allons déduire ensuite les compteurs bruts qui correspondent à ces transi-

tions pour essayer d�établir les indicateurs clefs de performances de la procédure Location Update

(LU).

3.5.1 Etablissement de la connexion radio

C�est l�étape préliminaire de toutes les procédures GSM initiées par le mobile. Elle consiste

à attribuer un canal SDCCH au mobile par le BSC. Nous n�allons pas en tenir compte pour la

détermination de la performance du la procédure LU vu qu�elle est indétectable sur l�interface A.

3.5.2 Indication de service

Après la commutation sur canal SDCCH, le mobile envoie une demande de mise à jour de

localisation qui contient des informations sur le type de cette mise à jour et sur l�identité du

mobile (voir �gure 3.13).

Fig. 3.13. Demande de service

Cette demande est transmise au MSC par le biais du message UPDATING_REQUEST en-

capsulé dans un message de la couche BSSMAP et accompagné par une demande de connexion

SCCP entre MSC et BSC. Ce message traduit le déclenchement de toute la procédure LU. L�au-

tomate Astellia fait la transition correspondante suivante :

Mahdi Kallel 39


VIDE LU_NLUREQ

BSC MSC

Dans cette transition, l�état de l�automate passe de l�état initial vide (VIDE) à LU_N (Lo-

cation Updating Normal). Selon le type de demande de mise à jour de localisation, cet état

est :

- LU_P pour une mise à jour de localisation périodique,

- LU_N pour une mise à jour de localisation normale,

- LU_IA pour une mise à jour de localisation IMSI Attach.

Cette transition fait incrémenter le compteur NbLUREQ_NU pour le LU normal, NbLU-REQ_P pour le LU periodique et le NbLUREQ_IA pour le LU IMSI Attach. On doit, bien

entendu, retrancher le nombre des purges sur cette procédure. Cependant, l�automate ne comp-

tabilise que les purges pendant la mise à jour de localisation périodique, il ne le fait pas pour les

deux autres types (LU_P et LU_IA). Nous pouvons en déduire le nombre de tentative LU pour

chaque type :

Nombre_tentativesLU_N = NbLUREQ_NU �NbPURGE_LU_NUNombre_tentativesLU_P = NbLUREQ_P

Nombre_tentativesLU_IA = NbLUREQ_IA

3.5.3 Allocation Numéro temporaire

Après l�authenti�cation et le passage en mode chi¤ré, le nouveau VLR du mobile fait une

allocation d�un nouveau TMSI pour le mobile (Voir �gure 3.14).

A noter que s�il s�agissait d�un LU ave IMSI Attach, une étape de demande du IMSI est

ajoutée avant l�authenti�cation.

Mahdi Kallel 40


Fig. 3.14. Allocation TMSI

Le message LOCATION_UPDATING_ACCEPT envoyé du MSC au BSC traduit, de point

de vue interface A, le succès de la procédure LU. Ce message correspond à la transition suivante

de l�état de l�automate :

LU_COMMLUACC

LU_FINMSC BSC

Cette transition fait incrémenter le compteur NbLUACC_NU s�il s�agit d�un LU normale,

NbLUACC_PU s�il s�agit d�un LU périodique. Pour LU avec IMSI Attach l�automate n�implé-

mente pas de compteurs spéci�ques. La déduction du taux de succès de la procédure LU en faisant

le rapport du nombre des messages de succès (ACCEPT) sur le nombre total de demandes est

désormais possible. Nous aurons alors les formules génériques suivantes :

Taux_Succ�es_LU_N =NbLUACC_NU

Nombre_tentativesLU_N(3.23)

Taux_Succ�es_LU_P =NbLUACC_PU

Nombre_tentativesLU_P(3.24)

3.5.4 Echec LU

Comme le cas de la procédure MOC ou MTC, les causes d�échec sont regroupées par partie :

NSS, BSS et MS. En cas d�échec l�automate Astellia fait la transition suivante :

Mahdi Kallel 41


LU_NLUREJ

LU_FIN

Le message correspondant est LU REJect (Location Updating REJect). Cette transition

fait incrémenter le compteur LU_N_Fail_User s�il s�agit d�un échec causé par l�abonné,LU_N_Fail_BSS s�il s�agit d�un échec d�origine BSS et LU_N_Fail_NSS s�il s�agit d�unéchec d�origine NSS. Ceci concerne le LU normale. Pour le LU périodique ou IA, c�est le même

principe sauf que la nomenclature change. (Au lieu la lettre N pour normale on trouve la lettre

P pour périodique et IA pour IMSI Attach). Le calcul du taux d�échec LU est alors possible en

faisant le rapport nombre de message d�échec sur nombre total de tentatives :

Taux_�echec_LU_USER = NU_N_FAIL_USER+NU_P_FAIL_USER+NU_IA_FAIL_USERNombre_tentativesLU_N+Nombre_tentativesLU_P

Taux_�echec_LU_BSS = NU_N_FAIL_BSS+NU_P_FAIL_BSS+NU_IA_FAIL_BSSNombre_tentativesLU_N+Nombre_tentativesLU_P

Taux_�echec_LU_NSS = NU_N_FAIL_NSS+NU_P_FAIL_NSS+NU_IA_FAIL_NSSNombre_tentativesLU_N+Nombre_tentativesLU_P

On peut véri�er que la somme des taux d�échec NSS, USER et BSS n�est d�autre que la

di¤érence (1-taux de succès) déjà calculé.

3.6 Les indicateurs Handover

Parmi les maillons faibles du suivi de la performance du réseau GSM à partir de l�interface A,

on distingue une limite pour la procédure handover. En e¤et, les messages relatifs aux handovers

intra-BSC ne transitent pas sur l�interface A. Il semble alors évident que seule la mesure de la

performance du handover inter-BSC sera prise en compte par le biais de l�interface A.

3.6.1 Handover interBSC

3.6.1.1 Handover sortant

Le mobile échange avec sa station de base des rapports de mesures sur la qualité du lien radio

et la puissance du signal, si la qualité ou la puissance est au dessous d�un minimum requis, et que

la cellule cible appartient à un autre BSC, alors le BSC origine demande un handover Inter-BSC

auprès du MSC par le biais d�un message de la couche BSSMAP HORQD (HandOver_ReQuireD)

(voir �gure 3.15).

Mahdi Kallel 42


Fig. 3.15. Handover sortant

Ce message traduit le déclenchement de toute la procédure Handover sortant. Il est possible

de constater que l�état de l�automate ne change pas pendant l�établissement et l�exécution du

handover. IL reste celui de la procédure en cours. IL en résulte que les transitions dans la procédure

handover sortant correspondent à des messages sans changement d�état. A titre d�exemple, la

transition suivante traduit la demande de handover sortant pendant un appel entrant en phase

de communication :

TC_COMM TC_COMMHORQD

BSC MSC

Et la transition suivante traduit la demande de handover entrant pendant un appel sortant

en phase de sonnerie :

TC_SONN TC_SONNHORQD

BSC MSC

L�occurrence du message HORQD est donnée par le compteur EtHoTotal_THorqd. Lenombre de purges sur HO sortant est donné par le compteur NbPURGE_E1_HO. Il enrésulte que le nombre total de demandes de HO sortant est :

Nombre_tentatives_HO_sortant = EtHoTotal_THorqd�NbPURGE_E1_HO (3.25)

Mahdi Kallel 43


Si le BSC cible a accepté la demande, Le MSC envoie alors au BSC origine un message

HO COMMAND qui le transmet à son tour au mobile pour l�ordonner à exécuter le handover.

Ce message fait incrémenter le compteur EtHoTotal_THocmd. Pendant cette phase de laprocédure, il est utile de concevoir un indicateur qui re�ète la performance de la procédure du

handover en disponibilité des ressources ou bien l�absence de cellules capables de supporter le

mobile dans le BSC cible. Cet indicateur calcule le taux de réponse du BSC cible par rapport au

nombre total des demandes handover. Nous obtenons donc :

Taux_HO_InterBSC_Sortant_Reponse =EtHoTotal_THocmd

Nombre_tentatives_HO_sortant(3.26)

Après sa reception de l�ordre de l�exécution du handover, le mobile va essayer de rejoindre le

nouveau canal sur le BTS cible (voir �gure 3.16).

Fig. 3.16. suite Handover sortant

Si le mobile réussit à atteindre le BTS cible. Alors le MSC envoie un message CLEAR COM-

MAND au MSC. Il résume le succès de la procédure du HO sortant coté interface A origine. Ce

message de la couche BSSMAP fait incrémenter le compteur EtHoTotal_THoClmd. Le tauxde succès du handover sortant est alors le rapport de l�occurrence de ce message sur le nombre

total de tentatives HO sortant. Soit :

Taux_HO_InterBSC_Sortant_Succ�es =EtHoTotal_THoClmd

Nombre_tentatives_HO_sortant(3.27)

3.6.1.2 Handover entrant

Un handover est considéré comme entrant pour la cellule cible. Dans cette partie, nous n�allons

tenir compte que les messages qui transitent à travers l�interface A dans le BSS cible. Le MSC

transmet le message HOREQ (HandOver_REQuest) au BSC cible (voir �gure 3.17).

Mahdi Kallel 44


Fig. 3.17. Handover entrant

L�état de l�automate fait donc la transition suivante :

VIDE HO_TCH_REQHOREQ

MSC BSC

L�occurrence de cette transition sur l�interface A traduit le nombre de demandes de handover

entrant. Et puisqu�elle fait incrémenter le compteur NbHORQ_HO et que le nombre de purges

sur le HO entrant est donné par NbPURGE_E2_HO, nous pouvons conclure donc que :

Nombre_tentatives_HO_entrant = NbHORQ_HO �NbPURGE_E2_HO (3.28)

Ensuite, le BSC cible active un canal radio sur la BTS demandée. Si cette action s�est déroulée

avec succès, le BSC envoie un message d�acquittement accompagné d�une commande d�exécution

du handover. Dans ce cas, l�état de l�automate fait la transition suivante :

HO_TCH_RACHORAC

BSC MSCHO_TCH_REQ

Cette transition fait incrémenter le compteur NbHORQACK_HO. Si cette transitionn�abouti pas, alors on peut conclure qu�il y a un problème de disponibilité de ressources radios.

Mahdi Kallel 45


L�idées été de concevoir un indicateur qui met en évidence ce problème. C�est donc le rapport de

l�occurrence du message HORAC sur le nombre total de tentatives des HO sortants, soit :

Taux_HO_InterBSC_entrant_Reponse =NbHORQACK_HO

Nombre_tentatives_HO_entrant(3.29)

Ensuite, le BTS cible attend le mobile. Si ce dernier réussit à accéder au canal déjà alloué

sur l�interface air, alors le BTS le détecte et envoie un message HO DETECTON au BSC qui le

transmet à son tour au MSC dans un message HODET (HO DETection) de la couche BSSMAP

(voir �gure 3.18).

Fig. 3.18. Suite handover entrant

L�automate Astellia change d�état selon la transition suivante :

HO_TCH_DETHODET

BSC MSCHO_TCH_RAC

Cette transition fait incrémenter le compteur NbHODET_HO. Dans le cas échéant, c�est-à-dire que le message n�aboutit pas, on peut déduire que le mobile n�a pas pu rejoindre la nouvelle

cellule à cause d�un problème radio. Concevoir un taux de détection de handover pouvait aider à

analyser les problèmes radio. Cet indicateur est le rapport du nombre des messages de détection

sur le nombre total de réponse du BSS cible, soit :

Mahdi Kallel 46


Taux_HO_InterBSC_entrant_Detect =NbHODET_HO


Si le mobile termine la connexion radio avec le BTS cible, Le BSC cible envoie au MSC

un message HOCMP (HO CoMPlete) qui indique que la procédure du handover sortant a été

exécutée avec succès. Ce message engendre la transition suivante :

HO_TCH_FINHOCMP

BSC MSCHO_TCH_DET

Cette transition fait incrémenter le compteur NbHOCMP_HO. Nous pouvons alors conce-voir l�indicateur du taux de succès du handover entrant comme suit :

Taux_HO_InterBSC_Entrant_Succ�es =NbHOCMP_HO


3.6.2 Handover intraBSC

Le seul message qui transite à travers l�interface A pendant la procédure du handover intra

BSC est le message HANDOVER_PERFORMED qui est envoyé par le BSC cible au MSC à la

�n d�un handover intra-BSC é¤ectué avec succès.

Ce message contient des informations tels que la cause du handover. Il est possible de conce-

voir un indicateur de répartition des causes du handover. Mais malheureusement, il y avait un

problème avec le �chier .XLH qui contient ce type d�informations. Ce �chier fait apparaître des

valeurs erronées. L�équipe QDF a contacté le fournisseur Astellia qui en a pris charge.

3.7 Les indicateurs SMS

Il existe deux scénarios de l�envoi d�SMS : SMS entrant ou SMS sortant. Pour l�SMS sortant,

le mobile envoi son SMS dans un message de type RP-DATA (voir �gure 4.19).

Mahdi Kallel 47


Fig. 3.19. SMS Sortant

Ce message constitue l�événement déclencheur de la procédure SMS, nous allons donc prendre

l�occurrence de ce message comme étant le nombre de total d�SMS envoyés par le mobile. Ce

message engendre la transition suivante :

MOSMS_SUBSMS_SUBMIT

HOCMPBSC MSC

MOSMS_EST

Cette transition fait incrémenter le compteur SmsSubmit. Le nombre total de SMS sortantsest alors :

Nb_SMS_OC = SmsSubmit (3.32)

Si le message arrive au SMSC (SMS Center) et ce dernier envoi un acquittement positif, le

MSC retransmet cet acquittement au BSC qui le retransmet à son tour au mobile. Il s�agit du

message RPack. (Voir second message encerclé dans la �gure). Ce message engendre la transitionsuivante :

MOSMS_SUB_FINRPack

MSC BSCMOSMS_SUB

Cette transition fait incrémenter le compteur SmsSubmit_RPack. Il en résulte que le tauxde succès de message sortant est donné par :

Mahdi Kallel 48


Taux_Succ�es_SMS_OC =SmsSubmit_RPackNb_SMS_OC

(3.33)

Le même principe est pour le transfert du SMS entrant sauf que le sens des messages s�inverse

et le nom des compteurs change. La transition qui déclenche la procédure au niveau de l�interface

A est la suivante

MTOSMS_DELSMS_DELIVER

MSC BSCMTSMS_EST

Cette transition fait incrémenter le compteur SmsDeliver. Le nombre total de SMS sortantsest alors :

Nb_SMS_TC = SmsDeliver (3.34)

Si le message arrive au mobile et ce dernier envoi un acquittement positif, alors le BSC

retransmet cet acquittement au MSC qui le retransmet à son tour au SMSC (SMS Center). Il

s�agit du message RP_MO_ack. Ce message engendre la transition suivante :

MOSMS_SUB_FINRP_MO_ack

MSC BSCMOSMS_DEL

Cette transition fait incrémenter le compteur SmsDeliver_RPack. Il en résulte que le tauxde succès de message entrant est donné par :

Taux_Succ�es_SMS_TC =SmsDeliver_RPackNb_SMS_TC

(3.35)

Il existe des scénarios et des messages d�erreurs si la procédure de transmission d�un SMS

n�abouti pas. Il y a un ensemble de transitions d�échec qui font incrémenter des compteurs d�échec.

Comme on a vu pour les autres procédures, les causes d�échec peuvent être groupées par

partie ; BSS ou NSS. Cela nous permet de concevoir des indicateurs d�échec à partir des compteurs

d�échec associés.

Lorsque l�échec est du à un problème BSS le compteur SmsDeliver_Fail_BSS est incré-menté pour le SMS entrant et le compteur SmsSubmit_Fail_BSS est incrémenté pour le SMSsortant. Le taux d�échec de transmission SMS du à un problème BSS est donné par :

Taux_Echec_SMS_BSS =SmsDeliver_Fail_BSS + SmsSubmit_Fail_BSS

Nb_SMS_TC +Nb_SMS_OC(3.36)

Lorsque l�échec est du à un problème NSS le compteur SmsDeliver_Fail_NSS est incré-menté pour le SMS entrant et le compteur SmsSubmit_Fail_NSS est incrémenté pour le SMSsortant. Le taux d�échec de transmission SMS du à un problème NSS est donné par :

Mahdi Kallel 49


Taux_Echec_SMS_NSS =SmsDeliver_Fail_NSS + SmsSubmit_Fail_NSS

Nb_SMS_TC +Nb_SMS_OC(3.37)

3.8 Des indicateurs Divers

3.8.1 Le double appel

Si quelqu�un appelle un abonné en cours de communication, l�appel sera mis en attente. Si

l�appelé décide de basculer entre les deux appels qui lui sont arrivés, il doit immédiatement mettre

l�un d�eux en garde car il ne peut pas faire deux communications à la fois. Cette procédure est

appelée le double appel. Elle peut être activée en communication sortante comme elle peut être

activée en communication entrante. La transition qui correspond à une mise en attente pour un

appel sortant est :

OC_CALLWAITINGMOSMS_SUB_FIN

ALERT

BSC MSCOC_COMM

Cette transition fait incrémenter le compteur NbHOLDACK_OC. Et la transition quicorrespond à une mise en attente pour un appel entrant est :

TC_CALLWAITINGMOSMS_SUB_FIN

ALERT

MSC BSCTC_COMM

Cette transition fait incrémenter le compteur NbHOLDACK_TC.Nous pouvons doncconcevoir l�indicateur :

Nombre_MiseAttente = NbHOLDACK_OC +NbHOLDACK_TC (3.38)

L�appelé a le choix : soit de basculer entre les deux communications soit de maintienir la

communication en cours et négliger celle qui est arrivée jusqu�à ce que ce dernier termine de

sonner. Dans ce cas l�état de l�automate rentre à son état d�origine de communication OC_COMM

et la transition est la suivante pour l�appel sortant :

RELCMP

MSC BSCOC_CALLWAITING OC_COMM

Cette transition fait incrémenter le compteur NbRETACK_OC. De même, le compteur

NbRETACK_TC est incrémenté en cas d�appel entrant. Le nombre de basculement entre appels

est alors donné par :

Nombre_double_appel = (NbHOLDACK_OC +NbHOLDACK_TC)�(NbRETACK_OC +NbRETACK_TC)

Mahdi Kallel 50


3.8.2 Connexion SCCP

Avant chaque transfert de messages entre MSC et BSC, une connexion SCCP est requise. Le

SCCP est un protocole qui garantie le transfert �able de signalisation entre deux n�uds sur le

réseau se signalisation SS7.

Astellia n�implémente sur son analyseur de protocole que les connexions SCCP pour les pro-

cédures LU, MTC et MOC et ne capte que les messages de type CC (Connection Con�rm) ou

CREF (Connection REFused). A partir de là, Nous avons eu l�idée de concevoir un indicateur qui

calcule le taux d�échec de la connexion SCCP pour les procédures précitées. Il s�agit du rapport de

nombre de refus de connexions sur le nombre de demande total de connexions. Chaque message CC

fait incrémenter les compteurs NbCC_LUia, NbCC_LUnu, NbCC_LUpu, NbCC_OCet NbCC_TC respectivement pour les procédures LU IMSI Attach, LU normal, Lu périodique,

MOC et MTC. Chaque message CREF fait incrémenter les compteurs NbCREF_LU et Nb-CREF_OCTC respectivement pour les procédures LU, MTC et MOC ensembles. Il en résulte

que l�indicateur du taux de refus SCCP a comme formule :

Taux_�echec_Connexion_SCCP =NbCREF_OCTC +NbCREF_LU

Nombre_ConnexionSCCP(3.39)

3.8.3 Indicateur de tra�c

Il est important de savoir l�évolution du tra�c écoulé dans le temps par objet (Cellule, BSC,

MSC). Pour chaque circuit (IT MIC), il est possible de dé�nir le taux d�occupation relatif. En

introduisant �pour représenter ce taux, il est dé�ni de la manière suivante :

� =Na �Da24� 3600 (3.40)

Dans cette expression Na représente le nombre d�appels passés ou reçus par jour dans le

circuit concerné, Da représente la durée moyenne d�un appel en secondes. En�n le produit 24

�3600 représente la durée d�une journée en secondes. On dé�nit ainsi l�occupation du circuit.L�unité retenue pour est l�Erlang. Ainsi un tra�c de 1 Erlang (1 E) correspond à un circuit

occupé 24 heures sur 24.

Du coté de la capture sur l�interface A, la durée d�occupation d�un circuit est calculée sur

chaque ITs des MICs entre BSC et MSC après transcodage. Elle est calculée pendant la procédure

MOC ou MTC entre le message CONNECT et le message DISCONNECT.

Dans cette optique, le �chier .XLT qui contient la répartition du tra�c sur chaque IT de

chaque MIC semble le plus intéressant (Voir �gure 3.20) :

Mahdi Kallel 51


Fig. 3.20. Répartition du tra�c

Dans ce tableau Dmoy conv correspond à Da et Nb conv correspond à Na.Il en résulte que le

taux d�occupation d�un circuit est donné par :

� =Nbconv �Dmoyconv

24� 3600 (3.41)

Les indicateurs conçu doivent être mis en pratiques pour pouvoir les visualiser. Leurs im-

plémentation logicielle dans un outil informatique s�avère donc nécessaaire est interressante. Le

chapitre suivant va décrire l�application informatique développée en commençant par la concep-

tion informatique ensuite en passant vers la réalisation.

Mahdi Kallel 52

Chapitre 4

Implémentation logicielle

Projet de �n d�études Implémentation logicielle

4Implémentation logicielle

Ce chapitre décrit la mise en oeuvre de l�outil informatique développé. Il commence par

expliquer les choix techniques des langages de programmation et des outils utilisés. Ensuite,

il s�intéresse à la conception informatique. En�n il cite une description des résultats aboutis

approuvés par quelques captures d�écrans.

4.1 Conception

4.1.1 Entrée/sortie et architecture de l�application

Cette application doit mettre aux indicateurs clefs de performances conçus à partir de capture

sur l�interface A une utilité pratique. Elle doit permettre de suivre l�évolution de ces indicateurs

par cellule, BSC, MSC et LAC. Cette évolution est non seulement par objet, mais aussi dans le

temps. Pour se faire, les données qui existent dans les �chiers générés par captures de l�analyseur

de protocole sont les sources de base des données. L�outil doit les traiter de façon harmonique

avec l�architecture de la base de données dans laquelle elles seront stockées. Après le traitement

et la centralisation des données, le programme doit savoir exécuter les requêtes convenables et

e¤ectuer les calculs nécessaires pour pouvoir a¢ cher les courbes et les statistiques souhaitées.

Avant d�avancer dans les détails de la conception, il faut tout d�abord choisir une architecture

convenable pour notre application. L�architecture choisie était l�architecture client-serveur (2-

tiers). Les applications complexes peuvent tirer pro�t d�une base de données et accéder aux

informations qu�elle contient en envoyant des requêtes SQL à un serveur pour lire et écrire les

Mahdi Kallel 54


données. Dans ce cas, la base de données fonctionne dans un processus indépendant de celui

de l�application, et parfois sur une machine di¤érente. Les composants permettant l�accès aux

données sont séparés du reste de l�application.

Fig. 4.1. Architecture client-serveur

Plusieurs utilisateurs de l�application peuvent l�utiliser simultanément. Un des inconvénients

de l�architecture deux-tiers est que la logique chargée de la manipulation des données et de

l�application des règles métiers est incluse dans l�application elle-même. Cela pose un problème

lorsque plusieurs applications doivent partager l�accès à une base de données.

Face à la multitude d�architectures informatiques existantes et des moyens de développement

associés, nous devons adopter une solution répondant aux besoins et à la nature même de l�ap-

plication. Pour choisir la bonne solution, il faut se baser sur des critères de choix qui sont dans

notre cas :

- Centraliser les données pour une multi-utilisation ;

- Alléger l�application du coté du client ;

- Fournir une interface homme machine conviviale.

L�architecture client-serveur, elle, répond à ces besoins, pour cela nous l�avons donc choisi.

En se basant sur l�architecture précédente et sur les entrées-sorties du système, nous avons

pu dégager le schéma synoptique suivant :

4.1.2 Choix de l�environnement de développement

Le choix du logiciel de développement est en fonction des exigences de l�application et de

degré de ses performances. Dans le cadre de cette application, nous avons besoin d�une part de

la gestion des �chiers et d�autre art d�un stockage des données de ces �chiers dans une base

de données. En outre, on a besoin de l�exécution des requêtes SQL pour l�a¢ chage de certains

résultats. Plusieurs logiciels de développement peuvent être utilisés ; tels que Windev, Visual

Basic, Delphi et visual C++ qui o¤rent tous presque les mêmes privilèges. Par ailleurs en tenant

compte des fonctionnalités o¤ertes par Windev à savoir la souplesse de traitement des �chiers et

la manipulation des bases de données, nous avons choisi de retenir ce langage de programmation.

4.1.2.1 Windev (w-Language)

WinDev 10 est un atelier de génie logiciel qui inclut plusieurs outils et modules tels que le

WDMap (Visionneur Hyper File), le WDOutil (outils d�administration Hyper File), le WDTrans

Mahdi Kallel 55


Fichiers TXT

Préparation etcentralisation des

données

Extraction Centralisation

DB SQL Server Output

Reporting enformat text

Graphes

FichiersExcel

ApplicationWindev

Input

Fig. 4.2. Architecture du système

(gestionnaire de transaction), etc.

Parmi les nombreux atouts de WinDev �gure le W-langage qui est le langage de dévelop-

pement utilisé. C�est un langage de la cinquième génération (L5G), donc il est à la fois assez

simple et puissant. De plus, et c�est le plus important pour notre projet, WinDev a la capacité

de s�interfacer avec des codes écrits avec d�autres langages tels que Java, C, C#, Visual Basic,

Cobol, Fortran, etc. En�n, et c�est un plus pour notre outil, WinDev permet de créer des fenêtres

conviviales dont la gestion, la manipulation et la programmation sont assez simpli�ées.

Les caractéristiques que nous venons de citer sont, de fait, à la base du choix de WinDev 10

comme environnement de développement.

4.1.2.2 Le SGBD SQL SERVER 2000

Une base de données ( eng data base) est un ensemble structuré de données logiquement

reliées entre elle et enregistrées sur des supports accessibles par l�ordinateur, représentant des

informations du monde réel et pouvant être interrogées et mises à jour simultanément et de façon

sélective.

SQL SERVER est un système de gestion de base de données. A l�aide de ce logiciel nous

pouvons gérer nos informations.

Dans le cadre de notre projet, nous avons choisi SQL SERVER pour stocker et gérer des

données contenues dans les �chiers car il permet l�accès à la base à distance. Dans cette base on

distingue toutes les tables nécessaires pour l�exécution de l�application.

Mahdi Kallel 56


4.1.3 Conception opérationnelle de l�application

La conception opérationnelle est la partie dans laquelle sont dressé les solutions prévues pour

le fonctionnement des di¤érents modules spéci�és dans le cahier des charges du projet. (Voir

annexeB pour mieux comprendre la conception par le language UML)

4.1.3.1 Modèle de cas d�utilisation (Use Cases)

L�intérêt des Use Cases est de traiter l�interaction entre les acteurs et le système d�une manière

formelle. Selon les cas d�utilisation nous pouvons déduire plusieurs scénarios dont la détermination

dépend essentiellement de ce que l�utilisateur attend du système. Compte tenu du besoin de notre

application, il s�avère que les acteurs éventuels se réduisent à un seul Utilisateur-Administrateur.

La �gure ci-après illustre le scénario complet d�une utilisation complète du système. On trouve

donc la fonction primordiale d�insertion des données dans la base de données, du suivi de l�évo-

lution des indicateurs de performances dans le temps et par objet, et en�n de la génération du

rapport.

Générer le rapport

Suivre l’évolution desindicateurs par objet

Suivre l’évolution desindicateurs dans le temps

Choisirl’indicateur

Choisir la duréed’observation

Choisir l’objet

Choisir la dated’observation

<<include>>

<<include>>

Choisirtype de courbe

<<extend>>

<<extend>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Insertion desdonnée dans la

baseCréation de la base

de donnée

Charger la topologiedu réseau

<<include>>

<<include>>

Fig. 4.3. Diagramme de cas d�utilisation

4.1.3.2 Diagramme de séquences

Le diagramme de séquences illustre le fonctionnement du système dans le temps. Il permet

d�analyser l�avancement chronologique des interactions entre les objets du système et de mieux

comprendre son fonctionnement interne. Le diagramme est structuré de la manière suivante : Le

diagramme possède un axe des temps dirigé du haut vers le bas. Chaque objet étudié dispose

d�une ligne de vie (ligne verticale pointillée). Sur ces lignes de vie, des périodes d�activité sont

Mahdi Kallel 57


indiquées par des rectangles �ns dont les extrémités représentent le début et la �n de l�activité.

Les messages échangés entre les di¤érentes entités sont représentés par des �èches horizontales

orientées de l�émetteur vers le destinataire. Lorsque le message possède un temps de propagation

non négligeable, les �èches sont alors obliques.

Diagramme de séquences d�insertion des données dans la base : L�utilisateur

sélectionne les �chiers à charger dans la base de donnée. L�outil d�application se charge alors de

faire des traitements nécessaires sur ces �chiers, et il envoi les requêtes appropriées au serveur de

base de donnée. Ce dernier exécute les requêtes. Les entités sont : l�utilisateur, l�outil d�application

et le serveur application.

Utilisateur L’outild’application Serveur de base de données

Lancer l’application

Interface lancée

Choisir le f ichier à charger dans la base

Fichier choisi

Lancer le traitement des fichiersTraiter les fichier

Construire les requêtes d’insertion Exécuter les requêtes

Requêtes éxcécutées

Données insérées

Fig. 4.4. Diagramme de séquences d�insertion des données dans la base

Diagramme de séquence de génération des courbes Ce diagramme décrit le dérou-

lement des étapes nécessaires à la génération des courbes. L�utilisateur commence par choisir le

type de la courbe, choisir l�indicateur et choisir la date de capture. Il pouvait personnaliser ces

paramètres.

L�outil d�application, lui, �ltre les données. Il construit les requêtes de sélections appropriées

selon les paramètres �xées par l�utilisateur. Il les envoie au serveur base de donnée qui les exé-

cute et renvoie les résultats à l�outil. Celui-ci fait la mise en forme des courbes et les a¢ che à

l�utilisateur.

4.2 Réalisation

Nous avons essayé, dans la réalisation de ce projet, d�automatiser le plus possible la phase de

post traitement. C�est un ensemble d�opérations qui permettent en�n d�insérer les données dans

la base de donnée.

Le menu dédié à la phase de traitement et de la centralisation est le menu « traitement » .

La �gure suivante montre ce menu et les sous menus rattachés.

Mahdi Kallel 58


Utilisateur L’outild’application Serveur de base de données

Lancer l’appliction

Interface lancée

Choisir les paramètres de l’affichage

Paramètres choisis

Demander l’affichage des courbes Filtrage des données

Construire les requêtes de sélection Exécution des requêtes

Résultat des requêtes de selectionMise en forme des courbes

Courbes affichées

Fig. 4.5. Diagramme de séquence de génération des courbes

L�action de création des tables de la base de données doit être faite une seule fois. C�est-à-dire

qu�il ne faut créer les tables que si elles n�étaient pas crées.

En cliquant sur le sous menu « insertion des donnée dans la base » , une fenêtre qui contient

deux anglets s�ouvre, l�un pour charger la topologie du réseau et l�autre pour faire le traitement

des �chiers.

Mahdi Kallel 59


En appuyant sur le bouton parcourir, nous pouvons choisir le �chier à charger dans la base

puis en appuyant sur le bouton Charger, le chargement du �chier souhaité dans la base commence.

Mahdi Kallel 60


Après chargement des données dans la base de données, nous pouvons faire les analyses

souhaitées. Pour ce faire, il existe deux menus, l�un pour faire une analyse par objet : cellule,

BSC, MSC et LAC pour une journée donnée. Et l�autre pour faire une analyse dans le temps

pour chaque objet. La fenêtre pour faire une analyse par cellule est la suivante.

Mahdi Kallel 61


Ici nous devons choisir le BSC pour lequel on souhaite a¢ cher les cellules, nous devons choisir

l�indicateur à calculer et choisir la date de capture, et c�est optionnel de choisir le type de graphe.

En appuyant sur le bouton a¢ cher, la courbe correspondante aux paramètres �xés s�a¢ che.

Mahdi Kallel 62


La même procédure se fait si on désire a¢ cher les statistiques par BSC, MSC et LAC. La

�gure suivante montre une analyse par BSC pour l�indicateur de coupure d�appel :

Nous pouvons modi�er les paramètres de la courbe en faisant un click droit sur la courbe. On

peut inverser les axes, faire une légende, modi�er la police, changer le type de graphe, imprimer

et enregistrer le graphique.

Le menu analyse dans le temps permet de montrer une évolution dans le temps d�un indicateur

donné sur un objet donné : cellule, BSC, MSC et LAC. Par exemple, la �gure suivante montre

l�évolution du taux de succès SMS sur une période donnée sur un MSC donné

Mahdi Kallel 63


En�n, après que l�analyse est faite, nous pouvons générer un rapport de QoS en sélectionnant

le menu « �chier » ensuite l�option «générer le rapport » .

Mahdi Kallel 64


L�implémentation logicielle des indicateurs conçus a permi de suivre leurs évolutions par

cellule, BSC, MSC ou LAC. La sélection des données et leurs rassemblements et l�a¢ chage des

statitistiques auraient pu être plus longs à manipuler s�ils étaient manuels. L�implémentation

logicielle fait gagner beaucoup de temps.

Le chapitre suivant va détailler la validation de quelques indicateurs ainsi que quelques études

de cas.

Mahdi Kallel 65

Chapitre 5

Validation et étude de cas

Projet de �n d�études Validation et étude de cas

5Validation et étude de cas

L�objectif de ce chapitre est de valider quelques indicateurs conçus, en les comparant avec

leurs homologues du coté de l�OMC. La validation est d�une importance extrême dans la mesure

où elle met en évidence l�objectivité de nouveaux indicateurs.

Le traitement de quelques exemples et de cas réels en analysant leurs causes et leurs e¤ets

éventuels permet, entre autre, de donner à ces indicateurs une importance technique dans la

pratique.

5.1 Validation

5.1.1 Choix des indicateurs à valider

Vu le nombre relativement élevé des indicateurs conçus, le choix était de valider seulement les

indicateurs qui re�ètent la performance globale de chaque procédure. Autrement dit, pour chaque

procédure GSM, l�indicateur qui résume le succès et / ou l�échec de la procédure est identi�é pour

être validé. Bien entendu, ceci ne voulait pas dire que le reste des indicateurs n�est pas apte pour

être validé.

En conséquence de quoi, les indicateurs à valider sont :

- Succès_établissement_MOC _Tech

- Succès_établissement_MTC _Tech

- Coupure_Appel

- Taux_Succès_LU_Tot

- Taux_HO_InterBSC_Sortant_Succès

Mahdi Kallel 67


- Taux_HO_InterBSC_Entrant_Succès

- Taux_Succès_SMS_OC

5.1.2 Aperçu sur les outils utilisés pour la validation

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

permettant d�explorer les di¤érentes données de qualité de service du réseau, que se soit des

données OMC ou des données équipements. Les principaux outils sont RNO et SPOTS.

5.1.2.1 RNO d�Alcatel

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

CATEL 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.

- Fournir les rapports de la QoS.

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

- 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

5.1.

Mahdi Kallel 68


Fig. 5.1. RNO system (Alcatel)

5.1.2.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 :

- Un outil opérationnel pour un seul constructeur à savoir SIEMENS ;

- Il n�existe pas de traitement par Heure de Pointe ;

- Il n�existe pas d�édition de zones.

5.1.3 Validation de Succès_établissement_MOC _Tech

Connu sous le nom de CSSR_MOC (Call Setup Sucess Rate), cet indicateur détermine le

taux de succès de l�établissement d�appel sortant. Etant donné qu�il faut comparer des choses

comparables, Il a été un peu di¢ cile de voir l�équivalent exact de cet indicateur sur RNO ou

SPOTS. Du coté de RNO, il ne donne pas de taux de succès d�établissement d�appel sortant.

En revanche il accumule les taux d�échecs BSS (radio ou équipements BSS). En général, Utiliser

RNO revient à traiter des problèmes radio.

Coté SPOTS, le problème était qu�il adopte une approche qui dé�ni l�établissement d�appel

comme étant tous les messages échangés avant l�a¤ectation du canal de tra�c TCH.

Contrairement à la notre qui dé�ni l�établissement comme étant tous les messages échangés

avant le début de la conversation proprement dite.

Mahdi Kallel 69


Puisqu�il s�est avéré impossible de comparer l�indicateur en question avec l�indicateur SPOTS

prédé�nit, il a été nécessaire de se référencier à la documentation SIEMENS pour voir la signi�-

cation des compteurs brutes pour pouvoir les adapter à la formule qu�on désire valider.

Les compteurs trouvés étaient des compteurs MSC, c�est-à-dire qu�ils sont implémentés du coté

du MSC. Par conséquent, on va suivre l�évolution des indicateurs par MSC lors de la comparaison.

La formule de Succès_établissement_MOC _Tech conçue sur l�interface A est :

Succ�es_�etablissement_MOC_Tech =NbASCMP_OC


Où NbASCMP_OC désigne le nombre de messages de la �n d�a¤ectation d�un canal de

tra�c et Nombre_Appels_MOC désigne le nombre total de tentatives d�établissement d�un appel

sortant donné par le nombre d�occurrence du message CM_SERVICE REQUEST envoyé par le

BSC au MSC.

Il a fallu chercher le compteur SIEMENS qui est incrémenté suite à la réception de ce message

par le MSC concerné. Le compteur est celui encerclé dans la �gure 5.2 [8].

Fig. 5.2. le compteur SIEMENS de CM_SERVICE_REQUEST

SPOTS donne aux indicateurs SIEMENS une nomenclature dédiée. L�équivalent de ce message

en SPOTS est CA_MORIG Nr.En suivant la même démarche pour le compteur NbASCMP_OC, on trouve que l�équivalent

de ce compteur en SPOTS est CSTCHMOR Nr.

Mahdi Kallel 70


L�étape suivante était de comparer les valeurs du rapport CSTCHMOR Nr/CA_MORIG Nr

avec celles de l�indicateur à valider rassemblés par MSC. L�écart était considérable !

Par la suite, il s�est avéré que cet écart est dû au fait que le compteur CA_MORIG Nrs�incrémente aussi à chaque fois où le MSC fait la redirection de l�appel vers une autre destination

lorsqu�il y a un renvoie d�appel. Il en résulte, en terme de nombre, qu�il y avait une di¤érence

considérable entre CA_MORIG Nr de SIEMENS et Nombre_Appels_MOC de l�interface A.Pour corriger cet écart, il a fallu trouver le compteur MSC SIEMENS qui compte le nombre de

renvoie d�appel et de le faire retrancher du compteur CA_MORIG Nr : C�était le compteurCS_EFOMOR Nr. Le résultat de la comparaison était le suivant sur l�objet MSCx classé par

jour :

CSSR_MOC_InterfaceA Vs CSSR_MOC_SPOTS

0,50,55

0,60,65

0,70,75

0,80,85

0,90,95

1

04/04/2

007

05/04/20

07

06/04/2

007

07/04

/2007

08/04/2

007

09/04

/2007

Jour

CS

SR

_MO

C

CSSR_MOC_SPOTSCSSR_MOC_InterfaceA

Fig. 5.3. Résultat de la comparaison CSSR_MOC

Il est clair qu�il existe une petite di¤érence . Cette petite di¤érence négligeable est due à un

petit retard ou avance de part ou d�autre des captures sur l�interface A ou des captures sur le

MSC.

5.1.4 Validation de Succès_établissement_MTC _Tech

La même démarche était suivie pour valider cet indicateur. La formule de cet indicateur

conçue sur l�interface A est :

Succ�es_�etablissement_MTC_Tech =NbASCMP_TC


Le Nombre_Tentatives_MTC est donnée par le nombre d�occurrence du message PAGIN-

GRESPONSE envoyé par le BSC au MSC. Après la consultation de la documentation SIEMENS,

Le compteur SPOTS relatif était REC_PRMTE Nr [10].De même pour NbASCMP_TC, le compteur SPOTS équivalent étaitCSTCHMTERNr[10].

En calculant le rapport CSTCHMTER Nr/RECPRMTE Nr sur l�objet MSCx et en le comparant

avec les valeurs de l�indicateur interface A en question, les résultats suivants ont été obtenus :

Mahdi Kallel 71


CSSR_MTC_InterfaceA Vs CSSR_MTC_SPOTS

0,50,55

0,60,65

0,70,75

0,80,85

0,90,95

1

04/04/2

007

05/04/2

007

06/04

/2007

07/04/2

007

08/04/2

007

09/04

/2007

Jour

CS

SR

_MTC

CSSR_MTC_SPOTSCSSR_MTC_InterfaceA

Fig. 5.4. Résultat de la comparaison CSSR_MTC

5.1.5 Validation de coupure_Appel

Il a été impossible de valider l�indicateur coupure_Appel par le biais de SPOTS dans la

mesure où ce dernier considère que la communication commence juste après l�a¤ectation d�un

canal TCH, c�est-à-dire après le message ASSIGNMENT_ COMPLETE. Cette approche était

di¤érente de celle adoptée pour la conception de l�indicateur coupure_Appel sur l�interface A, et

qui considère que la communication commence après que l�appelé ait décroché dans le vrai sens

physique de l�action, donc après le message CONNECT_ACK.

D�autre part, dégager les compteurs bruts SIEMENS comme on l�a fait pour la validation du

Call Setup a été inutile vu que SIEMENS n�implémente pas un compteur pour ce message.

Ensuite, il s�est avéré que RNO adopte la deuxième approche. Cependant il ne comptabilise

que le taux de coupure d�appel suite à une cause BSS (radio ou équipements). C�est la raison

pour laquelle, seul l�indicateur Coupure_Appel_BSS pouvait être validé.

Le résultat de comparaison entre les valeurs de cet indicateur prises sur BSCx et �ltrées par

jour, et les valeurs de l�indicateur RNO Call_drop_rate (QSCDR) est illustré par la �gure 5.5.

Mahdi Kallel 72


Call drop RNO Vs Call drop interface A BSS radio

0,00%0,10%0,20%0,30%0,40%0,50%0,60%0,70%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

call

drop

Call drop RNO

Call drop BSS InterfaceA

Fig. 5.5. Résultat de la comparaison Call drop

5.1.6 Validation de l�indicateur Taux_Succès_LU_Tot

Il est plus rigoureux de valider les indicateurs de mise à jour de localisation par le biais des

indicateurs MSC puisque l�exécution de la procédure se fait au c�ur du réseau entre le MSC, le

VLR et/ou le HLR. La formule de l�indicateur conçu était la suivante :

Taux_Succ�es_LU_Tot =NbACC_PU +NbACC_NU

Nombre_tentativesLU_P +Nombre_tentativesLU_N(5.3)

Il est à noté que la mise à jour de localisation avec IMSI Attach n�est pas prise en compte

dans cette formule car l�automate Cigale n�implémente pas de compteurs relatifs.

En se basant sur la documentation SIEMENS, il s�est avéré que le compteur SPOTS RQ_LCNr calcule le nombre de demande de mise à jour de localisation (LUREQ) non seulement normaleet périodique mais aussi par IMSI Attach. Par conséquent il a fallu chercher le compteur SIEMENS

qui calcule le nombre de demandes pour la mise à jour de localisation avec IMSI Attach et le

faire retrancher du compteur RQ_LC Nr pour adapter de part et d�autre les formules des deux

indicateurs à comparer, le compteur était RQ_LCIMAT Nr [10].D�autre part le compteur SPOTS qui indique le nombre des mises à jour de localisations

normales et périodiques acceptées est SUCC_RQLC Nr.En�n, Le résultat de comparaison entre les valeurs de l�indicateur Taux_Succès_LU_Tot

prises sur MSCx et �ltrées par jour, et les valeurs du rapport SUCC_RQLC Nr / (RQ_LC Nr -

RQ_LCIMAT Nr) est illustré par la �gure 5.6.

Mahdi Kallel 73


Lu_SUCC SPOTS Vs LU SUCC Interface A

94,00%95,00%96,00%97,00%98,00%99,00%

100,00%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

Jour

LU_S

UCC

MSC

08

LU_SUCC SPOTSLU_SUCC Interface A

Fig. 5.6. Résultat de la comparaison LU_SUCC

Les valeurs comparées sont proches, sauf pour le deuxième jour où il y avait une di¤érence

relative. La cause et que les durées d�observations de part et d�autres n�étaient pas exactement

confondues.

5.1.7 Validation du TauxHOInterBSCSortantSuccès et TauxHOInterBSCEntrant-Succès

La validation du succès du handover sortant et entrant était possible par le biais de RNO.

RNO donne les valeurs de ces indicateurs aussi bien au niveau d�une cellule qu�au niveau d�un

BSC. Par contre, SPOTS calcule le taux de succès des handover inter MSC et intra MSC sans

distinguer s�ils soient inter ou intra BSC.

La comparaison de l�indicateur TauxHOInterBSCSortantSuccès avec l�indicateur RNO équi-

valent HoOutMSCsuccess_rate est donnée par la �gure 5.7 pour le BSCx :

Mahdi Kallel 74


SUCC_Ho_Out RNO Vs SUCC_Ho_Out InterfaceA

76,00%78,00%80,00%82,00%84,00%86,00%88,00%90,00%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

SUC

C_H

o_O

ut

SUCC_Ho_Out RNO

SUCC_Ho_Out InterfaceA

Fig. 5.7. Résultat de lacomparaison SUCC_HO_Out

La même comparaison pour une cellule a donné les résultatsillustrés par la �gure 5.8.

SUCC_Ho_Out RNO Vs SUCC_Ho_Out InterfaceA

91,00%92,00%93,00%94,00%95,00%96,00%97,00%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

SUCC

_Ho_

Out

SUCC_Ho_Out RNO

SUCC_Ho_Out InterfaceA

Fig. 5.8. Résultat de la comparaison SUCC_HO_Out pour une cellule

La comparaison des l�indicateur TauxHOInterBSCEntrantSuccès avec l�indicateur RNO équi-

valent HOIncMSCsuccessrate est donnée par la �gure 5.9 pour le BSCx�:

Mahdi Kallel 75


SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A

84,00%85,00%86,00%87,00%88,00%89,00%90,00%91,00%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

SUC

C_Ho

_In

SUCC_Ho_In RNOSUCC_Ho_In Interface A

Fig. 5.9. Résultat de comparaison SUCC_HO_In

La même comparaison pour une cellule a donné les résultats (voir �gure 5.10)

SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A

0,00%20,00%40,00%60,00%80,00%

100,00%120,00%

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

SUCC

_Ho_

In

SUCC_Ho_In RNOSUCC_Ho_In Interface A

Fig. 5.10. Résultat de la comparaison SUCC_HO_In pour une cellule

C�est quasiment les mêmes valeurs sauf pour le deuxième jour (Durée d�observation di¤érente).

5.1.8 Validation du Taux_Succès_SMS_OC

SPOTS dé�nit le taux de succès de SMS sortant comme étant :

MOSMS% =SUCC_SMS_SEND_RP_ACKMS_SER_REQ_ATTEMPTS

(5.4)

C�est exactement la même formule qui a était dé�nie coté interface A :

Taux_Succ�es_SMS_OC =SmsSubmit_RPackNb_SMS_OC

(5.5)

La comparaison des l�indicateur Taux_Succès_SMS_OC avec l�indicateur SPOTS équivalent

MOSMS % est donnée par la �gure 5.11 pour le MSCx :

Mahdi Kallel 76


MOSMS SUCC SPOTS Vs MOSMS SUCC InterfaceA

657075808590

04/04

/2007

05/04

/2007

06/04

/2007

07/04

/2007

08/04

/2007

09/04

/2007

jour

MO

SMS

SUCC

MSC

08

MOSMS SUCC SPOTS

MOSMS SUCC InterfaceA

Fig. 5.11. Comparaison du MOSMS SUCC

5.2 Etude de cas

La mise en évidence de l�importance du suivi de la performance du réseau GSM par le biais

de captures sur l�interface A, ne peut se faire qu�en traitant des cas réels.Ce paragraphe donne

un aperçu sur quelques analyses faites sur des zones bien précises, suite à des observations sur

l�évolution des indicateurs de performances déjà conçus ainsi que sur les di¤érents �chiers générés

sur leur formes semi-brutes.

5.2.1 Etude d�une congestion sur l�interface A

Une congestion sur l�interface A est un manque de circuit sur cette interface suite à une

demande. La congestion se produit si le dimensionnement de l�interface A sous-estime le nombre de

connexions simultanées sur cette interface suite à une demande massive de ressources simultanées.

Pour commencer l�analyse, le suivi de l�évolution des indicateurs EchecMOCNSS, Echec-

MOCBSS et EchecMOCUser par BSC est illustrée par la �gure 5.12.

Fig. 5.12. Les échec MOC

Mahdi Kallel 77


En examinant cette évolution, on peut tirer des observations. En e¤et, le graphe représente

une commodité : Les origines d�échec sont réparties de la façon suivante : Causes User > Causes

BSS > Causes NSS. Ceci semble tout à fait logique dans la mesure où la majorité des cas

d�échec d�établissement d�un appel sortant sont dus à l�utilisateur lui-même ; Par exemple : solde

insu¢ sante, composition d�un numéro non valide, raccrochage précoce etc. . .

Les causes d�échec BSS, de leurs cotés, sont supérieures aux causes d�échec NSS car la partie

BSS du réseau est la plus vulnérable aux erreurs vu la non stationnarité de l�interface radio. La

partie NSS, relativement stable, contribue peu dans les causes d�échec. Toutefois, le taux d�échec

NSS ne devait pas dépasser un seuil tolérable �xé par l�opérateur.

L�indicateur Echec_MOC_NSS dépasse les 5% pour les 6 premiers BSC ce qui est un taux

élevé par rapport à un seuil �xé (Courbe jaune).

Dans le but de poursuivre l�investigation, nous avons analysé les �chiers générés sur l�interface

A exhaustivement pour essayer de trouvé la cause exacte qui est à l�origine de cette hausse.

Pour ce faire, nous avons essayé de rassembler la répartition des causes citées dans le tableau

3.1. Le résultat est donné par la �gure 5.13.

Fig. 5.13. Répartition des causes d�échec

En exploitant le camembert, on constate que le message DISCONNECT, avec une extension

F pour dire qu�il est envoyé par le MSC, et avec la cause NCCA, occupe une bonne partie du

camembert (la partie en noir). La cause NCCA (No Circuit Channel Available) veut dire qu�il

n�y avait plus de circuit pour satisfaire à la demande. Il s�agissait dès lors d�une congestion.

Il est à noter que le camembert précédent n�est pas restreint aux causes NSS, il illustre toutes

les causes possibles sans tenir compte de leurs types (NSS, BSS, USER), par exemple les causes

NSS sont RUu (ResourcesUnavailable) et NCCA.

L�étape suivante était d�essayer de connaître pendant quelle étape de la procédure MOC la

congestion se produit. Pour se faire, il a été indispensable d�exploiter le �chier .XL3 qui donne

l�ensemble des transitions de l�automate que fait chaque connexion sur le réseau. Il nous a permit

de voir la répartition des états de l�automate à partir desquels le message DISC_F-NCCA a été

envoyé. (Voir �gure 5.14)

Mahdi Kallel 78


Fig. 5.14. Répartition des états

Le camembert montre bien que la majorité absolue des messages DISC_F-NCCA a été en-

voyée lorsque l�état de l�automate était OC_PROC. C�est-à-dire pendant la phase proceeding de

la procédure MOC. L�allocation de circuit au niveau MSC se fait pendant cette étape. Ce qui

montre bien qu�il s�agissait bien d�une congestion !

D�autre part, en ce qui concerne la procédure MTC, la même démarche a été faite. Le suivi

de l�évolution des indicateurs Echec_MTC_NSS, Echec_MTC_BSS et Echec_MTC_User par

BSC est illustrée par la �gure 5.15.

Fig. 5.15. Les échecs MTC

La première constatation est que les taux d�échec MTC sont supérieurs à leurs homologues

MOC. La raison est que la procédure MOC est plus vulnérable à l�échec étant donné qu�elle est

initiée par le mobile.

Si on observe la partie jaune du graphe, on constate que le taux d�échec MOC NSS est

relativement élevé pour 3 BSC (3 pics).

Mahdi Kallel 79


L�analyse des �chiers générés après capture sur l�interface A nous a permit de rassembler la

répartition des causes citées dans le tableau 2.1. Le résultat est donné par la �gure 5.16.

Fig. 5.16. Répartition des causes

La partie en bleu du camembert montre que le message DISC_F-NCCA est responsable de

la dégradation de l�établissement d�un appel entrant sur ces BSC.

En examinant le �chier .XL3, il s�est avéré que ce message a été envoyé lorsque l�état de

l�automate était TC_CONF, c�est à dire pendant la phase de con�rmation d�appel (Voir �gure

5.17).

Fig. 5.17. Répartition des états

La phase de con�rmation d�appel est équivalente à Proceeding dans la procédure MOC. On

peut donc a¢ rmer qu�il s�agit bel et bien d�une congestion. Dans le but de con�rmer l�analyse

précédente, nous avons observé le �chier .XLT qui donne le tra�c écoulé pour chaque circuit. Nous

avons ensuite organisé ce tra�c de telle façon qu�il est rassemblé par BSC, la partie en bleu du

graphe de la �gure 5.18 compte le tra�c écoulé par BSC. Les points verts représentent le nombre

Mahdi Kallel 80


maximal de connexions simultanées et les points en noirs représentent le nombre maximal de

circuits disponibles par BSC (c�est-à-dire par interface A).

Fig. 5.18. Tra�c par BSC

En comparaison avec les trois BSC dans lesquels nous avons constaté une congestion selon

la méthode du calcul de l�évolution de l�indicateur Echec_MTC_NSS, seules la congestion des

deux premiers est montrée par la �gure 5.18.

En e¤et, pour les deux premiers BSC, les points verts et noirs sont quasi-confondus. Le fait de

trouver que le nombre de connexions simultanées est très proche de celui des circuits disponibles,

et en plus, pendant une courte durée d�observation, ne fait qu�a¢ rmer qu�il y avait certainement

une congestion au niveau des deux premiers BSC.

Cependant, pour le troisième BSC, les deux points verts et noirs sont relativement éloignés.

Cela représente une contradiction avec l�analyse précédente (calcul de l�évolution de l�indicateur

Echec_MTC_NSS) qui a montré une congestion au niveau de ce BSC.

L�analyse des �chiers générés par capture sur l�interface A a permit de comprendre la cause

de cette incohérence. La méthode était de véri�er les causes du Taux d�échec MTC élevé pour le

BSC en question. (Voir �gure 5.19)

Mahdi Kallel 81


Fig. 5.19. Distribution des causes pour le BSC

Le camembert montre que les Purges sont à l�origine de cette incohérence. Le problème

était que l�interface A, celle rattaché au BSC concerné, n�était pas supervisée par l�analyseur de

protocole ce qui a donné lieu à des incohérences et des purges sur les �chiers de capture.

5.2.2 Etude d�échec SMS Sortant

A partir d�observations sur l�évolution de l�indicateur Taux_Succès_SMS_OC sur les MSC

du réseau, nous avons pu signaler qu�il y avait une forte dégradation pour le MSCx et le MSCx�.

Fig. 5.20. Résultat de l�analyse de l�indicateur Taux_Succès_SMS_OC

En e¤et, le taux de succès était inférieur à 3%. Dès lors, une investigation a été lancée.

Tout d�abord, nous avons véri�é ce taux avec SPOTS en générant un rapport graphique qui

donne l�évolution de l�indicateur SPOTS « MOSMS %» sur le MSCx et le MSCx�. La �gure 5.21

illustre le résultat.

Nous remarquons bien que le taux de succès de l�envoi d�un SMS sortant a été dégradé pendant

la nuit, de 00h à 08h, pour les trois derniers jours.

Mahdi Kallel 82


Fig. 5.21. MOSMS% sur SPOTS

D�autre part, on n�a pas signalé des plaintes des clients autour de cette période. Il en résulte

qu�il a été indispensable de faire une trace sur l�envoie de ces SMS pour voir la cause exacte du

problème.

En parallèle avec cette trace, nous avons suivis l�évolution des indicateurs Taux_Echec_SMS_NSS

et Taux_Echec_SMS_BSS. Il n�y avait rien à signaler puisque les valeurs de ces indicateurs pen-

dant la période en question étaient régulières.

A priori, il semble clair que la cause des échecs d�envois est liée principalement aux utilisateurs

eux même.

Le résultat de la trace a montré que seul 4 numéros sont concernés par cet échec. Ces numéros

sont d�MSISDN consécutifs et la contribution de chacun dans l�échec était la suivante :

Fig. 5.22. Echec SMS par numéro

Ces numéros envoient tous des messages vers un même numéro qui était erroné ! Il s�est avéré

ensuite que ces numéros appartiennent à une société privée qui gère un réseau de véhicules par

Mahdi Kallel 83


GPS, elle envoie périodiquement, chaque minute, les coordonnées GPS de ses véhicules par le

biais d�une plate forme qui envoi les SMS automatiquement. En�n, la société a été contactée

pour corriger la con�guration de sa plateforme SMS.

5.2.3 Etude de détection d�un problème de croisement

Plusieurs critères d�analyse ont été faites, parmi elles celle relative à notre approche sur

l�interface A. En e¤et, nous avons suivi l�évolution de l�indicateur SuccèsEtablissementAppelTech

sur les cellules de la zone concernée et nous avons trouvé que l�indicateur est dégradé, il était au

dessous des 40%.

Fig. 5.23. Résultat d�analyse de l�indicateur Succès_Etablissement_Appel_Tech

Notre analyse sur l�analyse sur l�interface A a montré que deux secteurs appartenant au même

site étaient les plus dégradés. En consultant la liste des opérations programmées, Il s�est avéré

qu�il y avait une opération dans le site en question.

Suite à cette opération, nous avons constaté une diminution considérable du tra�c sur le

secteur 4 du site grâce à l�outil OTT-Perf (Voir �gure 5.24)

Fig. 5.24. Tra�c sur le secteur 4

Mahdi Kallel 84


Il est clair que le pic vers le bas des TCH valables (ligne bleu) indique le temps exact de l�opé-

ration. Ce défaut de tra�c est compensé par le secteur 3 augmentant ainsi le taux de congestion

SDCCH et TCH sur la cellule (atteint 90%). Voir �gure 5.25.

Mahdi Kallel 85


Fig. 5.25. Tra�c sur le secteur 3

L�idée était de véri�er s�il y avait un croisement de câblage. Pour véri�er cela, il a était

indispensable de comparer les performance des HO avant et après l�opération. Les positions GIS

des secteurs 4 avec une cellule voisine x et 3 avec une cellule voisine x�sont présentées par la

�gure 6.26.

Fig. 5.26. Positions GIS des secteurs.

RNO montre que les performances HO pour les deux couples précédents ont été inversées

avant et après l�opération (Voir les �gures 5.27 et 5.28).

Mahdi Kallel 86


Fig. 5.27. Performances HO pour le couple 4-x

Fig. 5.28. Performances HO pour le couple 3-x�

La conclusion est qu�il y avait un croisement de câblage.

Mahdi Kallel 87


Conclusion générale

Il ne fait désormais plus aucun doute que le suivi de la qualité de service du réseau GSM est

une tâche assez délicate, qui nécessite la coopération de méthodes et d�alternatives di¤érentes

pour parvenir à maintenir un niveau de QoS acceptable.

L�approche développée dans notre étude était de faire en sorte que l�opérateur pouvait en

pro�ter de l�analyseur de protocole installé sur les interface A de son réseau et qui intercepte le

�ux des messages sur cette interface.

Dans cette optique, l�apport de notre étude était la mise en disposition de nouveaux in-

dicateurs clefs de performance conçus à partir des captures sur l�interface A. Ces indicateurs

permettent d�analyser la performance du réseau ou bien de con�rmer quelques résultats.

Ces indicateurs peuvent aussi jouer un rôle de validation pour des opérations techniques

données. Ils permettent parfois de détecter les problèmes parvenus sur le réseau.

L�analyse par les indicateurs clefs de performance n�est qu�une étape durant tout un processus

du maintien d�une qualité de fonctionnent adéquate. Il est commode de se faire en pro�ter de tous

les outils mis à disposition. Il c�est avéré dès lors qu�une implémentation logicielle des indicateurs

conçus est indispensable dans la mesure où elle va servir de tableau de bord pour la visualisation

du réseau.

Cette implémentation logicielle nous a permis de nous familiariser avec des langages de dé-

veloppent et de modélisation intéressants. La validation des indicateurs conçus nous a permis de

toucher de prés les outils de performance mis à disposition et de s�intégrer au sein du service

QDF. L�étude de cas réels nous a permis d�aborder de vrais problèmes d�ingénierie technique.

En�n, et c�est le plus important, ce travail nous a permis de comprendre le vrais sens du

travail en équipe et de sentir son charme.

Mahdi Kallel 88

AnnexeA

Présentation du système GSM

Projet de �n d�études Présentation du système GSM

APrésentation du système 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 utilisateurs,

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 portatif émettant

à faible puissance (de 0.25 à 8W).

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

Mahdi Kallel 90


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-1785

Fréquence d�émission de la BTS vers le terminal 935-960 MHz 1805-1880Bande de fréquence disponible 25+25 MHz 75+75 MHz

Mode d�accès TDMA TDMAEspacement des canaux radio 200kHz 200kHzEspacement du duplex 45 MHz 95 MHz

Nombre de canaux radio par sens 124 374Nombre de canaux de parole plein débit 8 8

Débit d�un codec à plein débit 13 kbit/s 13 kbit/sDé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�établis-

sement 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

Mahdi Kallel 91


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 appli-

cation et de leur puissance (de 0.8W à 20W). Chaque terminal mobile est identifé par un code

unique IMEI (InternationalMobile Equipment Identity). La carte SIM est une carte à puces qui

contient dans sa mémoire le code IMSI (International Mobile Subscriber Indentity) qui identife

l�abonné de même que les renseignements relatifs à l�abonnement (services auxquels l�abonné a

droit).

A.2.2 Le sous-système radio

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), c�est l�organe intelligent du BSS dont le rôle est de gérer les

ressources radio (confguration 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. Le sous système Radio

A.2.3 Le sous Système Réseau

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 �xxe.

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

Mahdi Kallel 92


Fig. A.3. Le sous système réseau

�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 transmission 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 don-

nées contenant les informations relatives aux abonnés présents dans une zone géographique. 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 pro-

té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érifer 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.

A.3 Les interfaces du réseau GSM

Les di¤érents éléments du réseau GSM assurent des fonctions complémentaires et chacun

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.

Mahdi Kallel 93


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érifcation 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

A.4 Fonctionnement du réseau GSM

A.4.1 Traitement des appels

A.4.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 communication.

Il se met alors à sonner.

A.4.1.2 Authenti�cation et sécurité

L�emploi d�un canal radio rend les communications vulnérables aux écoutes et aux utilisations

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.

Mahdi Kallel 94


A.4.2 Gestion de la mobilité

A.4.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.4.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 conjointement

par la structure �xe et le mobile. La décision d�e¤ectue 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 environnantes) 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�eectuer 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 eectué par le mobile sur réception d�une commande émise par le BSC.

Dans le GSM, le Handover s�eectue 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 interférences,. . . ).

A.4.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.

Mahdi Kallel 95


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.

Mahdi Kallel 96

AnnexeB

Le langage de modélisation UML

Projet de �n d�études Le langage de modélisation UML

BLe langage 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.

B.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 aveccelui 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.

Mahdi Kallel 98


�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.

� La relation d�extension ou �extends �entre deux use cases signife 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.

B.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 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érationen terme

d�actions.

�Les diagrammes de composants : représentation du code en termes de modules,de compo-

sants 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 inter-

actions.

�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�état.

�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).

Mahdi Kallel 99


Bibliographie

[1] Recommantion UIT E-800

[2] MISSAOUI Mohammed Taher, cours SUP�COM, 2006/2007.

[3] Lionel Lumbroso, www.01net.com, 2002.

[4] GUNNAR Heine, GSM Networks : protocols, terminology and implementation, Artech

House, 1999.

[5] LAGRANGE Xavier, GODLEWSKI Philippe, TABBANE Sami, Réseaux GSM-DCS 4ème

édition revue et augmentée, Hermes science 1999.

[6] Astellia, Protocoles automates module 3, 2003.

[7] ZNARTY Simon, Le réseau Sémaphore n�7, E¤ort 2005.

[8] SIEMENS, GSM Call and Procedures, 2003

[9] SIEMENS, Tra¢ c annd performance Data counter description SR13, Siemens AG 2006

[10] SIEMENS, Data Model, SPOTS V10 Drop 3, Mai 2003

[11] ASTELLIA, Cigale USER MANUAL, ASTELLIA (2002).

Mahdi Kallel 100

Technology

Kallel mehdi