These GSM CallTrace

Rpublique Tunisienne Ministre de l enseignement suprieur et Ministre des tlcommunications Un i v e r s i t d e Ca r t h a g e
des
cole supprieure communications de Tunis
Rapport de mmoire de n d tudes Prsent en vue de l obtention du titre d ingnieur en Tlcommunications Thme:
Conception et implmentation d indicateurs clefs de performance du rseau GSM partir de captures effectues 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 e Adresse : Les jardins du Lac - Les Berges du Lac - 1053 Tunis Tel : (216) 22 12 00 00 Fax : (216)22 12 17 09
Remerciements
Mes remerciements les plus chaleureux vont particulirement aux gens qui, sans leurs aide inestimable, ce projet n aurait jamais t men bien. J exprime ma gratitude en premier lieu, Mme Valrie Lpillet pour m avoir accueilli au sein de son dpartement et pour ses multiples conseils. M. Fahmi KHARRAT, au Dr. Mohammed Taher MISSAOUI pour la qualit de l encadrement qu m fourni et ils ont pour 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 m fournies. ils ont Je remercie aussi tous les enseignants qui m ont enseign tout au long de mes tudes et particulirement les enseignants de SUP COM. Pour nir, je remercie les membres de jury qui ont accept d valuer mon projet. Je leurs prsente toute mes gratitudes et mes profonds respects.
Ddicaces
Mon cher pre Habib et ma chre mre Zeineb pour leur tendresse, leur aection, leur amour, leur patience, leurs considrables sacrices pour me parvenir ce niveau, et leur soutien moral ma chre eur Maha pour son amour inni mon cher frre Seddik, et sa femme Manel mon cher frre Ferouk, et sa anc Hejer Si Nejib, Malika, Anis et Ins mes collocaters Mohammed et Soen toute ma famille mes chers amis tous mes enseignants tous ceux qui m aiment et que j aime. je ddie ce travail Qu Allah vous protge tous, vous prserve la sant et le bonheur
Mahdi Kallel
Rsum
Le prsent travail, eectu au sein de l entreprise TUNISIANA, entre dans le cadre du projet de n d tudes pour l obtention du diplme national d ingnieur en tlcommunications. Il s intresse au suivi de la performance du rseau GSM partir des de messages sur l ux interface A. A cet eet, 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 supportant l approche propose en implmntant ces indicateurs. Finalement, nous validons quelques rsultats obtenus et nous menons quelques tudes de cas rels Mots cls: rseau GSM, interface A, procdures GSM, KPI, windev, QoS. . .
Abstract
This present work is carried out, within TUNISIANA as the graduated project to obtain the national diploma of Telecom Engineer.The aim of this project is to follow the GSM network performance by using the message over A interface. In fact, we disign keys performance ow indicators needing capture over this interface. In addition, we make a program that shows theses indicators. Finally, we ratify several obtained results and we show some real case study. Key words: GSM Network, A interface, KPI, windev, QoS. . .
Table des matires

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapitre 1. Contexte et problmatique . . . . . . . . . . . . . . . . . . 1.1. Dnition de la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Mthodes de mesures de QoS TUNISIANA . . . . . . . . . . . . . . 1.2.1. Mesures Drive Test . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2. suivi des indicateurs de performance . . . . . . . . . . . . . . . 1.2.3. Dispositifs de capture sur les interfaces . . . . . . . . . . . . . . 1.2.4. Comparaison entre les direntes mthodes de mesure de QoS . 1.3. Spcication du besoin et description du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii x 4 4 5 5 5 6 6 6 10 10 11 11 12 12 12 13 13 14 14 15 16 17 18 19 22 22 24 24 31 34 35 38 39 39 39 40
Chapitre 2. Etat de l art . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Description de l interface A . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. La signalisation sur l interface A . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Le rseau de signalisation N 7 (SS7) . . . . . . . . . . . . . . . . 2.2.2. Message Transfert Part (MTP) : . . . . . . . . . . . . . . . . . . 2.2.3. Signaling Connection Control Part (SCCP) . . . . . . . . . . . . 2.2.4. BSS Application Part (BSSAP) . . . . . . . . . . . . . . . . . . . 2.2.5. Les couches applicatives MM et CM . . . . . . . . . . . . . . . . 2.3. Les procdures GSM et les principaux messages sur l interface A . . . . 2.3.1. Appel entrant (Mobile Terminated Call MTC) . . . . . . . . . . 2.3.2. Appel sortant (Mobile Originating Call MOC) . . . . . . . . . . 2.3.3. Mise jour de localisation (Location UpdateLU) intra-VLR . . . 2.3.4. Mise jour de localisation (Location UpdateLU) inter-VLR . . . 2.3.5. Le handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.6. Le transfert de SMS . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. La mthode ASTELLIA : explication des notions Etat, transition, event Chapitre 3. Conception des indicateurs . . . . 3.1. Dmarche . . . . . . . . . . . . . . . . . . . . 3.2. Les indicateurs MOC . . . . . . . . . . . . . . 3.2.1. Etablissement d appel (Call SETUP) . 3.2.2. Echec d appel sortant . . . . . . . . . 3.2.3. La Conversation . . . . . . . . . . . . 3.3. Les indicateurs MTC . . . . . . . . . . . . . . 3.4. Les indicateurs d appel . . . . . . . . . . . . . 3.5. Mise jour de localisation (Location Update) 3.5.1. Etablissement de la connexion radio . 3.5.2. Indication de service . . . . . . . . . . 3.5.3. Allocation Numro temporaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
3.5.4. Echec LU . . . . . . 3.6. Les indicateurs Handover . 3.6.1. Handover interBSC . 3.6.2. Handover intraBSC 3.7. Les indicateurs SMS . . . . 3.8. Des indicateurs Divers . . . 3.8.1. Le double appel . . . 3.8.2. Connexion SCCP . . 3.8.3. Indicateur de trac .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
41 42 42 47 47 50 50 51 51 54 54 54 55 57 58 67 67 67 68 69 71 72 73 74 76 77 77 82 84 90 90 91 92 92 92 93 94 94 95 98 98 99
Chapitre 4. Implmentation logicielle . . . . . . . . . 4.1. Conception . . . . . . . . . . . . . . . . . . . . . . . 4.1.1. Entre/sortie et architecture de l application 4.1.2. Choix de l environnement de dveloppement . 4.1.3. Conception oprationnelle de l application . . 4.2. Ralisation . . . . . . . . . . . . . . . . . . . . . . .
Chapitre 5. Validation et tude de cas . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Choix des indicateurs valider . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Aperu sur les outils utiliss pour la validation . . . . . . . . . . . . . . . 5.1.3. Validation de Succs_tablissement_MOC _Tech . . . . . . . . . . . . . 5.1.4. Validation de Succs_tablissement_MTC _Tech . . . . . . . . . . . . . 5.1.5. Validation de coupure_Appel . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.6. Validation de l indicateur Taux_Succs_LU_Tot . . . . . . . . . . . . . . 5.1.7. Validation du TauxHOInterBSCSortantSuccs et TauxHOInterBSCEntrantSuccs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.8. Validation du Taux_Succs_SMS_OC . . . . . . . . . . . . . . . . . . . 5.2. Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Etude d une congestion sur l interface A . . . . . . . . . . . . . . . . . . . 5.2.2. Etude d chec SMS Sortant . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.3. Etude de dtection d problme de croisement . . . . . . . . . . . . . . un Annexe A. Prsentation du systme GSM A.1. Principe du rseau GSM . . . . . . . . . A.2. Architecture GSM . . . . . . . . . . . . A.2.1. La station Mobile . . . . . . . . . A.2.2. Le sous-systme radio . . . . . . A.2.3. Le sous Systme Rseau . . . . . A.3. Les interfaces du rseau GSM . . . . . . A.4. Fonctionnement du rseau GSM . . . . . A.4.1. Traitement des appels . . . . . . A.4.2. Gestion de la mobilit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annexe B. Le langage de modlisation UML . . . . . . . . . . . . . . . . . . . . . B.1. La syntaxe du langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2. Les diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
Table des figures

Figure 1.1. Figure 1.2. Figure 2.1. Figure 2.2. et MSC Figure 2.3. Figure 2.4. Figure 2.5. Figure 2.6. Figure 2.7. Figure 2.8. Figure 2.9. Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. 3.15. 3.16. 3.17. 3.18. 3.19. 3.20. 4.1. 4.2. 4.3. 4.4. 4.5. L emplacement de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schma fonctionnel de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . Pile protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principes d tablissement et de libration d une connexion SCCP entre BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . procdure MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Procdure MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LU intra -VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LU inter VLR avec IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover inter-BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le transfert d SMS sortant . . . . . . . . . . . . . . . . . . . . . . . . . un Table des transitions et les compteurs relatifs . . . . . . . . . . . . . . . . . Exemple de chier .EFF . . . . . . . . . . chier Automate.BDT . . . . . . . . . Les tapes de la procdure MOC . . . . . . Demande d canal SDCCH . . . . . . . . un Demande de service . . . . . . . . . . . . . authentication et passage en mode chir Dbut d appel . . . . . . . . . . . . . . . . Aectation d canal de trac . . . . . . . un Sonnerie et connexion . . . . . . . . . . . . Echec radio lors de l authentication . . . Recherche du mobile . . . . . . . . . . . . Rponse au paging . . . . . . . . . . . . . . Demande de service . . . . . . . . . . . . . Allocation TMSI . . . . . . . . . . . . . . . Handover sortant . . . . . . . . . . . . . . suite Handover sortant . . . . . . . . . . . Handover entrant . . . . . . . . . . . . . . Suite handover entrant . . . . . . . . . . . SMS Sortant . . . . . . . . . . . . . . . . . Rpartition du trac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 11 13 14 15 16 17 18 18 19 23 23 24 25 25 27 28 29 30 33 36 37 39 41 43 44 45 46 48 52 55 56 57 58 59 69 70 71
Architecture client-serveur . . . . . . . . . . . . . . . Architecture du systme . . . . . . . . . . . . . . . . Diagramme de cas d utilisation . . . . . . . . . . . . . Diagramme de squences d insertion des donnes dans Diagramme de squence de gnration des courbes . .
. . . . . . . . . . . . . . . la base . . . . .
Figure 5.1. Figure 5.2. Figure 5.3.
RNO system (Alcatel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . le compteur SIEMENS de CM_SERVICE_REQUEST . . . . . . . . . . . Rsultat de la comparaison CSSR_MOC . . . . . . . . . . . . . . . . . . .
viii
Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure
5.4. 5.5. 5.6. 5.7. 5.8. 5.9. 5.10. 5.11. 5.12. 5.13. 5.14. 5.15. 5.16. 5.17. 5.18. 5.19. 5.20. 5.21. 5.22. 5.23. 5.24. 5.25. 5.26. 5.27. 5.28.
Rsultat de la comparaison CSSR_MTC . . . . . . . . . . . . . . . . . Rsultat de la comparaison Call drop . . . . . . . . . . . . . . . . . . . Rsultat de la comparaison LU_SUCC . . . . . . . . . . . . . . . . . . Rsultat de lacomparaison SUCC_HO_Out . . . . . . . . . . . . . . . Rsultat de la comparaison SUCC_HO_Out pour une cellule . . . . . Rsultat de comparaison SUCC_HO_In . . . . . . . . . . . . . . . . . Rsultat de la comparaison SUCC_HO_In pour une cellule . . . . . . Comparaison du MOSMS SUCC . . . . . . . . . . . . . . . . . . . . . . Les chec MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rpartition des causes d chec . . . . . . . . . . . . . . . . . . . . . . . Rpartition des tats . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les checs MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rpartition des causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rpartition des tats . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trac par BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distribution des causes pour le BSC . . . . . . . . . . . . . . . . . . . . Rsultat de l analyse de l indicateur Taux_Succs_SMS_OC . . . . . MOSMS% sur SPOTS . . . . . . . . . . . . . . . . . . . . . . . . . . . Echec SMS par numro . . . . . . . . . . . . . . . . . . . . . . . . . . . Rsultat d analyse de l indicateur Succs_Etablissement_Appel_Tech Trac sur le secteur 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trac sur le secteur 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . Positions GIS des secteurs. . . . . . . . . . . . . . . . . . . . . . . . . . Performances HO pour le couple 4-x . . . . . . . . . . . . . . . . . . . . Performances HO pour le couple 3-x . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
72 73 74 75 75 76 76 77 77 78 79 79 80 80 81 82 82 83 83 84 84 86 86 87 87 91 92 93
Figure A.1. Architecture du rseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . Figure A.2. Le sous systme Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure A.3. Le sous systme rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
Liste des tableaux

Tableau 3.1. dnition des causes de rejet . . . . . . . . . . . . . . . . . . . . . . . . . 32 91 94 Tableau A.1. Caractristiques de la norme GSM . . . . . . . . . . . . . . . . . . . . . . Tableau A.2. Liste des interfaces dans le rseau GSM . . . . . . . . . . . . . . . . . . .
Introduction gnrale
La tlphonie mobile connat ds le dbut des annes 90 une croissance explosive dpassant les prvisions les plus optimistes des oprateurs de tlcommunication. Elle s impose de plus en plus comme le moyen le plus e cace pour conqurir d avantage des parts du march des tlcommunications. Le GSM est le systme de tlphonie mobile qui a connu un succs sans appel. Il a t commercialis depuis l anne 1992 en Europe. Le dveloppement des technologies utilises et les services et les applications oertes par le GSM ont contribu la cration d environnement propice la concurrence incitant ainsi les un oprateurs se soucier de la qualit de leurs prestations et des performances de fonctionnement de leurs rseaux et leurs infrastructures. Il s avre donc que la qualit, dans ce domaine comme dans beaucoup d autres, constitue une source importante de direnciation dterminante entre les oprateurs en concurrence. La prise la lgre de la qualit de service du rseau est une erreur stratgique puisqu constitue elle l lment qui stimule le choix nal du consommateur d la conqute du march, d le prot. o o Dans ce contexte, aprs la phase de dploiement d rseau cellulaire, l un oprateur commence analyser et amliorer les performances de son rseau pour garantir une qualit de service acceptable. Le maintien et le suivi de cette qualit ncessitent l observation permanente de l tat de fonctionnement du rseau et de toutes les actions ralises et par consquent, l utilisation d outils d ingnierie adapts. Cependant, la supervision de ce rseau est une tche assez dlicate vu l aspect dynamique de son architecture et de la conguration de ses dirents lments et l htrognit des outils de supervision et des bases de donnes des performances existantes. Dans cette optique se manifeste le cadre gnral de notre projet de n d tude. En eet, parmi les mthodes adoptes pour l valuation de la qualit de service du rseau GSM, on distingue le suivi de l volution d indicateurs clefs de performance (KPI). La signication de chaque indicateur est spcique, il en rsulte que la conception de ces indicateurs est la phase la plus importante. Dans un premier chapitre, nous allons voquer le contexte gnral du projet ainsi que la problmatique coule. Le second chapitre sera consacr la conception des indicateurs de performance. La phase d implmentation logicielle et de ralisation sera rassemble dans un troisime chapitre. Enn le dernier chapitre contient une tude de cas rels pour interprter et valider des rsultats obtenus.
Contexte et problmatique
Chapitre
Projet de n d tudes
L objectif de ce chapitre est de rattacher le projet son cadre thorique. Nous allons dnir la notion de QoS (Quality Of Service) dans les rseaux mobiles en prsentant ses mthodes et moyens de mesures. Cette notion tant assez globale, nous dgagerons celle rattache TUNISIANA et ses diverses perspectives d valuation. Nous allons enn dgager la problmatique originelle du projet. Il est noter que ce chapitre sera mieux compris avec une lecture parallle de l annexe A portant sur l architecture et des notions globale sur le GSM.
1.1
Dnition de la QoS
Selon la recommandation UIT E-800, la qualit de service est dnie en terminologie comme tant L eet global produit par la qualit de fonctionnement d service qui dtermine le degr un 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 eet la qualit de fonctionnement est le guide gnral des facteurs qui contribuent collectivement la qualit de service. De point de vue fournisseur de service, la qualit de fonctionnement du rseau est un concept qui traduit la manire dont les caractristiques du rseau sont tablies, mesures et contrles pour atteindre un niveau satisfaisant de qualit de service. Dans l utilisation d service, l un utilisateur d service ne distingue gnralement que le un fournisseur de service. Le degr de satisfaction que l utilisateur retire du service fourni dpend de la qualit de service, c est--dire de la perception qu a des aspects suivants : il L accessibilit au service,
Mahdi Kallel
Projet de n d tudes
La continuabilit du service, L intgrit du service. Dans le contexte actuel, la qualit de service est devenue un facteur dterminant pour TUNISIANA qui s donc aperu que la qualit de ses services et de ses prestations doit tre constamest ment contrle et suivie, d une part pour connatre l tat de fonctionnement de son infrastructure et d autre part pour pouvoir amliorer sa comptitivits. C dans ce cadre de concurrence et est d innovation qu s dote d service de qualit, dont la mission est d elle est un valuer et de mesurer la qualit de service dans toutes les parties du rseau. TUNISIANA utilise plusieurs mthodes pour valuer la qualit du service du rseau. Le paragraphe suivant va les dcrire.
1.2
Mthodes de mesures de QoS TUNISIANA
Pour mesurer la performance de son rseau, TUNISIANA utilise un ensemble de mthodes 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 rseau, sont des mthodes et approches qui contribuent toutes l valuation de la qualit de service. Une analyse rigoureuse des facteurs de la qualit de service, doit imprativement utiliser l ensemble de ces mthodes. 1.2.1 Mesures Drive Test
Il s agit d quipes qui font des parcours sur les routes et les zones couvertes par le rseau, pour mesurer des paramtres en downlink (DL). Ils utilisent un mobile trace pour l acquisition des mesures radio. Ce mobile est attach un rcepteur spcique qui est attach son tour un PC portable. Un logiciel spcial est install dans le PC portable sert l acquisition, l enregistrement et le traitement des mesures rcupres. Pour la localisation gographique 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 rseau, notamment sur les performances des procdures GSM. Gnralement 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 calculs partir de compteurs sous forme brutes qui s incrmentent chaque fois qu vnement surviens sur le rseau (on entend par vnement un message chang un entre deux quipements du rseau). Les indicateurs, dits KPI (Key Performance Indicators), sont calculs de la faon : KP I = f (Compteurs) La rcolte et le rassemblement des compteurs peuvent s eectuer par le biais de l OMC (Opration and Maintenance center) qui est un serveur gnrant des chiers de compteurs.
Mahdi Kallel
Projet de n d tudes 1.2.3 Dispositifs de capture sur les interfaces
Les dispositifs de capture sur les interfaces permettent d examiner les trames changes entre deux quipements du rseau des ns d investigation. Il sont des systmes qui se caractrisent par : Un Hardware (analyseur de protocole) sur lequel est implment un Software spcique pour dtecter et adapter les caractristiques de l interface sur laquelle il est implment ; Un logiciel qui permet le dcodage des trames ; Un cran pour a cher le rsultat des mesures ; Une mmoire de stockage importante. Ils peuvent intercepter, dcoder et analyser les trames et savoir de quel protocole elle relve.[4] 1.2.4 Comparaison entre les direntes mthodes de mesure de QoS
Le Drive Test et les indicateurs de performance sont indispensables pour la dtermination de la qualit de service du rseau GSM. Ils reprsentent nanmoins quelques insu sances. Le drive Test donne l ide sur la qualit de service comme l aperoit l utilisateur, il est insu sant dans la mesure o il n ore pas une vision complte sur le rseau, il fait des mesures Snapshot un instant donn et dans un lieu donn. En ce qui concerne la mthode d valuation par KPI, elle value globalement la qualit. Il est donc un peu di cile de dterminer la cause exacte d disfonctionnement. D un autre part, ces indicateurs dpendent troitement du constructeur dans la mesure ou chacun dni et implmente ses indicateurs d une faon propre. Ceci stimule l htrognit entre les systmes des fournisseurs d quipements. L importance du suivi de la QoS en se basant sur les captures sur les interfaces dcoule grce aux caractristiques suivantes : La capture sur les interfaces ne dpend pas du fournisseur des quipements GSM. Elle compense le problme du manque d interoprabilit entre dirents constructeurs. Elle permet de faire une analyse bas niveau et de suivre la totalit des traces de signalisation.
1.3
Spcication du besoin et description du projet
L oprateur Orascom Tlcom Tunisie a t conscient de l importance du suivi de la qualit de service du rseau GSM par des captures travers l interface A du rseau. L interface A a t choisie vu qu est totalement normalise par la recommandation GSM elle 08.08 et qu ne dpend en aucun cas du fournisseur des quipements. D elle autre part, l interface A constitue la limite entre le sous systme radio BSS et le sous systme rseau NSS. Il s agit d une fentre qui s ouvre sur les deux systmes la fois, elle pouvait dtecter les problmes BSS et les problmes NSS. La quasi-totalit des procdures 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 rseau. Du cot de chez TUNISIANA, La plateforme de capture sur l interface A est fournie par ASTELLIA : une socit spcialise dans la conception de solutions matrielles et logicielles
Mahdi Kallel
Projet de n d tudes
ddies l optimisation des performances des rseaux de la tlphonie mobile. Cette plateforme est appele CIGALE. Cigale a t dvelopp dans l objectif de complter et amliorer le potentiel d investigation dans le rseau 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 congurations. Par exemple, pour la mise jour de localisation, le chier NETWORK.BDT contient des informations sur les dirents Location Area. Le chier PHONES.BDT est utilis pour dclarer les numros pour lesquels on veut gnrer des statistiques particulires. Le chier CIGALE.INI contient les dirents paramtres et options de l application [11] (Voir gure 1.2 ).
Fig. 1.2. Schma fonctionnel de Cigale
Comme output, Cigale gnre quotidiennement des chiers bruts ou semi bruts. Durant le traitement il est possible de gnrer les chiers _Ref.txt bruts suivants (qui seront une base pour un outil appel Cigale View) :
Mahdi Kallel
Projet de n d tudes
TIM : informations sur les timers associs aux cellules et au BSC ; SS : informations associes chaque message relatif aux services supplmentaires ; SMS : informations pour chaque message court ; LHO : informations sur les liens HO qui n pas pu tre tablis ; ont EFF : Des compteurs e caces pour chaque cellule. A la n du traitement, les statistiques semi bruts suivantes peuvent tre gnres (Statistical le) : XL2 : Statistiques sur la machine d tat ( voir la dnition dans le chapitre suivant) ; XL3 : informations de chaque connexion et leur historique ; XLH et XLF : Statistiques sur le de handovers ; ux 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 dirents messages d erreurs et d alertes gnrs durant le traitement. Quoique intressante, l analyse exhaustive des chiers gnrs est dlicate voir trs di cile vu leurs tailles volumineuses. Il faudra en outre une longue dure d analyse pour pouvoir s sortir. en D l o ide qui a donn naissance ce projet. L ide tait d essayer de compenser la dure d analyse exhaustive des chiers en faisant la conception d indicateurs clefs de performances partir de ces chiers. Puis de les faire implmenter dans une application logicielle complte qui reprsente un tableau de bord de l volution de ces indicateurs en gnrant des courbes et des statistiques. Enn pour valider les rsultats obtenus, une tude de cas doit tre mene pour comparer les rsultats dcouls des indicateurs calculs avec ceux des indicateurs OMC.
Mahdi Kallel
Etat de l art
Chapitre
Projet de n d tudes
Etat de l art
Etat 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 changs travers l interface A. Dans un premier lieu, nous prsenterons l interface A globalement en voquant les protocoles de signalisation rattachs, ensuite nous mettrons les dirents messages transits sur l interface A dans leur contexte de procdure GSM. Enn, nous donnerons une brve description de la mthode Astellia en expliquant les notions : tat automate, transition et vnement.
2.1
Description de l interface A
NB : Ce paragraphe sera mieux compris en regardant paralllement l annexe n 1 portant sur des notions gnrales sur le rseau GSM. Du point de vue physique, l interface A est constitue 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 considration lors de l examen de cette interface. Par consquent, l interface A peut tre spare en 2 parties : La premire partie est situe entre le BSC et le TRAU, o l information utile est encore compresse. Dans quelques nomenclatures, cette interface est appele interface Ater. Comme c est le cas pour l interface Abis, un seul canal de trac occupe seulement deux bits des huit bits de l MIC. C pourquoi il, est possible de transporter quatre canaux de trac simultanment IT est
Mahdi Kallel
10
Projet de n d tudes
Etat de l art
dans un seul IT MIC. Mais l information de signalisation sur cette interface ncessite un IT entier MIC de 64 Kbps. La deuxime partie est situe entre le TRAU et le MSC. L information utile est maintenant dcompresse. Pour cette raison, chaque canal de trac ncessite la totalit des huit bits de l MIC soit 64 Kbps par canal. En outre, la position du canal de signalisation peut tre IT dirente avant et aprs le transcodage[4].
2.2
La signalisation sur l interface A
L interface A se situe entre le sous-systme radio (BSS) et le sous-systme rseau (NSS). A travers cette interface transitent de nombreux messages de signalisation. Cette signalisation s appuie sur les protocoles des couches MTP et SCCP du systme 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 consquent, le MSC n pas seulement reli aux dirents BSC par des circuits de est parole mais galement par des canaux smaphores directs : des intervalles de temps (Time Slot) sont donc rservs la signalisation. La gure 2.1 prsente les piles protocolaires des dirents composants du rseau GSM y compris bien sr celle qui rgit le de message au niveau de ux l interface A.
Fig. 2.1. Pile protocolaire
2.2.1
Le rseau de signalisation N 7 (SS7)
Ce systme de signalisation par canal smaphore normalis par le CCITT permet de sparer la signalisation de la transmission en faisant transiter la signalisation sur un canal spcique.
Mahdi Kallel
11
Projet de n d tudes
Etat de l art
De ce fait, on peut changer des messages de signalisation sans tablissement rel de circuit de communication. Les avantages de la signalisation smaphore sont : La possibilit de transfrer de la signalisation pure indpendamment de l tablissement d circuit. un La rduction des dlais de transfert de la signalisation et diminution du temps d occupation ine cace des circuits. La possibilit de transfrer la signalisation fort dbit pendant une communication sans que l utilisateur soit gn. La possibilit de rserver les circuits pour un appel seulement lorsque le correspondant demand est rellement joignable.[7] 2.2.2 Message Transfert Part (MTP) :
Le MTP ore un service de transfert able des messages de signalisation. Il est divis en trois niveaux (MTP1, MTP2, MTP3) proches des trois premires couches du modle OSI : MTP1 couche physique : dnit les caractristiques physiques, lectriques et fonctionnelles d une liaison physique (liaison smaphore de donnes dans le vocabulaire SS7) et les moyens d accder. On utilise le plus souvent des conduits numriques 64 kbit / s. y MTP2 procdures d acheminement des donnes sur une liaison : dnit les fonctions et les procdures de transfert des messages de signalisation de faon fournir un transfert able entre deux points. Ce niveau est comparable la couche liaison de donnes du modle OSI. Les donnes changes sont des "trames smaphores". Le protocole utilis contient un mcanisme de contrle du de dtection des erreurs et de correction par retransmission. Par consquent, le ux, MTP2 comporte un mcanisme de surveillance du taux d erreur sur la liaison smaphore. MTP3 routage et contrle : dnit les fonctions et les procdures de transfert de messages entre les noeuds du rseau smaphore (PS ou PTS). Il comprend deux fonctions : orientation des messages de signalisation et gestion du rseau smaphore. 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 rseau, le SCCP ore un adressage de bout en bout, mme travers les noeuds et les pays du rseau. Il faut aussi noter qu une connexion SCCP par mobile est ncessaire au niveau de l interface A pour toute procdure sur le rseau pour le cas GSM. Ces tapes sont illustres 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 forme 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
Projet de n d tudes
Etat de l art
Fig. 2.2. Principes d tablissement et de libration d une connexion SCCP entre BSC et MSC
Les messages interprts par le BSC qui traitent la gestion des ressources radio et l excution du Handover (sous-couche BSSMAP) Les autres messages qui sont en fait changs 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 supplmentaires (SS) et le service des messages courts (SMS) Aprs avoir comprendre les dirents protocoles qui rgissent le transfert de messages sur l interface A, il faut donner un aperu sur ces messages en les mettant dans leurs contextes vis-vis des procdures GSM correspondantes. Le paragraphe suivant prsente les procdures GSM les plus commodes et le rsum interface A relatif.
2.3
Les procdures GSM et les principaux messages sur l interface A
Pour valuer la qualit de service du rseau GSM, il faut comprendre les dirents processus qui grent 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
Projet de n d tudes 2.3.1 Appel entrant (Mobile Terminated Call MTC)
Etat de l art
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) spci par le VLR (Visiter Location Register). Le mobile tant trouv, la connexion radio s tablit. Et ds lors, la rponse au PAGING est envoye au BSC correspondant qui, son tour, la transmet au MSC a travers l interface A. Ensuite le systme authentie le mobile puis ordonne le passage en mode chir. Le BSC alloue ensuite un canal de trac TCH au mobile (Les messages prcdents tant sur un canal SDCCH). Aprs la conrmation d appel, la sonnerie est envoye l appel. Si le mobile dcroche, la conversation commence. Enn, aprs raccrochage, les ressources sont libres. Voir gure 2.3 [5].
MS BSS Interface A MSC/VLR HLR G-MSC AIM (MSISDN) Send routing info Provide roaming number Provide roaming number ACK MSRN Send routing info ACK AIM (MSRN) Paging Paging_Req Ch_Req Imm-Ass Paging_Resp Paging_Resp + SCCP Connection Auth_Req Auth_Resp Chiph_Mod_Cmd Chiph_Mod_Cmd _complete Setup Call_Confirmed PSTN
Sonnerie Alerting ACM ACM Dcroch Connect Answer Answer
CONVERSATION
Raccroch Disconnect Release Release Relsead Release_complete Release_complete Clr_Comm Ch_Release Clr_Complete
Fig. 2.3. procdure MTC
2.3.2
Appel sortant (Mobile Originating Call MOC)
Il s agit presque de la mme procdure MTC sauf que cette fois-ci, c le mobile qui initie est l appel, il fait la connexion radio SDCCH avec sa station de base puis il transmet une demande
Mahdi Kallel
14
Projet de n d tudes
Etat de l art
de service (SERVICE REQUEST). Ensuite, les tapes qui suivent sont identiques celle dcrites en MTC. Voir la gure 3.4[5].
MS Ch_Req Imm-Ass SABM + Serv_Req UA Conn_ Req BSS Interface A MSC VLR PSTN
Process Access_Req Authenticate
Auth_Req Auth_Resp
Auth_Req
Auth_Resp
Authenticate.Res Set_Ciph_Mod
Chiph_Mod_Cmd
Chiph_Mod_Cmd
Chiph_Mod_Cmd _complete Chiph_Mod_Cmd _complete Chiph_Mod_Cmd _complete Rallocation TMSI Optionnelle SETUP Process Access_Req_Accept SETUP Call_Proceeding Ass_Req Complete_Call
Call_Proceeding Ass_Req Ass_Complete
Ass_Complete
AIM (numro demand) ACM
Alerting Connect Connect_Ack
Alerting Connect
Answer
Connect_Ack
CONVERSATION
Raccroch Disconnect Release Release Relsead Release_complete
Release_complete Ch_Release Clr_Comm Clr_Complete
Fig. 2.4. Procdure 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 faon priodique. Si la nouvelle localisation du mobile appartient au mme VLR que la localisation prcdente, alors il s agit d LU intra VLR. Les principales tapes sont : la connexion radio SDCCH, la un demande de LU, l authentication et enn l excution de la mise jour au niveau de VLR. Voir la gure 2.5[5].
Mahdi Kallel
15
Projet de n d tudes
Etat de l art
MS Ch_Req Imm_Ass Loc_Upd_Req
BSS
Interface A
MSC/VLR
Loc_Upd_Req Auth_Req Auth_Req Auth_Resp Auth_Resp Loc_Upd_Acc Loc_Upd_Acc Clr_Comm Clr_Complete Ch_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 appartient pas au mme VLR de l ancienne localisation. Cette fois-ci, la mise jour de localisation passe par le HLR qui conrme 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 authentication.
Mahdi Kallel
16
Projet de n d tudes
Etat de l art
MS Ch_Req Imm_Ass Loc_Upd_Req
BSS
Interface A
MSC
VLR2
HLR
VLR1
Loc_Upd_Req Loc_Upd.Area Provide IMSI IMSI_Req Identity_Req Identity_Resp IMSI_Resp IMSI_Ack Send Param (Req_Authent_set) Send Param.Result (Rand, Sres, Kc) Authenticate Auth_Req Auth_Req Auth_Resp Auth_Resp Authenticate.Res Update_Loc Insert Subscriber data Insert Subscriber data.ACK Cancel_Loc Cancel_Loc_ACK Update_Loc_ACK Set_Ciph_Mod Chiph_Mod_Cmd Chiph_Mod_Cmd Chiph_Mod_Cmd _complete Chiph_Mod_Cmd _complete Chiph_Mod_Cmd _complete Forword_New_TMSI TMSI Realloc_Cmd TMSI Realloc_Cmd TMSI Realloc_complete TMSI Realloc_complete Forword_New_TMSI.Res Loc_Upd.Area_ACK Loc_Upd_Accept Loc_Upd_Accept Clr_Comm Clr_Complete Ch_Release
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 dclenche suite un algorithme spcique qui met en vigueur les critres de dclenchement suivants : le niveau de champs, la qualit du lien radio, le niveau d interfrence, l loignement du mobile de sa station de base et le trac. Les handovers peuvent tre par ordre hirarchique 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 dtermination 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 procdure.
Mahdi Kallel
17
Projet de n d tudes La procdure du handover inter-BSC est donne par la gure2.7.
Etat de l art
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. Aprs les phases rituelles de connexion radio Sur SDCCH et l authentication, le mobile envoie son SMS sur la voie de signalisation. Si ce message parvient au centre d SMS (SMSC), le mobile reoit un acquittement positif. Cette procdure est illustre par la gure 2.8 [6]. (On a pris le cas d SMS sortant). un
Fig. 2.8. Le transfert d SMS sortant un

Pour intercepter ces dirents messages transits a travers l interface A, TUNISIANA a implment un analyseur de protocole Astellia : une socit spcialise dans la conception de solutions matrielles et logicielles ddies l optimisation des performances des rseaux de la tlphonie mobile. Le paragraphe suivant explique la mthode Astellia de capture.
Mahdi Kallel
18
Projet de n d tudes
Etat de l art
2.4
La mthode ASTELLIA : explication des notions Etat, transition, event
Le dispositif de capture intercepte les messages qui transitent travers l interface A. Pour qu russisse dcoder et comprendre chaque message, l il enchanement de chaque procdure GSM doit tre pris en compte lors de sa conguration initiale. Cette conguration dnit un ensemble d tats de telle faon que chaque message intercept fait changer un tat donn de l automate de l analyseur. Par dnition, Une transition est constitue de : Un tat original ; Un tat nal Un message (event) avec parfois une cause associe. Ce message est le message proprement dit, connu, dnit par la norme et capt au niveau de l interface A. Les event sont parfois accompagns d une extension permettant : d indiquer le sens du message ; d ajouter une information supplmentaire. 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 direntes transitions implmentes sur l automate et qui est fournis lors de la livraison du produit et mis jour si ncessaire [6].
Fig. 2.9. Table des transitions et les compteurs relatifs
Chaque connexion passe une succession ordonne d tats de l automate selon la procdure GSM (MOC, MTC, LU, SMS, HO. . . ). Dans la procdure MOC, par exemple, le premier message qui passe par l interface A est le message SERVICE_REQUEQST not dans le tableau CMSRQ. Ce message fait donc changer l tat de l automate de l tat VIDE l tat OC_CMSREQ. Le deuxime 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 procdure MOC doit passer. Par consquent, la classication des transitions par procdure et leur organisation par ordre d enchanement de chaque procdure est indispensable pour tirer les compteurs associs qui seront par la suite la base de la phase de la conception des indicateurs clefs de performance. Chaque transition fait incrmenter un ou plusieurs ces compteurs dits e caces qui gurent dans le chier .EFF gnr par Cigale.
Mahdi Kallel
19
Projet de n d tudes
Etat de l art
L tude des spcits de l interface A dans ce chapitre, ainsi que la description de la mthode Astellia vont tre des lments clefs pour la comprhension 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 rseau.
Mahdi Kallel
20
Conception des indicateurs
Chapitre
Projet de n d tudes
3.1
Dmarche
La conception des indicateurs ncessite une connaissance des procdures que dnit la norme GSM. Puisqu eet, les messages de ces procdures qui transitent travers l en interface A constituent la base des indicateurs conus. L analyse et la distinction entre les messages sur l interface A des direntes procdures s avrent donc indispensables dans la mesure o il s agit de l tape prliminaire de la conception des indicateurs. Aprs l identication des messages dterminant 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 aprs la documentation et analyse des dirents chiers gnrs par Cigale, il s est avr que le chier .EFF, gnr chaque jour par capture, est le plus intressant vu qu donne il un ensemble de compteurs qui s incrmentent suite aux transitions de l tat de l automate donc suite aux messages qu dsire calculer l on occurrence. Ces compteurs sont classis par cellules. La gure 3.1 montre la structure d chier .EFF. un
Mahdi Kallel
22
Projet de n d tudes
Fig. 3.1. Exemple de chier .EFF
Il n existe pas encore une documentation qui donne la dnition des compteurs que le chier .EFF calcule. On ne peut savoir leurs signications que si on passe par une analyse exhaustive du chier Automate.BDT qui donne l ensemble de toutes les transitions congures sur l analyseur de protocole avec les compteurs qui s incrmentent suite chaque transition. La gure 3.2 montre le chier Automate.BDT .
Fig. 3.2. chier Automate.BDT
Chaque ligne est une transition forme par un tat initial, le message, l tat suivant et, optionnellement, les extensions et les causes (les causes des rejets si c une transition de rejet). est A la n de la ligne on trouve les compteurs qui s incrmentent suite chaque transitions. Un compteur peut correspondre une ou plusieurs transitions et une transition peut incrmenter un
Mahdi Kallel
23
Projet de n d tudes
ou plusieurs compteurs selon le cas et selon les extensions o les causes. Par consquent, pour la conception d indicateur il faut paser par les tapes suivantes : un S inspirer des indicateurs de performances OMC des fournisseurs d quipements ; Identication des messages cruciaux qui transitent travers l interface A pour chaque procdure GSM selon le critre de qualit de service et les critres techniques ; Rorganiser les transitions qui se trouvent dans le chier Automate.BDT selon le droulement de chaque procdure ; Identier la transition qui correspond ces messages ; Tirer les compteurs associs ; Dnition de la formule.
3.2
Les indicateurs MOC
Lors de ce pargraphe, nous allons essayer de parcourir toute la procdure en commenant par l tablissement d appel sortant puis la converstion. 3.2.1 Etablissement d appel (Call SETUP)
L tablissement d appel sortant passe par 3 tapes : un
Fig. 3.3. Les tapes de la procdure MOC
Etape 1 : Elle Commence avec le message initial sur l interface A (CM SERVICE REQUEST) et se termine avec la demande du canal de trac TCH (ASSIGNEMENT REQUEST) Etape 2 : Elle commence avec la demande du canal TCH (ASSIGNEMENT REQUEUST) et se termine par le message de succs d allocation d canal TCH (ASSIGNEMENT COMun PLETE). Etape 3 : Elle commence avec le message de succs d allocation d canal TCH (ASSIun GNEMENT COMPLETE) et se termine par la connexion directe (DIRECT CONNECT). Nous allons tablir les indicateurs relatifs chaque tape en distinguant les scnarios d chec et de succs correspondants. 3.2.1.1 L tablissement de la connexion radio (Demande de canal SDCCH)
L tablissement de la connexion radio est l tape prliminaire pour toute procdure GSM. Elle n pas spcique la procdure de l est appel sortant. Nanmoins, il n a aucun message qui y transite sur l interface A pour cette tape (voir gure 3.4 [6])
Mahdi Kallel
24
Projet de n d tudes
Fig. 3.4. Demande d canal SDCCH un
Il en rsulte que l analyseur de protocole ne va pas dtecter cette tape ce qui n pas le cas est des tapes suivantes. . . 3.2.1.2 Dclenchement :
Le dclenchement de toute la procdure 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
Projet de n d tudes
SREQ) selon la transition suivante : (CMSRQ tant le message SERVICE_REQUEST selon la nomenclature d Astellia)
CMSRQ VIDE BSC MSC OC_CMS_REQ
Nous pouvons ainsi dnir 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 dbut et une n. Il se peut que la capture se ferme alors que la procdure n pas encore termine. Il en rsulte qu peut trouver quelques a on incohrences dans les chiers gnrs par ces captures : c ce qu appelle les Purges . est on Pour tre plus concis, et pour que ce phnomne n aecte pas nos calculs, il faut retrancher le nombre de purges du nombre total de tentatives MOC. La transition mentionne ci-dessus fait incrmenter le compteur Nb_OC qui gure dans le chier .EFF . Le nombre de purges de l appel sortant est donn par le compteur NbPURGE_E1_OC pour 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 gnrique suivante : Nombre_Appels_MOC=NbOC-NbPURGE_E1_OC-NbPURGE_E2_OCNbPURGE_E3_OC 3.2.1.3 Authentication 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 premire tentative de l authentication (OC_AUT_REQ_1) selon la transition suivante :
AUTRQ OC_CMS_REQ MSC BSC OC_AUT_REQ_1
Cette transition correspond au message AUTHENTICATION_REQUEST. (Voir gure 3.6)
Mahdi Kallel
26
Projet de n d tudes
Fig. 3.6. authentication et passage en mode chir
Si le mobile rpond, le BSC envoi le SRES calcul par le mobile au MSC dans un message AUTHENTICATION RESPONSE (AUTRP). L automate fait alors la transition suivante :
AUTRP OC_AUT_REQ_1 BSC MSC OC_AUT_RP
Une fois le mobile est authenti, le MSC envoi une commande de chirement de la couche BSSMAP CMCMD (Cipher Mode CoMmanD). Ceci correspond la transition suivante :
CMCMD OC_AUT_RP MSC BSC OC_CIM_CMD
Le mobile rpond 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 :
CMCMP OC_CIM_CMD BSC MSC OC_CIM_CMP
Mahdi Kallel
27
Projet de n d tudes 3.2.1.4 Dbut d appel
Aprs la phase de l authentication et du passage en mode chir, vient la phase de dbut d appel ( On ne parle pas encore du dbut de la conversation). Dans cette phase les donnes ncessaires pour l tablissement d appel sont envoyes par le mobile (voir gure 3.7)
Fig. 3.7. Dbut d appel
Le passage cette tape correspond la transition suivante :
SETUP OC_CIM_CMP BSC MSC OC_SETUP
Selon le numro 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 :
CPROC OC_SETUP MSC MSC BSC OC_PROC
3.2.1.5
A ectation d canal de trac un
Si le MSC a allou un circuit, il ordonne le BSC d attribuer au mobile un canal de trac TCH dans un message ASREQ (ASsignment REQuest). La procdure est illustre par la gure 3.8 [6] Ce message fait changer l tat de l automate comme suit :
Mahdi Kallel
28
Projet de n d tudes
Fig. 3.8. Aectation d canal de trac un
ASREQ OC_PROC MSC MSC BSC OC_ASS_REQ_1
Cette transition fait incrmenter le compteur NbASREQ_OC. Si toute la procdure de l aectation de canal TCH est termine avec succs, le BSC envoi le message ASCMP (ASsignment CoMPlete) au MSC. L automate change alors d tat :
ASCMP OC_ASS_REQ_1 OC_ASS_CMP BSC MSC MSC
Cette transition fait incrmenter le compteur NbASCMP_OC. Ainsi on peut dnir un indicateur qui caractrise le taux de succs de l attribution d canal un TCH dans la procdure MOC. Cet indicateur est de type Succs/Demandes. Il est donn par la formule suivante : T aux_succes_attribution_T CH_M OC = N bASCM P _OC N bASREQ_OC (3.1)
Mahdi Kallel
29
Projet de n d tudes 3.2.1.6 Conrmation 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 :
ALERT OC_ASS_CMP MSC MSC BSC OC_SONN
Si l appel dcroche, MSC fait la connexion avec le mobile par la commande CON (CONnect). La transition correspondante est la suivante :
CON OC_SONN MSC MSC BSC OC_CON
S est connect, le mobile envoi un acquittement positif dans un message CONACK il (CONnect ACKnowledge). La transition est la suivante :
CONACK OC_CON BSC MSC MSC OC_COMM
Mahdi Kallel
30
Projet de n d tudes
Cette transition rsume le succs de l tablissement d appel MOC. Elle fait incrmenter le compteur NbCONACK_OC. Nous pouvons dnir l indicateur de succs d tablissement MOC comme tant succs/demandes, soit : N b_CON ACK_OC N ombre_Appel_M OC
Succes_etablissement_M OC_U ser =
(3.2)
Cet indicateur re la performance de la procdure MOC comme l te aperoit l utilisateur. En eet, un tablissement d appel qui a commenc par SERVICE REQUEST et qui n pas est termin par CONNECT Ack sera considr comme chou mme si les causes sont normales et ne reprsentant pas de problmes 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 donne pour voir si les abonnes communiquent ou non. Mais son insu sance est qu induit l il erreur s s il agit d problme un purement technique. Dans ce contexte, notre ide tait d ajouter l extension USER cet indicateur pour montrer sa signication relle. En outre, il a t indispensable de concevoir un indicateur qui re la te performance de la procdure MOC techniquement. Pour se faire, nous avons constat que les causes normales d abondant d appel se produisent en gnral pendant la phase de conrmation d appel, c est--dire pendant la phase de sonnerie. Il en rsulte que le message qui re le succs de la procdure d te tablissement d appel techniquement est ASSIGNEMENT_COMPLETE : le message qui, suite auquel, un canal TCH est allou. Ce message fait incrmenter le compteur NbASCMP_OC. Ainsi, le taux de succs de l tablissement d appel sortant MOC techniquement est dnit par : Succes_etablissement_M OC_T ech = 3.2.2 Echec d appel sortant N bASCM P _OC N ombre_Appel_M OC (3.3)
Lors de notre tude des dirents scnarios d chec de l appel sortant, on a pu identier les messages d checs qui transitent travers l interface A, et de voir les causes correspondantes. Le tableau ci-aprs illustre bien ces messages.
Mahdi Kallel
31
Projet de n d tudes
Message/ Sens
S E RV IC E _ R E J E C T (M S C -B S C )
Causes
SONS IU H IU V NF IM E IN A
Description des causes

S e rv ic e O p tio n N o t S u p p o rte d , se rv ic e d e m a n d n st p a s va la b le . e IM S I U n k n ow n in th e H L R IM S I U n k n ow n in th e V L R N e tw o rk Fa ilu re : ch e c N S S IM E I N o t A c c e p te d (E q u ip e m e nt vo l ) R a d io Inte rfa c e Fa ilu re : le m o b ile p e rd la c o n n e x io n ra d io ave c sa B T S E q u ip e m e nt Fa ilu re : u n q u ip e m e nt d e la p a rtie B S S n e fo n c tio n n e p a s R a d io Inte rfa c e M e ssa g e Fa ilu re : e rre u r d e m e ssa g e su r l inte rfa c e ra d io . L e m o b ile d o n n e u n S R E S e rro n
C L E A R R E Q U E S T (B S C -M S C )
R IF EF R IM F
A U T H R E J E C T (M S C -B S C ) C O N N E C T IO R E F U F E D (M S C -B S C ) CR NC IN F UN NUR UB NCCA NOOO A S S E IG N M E N T FA IL (B S C -M S C ) NRRA R IF E F
C o n n e c tio n S C C P e st re fu s e e ntre le B S C e t le M S C N o rm a l C le a rin g : le m o b ile q u itte l p p e l vo lo nta ire m e nt a Inva lid N u m b e r Fo rm a t : le m o b ile c o m p o se u n fo rm a t d e nu m ro inva lid e U n a ssig n e d N u m b e r : le nu m ro d e m a n d e st inva lid e N o U se r R e sp o n d in g : l p p e l n e r p o n d p a s a U se r B u sy : a p p e l o c c u p N o C irc u it C h a n n e l A va ila b le : p a s d e c irc u its va la b le s a u n ive a u M S C . N e tw o rk O u t O f o rd e r : le r se a u n e r p o n d p a s N o R a d io R e so u rc e A va ila b le : p a s d e re sso u rc e s T C H va la b le s. M m e sig n ic a tio n q u e le m e ssa g e C le a r re q u e st
Tab. 3.1. dnition des causes de rejet
L automate Cigale regroupe les scnarios d chec de l appel sortant par le couple (partie, tape). On distingue : Le couple (NSS, tape x) regroupe les scnarios d chec cot NSS pendent l tape 1 de l appel sortant. Il correspond au compteur OCx_AfNSS (x dans {1, 2, 3}). Ce compteur s incrmente chaque foi que l automate dtecte un chec d tablissement d appel sortant pendant l tape 1 du un problme du cur du rseau par une transition bien spcique. Les causes Associs ce compteur sont : NF, NOO, NCCA (voir la dnition de ces causes dans le tableau prcdant) Le couple (BSS, tape x) regroupe les scnarios d chec cot BSS de l appel sortant. Il correspond au compteur OCx_AfBSS (x dans {1, 2, 3}). Ce compteur s incrmente chaque fois que l automate dtecte un chec d tablissement d appel sortant pendant l tape 1 du un problme dans les quipements de la partie BSS. Les causes associes ce compteur sont : EF, NRRA (Voir la dnition de ces causes dans le tableaux prcdant). Le couple (MS, tape x) regroupe les scnarios d chec de l appel sortant du ct de utilisateur. Il correspond au compteur OCx_AfMS : Ce compteur comptabilise l chec de la procdure MOC dans sa phase 1 cause du mobile. Les causes associes ce compteur sont : SONS, UIH, UIV, IMEINA, NC, INF, UN, NUR, UB. Le couple (BSSMS, tape x) regroupe les scnarios d chec de l appel sortant sur l interface radio. Il correspond au compteur OCx_AfBSSMS : ce compteur est incrment s y il a un chec au niveau de l interface radio dans la premire tape du MOC, par exemple lors de l authentication (Voir gure 3.10). Les causes associes ce compteur sont : RIF, RIMF.
Mahdi Kallel
32
Projet de n d tudes
Fig. 3.10. Echec radio lors de l authentication
Le couple (NSSMS, tape x) regroupe les scnarios d chec de l appel sortant du un problme dans les protocole des couches hautes (CM, RR) qui rgissent le dialogue direct entre la partie NSS et le mobile. Il correspond au compteur OCx_AfNSSMS. Ce compteur est incrment s y a un problme dans le dialogue du mobile avec les bases de donns du rseau il au court de la procdure MOC. Les causes associs ce compteur sont : IUH et IUV. Le couple (NSSBS, tape x) regroupe les scnarios d chec de l appel sortant du un problme de connexion entre le BSC et le MSC. Il correspond au compteur OCx_AfNSSBS. Ce compteur est incrment s y a un problme de connexion SCCP entre le BSC et le MSC. il La cause associe ce compteur est CR. Nous avons pu identier ces compteurs en identiant les transitions correspondantes aux messages d checs. Ainsi, nous pouvons rassembler des indicateurs de l chec de l tablissement de la procdure MOC par cause. 3.2.2.1 Le taux d chec d tablissement MOC reli un problme NSS
C la somme des checs cause NSS des trois tapes ensembles divise par le nombre total est des tentatives MOC, soit :
3 P
(OCx_ Af N SS + OCx_ Af N SSM S + OCx_ Af N SSBS) N ombre_ Appel_ M OC (3.4)
Echec_M OC_N SS = 3.2.2.2
x=1
Le taux d chec d tablissemnt MOC reli un problme BSS
C la somme des checs cause BSS des trois tapes ensembles divise par le nombre total est de tentatives MOC, soit :
Mahdi Kallel
33
Projet de n d tudes
Echec_M OC_BSS = 3.2.2.3
x=1
3 P
(OCx_Af BSS + OCx_Af BSSM S) N ombre_Appel_M OC (3.5)
Le taux d chec d tablissemnt MOC reli un problme utilisateur
C la somme des checs cause utilisateur des trois tapes ensembles divise par le nombre est total de tentatives MOC, soit :
3 P
OCx_Af M S (3.6)
Echec_M OC_U ser =
x=1
N ombre_Appel_M OC
Nous pouvons ainsi en dduire le taux d chec de la procdure MOC techniquement, c est-dire que nous liminons l chec de la procdure caus par l utilisateur car il n entre pas en jeux pour la dtermination de la performance du rseau. Il en rsulte que le taux d chec de l tablissement MOC est la somme des indicateurs Echec_MOC_NSS et Echec_MOC_BSS, soit :
Echec_CALL_SET U P _M OC = Echec_M OC_N SS + Echec_M OC_BSS
(3.7)
A partir de l, nous pouvons dgager une autre approche dirente de celle cite prcdemment concernant la formule du Succs_tablissement_MOC _Tech , ce n d est autre que : Succes_etablissement_M OC_T ech = 1 3.2.3 La Conversation Echec_CALL_SET U P _M OC (3.8)
La phase de la conversation commence aprs le message de connexion CONNECT ACK. La chose qui peut le plus gner l utilisateur c lorsque son appel est coup involontairement au est cour d une communication, c ce qu appelle le call drop ou coupure d est on appel. C un indicateur crucial pour la dtermination de la qualit de service du rseau techniest quement mais, aussi du ct de l utilisateur, car ce phnomne engendre en gnral les plaintes des clients. Pour la coupure d appel l automate Cigale change d tat selon la transition suivante :
<Message i> OC_COMM OC_COMM_FIN
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 dnition de ces causes dans le tableau 4.1). On peut ainsi dnir des indicateurs de performances relatifs la coupure d appel par cause.
Mahdi Kallel
34
Projet de n d tudes 3.2.3.1 La Coupure d appel due un problme BSS
Deux paramtres 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 et OCcom_AfBSSMS, et nous allons les diviser sur le nombre total des conversations sortantes qui est le nombre d occurrence du dernier message de l tablissement d appel CONNECT ACK, Soit : Coupure_M OC_BSS = 3.2.3.2 OCcom_Af BSS + OCcom_Af BSSM S N bCON ACK_OC (3.9)
La Coupure d appel due un problme NSS
Les compteurs prendre en compte sont OCcom_AfNSS, OCcom_AfNSSBS et OCcom_AfNSSMS. Et nous allons les diviser sur le nombre total des conversations sortantes. Soit : OCcom_ Af N SS + OCcom_ Af N SSM S + OCcom_ Af N SSBS N bCON ACK _ OC (3.10)
Coupure_M OC_N SS =
3.2.3.3
La Coupure totale d appel MOC
C la somme des deux indicateurs prcdents : est Coupure_M OC = Coupure_M OC_BSS + Coupure_M OC_N SS (3.11)
3.3
Les indicateurs MTC
La procdure MTC est identique la procdure MOC sauf pour la phase d initiation d appel. En eet, contrairement la procdure MOC, celle-ci est initie par le rseau et non pas par le mobile. Pour le reste de la procdure tous les indicateurs auront la mme dnition que leurs homologues de la procdure MOC. Le rseau lance un avis de recherche du mobile (BSSMAP PAGING) sur l ensemble des BSC du LAC du mobile. Si le mobile reoit cet avis de recherche de la part de sa BTS, il tablit la connexion radio (voir gure 3.11) :
Mahdi Kallel
35
Projet de n d tudes
Fig. 3.11. Recherche du mobile

Le message PAGING ne pouvait pas tre le message dclencheur de la procdure MTC pour la simple raison qu est envoy pour tout les BSC du LAC du mobile recherch, donc sur l il ensemble des interfaces A relatifs ces BSC. Si le mobile est trouv, il envoi au rseau sa rponse la recherche (PAGING RESPONSE). (Voir gure 3.12) :
Mahdi Kallel
36
Projet de n d tudes
Fig. 3.12. Rponse au paging
Le dclenchement de toute la procdure 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 rponse la recherche (TC_PAG_RP) selon la transition :
PAGRP
VIDE BSC MSC
TC_PAG_RP
PAGRP tant le message PAGING selon la nomenclature Astellia. On peut ainsi dnir 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 dbut et une n. Il se peut que la capture se ferme alors que la procdure n pas encore termine. Il en rsulte qu peut trouver quelques est on incohrences dans les chiers gnrs par ces captures : c ce qu appelle les Purges . Pour est on tre plus concis, et pour que ce phnomne n aecte pas nos calculs, il faut retrancher le nombre de purges du nombre total de tentatives MTC. Or, la transition mentionne ci-dessus fait incrmenter le compteur Nb_TC qui gure dans le chier .EFF . Et le nombre de purges de l appel entrant est donn par le compteur NbPURGE_E1_TC pour les Purges de la phase1 de l tablissement d appel, NbPURGE_E2_TC pour 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 gnrique suivante : Nombre_tentatives_MTC=Nb_TC-NbPURGE_E1_TC-NbPURGE_E2_TC
Mahdi Kallel
37
Projet de n d tudes
-NbPURGE_E3_TC Pour tout le reste des indicateurs MTC, il s agit de la mme dmarche adopte pour les indicateurs MOC puisqu s il agit quasiment de la mme procdure. En consquence de quoi, on peut donner la dnition des indicateurs suivants : T aux_succes_attribution_T CH_M T C = N bASCM P _T C N bASREQ_T C (3.12)
Succes_etablissement_M T C_U ser =
N b_CON ACK_T C N ombre_Appel_M T C N bASCM P _T C N ombre_Appel_M T C
(3.13)
Succes_etablissement_M T C_T ech =
(3.14)
Echec_M T C_N SS =
x=1
3 P
(T Cx_ Af N SS + T Cx_ Af N SSM S + T Cx_ Af N SSBS) N ombre_ Appel_ M T C

3 P
(3.15)
(T Cx_Af BSS + T Cx_Af BSSM S) N ombre_Appel_M T C

3 P
Echec_M T C_BSS =
x=1
(3.16)
T Cx_Af M S (3.17)
Echec_M T C_U ser =
x=1
N ombre_Appel_M T C
Echec_CALL_SET U P _M T C = Echec_M T C_N SS + Echec_M T C_BSS
(3.18)
Succes_etablissement_M T C_T ech = 1
Echec_CALL_SET U P _M T C
(3.19)
Coupure_M T C_BSS =
T Ccom_Af BSS + T Ccom_Af BSSM S N bCON ACK_T C
(3.20)
Coupure_M T C_N SS =
T Ccom_ Af N SS + T Ccom_ Af N SSM S + T Ccom_ Af N SSBS N bCON ACK _ T C (3.21) (3.22)
Coupure_M T C = Coupure_M T C_BSS + Coupure_M T C_N SS
3.4
Les indicateurs d appel
Ces sont des indicateurs hybrides MTC/MOC. Ils sont dduit partir des indicateurs MOC et MTC de la faon suivante : 1 2 Si indicateurM OC = x1 et indicateurM T C = x2 y y x1 +x2 Alors indicateurAppel = y1 +y2
Mahdi Kallel
38
Projet de n d tudes
3.5
Mise jour de localisation (Location Update)
Comme nous avons fait pour la procdure MOC, nous allons parcourir toute la procdure de mise jour de localisation, tirer les messages cruciaux et identier les transitions automate correspondantes. Nous allons dduire ensuite les compteurs bruts qui correspondent ces transitions pour essayer d tablir les indicateurs clefs de performances de la procdure Location Update (LU). 3.5.1 Etablissement de la connexion radio
C l est tape prliminaire de toutes les procdures GSM inities par le mobile. Elle consiste attribuer un canal SDCCH au mobile par le BSC. Nous n allons pas en tenir compte pour la dtermination de la performance du la procdure LU vu qu est indtectable sur l elle interface A. 3.5.2 Indication de service
Aprs 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 encapsul dans un message de la couche BSSMAP et accompagn par une demande de connexion SCCP entre MSC et BSC. Ce message traduit le dclenchement de toute la procdure LU. L automate Astellia fait la transition correspondante suivante :
Mahdi Kallel
39
Projet de n d tudes
LUREQ VIDE BSC MSC
LU_N
Dans cette transition, l tat de l automate passe de l tat initial vide (VIDE) LU_N (Location Updating Normal). Selon le type de demande de mise jour de localisation, cet tat est : LU_P pour une mise jour de localisation priodique, LU_N pour une mise jour de localisation normale, LU_IA pour une mise jour de localisation IMSI Attach. Cette transition fait incrmenter le compteur NbLUREQ_NU pour le LU normal, NbLUREQ_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 procdure. Cependant, l automate ne comptabilise que les purges pendant la mise jour de localisation priodique, il ne le fait pas pour les deux autres types (LU_P et LU_IA). Nous pouvons en dduire le nombre de tentative LU pour chaque type : N ombre_tentativesLU _N = N bLU REQ_N U N bP U RGE_LU _N U N ombre_tentativesLU _P = N bLU REQ_P N ombre_tentativesLU _IA = N bLU REQ_IA 3.5.3 Allocation Numro temporaire
Aprs l authentication et le passage en mode chir, le nouveau VLR du mobile fait une allocation d nouveau TMSI pour le mobile (Voir gure 3.14). un A noter que s s il agissait d LU ave IMSI Attach, une tape de demande du IMSI est un ajoute avant l authentication.
Mahdi Kallel
40
Projet de n d tudes
Fig. 3.14. Allocation TMSI
Le message LOCATION_UPDATING_ACCEPT envoy du MSC au BSC traduit, de point de vue interface A, le succs de la procdure LU. Ce message correspond la transition suivante de l tat de l automate :
LUACC
LU_COMM MSC BSC
LU_FIN
Cette transition fait incrmenter le compteur NbLUACC_NU s s il agit d LU normale, un NbLUACC_PU s s il agit d LU priodique. Pour LU avec IMSI Attach l un automate n implmente pas de compteurs spciques. La dduction du taux de succs de la procdure LU en faisant le rapport du nombre des messages de succs (ACCEPT) sur le nombre total de demandes est dsormais possible. Nous aurons alors les formules gnriques suivantes : T aux_Succes_LU _N = N bLU ACC_N U N ombre_tentativesLU _N N bLU ACC_P U N ombre_tentativesLU _P (3.23)
T aux_Succes_LU _P = 3.5.4 Echec LU
(3.24)
Comme le cas de la procdure MOC ou MTC, les causes d chec sont regroupes par partie : NSS, BSS et MS. En cas d chec l automate Astellia fait la transition suivante :
Mahdi Kallel
41
Projet de n d tudes
LUREJ
LU_N
LU_FIN
Le message correspondant est LU REJect (Location Updating REJect). Cette transition fait incrmenter le compteur LU_N_Fail_User s s il agit d chec caus par l un abonn, LU_N_Fail_BSS s s il agit d chec d un origine BSS et LU_N_Fail_NSS s s il agit d un chec d origine NSS. Ceci concerne le LU normale. Pour le LU priodique ou IA, c le mme est principe sauf que la nomenclature change. (Au lieu la lettre N pour normale on trouve la lettre P pour priodique 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 : N U _N _F AIL_U SER+N U _P _F AIL_U SER+N U _IA_F AIL_U SER T aux_echec_LU _U SER = N ombre_tentativesLU _N +N ombre_tentativesLU _P T aux_echec_LU _BSS = T aux_echec_LU _N SS = On peut vrier que la somme des taux d chec NSS, USER et BSS n d est autre que la dirence (1-taux de succs) dj calcul.
N U _N _F AIL_BSS+N U _P _F AIL_BSS+N U _IA_F AIL_BSS N ombre_tentativesLU _N +N ombre_tentativesLU _P N U _N _F AIL_N SS+N U _P _F AIL_N SS+N U _IA_F AIL_N SS N ombre_tentativesLU _N +N ombre_tentativesLU _P
3.6
Les indicateurs Handover
Parmi les maillons faibles du suivi de la performance du rseau GSM partir de l interface A, on distingue une limite pour la procdure handover. En eet, 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 Handover sortant
3.6.1.1
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 minimum requis, et que un la cellule cible appartient un autre BSC, alors le BSC origine demande un handover Inter-BSC auprs du MSC par le biais d message de la couche BSSMAP HORQD (HandOver_ReQuireD) un (voir gure 3.15).
Mahdi Kallel
42
Projet de n d tudes
Fig. 3.15. Handover sortant

Ce message traduit le dclenchement de toute la procdure Handover sortant. Il est possible de constater que l tat de l automate ne change pas pendant l tablissement et l excution du handover. IL reste celui de la procdure en cours. IL en rsulte que les transitions dans la procdure 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 :
HORQD TC_COMM BSC MSC
TC_COMM
Et la transition suivante traduit la demande de handover entrant pendant un appel sortant en phase de sonnerie :
HORQD TC_SONN BSC MSC
TC_SONN
L occurrence du message HORQD est donne par le compteur EtHoTotal_THorqd. Le nombre de purges sur HO sortant est donn par le compteur NbPURGE_E1_HO. Il en rsulte que le nombre total de demandes de HO sortant est :
N ombre_tentatives_HO_sortant = EtHoT otal_T Horqd
N bP U RGE_E1_HO
(3.25)
Mahdi Kallel
43
Projet de n d tudes
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 excuter le handover. Ce message fait incrmenter le compteur EtHoTotal_THocmd. Pendant cette phase de la procdure, il est utile de concevoir un indicateur qui re la performance de la procdure du te 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 rponse du BSC cible par rapport au nombre total des demandes handover. Nous obtenons donc : EtHoT otal_T Hocmd N ombre_tentatives_HO_sortant
T aux_HO_InterBSC_Sortant_Reponse =
(3.26)
Aprs sa reception de l ordre de l excution 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 russit atteindre le BTS cible. Alors le MSC envoie un message CLEAR COMMAND au MSC. Il rsume le succs de la procdure du HO sortant cot interface A origine. Ce message de la couche BSSMAP fait incrmenter le compteur EtHoTotal_THoClmd. Le taux de succs du handover sortant est alors le rapport de l occurrence de ce message sur le nombre total de tentatives HO sortant. Soit : EtHoT otal_T HoClmd N ombre_tentatives_HO_sortant
T aux_HO_InterBSC_Sortant_Succes = 3.6.1.2 Handover entrant
(3.27)
Un handover est considr 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
Projet de n d tudes
Fig. 3.17. Handover entrant
L tat de l automate fait donc la transition suivante :
HOREQ VIDE MSC BSC
HO_TCH_REQ
L occurrence de cette transition sur l interface A traduit le nombre de demandes de handover entrant. Et puisqu fait incrmenter le compteur NbHORQ_HO et que le nombre de purges elle sur le HO entrant est donn par NbPURGE_E2_HO, nous pouvons conclure donc que :
N ombre_tentatives_HO_entrant = N bHORQ_HO
N bP U RGE_E2_HO
(3.28)
Ensuite, le BSC cible active un canal radio sur la BTS demande. Si cette action s droule est avec succs, le BSC envoie un message d acquittement accompagn d une commande d excution du handover. Dans ce cas, l tat de l automate fait la transition suivante :
HO_TCH_REQ
HORAC BSC MSC
HO_TCH_RAC
Cette transition fait incrmenter le compteur NbHORQACK_HO. Si cette transition n abouti pas, alors on peut conclure qu y a un problme de disponibilit de ressources radios. il
Mahdi Kallel
45
Projet de n d tudes
L ides t de concevoir un indicateur qui met en vidence ce problme. C donc le rapport de est l occurrence du message HORAC sur le nombre total de tentatives des HO sortants, soit : N bHORQACK_HO N ombre_tentatives_HO_entrant
T aux_HO_InterBSC_entrant_Reponse =
(3.29)
Ensuite, le BTS cible attend le mobile. Si ce dernier russit accder au canal dj allou sur l interface air, alors le BTS le dtecte 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_RAC
HODET BSC MSC
HO_TCH_DET
Cette transition fait incrmenter le compteur NbHODET_HO. Dans le cas chant, c est-dire que le message n aboutit pas, on peut dduire que le mobile n pas pu rejoindre la nouvelle a cellule cause d problme radio. Concevoir un taux de dtection de handover pouvait aider un analyser les problmes radio. Cet indicateur est le rapport du nombre des messages de dtection sur le nombre total de rponse du BSS cible, soit :
Mahdi Kallel
46
Projet de n d tudes
T aux_HO_InterBSC_entrant_Detect =
N bHODET _HO N ombre_tentatives_HO_entrant
(3.30)
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 procdure du handover sortant a t excute avec succs. Ce message engendre la transition suivante :
HO_TCH_DET
HOCMP BSC MSC
HO_TCH_FIN
Cette transition fait incrmenter le compteur NbHOCMP_HO. Nous pouvons alors concevoir l indicateur du taux de succs du handover entrant comme suit : N bHOCM P _HO N ombre_tentatives_HO_entrant
T aux_HO_InterBSC_Entrant_Succes = 3.6.2 Handover intraBSC
(3.31)
Le seul message qui transite travers l interface A pendant la procdure du handover intra BSC est le message HANDOVER_PERFORMED qui est envoy par le BSC cible au MSC la n d handover intra-BSC ectu avec succs. un Ce message contient des informations tels que la cause du handover. Il est possible de concevoir un indicateur de rpartition des causes du handover. Mais malheureusement, il y avait un problme avec le chier .XLH qui contient ce type d informations. Ce chier fait apparatre des valeurs errones. L quipe QDF a contact le fournisseur Astellia qui en a pris charge.
3.7
Les indicateurs SMS
Il existe deux scnarios 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
Projet de n d tudes
Fig. 3.19. SMS Sortant

Ce message constitue l vnement dclencheur de la procdure SMS, nous allons donc prendre l occurrence de ce message comme tant le nombre de total d SMS envoys par le mobile. Ce message engendre la transition suivante :
MOSMS_EST
SMS_SUBMIT HOCMP BSC MSC
MOSMS_SUB
Cette transition fait incrmenter le compteur SmsSubmit. Le nombre total de SMS sortants est alors : N b_SM S_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 transition suivante :
MOSMS_SUB
RPack MSC BSC
MOSMS_SUB_FIN
Cette transition fait incrmenter le compteur SmsSubmit_RPack. Il en rsulte que le taux de succs de message sortant est donn par :
Mahdi Kallel
48
Projet de n d tudes
SmsSubmit_RP ack (3.33) N b_SM S_OC Le mme 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 dclenche la procdure au niveau de l interface A est la suivante T aux_Succes_SM S_OC =
MTSMS_EST
SMS_DELIVER MSC BSC
MTOSMS_DEL
Cette transition fait incrmenter le compteur SmsDeliver. Le nombre total de SMS sortants est alors : N b_SM S_T C = 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_DEL
RP_MO_ack MSC BSC
MOSMS_SUB_FIN
Cette transition fait incrmenter le compteur SmsDeliver_RPack. Il en rsulte que le taux de succs de message entrant est donn par : SmsDeliver_RP ack (3.35) N b_SM S_T C Il existe des scnarios et des messages d erreurs si la procdure de transmission d SMS un n abouti pas. Il y a un ensemble de transitions d chec qui font incrmenter des compteurs d chec. Comme on a vu pour les autres procdures, les causes d chec peuvent tre groupes par partie ; BSS ou NSS. Cela nous permet de concevoir des indicateurs d chec partir des compteurs d chec associs. Lorsque l chec est du un problme BSS le compteur SmsDeliver_Fail_BSS est incrment pour le SMS entrant et le compteur SmsSubmit_Fail_BSS est incrment pour le SMS sortant. Le taux d chec de transmission SMS du un problme BSS est donn par : T aux_Succes_SM S_T C = SmsDeliver_F ail_BSS + SmsSubmit_F ail_BSS N b_SM S_T C + N b_SM S_OC
T aux_Echec_SM S_BSS =
(3.36)
Lorsque l chec est du un problme NSS le compteur SmsDeliver_Fail_NSS est incrment pour le SMS entrant et le compteur SmsSubmit_Fail_NSS est incrment pour le SMS sortant. Le taux d chec de transmission SMS du un problme NSS est donn par :
Mahdi Kallel
49
Projet de n d tudes
T aux_Echec_SM S_N SS =
SmsDeliver_F ail_N SS + SmsSubmit_F ail_N SS N b_SM S_T C + N b_SM S_OC
(3.37)
3.8
3.8.1
Des indicateurs Divers

Le double appel
Si quelqu appelle un abonn en cours de communication, l un appel sera mis en attente. Si l appel dcide de basculer entre les deux appels qui lui sont arrivs, il doit immdiatement mettre l d un eux en garde car il ne peut pas faire deux communications la fois. Cette procdure est appele le double appel. Elle peut tre active en communication sortante comme elle peut tre active en communication entrante. La transition qui correspond une mise en attente pour un appel sortant est :
OC_COMM
ALERT BSC MSC OC_CALLWAITING MOSMS_SUB_FIN
Cette transition fait incrmenter le compteur NbHOLDACK_OC. Et la transition qui correspond une mise en attente pour un appel entrant est :
TC_COMM
ALERT MSC BSC TC_CALLWAITING MOSMS_SUB_FIN
Cette transition fait incrmenter le compteur NbHOLDACK_TC.Nous pouvons donc concevoir l indicateur : N ombre_M iseAttente = N bHOLDACK_OC + N bHOLDACK_T C (3.38)
L appel a le choix : soit de basculer entre les deux communications soit de maintienir la communication en cours et ngliger celle qui est arrive 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 OC_COMM MSC BSC
OC_CALLWAITING
Cette transition fait incrmenter le compteur NbRETACK_OC. De mme, le compteur NbRETACK_TC est incrment en cas d appel entrant. Le nombre de basculement entre appels est alors donn par : N ombre_ double_ appel = (N bHOLDACK _ OC + N bHOLDACK _ T C) (N bRET ACK _ OC + N bRET ACK _ T C)
Mahdi Kallel
50
Projet de n d tudes 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 nuds sur le rseau se signalisation SS7. Astellia n implmente sur son analyseur de protocole que les connexions SCCP pour les procdures LU, MTC et MOC et ne capte que les messages de type CC (Connection Conrm) ou CREF (Connection REFused). A partir de l, Nous avons eu l ide de concevoir un indicateur qui calcule le taux d chec de la connexion SCCP pour les procdures prcites. Il s agit du rapport de nombre de refus de connexions sur le nombre de demande total de connexions. Chaque message CC fait incrmenter les compteurs NbCC_LUia, NbCC_LUnu, NbCC_LUpu, NbCC_OC et NbCC_TC respectivement pour les procdures LU IMSI Attach, LU normal, Lu priodique, MOC et MTC. Chaque message CREF fait incrmenter les compteurs NbCREF_LU et NbCREF_OCTC respectivement pour les procdures LU, MTC et MOC ensembles. Il en rsulte que l indicateur du taux de refus SCCP a comme formule : N bCREF _OCT C + N bCREF _LU N ombre_ConnexionSCCP
T aux_echec_Connexion_SCCP = 3.8.3 Indicateur de trac
(3.39)
Il est important de savoir l volution du trac coul dans le temps par objet (Cellule, BSC, MSC). Pour chaque circuit (IT MIC), il est possible de dnir le taux d occupation relatif. En introduisant pour reprsenter ce taux, il est dni de la manire suivante : Na Da (3.40) 24 3600 Dans cette expression Na reprsente le nombre d appels passs ou reus par jour dans le circuit concern, Da reprsente la dure moyenne d appel en secondes. Enn le produit 24 un 3600 reprsente la dure d une journe en secondes. On dnit ainsi l occupation du circuit. L unit retenue pour est l Erlang. Ainsi un trac de 1 Erlang (1 E) correspond un circuit occup 24 heures sur 24. Du cot de la capture sur l interface A, la dure d occupation d circuit est calcule sur un chaque ITs des MICs entre BSC et MSC aprs transcodage. Elle est calcule pendant la procdure MOC ou MTC entre le message CONNECT et le message DISCONNECT. Dans cette optique, le chier .XLT qui contient la rpartition du trac sur chaque IT de chaque MIC semble le plus intressant (Voir gure 3.20) : =
Mahdi Kallel
51
Projet de n d tudes
Fig. 3.20. Rpartition du trac
Dans ce tableau Dmoy conv correspond Da et Nb conv correspond Na.Il en rsulte que le taux d occupation d circuit est donn par : un = N bconv 24 Dmoyconv 3600 (3.41)
Les indicateurs conu doivent tre mis en pratiques pour pouvoir les visualiser. Leurs implmentation logicielle dans un outil informatique s avre donc ncessaaire est interressante. Le chapitre suivant va dcrire l application informatique dveloppe en commenant par la conception informatique ensuite en passant vers la ralisation.
Mahdi Kallel
52
Implmentation logicielle
Chapitre
Projet de n d tudes
4
Ce chapitre dcrit la mise en oeuvre de l outil informatique dvelopp. Il commence par expliquer les choix techniques des langages de programmation et des outils utiliss. Ensuite, il s intresse la conception informatique. Enn il cite une description des rsultats aboutis approuvs par quelques captures d crans.
4.1
4.1.1
Conception
Entre/sortie et architecture de l application
Cette application doit mettre aux indicateurs clefs de performances conus 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 donnes qui existent dans les chiers gnrs par captures de l analyseur de protocole sont les sources de base des donnes. L outil doit les traiter de faon harmonique avec l architecture de la base de donnes dans laquelle elles seront stockes. Aprs le traitement et la centralisation des donnes, le programme doit savoir excuter les requtes convenables et eectuer les calculs ncessaires pour pouvoir a cher les courbes et les statistiques souhaites. Avant d avancer dans les dtails de la conception, il faut tout d abord choisir une architecture convenable pour notre application. L architecture choisie tait l architecture client-serveur (2tiers). Les applications complexes peuvent tirer prot d une base de donnes et accder aux informations qu elle contient en envoyant des requtes SQL un serveur pour lire et crire les
Mahdi Kallel
54
Projet de n d tudes
donnes. Dans ce cas, la base de donnes fonctionne dans un processus indpendant de celui de l application, et parfois sur une machine dirente. Les composants permettant l accs aux donnes sont spars du reste de l application.
Fig. 4.1. Architecture client-serveur

Plusieurs utilisateurs de l application peuvent l utiliser simultanment. Un des inconvnients de l architecture deux-tiers est que la logique charge de la manipulation des donnes et de l application des rgles mtiers est incluse dans l application elle-mme. Cela pose un problme lorsque plusieurs applications doivent partager l accs une base de donnes. Face la multitude d architectures informatiques existantes et des moyens de dveloppement associs, nous devons adopter une solution rpondant aux besoins et la nature mme de l application. Pour choisir la bonne solution, il faut se baser sur des critres de choix qui sont dans notre cas : - Centraliser les donnes pour une multi-utilisation ; - Allger l application du cot du client ; - Fournir une interface homme machine conviviale. L architecture client-serveur, elle, rpond ces besoins, pour cela nous l avons donc choisi. En se basant sur l architecture prcdente et sur les entres-sorties du systme, nous avons pu dgager le schma synoptique suivant : 4.1.2 Choix de l environnement de dveloppement
Le choix du logiciel de dveloppement 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 stockage des donnes de ces chiers dans une base un de donnes. En outre, on a besoin de l excution des requtes SQL pour l chage de certains a rsultats. Plusieurs logiciels de dveloppement peuvent tre utiliss ; tels que Windev, Visual Basic, Delphi et visual C++ qui orent tous presque les mmes privilges. Par ailleurs en tenant compte des fonctionnalits oertes par Windev savoir la souplesse de traitement des chiers et la manipulation des bases de donnes, nous avons choisi de retenir ce langage de programmation. 4.1.2.1 Windev (w-Language)
WinDev 10 est un atelier de gnie 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
Projet de n d tudes
Input
Prparation et centralisation des donnes
DB SQL Server
Output Reporting en format text
Fichiers TXT
Application Windev Fichiers Excel
- Extraction - Centralisation
Graphes
Fig. 4.2. Architecture du systme
(gestionnaire de transaction), etc. Parmi les nombreux atouts de WinDev gure le W-langage qui est le langage de dveloppement utilis. C un langage de la cinquime gnration (L5G), donc il est la fois assez est simple et puissant. De plus, et c le plus important pour notre projet, WinDev a la capacit est de s interfacer avec des codes crits avec d autres langages tels que Java, C, C#, Visual Basic, Cobol, Fortran, etc. Enn, et c un plus pour notre outil, WinDev permet de crer des fentres est conviviales dont la gestion, la manipulation et la programmation sont assez simplies. Les caractristiques que nous venons de citer sont, de fait, la base du choix de WinDev 10 comme environnement de dveloppement. 4.1.2.2 Le SGBD SQL SERVER 2000
Une base de donnes ( eng data base) est un ensemble structur de donnes logiquement relies entre elle et enregistres sur des supports accessibles par l ordinateur, reprsentant des informations du monde rel et pouvant tre interroges et mises jour simultanment et de faon slective. SQL SERVER est un systme de gestion de base de donnes. A l aide de ce logiciel nous pouvons grer nos informations. Dans le cadre de notre projet, nous avons choisi SQL SERVER pour stocker et grer des donnes contenues dans les chiers car il permet l accs la base distance. Dans cette base on distingue toutes les tables ncessaires pour l excution de l application.
Mahdi Kallel
56
Projet de n d tudes 4.1.3 Conception oprationnelle de l application
La conception oprationnelle est la partie dans laquelle sont dress les solutions prvues pour le fonctionnement des dirents modules spcis dans le cahier des charges du projet. (Voir annexeB pour mieux comprendre la conception par le language UML) 4.1.3.1 Modle de cas d utilisation (Use Cases)
L intrt des Use Cases est de traiter l interaction entre les acteurs et le systme d une manire formelle. Selon les cas d utilisation nous pouvons dduire plusieurs scnarios dont la dtermination dpend essentiellement de ce que l utilisateur attend du systme. Compte tenu du besoin de notre application, il s avre que les acteurs ventuels se rduisent un seul Utilisateur-Administrateur. La gure ci-aprs illustre le scnario complet d une utilisation complte du systme. On trouve donc la fonction primordiale d insertion des donnes dans la base de donnes, du suivi de l volution des indicateurs de performances dans le temps et par objet, et enn de la gnration du rapport.
Gnrer le rapport
<<include>>
Choisir la dure d observation

<<extend>>
Suivre l volution des indicateurs dans le temps

<<include>> <<include>>
Choisir l indicateur
<<include>>
<<include>>
Choisir l objet
<<include>> <<include>>
Choisir type de courbe
Suivre l volution des indicateurs par objet
<<include>>
<<extend>>
Choisir la date d observation

Cration de la base de donne
Insertion des donne dans la base
<<include>>
<<include>>
Charger la topologie du rseau
Fig. 4.3. Diagramme de cas d utilisation
4.1.3.2
Diagramme de squences
Le diagramme de squences illustre le fonctionnement du systme dans le temps. Il permet d analyser l avancement chronologique des interactions entre les objets du systme et de mieux comprendre son fonctionnement interne. Le diagramme est structur de la manire suivante : Le diagramme possde un axe des temps dirig du haut vers le bas. Chaque objet tudi dispose d une ligne de vie (ligne verticale pointille). Sur ces lignes de vie, des priodes d activit sont
Mahdi Kallel
57
Projet de n d tudes
indiques par des rectangles ns dont les extrmits reprsentent le dbut et la n de l activit. Les messages changs entre les direntes entits sont reprsents par des ches horizontales orientes de l metteur vers le destinataire. Lorsque le message possde un temps de propagation non ngligeable, les ches sont alors obliques.
Diagramme de squences d insertion des donnes dans la base : L utilisateur

slectionne les chiers charger dans la base de donne. L outil d application se charge alors de faire des traitements ncessaires sur ces chiers, et il envoi les requtes appropries au serveur de base de donne. Ce dernier excute les requtes. Les entits sont : l utilisateur, l outil d application et le serveur application.
Utilisateur
Lancer l application
L outil d application
Serveur de base de donnes
Interface lance
Choisir le fichier charger dans la base
Fichier choisi
Lancer le traitement des fichiers Traiter les fichier Construire les requtes d insertion Requtes xccutes Donnes insres Excuter les requtes
Fig. 4.4. Diagramme de squences d insertion des donnes dans la base
Diagramme de squence de gnration des courbes Ce diagramme dcrit le droulement des tapes ncessaires la gnration 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 paramtres. L outil d application, lui, ltre les donnes. Il construit les requtes de slections appropries selon les paramtres xes par l utilisateur. Il les envoie au serveur base de donne qui les excute et renvoie les rsultats l outil. Celui-ci fait la mise en forme des courbes et les a che l utilisateur.
4.2
Ralisation
Nous avons essay, dans la ralisation de ce projet, d automatiser le plus possible la phase de post traitement. C un ensemble d est oprations qui permettent enn d insrer les donnes dans la base de donne. Le menu ddi la phase de traitement et de la centralisation est le menu traitement . La gure suivante montre ce menu et les sous menus rattachs.
Mahdi Kallel
58
Projet de n d tudes
L outil d application
Lancer l appliction
Utilisateur
Serveur de base de donnes
Interface lance
Choisir les paramtres de l affichage Paramtres choisis
Demander l affichage des courbes
Filtrage des donnes Construire les requtes de slection Excution des requtes
Mise en forme des courbes Courbes affiches
Rsultat des requtes de selection
Fig. 4.5. Diagramme de squence de gnration des courbes
L action de cration des tables de la base de donnes doit tre faite une seule fois. C est--dire qu ne faut crer les tables que si elles n il taient pas cres. En cliquant sur le sous menu insertion des donne dans la base , une fentre qui contient deux anglets s ouvre, l pour charger la topologie du rseau et l un autre pour faire le traitement des chiers.
Mahdi Kallel
59
Projet de n d tudes
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
Projet de n d tudes
Aprs chargement des donnes dans la base de donnes, nous pouvons faire les analyses souhaites. Pour ce faire, il existe deux menus, l pour faire une analyse par objet : cellule, un BSC, MSC et LAC pour une journe donne. Et l autre pour faire une analyse dans le temps pour chaque objet. La fentre pour faire une analyse par cellule est la suivante.
Mahdi Kallel
61
Projet de n d tudes
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 optionnel de choisir le type de graphe. est
En appuyant sur le bouton a cher, la courbe correspondante aux paramtres xs s che. a
Mahdi Kallel
62
Projet de n d tudes
La mme procdure se fait si on dsire 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 modier les paramtres de la courbe en faisant un click droit sur la courbe. On peut inverser les axes, faire une lgende, modier 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 indicateur un donn sur un objet donn : cellule, BSC, MSC et LAC. Par exemple, la gure suivante montre l volution du taux de succs SMS sur une priode donne sur un MSC donn
Mahdi Kallel
63
Projet de n d tudes
Enn, aprs que l analyse est faite, nous pouvons gnrer un rapport de QoS en slectionnant le menu chier ensuite l option gnrer le rapport .
Mahdi Kallel
64
Projet de n d tudes
L implmentation logicielle des indicateurs conus a permi de suivre leurs volutions par cellule, BSC, MSC ou LAC. La slection des donnes et leurs rassemblements et l chage des a statitistiques auraient pu tre plus longs manipuler s taient manuels. L ils implmentation logicielle fait gagner beaucoup de temps. Le chapitre suivant va dtailler la validation de quelques indicateurs ainsi que quelques tudes de cas.
Mahdi Kallel
65
Validation et tude de cas
Chapitre
Projet de n d tudes
L objectif de ce chapitre est de valider quelques indicateurs conus, en les comparant avec leurs homologues du cot de l OMC. La validation est d une importance extrme dans la mesure o elle met en vidence l objectivit de nouveaux indicateurs. Le traitement de quelques exemples et de cas rels en analysant leurs causes et leurs eets ventuels permet, entre autre, de donner ces indicateurs une importance technique dans la pratique.
5.1
5.1.1
Validation
Choix des indicateurs valider
Vu le nombre relativement lev des indicateurs conus, le choix tait de valider seulement les indicateurs qui re tent la performance globale de chaque procdure. Autrement dit, pour chaque procdure GSM, l indicateur qui rsume le succs et / ou l chec de la procdure est identi pour tre valid. Bien entendu, ceci ne voulait pas dire que le reste des indicateurs n pas apte pour est tre valid. En consquence de quoi, les indicateurs valider sont : Succs_tablissement_MOC _Tech Succs_tablissement_MTC _Tech Coupure_Appel Taux_Succs_LU_Tot Taux_HO_InterBSC_Sortant_Succs
Mahdi Kallel
67
Projet de n d tudes 5.1.2 Taux_HO_InterBSC_Entrant_Succs Taux_Succs_SMS_OC Aperu sur les outils utiliss pour la validation
OTT dispose d ensemble d un outils fournis par les deux constructeurs Alcatel et Siemens permettant d explorer les direntes donnes de qualit de service du rseau, que se soit des donnes OMC ou des donnes 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 ALCATEL qui permet le management en temps rel de tout le rseau. Outre les fonctionnalits classiques savoir la gestion des alarmes, le suivi et la conguration des composants physiques et logiques du rseau, ce logiciel permet : Une analyse totalement informatise des mesures de performance. La visualisation et l export des donnes sur la conguration software et hardware du rseau. La dtection des problmes lis la qualit de service du rseau et la localisation des questions les plus urgentes. Le choix des actions correctives entreprendre pour amliorer la QoS. L optimisation de la recherche des ressources radio. Fournir les rapports de la QoS. Cependant RNO prsente un ensemble de limitation qui se rsume dans les points suivants : Il est Oprationnel que pour un seul constructeur savoir Alcatel. Il prsente un retard au niveau de l import des donnes, ce qui oblige parfois les ingnieurs utiliser d autres outils. Le schma synoptique d tel systme est donn par la gure un 5.1.
Mahdi Kallel
68
Projet de n d tudes
Fig. 5.1. RNO system (Alcatel)
5.1.2.2
SPOTS
L outil SPOTS de SIEMENS permet de : Traiter les donnes par famille de compteurs NSS, BSS, BTS ; Fournir des rapports de QoS ; Dtecter les problmes du rseau par la conguration d alerteur de QoS temps rel. Les principaux problmes SPOT se rsument dans les points suivants : Un outil oprationnel 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 Succs_tablissement_MOC _Tech
Connu sous le nom de CSSR_MOC (Call Setup Sucess Rate), cet indicateur dtermine le taux de succs de l tablissement d appel sortant. Etant donn qu faut comparer des choses il 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 succs d tablissement d appel sortant. En revanche il accumule les taux d checs BSS (radio ou quipements BSS). En gnral, Utiliser RNO revient traiter des problmes radio. Cot SPOTS, le problme tait qu adopte une approche qui dni l il tablissement d appel comme tant tous les messages changs avant l aectation du canal de trac TCH. Contrairement la notre qui dni l tablissement comme tant tous les messages changs avant le dbut de la conversation proprement dite.
Mahdi Kallel
69
Projet de n d tudes
Puisqu s avr impossible de comparer l il est indicateur en question avec l indicateur SPOTS prdnit, il a t ncessaire de se rfrencier la documentation SIEMENS pour voir la signication des compteurs brutes pour pouvoir les adapter la formule qu dsire valider. on Les compteurs trouvs taient des compteurs MSC, c est--dire qu sont implments du cot ils du MSC. Par consquent, on va suivre l volution des indicateurs par MSC lors de la comparaison. La formule de Succs_tablissement_MOC _Tech conue sur l interface A est : Succes_etablissement_M OC_T ech = N bASCM P _OC N ombre_Appel_M OC (5.1)
O NbASCMP_OC dsigne le nombre de messages de la n d aectation d canal de un trac et Nombre_Appels_MOC dsigne le nombre total de tentatives d tablissement d appel un 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 incrment suite la rception 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 ddie. L quivalent de ce message en SPOTS est CA_MORIG Nr. En suivant la mme dmarche pour le compteur NbASCMP_OC, on trouve que l quivalent de ce compteur en SPOTS est CSTCHMOR Nr.
Mahdi Kallel
70
Projet de n d tudes
L tape suivante tait de comparer les valeurs du rapport CSTCHMOR Nr/CA_MORIG Nr avec celles de l indicateur valider rassembls par MSC. L cart tait considrable ! Par la suite, il s avr que cet cart est d au fait que le compteur CA_MORIG Nr est s incrmente aussi chaque fois o le MSC fait la redirection de l appel vers une autre destination lorsqu y a un renvoie d il appel. Il en rsulte, en terme de nombre, qu y avait une dirence il considrable 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 compteur CS_EFOMOR Nr. Le rsultat de la comparaison tait le suivant sur l objet MSCx class par jour :
CSSR_MOC_InterfaceA Vs CSSR_MOC_SPOTS
1 0,95 0,9 0,85 0,8 0,75 0,7 0,65 0,6 0,55 0,5
20 07 4/ 20 07 4/ 20 07 /2 00 7 /2 00 7 /2 00 7
CSSR_MOC
CSSR_MOC_SPOTS CSSR_MOC_InterfaceA
04 /0 4
4/
08 /0 4
05 /0 4
06 /0
07 /0
Jour
Fig. 5.3. Rsultat de la comparaison CSSR_MOC
Il est clair qu existe une petite dirence . Cette petite dirence ngligeable est due un il 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 Succs_tablissement_MTC _Tech
La mme dmarche tait suivie pour valider cet indicateur. La formule de cet indicateur conue sur l interface A est : Succes_etablissement_M T C_T ech = N bASCM P _T C N ombre_Appel_M T C (5.2)
Le Nombre_Tentatives_MTC est donne par le nombre d occurrence du message PAGINGRESPONSE envoy par le BSC au MSC. Aprs la consultation de la documentation SIEMENS, Le compteur SPOTS relatif tait REC_PRMTE Nr [10]. De mme pour NbASCMP_TC, le compteur SPOTS quivalent tait CSTCHMTER Nr[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 rsultats suivants ont t obtenus :
Mahdi Kallel
09 /0
71
Projet de n d tudes
CSSR_MTC_InterfaceA Vs CSSR_MTC_SPOTS
1 0,95 0,9 0,85 0,8 0,75 0,7 0,65 0,6 0,55 0,5
4/ 20 07 4/ 20 07 /2 00 7 /2 00 7 /2 00 7 /2 00 7
CSSR_MTC
CSSR_MTC_SPOTS CSSR_MTC_InterfaceA
04 /0 4
05 /0 4
07 /0 4
08 /0 4
06 /0
Jour
Fig. 5.4. Rsultat 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 considre que la communication commence juste aprs l aectation d un canal TCH, c est--dire aprs le message ASSIGNMENT_ COMPLETE. Cette approche tait dirente de celle adopte pour la conception de l indicateur coupure_Appel sur l interface A, et qui considre que la communication commence aprs que l appel ait dcroch dans le vrai sens physique de l action, donc aprs le message CONNECT_ACK. D autre part, dgager les compteurs bruts SIEMENS comme on l fait pour la validation du a Call Setup a t inutile vu que SIEMENS n implmente pas un compteur pour ce message. Ensuite, il s avr que RNO adopte la deuxime approche. Cependant il ne comptabilise est que le taux de coupure d appel suite une cause BSS (radio ou quipements). C la raison est pour laquelle, seul l indicateur Coupure_Appel_BSS pouvait tre valid. Le rsultat de comparaison entre les valeurs de cet indicateur prises sur BSCx et ltres par jour, et les valeurs de l indicateur RNO Call_drop_rate (QSCDR) est illustr par la gure 5.5.
Mahdi Kallel
09 /0
72
Projet de n d tudes
Call drop RNO Vs Call drop interface A BSS radio

0,70% 0,60% 0,50% 0,40% 0,30% 0,20% 0,10% 0,00%
04 /0 4/ 20 07 05 /0 4/ 20 07 06 /0 4/ 20 07 07 /0 4/ 20 07 08 /0 4/ 20 07 09 /0 4/ 20 07
call drop
Call drop RNO Call drop BSS Interface A
jour
Fig. 5.5. Rsultat de la comparaison Call drop
5.1.6
Validation de l indicateur Taux_Succs_LU_Tot
Il est plus rigoureux de valider les indicateurs de mise jour de localisation par le biais des indicateurs MSC puisque l excution de la procdure se fait au cur du rseau entre le MSC, le VLR et/ou le HLR. La formule de l indicateur conu tait la suivante : N bACC_P U + N bACC_N U N ombre_tentativesLU _P + N ombre_tentativesLU _N
T aux_Succes_LU _T ot =
(5.3)
Il est not que la mise jour de localisation avec IMSI Attach n pas prise en compte est dans cette formule car l automate Cigale n implmente pas de compteurs relatifs. En se basant sur la documentation SIEMENS, il s avr que le compteur SPOTS RQ_LC est Nr calcule le nombre de demande de mise jour de localisation (LUREQ) non seulement normale et priodique mais aussi par IMSI Attach. Par consquent 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 priodiques acceptes est SUCC_RQLC Nr. Enn, Le rsultat de comparaison entre les valeurs de l indicateur Taux_Succs_LU_Tot prises sur MSCx et ltres 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
Projet de n d tudes
Lu_SUCC SPOTS Vs LU SUCC Interface A

100,00% 99,00% 98,00% 97,00% 96,00% 95,00% 94,00%
04 /0 4/ 20 07 05 /0 4/ 20 07 06 /0 4/ 20 07 07 /0 4/ 20 07 08 /0 4/ 20 07 09 /0 4/ 20 07
LU_SUCC MSC08
LU_SUCC SPOTS LU_SUCC Interface A
Jour
Fig. 5.6. Rsultat de la comparaison LU_SUCC
Les valeurs compares sont proches, sauf pour le deuxime jour o il y avait une dirence relative. La cause et que les dures d observations de part et d autres n taient pas exactement confondues. 5.1.7 Validation du TauxHOInterBSCSortantSuccs et TauxHOInterBSCEntrantSuccs
La validation du succs 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 niveau d au un BSC. Par contre, SPOTS calcule le taux de succs des handover inter MSC et intra MSC sans distinguer s soient inter ou intra BSC. ils La comparaison de l indicateur TauxHOInterBSCSortantSuccs avec l indicateur RNO quivalent HoOutMSCsuccess_rate est donne par la gure 5.7 pour le BSCx :
Mahdi Kallel
74
Projet de n d tudes

SUCC_Ho_Out RNO Vs SUCC_Ho_Out Interface A
90,00% 88,00% 86,00% 84,00% 82,00% 80,00% 78,00% 76,00%
04 /0 4/ 20 05 07 /0 4/ 20 06 07 /0 4/ 20 07 07 /0 4/ 20 08 07 /0 4/ 20 09 07 /0 4/ 20 07
SUCC_Ho_Out
SUCC_Ho_Out RNO SUCC_Ho_Out Interface A
jour
Fig. 5.7. Rsultat de lacomparaison SUCC_HO_Out
La mme comparaison pour une cellule a donn les rsultatsillustrs par la gure 5.8.
SUCC_Ho_Out RNO Vs SUCC_Ho_Out Interface A
97,00% 96,00% 95,00% 94,00% 93,00% 92,00% 91,00%
04 /0 4/ 20 05 07 /0 4/ 20 06 07 /0 4/ 20 07 07 /0 4/ 20 08 07 /0 4/ 20 09 07 /0 4/ 20 07
SUCC_Ho_Out
SUCC_Ho_Out RNO SUCC_Ho_Out Interface A
jour
Fig. 5.8. Rsultat de la comparaison SUCC_HO_Out pour une cellule
La comparaison des l indicateur TauxHOInterBSCEntrantSuccs avec l indicateur RNO quivalent HOIncMSCsuccessrate est donne par la gure 5.9 pour le BSCx:
Mahdi Kallel
75
Projet de n d tudes
SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A

91,00% 90,00% 89,00% 88,00% 87,00% 86,00% 85,00% 84,00%
04 /0 4/ 20 05 07 /0 4/ 20 06 07 /0 4/ 20 07 07 /0 4/ 20 08 07 /0 4/ 20 09 07 /0 4/ 20 07
SUCC_Ho_In
SUCC_Ho_In RNO SUCC_Ho_In Interface A
jour
Fig. 5.9. Rsultat de comparaison SUCC_HO_In
La mme comparaison pour une cellule a donn les rsultats (voir gure 5.10)
SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A
120,00% 100,00% 80,00% 60,00% 40,00% 20,00% 0,00%
04 /0 4/ 20 05 07 /0 4/ 20 06 07 /0 4/ 20 07 07 /0 4/ 20 08 07 /0 4/ 20 09 07 /0 4/ 20 07
SUCC_Ho_In
SUCC_Ho_In RNO SUCC_Ho_In Interface A
jour
Fig. 5.10. Rsultat de la comparaison SUCC_HO_In pour une cellule
C quasiment les mmes valeurs sauf pour le deuxime jour (Dure d est observation dirente). 5.1.8 Validation du Taux_Succs_SMS_OC
SPOTS dnit le taux de succs de SMS sortant comme tant :
M OSM S% =
SU CC_SM S_SEN D_RP _ACK M S_SER_REQ_AT T EM P T S
(5.4)
C exactement la mme formule qui a tait dnie cot interface A : est T aux_Succes_SM S_OC = SmsSubmit_RP ack N b_SM S_OC (5.5)
La comparaison des l indicateur Taux_Succs_SMS_OC avec l indicateur SPOTS quivalent MOSMS % est donne par la gure 5.11 pour le MSCx :
Mahdi Kallel
76
Projet de n d tudes
MOSMS SUCC SPOTS Vs MOSMS SUCC Interface A

MOSMS SUCC MSC08
90 85 80 75 70 65
04 /0 4/ 20 05 07 /0 4/ 20 06 07 /0 4/ 20 07 07 /0 4/ 20 08 07 /0 4/ 20 09 07 /0 4/ 20 07
MOSMS SUCC SPOTS MOSMS SUCC Interface A
jour
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 rseau GSM par le biais de captures sur l interface A, ne peut se faire qu traitant des cas rels.Ce paragraphe donne en un aperu sur quelques analyses faites sur des zones bien prcises, suite des observations sur l volution des indicateurs de performances dj conus ainsi que sur les dirents chiers gnrs 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 simultanes sur cette interface suite une demande massive de ressources simultanes. Pour commencer l analyse, le suivi de l volution des indicateurs EchecMOCNSS, EchecMOCBSS et EchecMOCUser par BSC est illustre par la gure 5.12.
Fig. 5.12. Les chec MOC
Mahdi Kallel
77
Projet de n d tudes
En examinant cette volution, on peut tirer des observations. En eet, le graphe reprsente une commodit : Les origines d chec sont rparties de la faon 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 appel sortant sont dus l un utilisateur lui-mme ; Par exemple : solde insu sante, composition d numro non valide, raccrochage prcoce etc. . . un Les causes d chec BSS, de leurs cots, sont suprieures aux causes d chec NSS car la partie BSS du rseau est la plus vulnrable 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 dpasser un seuil tolrable x par l oprateur. L indicateur Echec_MOC_NSS dpasse 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 gnrs 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 rpartition des causes cites dans le tableau 3.1. Le rsultat est donn par la gure 5.13.
Fig. 5.13. Rpartition des causes d chec
En exploitant le camembert, on constate que le message DISCONNECT, avec une extension F pour dire qu est envoy par le MSC, et avec la cause NCCA, occupe une bonne partie du il camembert (la partie en noir). La cause NCCA (No Circuit Channel Available) veut dire qu il n avait plus de circuit pour satisfaire la demande. Il s y agissait ds lors d une congestion. Il est noter que le camembert prcdent n pas restreint aux causes NSS, il illustre toutes est 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 connatre pendant quelle tape de la procdure 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 rseau. Il nous a permit de voir la rpartition des tats de l automate partir desquels le message DISC_F-NCCA a t envoy. (Voir gure 5.14)
Mahdi Kallel
78
Projet de n d tudes
Fig. 5.14. Rpartition des tats
Le camembert montre bien que la majorit absolue des messages DISC_F-NCCA a t envoye lorsque l tat de l automate tait OC_PROC. C est--dire pendant la phase proceeding de la procdure MOC. L allocation de circuit au niveau MSC se fait pendant cette tape. Ce qui montre bien qu s il agissait bien d une congestion ! D autre part, en ce qui concerne la procdure MTC, la mme dmarche a t faite. Le suivi de l volution des indicateurs Echec_MTC_NSS, Echec_MTC_BSS et Echec_MTC_User par BSC est illustre par la gure 5.15.
Fig. 5.15. Les checs MTC
La premire constatation est que les taux d chec MTC sont suprieurs leurs homologues MOC. La raison est que la procdure MOC est plus vulnrable l chec tant donn qu elle est initie 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
Projet de n d tudes
L analyse des chiers gnrs aprs capture sur l interface A nous a permit de rassembler la rpartition des causes cites dans le tableau 2.1. Le rsultat est donn par la gure 5.16.
Fig. 5.16. Rpartition des causes
La partie en bleu du camembert montre que le message DISC_F-NCCA est responsable de la dgradation de l tablissement d appel entrant sur ces BSC. un En examinant le chier .XL3, il s avr que ce message a t envoy lorsque l est tat de l automate tait TC_CONF, c dire pendant la phase de conrmation d est appel (Voir gure 5.17).
Fig. 5.17. Rpartition des tats
La phase de conrmation d appel est quivalente Proceeding dans la procdure MOC. On peut donc a rmer qu s il agit bel et bien d une congestion. Dans le but de conrmer l analyse prcdente, nous avons observ le chier .XLT qui donne le trac coul pour chaque circuit. Nous avons ensuite organis ce trac de telle faon qu est rassembl par BSC, la partie en bleu du il graphe de la gure 5.18 compte le trac coul par BSC. Les points verts reprsentent le nombre
Mahdi Kallel
80
Projet de n d tudes
maximal de connexions simultanes et les points en noirs reprsentent le nombre maximal de circuits disponibles par BSC (c est--dire par interface A).
Fig. 5.18. Trac par BSC
En comparaison avec les trois BSC dans lesquels nous avons constat une congestion selon la mthode du calcul de l volution de l indicateur Echec_MTC_NSS, seules la congestion des deux premiers est montre par la gure 5.18. En eet, pour les deux premiers BSC, les points verts et noirs sont quasi-confondus. Le fait de trouver que le nombre de connexions simultanes est trs proche de celui des circuits disponibles, et en plus, pendant une courte dure d observation, ne fait qu rmer qu y avait certainement a il une congestion au niveau des deux premiers BSC. Cependant, pour le troisime BSC, les deux points verts et noirs sont relativement loigns. Cela reprsente une contradiction avec l analyse prcdente (calcul de l volution de l indicateur Echec_MTC_NSS) qui a montr une congestion au niveau de ce BSC. L analyse des chiers gnrs par capture sur l interface A a permit de comprendre la cause de cette incohrence. La mthode tait de vrier les causes du Taux d chec MTC lev pour le BSC en question. (Voir gure 5.19)
Mahdi Kallel
81
Projet de n d tudes
Fig. 5.19. Distribution des causes pour le BSC
Le camembert montre que les Purges sont l origine de cette incohrence. Le problme tait que l interface A, celle rattach au BSC concern, n tait pas supervise par l analyseur de protocole ce qui a donn lieu des incohrences 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_Succs_SMS_OC sur les MSC du rseau, nous avons pu signaler qu y avait une forte dgradation pour le MSCx et le MSCx il .
Fig. 5.20. Rsultat de l analyse de l indicateur Taux_Succs_SMS_OC
En eet, le taux de succs tait infrieur 3%. Ds lors, une investigation a t lance. Tout d abord, nous avons vri ce taux avec SPOTS en gnrant un rapport graphique qui donne l volution de l indicateur SPOTS MOSMS % sur le MSCx et le MSCx La gure 5.21 . illustre le rsultat. Nous remarquons bien que le taux de succs de l envoi d SMS sortant a t dgrad pendant un la nuit, de 00h 08h, pour les trois derniers jours.
Mahdi Kallel
82
Projet de n d tudes
Fig. 5.21. MOSMS% sur SPOTS
D autre part, on n pas signal des plaintes des clients autour de cette priode. Il en rsulte a qu a t indispensable de faire une trace sur l il envoie de ces SMS pour voir la cause exacte du problme. En parallle avec cette trace, nous avons suivis l volution des indicateurs Taux_Echec_SMS_NSS et Taux_Echec_SMS_BSS. Il n avait rien signaler puisque les valeurs de ces indicateurs peny dant la priode en question taient rgulires. A priori, il semble clair que la cause des checs d envois est lie principalement aux utilisateurs eux mme. Le rsultat de la trace a montr que seul 4 numros sont concerns par cet chec. Ces numros sont d MSISDN conscutifs et la contribution de chacun dans l chec tait la suivante :
Fig. 5.22. Echec SMS par numro
Ces numros envoient tous des messages vers un mme numro qui tait erron ! Il s avr est ensuite que ces numros appartiennent une socit prive qui gre un rseau de vhicules par
Mahdi Kallel
83
Projet de n d tudes
GPS, elle envoie priodiquement, chaque minute, les coordonnes GPS de ses vhicules par le biais d une plate forme qui envoi les SMS automatiquement. Enn, la socit a t contacte pour corriger la conguration de sa plateforme SMS. 5.2.3 Etude de dtection d problme de croisement un
Plusieurs critres d analyse ont t faites, parmi elles celle relative notre approche sur l interface A. En eet, nous avons suivi l volution de l indicateur SuccsEtablissementAppelTech sur les cellules de la zone concerne et nous avons trouv que l indicateur est dgrad, il tait au dessous des 40%.
Fig. 5.23. Rsultat d analyse de l indicateur Succs_Etablissement_Appel_Tech
Notre analyse sur l analyse sur l interface A a montr que deux secteurs appartenant au mme site taient les plus dgrads. En consultant la liste des oprations programmes, Il s avr est qu y avait une opration dans le site en question. il Suite cette opration, nous avons constat une diminution considrable du trac sur le secteur 4 du site grce l outil OTT-Perf (Voir gure 5.24)
Fig. 5.24. Trac sur le secteur 4
Mahdi Kallel
84
Projet de n d tudes
Il est clair que le pic vers le bas des TCH valables (ligne bleu) indique le temps exact de l opration. Ce dfaut de trac 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
Projet de n d tudes
Fig. 5.25. Trac sur le secteur 3

L ide tait de vrier s y avait un croisement de cblage. Pour vrier cela, il a tait il indispensable de comparer les performance des HO avant et aprs l opration. Les positions GIS des secteurs 4 avec une cellule voisine x et 3 avec une cellule voisine x sont prsentes par la gure 6.26.
Fig. 5.26. Positions GIS des secteurs.
RNO montre que les performances HO pour les deux couples prcdents ont t inverses avant et aprs l opration (Voir les gures 5.27 et 5.28).
Mahdi Kallel
86
Projet de n d tudes
Fig. 5.27. Performances HO pour le couple 4-x
Fig. 5.28. Performances HO pour le couple 3-x
La conclusion est qu y avait un croisement de cblage. il
Mahdi Kallel
87
Projet de n d tudes
Conclusion gnrale
Il ne fait dsormais plus aucun doute que le suivi de la qualit de service du rseau GSM est une tche assez dlicate, qui ncessite la coopration de mthodes et d alternatives direntes pour parvenir maintenir un niveau de QoS acceptable. L approche dveloppe dans notre tude tait de faire en sorte que l oprateur pouvait en proter de l analyseur de protocole install sur les interface A de son rseau et qui intercepte le des messages sur cette interface. ux Dans cette optique, l apport de notre tude tait la mise en disposition de nouveaux indicateurs clefs de performance conus partir des captures sur l interface A. Ces indicateurs permettent d analyser la performance du rseau ou bien de conrmer quelques rsultats. Ces indicateurs peuvent aussi jouer un rle de validation pour des oprations techniques donnes. Ils permettent parfois de dtecter les problmes parvenus sur le rseau. L analyse par les indicateurs clefs de performance n qu est une tape durant tout un processus du maintien d une qualit de fonctionnent adquate. Il est commode de se faire en proter de tous les outils mis disposition. Il c avr ds lors qu est une implmentation logicielle des indicateurs conus est indispensable dans la mesure o elle va servir de tableau de bord pour la visualisation du rseau. Cette implmentation logicielle nous a permis de nous familiariser avec des langages de dveloppent et de modlisation intressants. La validation des indicateurs conus nous a permis de toucher de prs les outils de performance mis disposition et de s intgrer au sein du service QDF. L tude de cas rels nous a permis d aborder de vrais problmes d ingnierie technique. Enn, et c le plus important, ce travail nous a permis de comprendre le vrais sens du est travail en quipe et de sentir son charme.
Mahdi Kallel
88
Prsentation du systme GSM
Annexe
Projet de n d tudes
A.1
Principe du rseau GSM
Le GSM est un systme cellulaire qui a t dvelopp dans le but de permettre aux utilisateurs, o qu soient, stationnaires ou mobiles, de communiquer entre eux et avec les abonns du rseau ils xe (RTC, Rseau Tlphonique Commut), par l intermdiaire d terminal portatif mettant un faible puissance (de 0.25 8W). Pour cela, le territoire est dcoup en "cellules" couvertes par des metteurs rcepteurs de base (BTS, Base Transceiver Station). Pour viter les interfrences, deux cellules contigus ne peuvent utiliser les mmes frquences ; par contre les mmes frquences peuvent tre rutilises pour des cellules su samment loignes. Les rseaux GSM utilisent le format numrique pour la transmission des informations, qu elles soient de type voix, donnes ou signalisation. Les quipements spciques constituant le squelette matriel d rseau GSM (BTS, BSC, MSC, VLR et HLR) dialoguent entre eux en mettant en un oeuvre les mmes principes que ceux utiliss dans le RNIS (Rseau Numrique Intgration de Service) : Architecture en couche (couches 1 3 du modle OSI), Utilisation des liaisons smaphores (signalisation), Caractristiques 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 rception, soit une disponibilit en frquences de 25 MHz. La bande de frquences utilise par un portable GSM (900 MHz) ainsi que la puissance
Mahdi Kallel
90
Projet de n d tudes
dveloppe 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 frquence des 1800Mhz) (1800 MHz - 1 watt), la distance maximale laquelle un portable peut accrocher un relais est donc moins importante ce qui le dsavantage en milieu rural par rapport au GSM. De ce fait pour couvrir une mme surface,on estime qu est ncessaire d il avoir une fois et demi plus de relais DCS 1800 que de relais GSM. Les principales caractristiques de la norme GSM sont donnes dans le tableau A.1.
Frquence d mission du terminal vers la station de base Frquence d mission de la BTS vers le terminal Bande de frquence disponible Mode d accs Espacement des canaux radio Espacement du duplex Nombre de canaux radio par sens Nombre de canaux de parole plein dbit Dbit d codec plein dbit un Dbit maximal de transmission de donnes
GSM 890-915 MHz 935-960 MHz 25+25 MHz TDMA 200kHz 45 MHz 124 8 13 kbit/s 9.6 kbit/s
DCS 1710-1785 1805-1880 75+75 MHz TDMA 200kHz 95 MHz 374 8 13 kbit/s 9.6 kbit/s
Tab. A.1. Caractristiques de la norme GSM
A.2
Architecture GSM
Un rseau GSM est constitu de deux sous parties essentielles qui sont le BSS (Base station Sub-System) qui gre les ressources radio, et le NSS (Network Sub-System) qui assure l tablissement des appels et la mobilit. Les principaux composants d rseau GSM sont illustrs dans un la gure A.1.
Fig. A.1. Architecture du rseau GSM
Mahdi Kallel
91
Projet de n d tudes A.2.1 La station Mobile
La station mobile est compose 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. Dirents types de terminal sont prescrits par la norme en fonction de leur application et de leur puissance (de 0.8W 20W). Chaque terminal mobile est identif par un code unique IMEI (InternationalMobile Equipment Identity). La carte SIM est une carte puces qui contient dans sa mmoire le code IMSI (International Mobile Subscriber Indentity) qui identife l abonn de mme que les renseignements relatifs l abonnement (services auxquels l abonn a droit). A.2.2 Le sous-systme radio
Le sous-systme radio, reprsent par la gure A.2, comprend deux parties. La premire, appele station de base (BTS : Base Transceiver Station). Une BTS est le point d accs au PLMN. Elle est compose d ensemble d un metteur rcepteur appels TRX, Transceiver. Elle a la charge de la transmission radio, la modulation, la dmodulation et le codage correcteur d erreur. La BTS gre la couche physique en assurant le multiplexage TDMA, le saut de frquence et le chirement. Elle ralise aussi les mesures radio ncessaires. La seconde partie est le contrleur de station de base (BSC : Base Station Controller), c l est organe intelligent du BSS dont le rle est de grer les ressources radio (confguration des canaux, transfert intercellulaire) d une ou plusieurs stations de base (BTS), de contrler les puissances mises par la BTS et la MS et de dcider l excution 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 systme Radio
A.2.3
Le sous Systme Rseau
Le rle principal de ce sous-systme est de grer les communications entre les abonns et les autres usagers qui peuvent tre d autres abonns ou des usagers du rseau tlphonique xxe. Comme l illustre la gure A.3, ce sous-systme est compos de :
Mahdi Kallel
92
Projet de n d tudes
Fig. A.3. Le sous systme rseau
Commutateur de service mobile (MSC - Mobile Switching Center) : est un commutateur numrique en mode circuit. Cet lment s occupe de la gestion des appels, gre la transmission des messages courts (Short Message Service SMS) et l excution du handover inter BSC. Il dialogue avec le VLR pour grer la mobilit des usagers et tout ce qui est li l identit des abonns, leur enregistrement et leur localisation. Commutateur d entre de service mobile (GMSC Gateway MSC) : Ce commutateur est l interface entre le rseau cellulaire et le rseau tlphonique publique. Le GMSC est charg d acheminer les appels entre le rseau xe et le rseau GSM. Registre des abonns locaux (HLR Home Location Register) : Le HLR est une base de donnes dans laquelle sont stockes les informations de tous les abonns un PLMN. Ces donnes regroupent l IMSI, le numro de l abonn et le prol de l abonnement. Le HLR mmorise pour chaque abonn le VLR o il est enregistr. Registre des abonns visiteurs (VLR Visitor Location Register) : C une base de donest nes contenant les informations relatives aux abonns prsents dans une zone gographique. Ces donnes regroupent principalement l identit temporelle et la zone de localisation. En gnral il y a un seul VLR pour chaque MSC. Centre d authenticit (AuC Authentication Center) : Le AuC est une base de donnes protge qui contient une copie de la cl secrte inscrite sur la carte SIM de chaque abonn. Cette cl est utilise pour vrifer l authenticit de l abonn et pour l encryptage des donnes envoyes. Registre d identication 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 rseau GSM
Les dirents lments du rseau GSM assurent des fonctions complmentaires et chacun obit des normes spciques. En eet, chaque lien entre deux quipements adjacents forme une interface. Les interfaces sont des composantes importantes du rseau GSM car elles assurent le dialogue entre les quipements et permettent leur inter-fonctionnement. Ces interfaces sont prsentes dans le tableau A.2.
Mahdi Kallel
93
Projet de n d tudes
Nom Um Abis A C D E G F B H
Localisation MS BTS BTS BSC BSC MSC GMSC HLR VLR HLR MSC MSC VLR VLR MSC EIR MSC VLR HLR AUC
Utilisation Interface radio Divers Divers Interrogation HLR pour appel entrant Gestion des inforamtions d abonnes et de localisation Excution des handovers Gestion des informations abonnes Vrifcation de l identit du terminal Divers Echange des donnes d authentication
Tab. A.2. Liste des interfaces dans le rseau GSM
A.4
A.4.1
Fonctionnement du rseau GSM

Traitement des appels L tablissement d une communication
A.4.1.1
Lorsqu mobile dsire faire un appel : un Il transmet son identit et le numro appeler sur un canal d accs. Le BSC reoit le message et prvient le MSC. Le MSC cherche un canal libre et le transmet au mobile. Le mobile se met sur le nouveau canal et attend la rponse. Lorsqu mobile est appel : un Le mobile est toujours l coute du canal de paging, attendant qu message lui soit un envoy. Lorsqu MSC doit diriger un appel vers sa destination, il demande au MSC d un attache du tlphone 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 requte d appel. Le tlphone qui se reconnat rpond et reoit alors le canal utiliser pour la communication. Il se met alors sonner. A.4.1.2 Authentication et scurit
L emploi d canal radio rend les communications vulnrables aux coutes et aux utilisations un frauduleuses, le systme GSM a donc recours aux procds suivants : Authentication de chaque abonn avant de lui autoriser l accs un service, Utilisation d une identit temporaire, Chirement (ou cryptage) des communications.
Mahdi Kallel
94
Projet de n d tudes A.4.2 Gestion de la mobilit La mise jour de localisation
A.4.2.1
La fonction de mise jour de localisation permet de localiser en permanence les abonns du rseau et de mettre jour les informations de localisation. Pour faciliter cette localisation, les cellules sont regroupes en "zones de localisation" et chaque changement de zone, le mobile doit s authentier au rseau pour indiquer sa nouvelle position. Dans le cas habituel, un message de mise jour de la localisation est envoy au nouveau MSC/VLR s y a changement de zone il de localisation de l abonn. Le VLR procde par la suite la rcupration du prol de l abonn auprs de l ancien VLR qui enregistre les informations et les envoie au HLR de l abonn. Le HLR demande alors l ancien VLR d eacer les donnes relatives l abonn. A.4.2.2 Le Handover
Dans un rseau cellulaire, la liaison radio entre un mobile et une station de base n pas est alloue dnitivement pour toute la conversation. Le "Handover" reprsente la commutation d un appel en cours vers un autre canal ou une autre cellule. Les problmes lis la mobilit d terminal en communication, sont rgls conjointement un par la structure xe et le mobile. La dcision d eectue un basculement de frquence ncessaire au traitement d transfert intercellulaire (Handover) reste toutefois la charge des quipements un xes (MSC + BSC). Cette dcision dcoule des traitements lis aux mesures sur le niveau de rception du mobile eectu par ce dernier (sur les frquences 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 dcision prise par le BSC d eectuer un Handover aprs identication d une ou plusieurs cellules utilisables ; si plusieurs cellules sont ligibles, le MSC dtermine, en fonction des charges de trac, la cellule la plus judicieuse eectuer la communication ; La rservation d deuxime canal de trac entre la nouvelle BTS et le mobile ; un Un basculement eectu par le mobile sur rception 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 dclenchs an d amliorer la performance du rseau en minimisant l interfrence et la charge de signalisation. Emergency Handovers qui sont dclenchs lors de la dtection d problme dans la cellule un de service (une mauvaise qualit du signal, un niveau faible du signal, des interfrences,. . . ). A.4.2.3 La slection/re-slection des cellules
Contrairement au Handover qui se droule lorsque le mobile est en mode ddi, le processus de slection ou de re-slection de cellules s eectue lorsque le mobile est en mode de veille. La fonction de slection de cellule est ralise uniquement la mise sous tension du mobile, elle permet ce dernier de choisir quelle cellule se connecter an de communiquer avec le rseau et d tre prt tout instant mettre ou recevoir des appels.
Mahdi Kallel
95
Projet de n d tudes
La fonction de re-slection n eectue qu est aprs une premire slection et est ralise lors du dplacement du mobile. Cette fonction est active si la cellule prcdemment slectionne ne permet plus au mobile de communiquer correctement avec le rseau pour une raison ou une autre.
Mahdi Kallel
96
Le langage de modlisation UML
Annexe
Projet de n d tudes
UML (Unied Modeling Language) se dnit comme un langage de modlisation graphique et textuelle destin comprendre et decrire des besoins, spcier et documenter des systmes, esquisser des architectures logicielles, concevoir et communiquer travers divers points de vue. Nous essayerons dans ce qui suit de donner une brve prsentation sur ce langage conceptuel.
B.1
La syntaxe du langage UML
La modlisation du systme commence par l identication des acteurs et des use cases et se poursuit par la description des use cases. Pour une bonne comprhension du modle, il parat ncessaire de dnir certains termes propres au langage UML. Les acteurs : Ils n appartiennent pas au systme, mais ils interagissent aveccelui ci. Ils fournissent de l information en entre et/ou reoivent de l information en sortie. Le nom de l acteur correspond au rle jou par la personne. Les scnarios ou use cases : Un use case modlise un dialogue entre un acteur et le systme. C la reprsentation d est une fonctionnalit oerte par le systme. L ensemble des uses forme toutes les faons possibles d utilisation du systme. Les relations dans les uses cases : UML propose dirents 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 acteur et est un reprsente par une ligne solide entre l acteur et le use case. C la seule relation possible entre est un acteur et les use cases.
Mahdi Kallel
98
Projet de n d tudes
La relation d utilisation ou includes entre use cases signie qu une instance du use case source inclut aussi le comportement decrit dans le use case destination. Cette relation lie l excution d use case un autre. un La relation d extension ou extends entre deux use cases signife que le use case source tend le comportement du use case destination. L excution d une fonction peut s eectuer indpendamment d une autre.
B.2
Les diagrammes UML
La notation unie dnit 9 diagrammes pour reprsenter les dirents points de vue de modlisation. Ces diagrammes permettent de visualiser et de manipuler les lments de modlisation. Les diagrammes dnis par UML sont les suivants : Les diagrammes des use cases : reprsentation des fonctions du systme du point de vue de l utilisateur. Les diagrammes de squence : reprsentation temporelle des objets et de leurs interactions. Les diagrammes d activits : reprsentation du comportement d une oprationen terme d actions. Les diagrammes de composants : reprsentation du code en termes de modules,de composants et surtout des concepts du langage ou de l environnement d implmentation. Les diagrammes de classes : reprsentation de la structure statique en terme de classes et de relations. Les diagrammes de collaboration : reprsentation spatiale des objets, des liens et des interactions. Les diagrammes de dploiement : reprsentation du deploiement des composants sur les dispositifs matriels. Les diagrammes d etats transitions : reprsentation du comportement d une classe en terme d tat. Les diagrammes d objets :reprsentation des objets et de leurs relations, correspond un diagramme de collaboration simpli. . . , sans reprsentation des envois de messages. D une faon plus gnrale, UML permet de modliser les utilisations de cas et les scnarios (spcications, architecture fonctionnelle), les classes et les objets (analyse technique dtaille), les composants (architecture logicielle) et la distribution et le dploiement (architecture technique).
Mahdi Kallel
99
Projet de n d tudes
Bibliographie
[1] [2] [3] [4] [5] [6] [7] [8] [9] Recommantion UIT E-800 MISSAOUI Mohammed Taher, cours SUP COM, 2006/2007. Lionel Lumbroso, www.01net.com, 2002. GUNNAR Heine, GSM Networks : protocols, terminology and implementation, Artech House, 1999. LAGRANGE Xavier, GODLEWSKI Philippe, TABBANE Sami, Rseaux GSM-DCS 4me dition revue et augmente, Hermes science 1999. Astellia, Protocoles automates module 3, 2003. ZNARTY Simon, Le rseau Smaphore n 7, Eort 2005. SIEMENS, GSM Call and Procedures, 2003 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

These GSM CallTrace

Transféré par

Droits d'auteur :

Formats disponibles

These GSM CallTrace

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

These GSM CallTrace

Transféré par

Droits d'auteur :

Formats disponibles

Rpublique Tunisienne Ministre de l enseignement suprieur et Ministre des tlcommunications Un i v e r s i t d e Ca r t h a g e

cole supprieure communications de Tunis

Table des matires

Table des figures

Figure 5.1. Figure 5.2. Figure 5.3.

RNO system (Alcatel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . le compteur SIEMENS de CM_SERVICE_REQUEST . . . . . . . . . . . Rsultat de la comparaison CSSR_MOC . . . . . . . . . . . . . . . . . . .

Liste des tableaux

Mthodes de mesures de QoS TUNISIANA

Projet de n d tudes 1.2.3 Dispositifs de capture sur les interfaces

Spcication du besoin et description du projet

Fig. 1.1. L emplacement de Cigale

Fig. 1.2. Schma fonctionnel de Cigale

La signalisation sur l interface A

Fig. 2.1. Pile protocolaire

Le rseau de signalisation N 7 (SS7)

Les procdures GSM et les principaux messages sur l interface A

Projet de n d tudes 2.3.1 Appel entrant (Mobile Terminated Call MTC)

Sonnerie Alerting ACM ACM Dcroch Connect Answer Answer

Fig. 2.3. procdure MTC

Appel sortant (Mobile Originating Call MOC)

Process Access_Req Authenticate

Call_Proceeding Ass_Req Ass_Complete

AIM (numro demand) ACM

Alerting Connect Connect_Ack

Release_complete Ch_Release Clr_Comm Clr_Complete

Fig. 2.4. Procdure MOC

Mise jour de localisation (Location UpdateLU) intra-VLR

MS Ch_Req Imm_Ass Loc_Upd_Req

Fig. 2.5. LU intra -VLR

Mise jour de localisation (Location UpdateLU) inter-VLR

MS Ch_Req Imm_Ass Loc_Upd_Req

Fig. 2.6. LU inter VLR avec IMSI

Projet de n d tudes La procdure du handover inter-BSC est donne par la gure2.7.

Fig. 2.7. Handover inter-BSC

Fig. 2.8. Le transfert d SMS sortant un

La mthode ASTELLIA : explication des notions Etat, transition, event

Fig. 2.9. Table des transitions et les compteurs relatifs

Conception des indicateurs

Conception des indicateurs

Conception des indicateurs

Conception des indicateurs

Fig. 3.1. Exemple de chier .EFF

Fig. 3.2. chier Automate.BDT

Conception des indicateurs

Les indicateurs MOC

L tablissement d appel sortant passe par 3 tapes : un

Fig. 3.3. Les tapes de la procdure MOC

Conception des indicateurs

Fig. 3.4. Demande d canal SDCCH un

Fig. 3.5. Demande de service

Conception des indicateurs

CMSRQ VIDE BSC MSC OC_CMS_REQ

AUTRQ OC_CMS_REQ MSC BSC OC_AUT_REQ_1

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

Conception des indicateurs

Fig. 3.6. authentication et passage en mode chir

AUTRP OC_AUT_REQ_1 BSC MSC OC_AUT_RP

CMCMD OC_AUT_RP MSC BSC OC_CIM_CMD

CMCMP OC_CIM_CMD BSC MSC OC_CIM_CMP