Kallel mehdi
-
Upload
farid-sellabi -
Category
Technology
-
view
495 -
download
0
Transcript of Kallel mehdi
République Tunisienne
Ministère de l�enseignement supérieur et Ministère destélécommunications
U n i v e r s i t é d e C a r t h a g e
é c o l e s u p p é r i e u r ed e s c o m m u n i c a t i o n s d e T u n i s
Rapportde mémoire de �n d�études
Présenté en vue de l�obtention du titred�ingénieur en Télécommunications
Thème:
Conception et implémentationd�indicateurs clefs de performancedu réseau GSM à partir de captures
effectuées sur l�interface A
Elaboré par : Mahdi KALLEL
Encadré par : M. Fahmi KHARRAT
Supervisé par : Dr. Mohamed Tahar MISSAOUI
Organisme : O r a s c o m T e l e c o m T u n i s i eAdresse : Les jardins du Lac - Les Berges du Lac - 1053 TunisTel : (216) 22 12 00 00 Fax : (216)22 12 17 09
Remerciements
Mes remerciements les plus chaleureux vont particulièrement aux gens qui, sans leursaide inestimable, ce projet n�aurait jamais été mené à bien.J�exprime ma gratitude en premier lieu, à Mme Valérie Lépillet pour m�avoir accueilli
au sein de son département et pour ses multiples conseils. À M. Fahmi KHARRAT, auDr. Mohammed Taher MISSAOUI pour la qualité de l�encadrement qu�ils m�ont fourni etpour leurs multiples conseils et orientations tout au long de ce projet. Je tiens également àremercier les membres de l�équipe QDF pour les conditions de travail qu�ils m�ont fournies.Je remercie aussi tous les enseignants qui m�ont enseigné tout au long de mes étudeset particulièrement les enseignants de SUP�COM. Pour �nir, je remercie les membres dejury qui ont accepté d�évaluer mon projet. Je leurs présente toute mes gratitudes et mesprofonds respects.
Dédicaces
ÀMon cher père Habib et ma chère mère Zeineb
pour leur tendresse, leur a¤ection,leur amour, leur patience, leurs considérables sacri�ces pour
me parvenir à ce niveau, et leur soutien moralà
ma chère �eur Mahapour son amour in�ni
àmon cher frère Seddik, et sa femme Manel
àmon cher frère Ferouk, et sa �ancé Hejer
àSi Nejib, Malika, Anis et Inès
àmes collocaters Mohammed et So�en
àtoute ma famille
àmes chers amis
àtous mes enseignants
àtous ceux qui m�aiment et que j�aime.
je dédie ce travailQu�Allah vous protège tous, vous préserve la santé et le bonheur
Mahdi Kallel
RésuméLe présent travail, e¤ectué au sein de l�entreprise TUNISIANA, entre dans le cadre du
projet de �n d�études pour l�obtention du diplôme national d�ingénieur en télécommunications. Ils�intéresse au suivi de la performance du réseau GSM à partir des �ux de messages sur l�interfaceA. A cet e¤et, nous proposons une approche de conception d�indicateurs clefs de performanceà l�aide de capture sur cette interface. Par ailleurs, nous mettons en �uvre un outil supportantl�approche proposée en impléméntant ces indicateurs. Finalement, nous validons quelques résul-tats obtenus et nous menons quelques études de cas réelsMots clés: réseau GSM, interface A, procédures GSM, KPI, windev, QoS. . .
AbstractThis present work is carried out, within TUNISIANA as the graduated project to obtain thenational diploma of Telecom Engineer.The aim of this project is to follow the GSM networkperformance by using the message �ow over A interface. In fact, we disign keys performanceindicators needing capture over this interface. In addition, we make a program that shows thesesindicators. Finally, we ratify several obtained results and we show some real case study.Key words: GSM Network, A interface, KPI, windev, QoS. . .
Table des matières
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Chapitre 1. Contexte et problématique . . . . . . . . . . . . . . . . . . . . . . . . 41.1. Dé�nition de la QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2. Méthodes de mesures de QoS à TUNISIANA . . . . . . . . . . . . . . . . . . . . 5
1.2.1. Mesures Drive Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2. suivi des indicateurs de performance . . . . . . . . . . . . . . . . . . . . . 51.2.3. Dispositifs de capture sur les interfaces . . . . . . . . . . . . . . . . . . . . 61.2.4. Comparaison entre les di¤érentes méthodes de mesure de QoS . . . . . . . 6
1.3. Spéci�cation du besoin et description du projet . . . . . . . . . . . . . . . . . . . 6
Chapitre 2. Etat de l�art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1. Description de l�interface A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2. La signalisation sur l�interface A . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Le réseau de signalisation N�7 (SS7) . . . . . . . . . . . . . . . . . . . . . 112.2.2. Message Transfert Part (MTP) : . . . . . . . . . . . . . . . . . . . . . . . 122.2.3. Signaling Connection Control Part (SCCP) . . . . . . . . . . . . . . . . . 122.2.4. BSS Application Part (BSSAP) . . . . . . . . . . . . . . . . . . . . . . . . 122.2.5. Les couches applicatives MM et CM . . . . . . . . . . . . . . . . . . . . . 13
2.3. Les procédures GSM et les principaux messages sur l�interface A . . . . . . . . . 132.3.1. Appel entrant (Mobile Terminated Call MTC) . . . . . . . . . . . . . . . 142.3.2. Appel sortant (Mobile Originating Call MOC) . . . . . . . . . . . . . . . 142.3.3. Mise à jour de localisation (Location UpdateLU) intra-VLR . . . . . . . . 152.3.4. Mise à jour de localisation (Location UpdateLU) inter-VLR . . . . . . . . 162.3.5. Le handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.6. Le transfert de SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4. La méthode ASTELLIA : explication des notions Etat, transition, event . . . . . 19
Chapitre 3. Conception des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . 223.1. Démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2. Les indicateurs MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1. Etablissement d�appel (Call SETUP) . . . . . . . . . . . . . . . . . . . . . 243.2.2. Echec d�appel sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.3. La Conversation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3. Les indicateurs MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4. Les indicateurs d�appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.5. Mise à jour de localisation (Location Update) . . . . . . . . . . . . . . . . . . . . 39
3.5.1. Etablissement de la connexion radio . . . . . . . . . . . . . . . . . . . . . 393.5.2. Indication de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.5.3. Allocation Numéro temporaire . . . . . . . . . . . . . . . . . . . . . . . . 40
vi
3.5.4. Echec LU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6. Les indicateurs Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.1. Handover interBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6.2. Handover intraBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.7. Les indicateurs SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.8. Des indicateurs Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.8.1. Le double appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.8.2. Connexion SCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.8.3. Indicateur de tra�c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Chapitre 4. Implémentation logicielle . . . . . . . . . . . . . . . . . . . . . . . . . 544.1. Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.1. Entrée/sortie et architecture de l�application . . . . . . . . . . . . . . . . 544.1.2. Choix de l�environnement de développement . . . . . . . . . . . . . . . . . 554.1.3. Conception opérationnelle de l�application . . . . . . . . . . . . . . . . . . 57
4.2. Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapitre 5. Validation et étude de cas . . . . . . . . . . . . . . . . . . . . . . . . 675.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1. Choix des indicateurs à valider . . . . . . . . . . . . . . . . . . . . . . . . 675.1.2. Aperçu sur les outils utilisés pour la validation . . . . . . . . . . . . . . . 685.1.3. Validation de Succès_établissement_MOC _Tech . . . . . . . . . . . . . 695.1.4. Validation de Succès_établissement_MTC _Tech . . . . . . . . . . . . . 715.1.5. Validation de coupure_Appel . . . . . . . . . . . . . . . . . . . . . . . . . 725.1.6. Validation de l�indicateur Taux_Succès_LU_Tot . . . . . . . . . . . . . . 735.1.7. Validation du TauxHOInterBSCSortantSuccès et TauxHOInterBSCEntrant-
Succès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.1.8. Validation du Taux_Succès_SMS_OC . . . . . . . . . . . . . . . . . . . 76
5.2. Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.2.1. Etude d�une congestion sur l�interface A . . . . . . . . . . . . . . . . . . . 775.2.2. Etude d�échec SMS Sortant . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.3. Etude de détection d�un problème de croisement . . . . . . . . . . . . . . 84
Annexe A. Présentation du système GSM . . . . . . . . . . . . . . . . . . . . . . . 90A.1. Principe du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90A.2. Architecture GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
A.2.1. La station Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.2.2. Le sous-système radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92A.2.3. Le sous Système Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.3. Les interfaces du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A.4. Fonctionnement du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.4.1. Traitement des appels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94A.4.2. Gestion de la mobilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Annexe B. Le langage de modélisation UML . . . . . . . . . . . . . . . . . . . . . 98B.1. La syntaxe du langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98B.2. Les diagrammes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
vii
Table des figures
Figure 1.1. L�emplacement de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Figure 1.2. Schéma fonctionnel de Cigale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 2.1. Pile protocolaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 2.2. Principes d�établissement et de libération d�une connexion SCCP entre BSC
et MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 2.3. procédure MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 2.4. Procédure MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 2.5. LU intra -VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 2.6. LU inter �VLR avec IMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 2.7. Handover inter-BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2.8. Le transfert d�un SMS sortant . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2.9. Table des transitions et les compteurs relatifs . . . . . . . . . . . . . . . . . 19
Figure 3.1. Exemple de �chier .EFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.2. �chier «Automate.BDT » . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 3.3. Les étapes de la procédure MOC . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 3.4. Demande d�un canal SDCCH . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 3.5. Demande de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 3.6. authenti�cation et passage en mode chi¤ré . . . . . . . . . . . . . . . . . . 27Figure 3.7. Début d�appel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 3.8. A¤ectation d�un canal de tra�c . . . . . . . . . . . . . . . . . . . . . . . . . 29Figure 3.9. Sonnerie et connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 3.10. Echec radio lors de l�authenti�cation . . . . . . . . . . . . . . . . . . . . . 33Figure 3.11. Recherche du mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 3.12. Réponse au paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 3.13. Demande de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 3.14. Allocation TMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Figure 3.15. Handover sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 3.16. suite Handover sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 3.17. Handover entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figure 3.18. Suite handover entrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 3.19. SMS Sortant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 3.20. Répartition du tra�c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 4.1. Architecture client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figure 4.2. Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 4.3. Diagramme de cas d�utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 57Figure 4.4. Diagramme de séquences d�insertion des données dans la base . . . . . . . 58Figure 4.5. Diagramme de séquence de génération des courbes . . . . . . . . . . . . . . 59
Figure 5.1. RNO system (Alcatel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Figure 5.2. le compteur SIEMENS de CM_SERVICE_REQUEST . . . . . . . . . . . 70Figure 5.3. Résultat de la comparaison CSSR_MOC . . . . . . . . . . . . . . . . . . . 71
viii
Figure 5.4. Résultat de la comparaison CSSR_MTC . . . . . . . . . . . . . . . . . . . 72Figure 5.5. Résultat de la comparaison Call drop . . . . . . . . . . . . . . . . . . . . . 73Figure 5.6. Résultat de la comparaison LU_SUCC . . . . . . . . . . . . . . . . . . . . 74Figure 5.7. Résultat de lacomparaison SUCC_HO_Out . . . . . . . . . . . . . . . . . 75Figure 5.8. Résultat de la comparaison SUCC_HO_Out pour une cellule . . . . . . . 75Figure 5.9. Résultat de comparaison SUCC_HO_In . . . . . . . . . . . . . . . . . . . 76Figure 5.10. Résultat de la comparaison SUCC_HO_In pour une cellule . . . . . . . . 76Figure 5.11. Comparaison du MOSMS SUCC . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 5.12. Les échec MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 5.13. Répartition des causes d�échec . . . . . . . . . . . . . . . . . . . . . . . . . 78Figure 5.14. Répartition des états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 5.15. Les échecs MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Figure 5.16. Répartition des causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 5.17. Répartition des états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 5.18. Tra�c par BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Figure 5.19. Distribution des causes pour le BSC . . . . . . . . . . . . . . . . . . . . . . 82Figure 5.20. Résultat de l�analyse de l�indicateur Taux_Succès_SMS_OC . . . . . . . 82Figure 5.21. MOSMS% sur SPOTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figure 5.22. Echec SMS par numéro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figure 5.23. Résultat d�analyse de l�indicateur Succès_Etablissement_Appel_Tech . . 84Figure 5.24. Tra�c sur le secteur 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Figure 5.25. Tra�c sur le secteur 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figure 5.26. Positions GIS des secteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figure 5.27. Performances HO pour le couple 4-x . . . . . . . . . . . . . . . . . . . . . . 87Figure 5.28. Performances HO pour le couple 3-x� . . . . . . . . . . . . . . . . . . . . . 87
Figure A.1. Architecture du réseau GSM . . . . . . . . . . . . . . . . . . . . . . . . . . 91Figure A.2. Le sous système Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Figure A.3. Le sous système réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ix
Liste des tableaux
Tableau 3.1. dé�nition des causes de rejet . . . . . . . . . . . . . . . . . . . . . . . . . 32
Tableau A.1. Caractéristiques de la norme GSM . . . . . . . . . . . . . . . . . . . . . . 91Tableau A.2. Liste des interfaces dans le réseau GSM . . . . . . . . . . . . . . . . . . . 94
x
Introduction générale
La téléphonie mobile connaît dès le début des années 90 une croissance explosive dépassant
les prévisions les plus optimistes des opérateurs de télécommunication. Elle s�impose de plusen plus comme le moyen le plus e¢ cace pour conquérir d�avantage des parts du marché destélécommunications.
Le GSM est le système de téléphonie mobile qui a connu un succès sans appel. Il a étécommercialisé depuis l�année 1992 en Europe.
Le développement des technologies utilisées et les services et les applications o¤ertes par leGSM ont contribué à la création d�un environnement propice à la concurrence incitant ainsi lesopérateurs à se soucier de la qualité de leurs prestations et des performances de fonctionnementde leurs réseaux et leurs infrastructures.
Il s�avère donc que la qualité, dans ce domaine comme dans beaucoup d�autres, constitueune source importante de di¤érenciation déterminante entre les opérateurs en concurrence. Laprise à la légère de la qualité de service du réseau est une erreur stratégique puisqu�elle constituel�élément qui stimule le choix �nal du consommateur d�où la conquête du marché, d�où le pro�t.
Dans ce contexte, après la phase de déploiement d�un réseau cellulaire, l�opérateur commenceà analyser et améliorer les performances de son réseau pour garantir une qualité de serviceacceptable.
Le maintien et le suivi de cette qualité nécessitent l�observation permanente de l�état defonctionnement du réseau et de toutes les actions réalisées et par conséquent, l�utilisation d�outilsd�ingénierie adaptés.
Cependant, la supervision de ce réseau est une tâche assez délicate vu l�aspect dynamique deson architecture et de la con�guration de ses di¤érents éléments et l�hétérogénéité des outils desupervision et des bases de données des performances existantes.
Dans cette optique se manifeste le cadre général de notre projet de �n d�étude. En e¤et, parmiles méthodes adoptées pour l�évaluation de la qualité de service du réseau GSM, on distingue lesuivi de l�évolution d�indicateurs clefs de performance (KPI). La signi�cation de chaque indicateurest spéci�que, il en résulte que la conception de ces indicateurs est la phase la plus importante.
Dans un premier chapitre, nous allons évoquer le contexte général du projet ainsi que laproblématique écoulée. Le second chapitre sera consacré à la conception des indicateurs de per-formance. La phase d�implémentation logicielle et de réalisation sera rassemblée dans un troisièmechapitre. En�n le dernier chapitre contient une étude de cas réels pour interpréter et valider desrésultats obtenus.
2
Chapitre 1
Contexte et problématique
Projet de �n d�études Contexte et problématique
1Contexte et problématique
L�objectif de ce chapitre est de rattacher le projet à son cadre théorique. Nous allons dé�nir la
notion de QoS (Quality Of Service) dans les réseaux mobiles en présentant ses méthodes et moyens
de mesures. Cette notion étant assez globale, nous dégagerons celle rattachée à TUNISIANA et
ses diverses perspectives d�évaluation. Nous allons en�n dégager la problématique originelle du
projet.
Il est à noter que ce chapitre sera mieux compris avec une lecture parallèle de l�annexe A
portant sur l�architecture et des notions globale sur le GSM.
1.1 Dé�nition de la QoS
Selon la recommandation UIT E-800, la qualité de service est dé�nie en terminologie comme
étant «L�e¤et global produit par la qualité de fonctionnement d�un service qui détermine le degré
de satisfaction de l�usager du service» . Il faut donc distinguer entre la qualité de fonctionnement
QDF et la qualité de service QoS.[1]
En e¤et la qualité de fonctionnement est le guide général des facteurs qui contribuent collecti-
vement à la qualité de service. De point de vue fournisseur de service, la qualité de fonctionnement
du réseau est un concept qui traduit la manière dont les caractéristiques du réseau sont établies,
mesurées et contrôlées pour atteindre un niveau satisfaisant de qualité de service.
Dans l�utilisation d�un service, l�utilisateur d�un service ne distingue généralement que le
fournisseur de service. Le degré de satisfaction que l�utilisateur retire du service fourni dépend
de la qualité de service, c�est-à-dire de la perception qu�il a des aspects suivants :
- L�accessibilité au service,
Mahdi Kallel 4
Projet de �n d�études Contexte et problématique
- La continuabilité du service,
- L�intégrité du service.
Dans le contexte actuel, la qualité de service est devenue un facteur déterminant pour TUNI-
SIANA qui s�est donc aperçu que la qualité de ses services et de ses prestations doit être constam-
ment contrôlée et suivie, d�une part pour connaître l�état de fonctionnement de son infrastructure
et d�autre part pour pouvoir améliorer sa compétitivités. C�est dans ce cadre de concurrence et
d�innovation qu�elle s�est dotée d�un service de qualité, dont la mission est d�évaluer et de mesurer
la qualité de service dans toutes les parties du réseau.
TUNISIANA utilise plusieurs méthodes pour évaluer la qualité du service du réseau. Le
paragraphe suivant va les décrire.
1.2 Méthodes de mesures de QoS à TUNISIANA
Pour mesurer la performance de son réseau, TUNISIANA utilise un ensemble de méthodes et
d�outils qui aident à l�investigation. Les mesures Drive Test, le suivi des indicateurs de performance
et les dispositifs de capture sur les interfaces du réseau, sont des méthodes et approches qui
contribuent toutes à l�évaluation de la qualité de service. Une analyse rigoureuse des facteurs de
la qualité de service, doit impérativement utiliser l�ensemble de ces méthodes.
1.2.1 Mesures Drive Test
Il s�agit d�équipes qui font des parcours sur les routes et les zones couvertes par le réseau, pour
mesurer des paramètres en downlink (DL). Ils utilisent un mobile à trace pour l�acquisition des
mesures radio. Ce mobile est attaché à un récepteur spéci�que qui est attaché à son tour à un PC
portable. Un logiciel spécial est installé dans le PC portable sert à l�acquisition, l�enregistrement
et le traitement des mesures récupérées.
Pour la localisation géographique des points de mesures, Un GPS (Global position system)
est Utilisé.[2]
1.2.2 suivi des indicateurs de performance
Ce sont des indicateurs permettant de disposer d�une vue globale sur le réseau, notamment
sur les performances des procédures GSM. Généralement on distingue :
- Des indicateurs relatifs à l�établissement d�appel ;
- Des indicateurs de coupure d�appel ;
- Des indicateurs relatifs aux handovers ;
- Des indicateurs relatifs à la mise à jour de localisation ;
- Des indicateurs relatifs au transfert de SMS.
Ces indicateurs sont calculés à partir de compteurs sous forme « brutes » qui s�incrémentent à
chaque fois qu�un événement surviens sur le réseau (on entend par événement un message échangé
entre deux équipements du réseau). Les indicateurs, dits KPI (Key Performance Indicators), sont
calculés de la façon :
KPI = f(Compteurs)
La récolte et le rassemblement des compteurs peuvent s�e¤ectuer par le biais de l�OMC (Opé-
ration and Maintenance center) qui est un serveur générant des �chiers de compteurs.
Mahdi Kallel 5
Projet de �n d�études Contexte et problématique
1.2.3 Dispositifs de capture sur les interfaces
Les dispositifs de capture sur les interfaces permettent d�examiner les trames échangées entre
deux équipements du réseau à des �ns d�investigation. Il sont des systèmes qui se caractérisent
par :
- Un Hardware (analyseur de protocole) sur lequel est implémenté un Software spéci�que
pour détecter et adapter les caractéristiques de l�interface sur laquelle il est implémenté ;
- Un logiciel qui permet le décodage des trames ;
- Un écran pour a¢ cher le résultat des mesures ;
- Une mémoire de stockage importante.
Ils peuvent intercepter, décoder et analyser les trames et savoir de quel protocole elle relève.[4]
1.2.4 Comparaison entre les di¤érentes méthodes de mesure de QoS
Le Drive Test et les indicateurs de performance sont indispensables pour la détermination de
la qualité de service du réseau GSM. Ils représentent néanmoins quelques insu¢ sances.
Le drive Test donne l�idée sur la qualité de service comme l�aperçoit l�utilisateur, il est in-
su¢ sant dans la mesure où il n�o¤re pas une vision complète sur le réseau, il fait des mesures
«Snapshot » à un instant donné et dans un lieu donné.
En ce qui concerne la méthode d�évaluation par KPI, elle évalue globalement la qualité. Il
est donc un peu di¢ cile de déterminer la cause exacte d�un disfonctionnement. D�autre part, ces
indicateurs dépendent étroitement du constructeur dans la mesure ou chacun dé�ni et implémente
ses indicateurs d�une façon propre. Ceci stimule l�hétérogénéité entre les systèmes des fournisseurs
d�équipements.
L�importance du suivi de la QoS en se basant sur les captures sur les interfaces découle grâce
aux caractéristiques suivantes :
- La capture sur les interfaces ne dépend pas du fournisseur des équipements GSM. Elle
compense le problème du manque d�interopérabilité entre di¤érents constructeurs.
- Elle permet de faire une analyse bas niveau et de suivre la totalité des traces de signa-
lisation.
1.3 Spéci�cation du besoin et description du projet
L�opérateur « Orascom Télécom Tunisie » a été conscient de l�importance du suivi de la
qualité de service du réseau GSM par des captures à travers l�interface A du réseau.
L�interface A a été choisie vu qu�elle est totalement normalisée par la recommandation GSM
08.08 et qu�elle ne dépend en aucun cas du fournisseur des équipements. D�autre part, l�interface
A constitue la limite entre le sous système radio BSS et le sous système réseau NSS. Il s�agit
d�une fenêtre qui s�ouvre sur les deux systèmes à la fois, elle pouvait détecter les problèmes BSS
et les problèmes NSS. La quasi-totalité des procédures GSM font transiter des messages à travers
l�interface A, il est donc possible de tirer les informations utiles qui renseignent sur la qualité de
service du réseau.
Du coté de chez TUNISIANA, La plateforme de capture sur l�interface A est fournie par
ASTELLIA : une société spécialisée dans la conception de solutions matérielles et logicielles
Mahdi Kallel 6
Projet de �n d�études Contexte et problématique
dédiées à l�optimisation des performances des réseaux de la téléphonie mobile. Cette plateforme
est appelée CIGALE.
Cigale a été développé dans l�objectif de compléter et améliorer le potentiel d�investigation
dans le réseau GSM. Il est placé au niveau de l�interface A [11] (Voir �gure 1.1)
Fig. 1.1. L�emplacement de Cigale
Cigale prend comme input des �chiers de con�gurations. Par exemple, pour la mise à jour
de localisation, le �chier NETWORK.BDT contient des informations sur les di¤érents Location
Area. Le �chier PHONES.BDT est utilisé pour déclarer les numéros pour lesquels on veut générer
des statistiques particulières. Le �chier CIGALE.INI contient les di¤érents paramètres et options
de l�application [11] (Voir �gure 1.2 ).
Fig. 1.2. Schéma fonctionnel de Cigale
Comme output, Cigale génère quotidiennement des �chiers bruts ou semi bruts. Durant le
traitement il est possible de générer les �chiers _Ref.txt bruts suivants (qui seront une base pour
un outil appelé Cigale View) :
Mahdi Kallel 7
Projet de �n d�études Contexte et problématique
- TIM : informations sur les timers associés aux cellules et au BSC ;
- SS : informations associées à chaque message relatif aux services supplémentaires ;
- SMS : informations pour chaque message court ;
- LHO : informations sur les liens HO qui n�ont pas pu être établis ;
- EFF : Des compteurs e¢ caces pour chaque cellule.
A la �n du traitement, les statistiques semi bruts suivantes peuvent être générées (Statistical
�le) :
- XL2 : Statistiques sur la machine d�état (à voir la dé�nition dans le chapitre suivant) ;
- XL3 : informations de chaque connexion et leur historique ;
- XLH et XLF : Statistiques sur le �ux de handovers ;
- XLU : Statistiques sur les mises à jour de localisation ;
- XLT : Statistiques sur les ressources SCCP, CIC et TCH.
Et pour �nir le �chier LOG contient les di¤érents messages d�erreurs et d�alertes générés
durant le traitement.
Quoique intéressante, l�analyse exhaustive des �chiers générés est délicate voir très di¢ cile vu
leurs tailles volumineuses. Il faudra en outre une longue durée d�analyse pour pouvoir s�en sortir.
D�où l�idée qui a donné naissance à ce projet.
L�idée était d�essayer de compenser la durée d�analyse exhaustive des �chiers en faisant la
conception d�indicateurs clefs de performances à partir de ces �chiers. Puis de les faire implémenter
dans une application logicielle complète qui représente un tableau de bord de l�évolution de ces
indicateurs en générant des courbes et des statistiques.
En�n pour valider les résultats obtenus, une étude de cas doit être menée pour comparer les
résultats découlés des indicateurs calculés avec ceux des indicateurs OMC.
Mahdi Kallel 8
Chapitre 2
Etat de l�art
Projet de �n d�études Etat de l�art
2Etat de l�art
Dans ce chapitre, nous allons mettre l�accent sur quelques notions qui seront utiles pour
comprendre la conception des indicateurs clefs de performances à partir des messages échangés à
travers l�interface A.
Dans un premier lieu, nous présenterons l�interface A globalement en évoquant les protocoles
de signalisation rattachés, ensuite nous mettrons les di¤érents messages transités sur l�interface A
dans leur contexte de procédure GSM. En�n, nous donnerons une brève description de la méthode
Astellia en expliquant les notions : état automate, transition et événement.
2.1 Description de l�interface A
NB : Ce paragraphe sera mieux compris en regardant parallèlement l�annexe n�1 portant sur
des notions générales sur le réseau GSM.
Du point de vue physique, l�interface A est constituée de plusieurs liaisons MIC entre le BSC
et le MSC, chacune d�entre elle supporte une capacité de transmission de 2 Mbps. Le transcodeur
(TRAU), situé typiquement entre le MSC et le BSC pour l�adaptation en capacité des canaux de
transmission, doit être pris en considération lors de l�examen de cette interface. Par conséquent,
l�interface A peut être séparée en 2 parties :
- La première partie est située entre le BSC et le TRAU, où l�information utile est encore
compressée. Dans quelques nomenclatures, cette interface est appelée interface Ater. Comme c�est
le cas pour l�interface Abis, un seul canal de tra�c occupe seulement deux bits des huit bits de
l�IT MIC. C�est pourquoi il, est possible de transporter quatre canaux de tra�c simultanément
Mahdi Kallel 10
Projet de �n d�études Etat de l�art
dans un seul IT MIC. Mais l�information de signalisation sur cette interface nécessite un IT entier
MIC de 64 Kbps.
- La deuxième partie est située entre le TRAU et le MSC. L�information utile est main-
tenant décompressée. Pour cette raison, chaque canal de tra�c nécessite la totalité des huit bits
de l�IT MIC soit 64 Kbps par canal. En outre, la position du canal de signalisation peut être
di¤érente avant et après le transcodage[4].
2.2 La signalisation sur l�interface A
L�interface A se situe entre le sous-système radio (BSS) et le sous-système réseau (NSS).
A travers cette interface transitent de nombreux messages de signalisation. Cette signalisation
s�appuie sur les protocoles des couches MTP et SCCP du système de signalisation n�7 du CCITT,
et aussi sur les protocoles BSSMAP et DTAP pour les couches les plus hautes qui sont propres
à la norme GSM.
Par conséquent, le MSC n�est pas seulement relié aux di¤érents BSC par des circuits de
parole mais également par des canaux sémaphores directs : des intervalles de temps (Time Slot)
sont donc réservés à la signalisation. La �gure 2.1 présente les piles protocolaires des di¤érents
composants du réseau GSM y compris bien sûr celle qui régit le �ux de message au niveau de
l�interface A.
Fig. 2.1. Pile protocolaire
2.2.1 Le réseau de signalisation N�7 (SS7)
Ce système de signalisation par canal sémaphore normalisé par le CCITT permet de séparer
la signalisation de la transmission en faisant transiter la signalisation sur un canal spéci�que.
Mahdi Kallel 11
Projet de �n d�études Etat de l�art
De ce fait, on peut échanger des messages de signalisation sans établissement réel de circuit
de communication.
Les avantages de la signalisation sémaphore sont :
- La possibilité de transférer de la signalisation pure indépendamment de l�établissement
d�un circuit.
- La réduction des délais de transfert de la signalisation et diminution du temps d�occu-
pation ine¢ cace des circuits.
- La possibilité de transférer la signalisation à fort débit pendant une communication sans
que l�utilisateur soit gêné.
- La possibilité de réserver les circuits pour un appel seulement lorsque le correspondant
demandé est réellement joignable.[7]
2.2.2 Message Transfert Part (MTP) :
Le MTP o¤re un service de transfert �able des messages de signalisation. Il est divisé en trois
niveaux (MTP1, MTP2, MTP3) proches des trois premières couches du modèle OSI :
- MTP1 couche physique : dé�nit les caractéristiques physiques, électriques et fonction-
nelles d�une liaison physique (liaison sémaphore de données dans le vocabulaire SS7) et les moyens
d�y accéder. On utilise le plus souvent des conduits numériques à 64 kbit / s.
- MTP2 procédures d�acheminement des données sur une liaison : dé�nit les fonctions et
les procédures de transfert des messages de signalisation de façon à fournir un transfert �able
entre deux points. Ce niveau est comparable à la couche liaison de données du modèle OSI. Les
données échangées sont des "trames sémaphores". Le protocole utilisé contient un mécanisme de
contrôle du �ux, de détection des erreurs et de correction par retransmission. Par conséquent, le
MTP2 comporte un mécanisme de surveillance du taux d�erreur sur la liaison sémaphore.
- MTP3 routage et contrôle : dé�nit les fonctions et les procédures de transfert de messages
entre les noeuds du réseau sémaphore (PS ou PTS). Il comprend deux fonctions : orientation des
messages de signalisation et gestion du réseau sémaphore.
2.2.3 Signaling Connection Control Part (SCCP)
A l�encontre du MTP avec ses 3 couches, qui est responsable du transport et l�acheminement
entre 2 noeuds du réseau, le SCCP o¤re un adressage de bout en bout, même à travers les noeuds
et les pays du réseau.
Il faut aussi noter qu�une connexion SCCP par mobile est nécessaire au niveau de l�interface
A pour toute procédure sur le réseau pour le cas GSM. Ces étapes sont illustrées par la �gure
2.2[4].
2.2.4 BSS Application Part (BSSAP)
Au dessus des couches MTP et SCCP, on trouve le BSSAP (BSS Application Part). Cette
couche est formée de deux sous-couches : la sous-couche BSSMAP et la sous-couche DTAP.
Entre le BSC et le MSC transitent deux types de messages :
Mahdi Kallel 12
Projet de �n d�études Etat de l�art
Fig. 2.2. Principes d�établissement et de libération d�une connexion SCCP entre BSC etMSC
- Les messages interprétés par le BSC qui traitent à la gestion des ressources radio et
l�exécution du Handover (sous-couche BSSMAP)
- Les autres messages qui sont en fait échangés entre le mobile et le MSC (sous-couche
DTAP).
2.2.5 Les couches applicatives MM et CM
- MM inclus les messages relatifs à la mobilité
- CM inclus le traitement d�appel (CC), les services supplémentaires (SS) et le service des
messages courts (SMS)
Après avoir comprendre les di¤érents protocoles qui régissent le transfert de messages sur
l�interface A, il faut donner un aperçu sur ces messages en les mettant dans leurs contextes vis-
à-vis des procédures GSM correspondantes. Le paragraphe suivant présente les procédures GSM
les plus commodes et le résumé interface A relatif.
2.3 Les procédures GSM et les principaux messages sur l�inter-face A
Pour évaluer la qualité de service du réseau GSM, il faut comprendre les di¤érents processus
qui gèrent son fonctionnement. Les processus les plus commodes sont : l�établissement d�appel
entrant et sortant (resp MTC et MOC), la mise à jour de localisation (LU), le Handover (HO)
et le SMS.
Mahdi Kallel 13
Projet de �n d�études Etat de l�art
2.3.1 Appel entrant (Mobile Terminated Call MTC)
Une fois le roaming number MSRN fourni, le MSC lance un avis de recherche aux BSCs des
cellules qui appartiennent au LAC (Location Area Code) spéci�é par le VLR (Visiter Location
Register). Le mobile étant trouvé, la connexion radio s�établit. Et dés lors, la réponse au PAGING
est envoyée au BSC correspondant qui, à son tour, la transmet au MSC a travers l�interface A.
Ensuite le système authenti�e le mobile puis ordonne le passage en mode chi¤ré. Le BSC alloue
ensuite un canal de tra�c TCH au mobile (Les messages précédents étant sur un canal SDCCH).
Après la con�rmation d�appel, la sonnerie est envoyée à l�appelé. Si le mobile décroche, la
conversation commence.
En�n, après raccrochage, les ressources sont libérées. Voir �gure 2.3 [5].
MS BSS MSC/VLR HLR GMSC PSTN
AIM (MSISDN)Send routing info
Provide roaming number
Provide roaming number ACKMSRN Send routing info ACK
AIM (MSRN)
PagingPaging_Req
Ch_Req
ImmAss
Paging_RespPaging_Resp + SCCP Connection
Auth_Req
Auth_Resp
Chiph_Mod_Cmd
Chiph_Mod_Cmd _complete
Setup
Call_Confirmed
Sonnerie
AlertingACM
ACM
Décroché
ConnectAnswer
Answer
CONVERSATION
Raccroché
DisconnectRelease
ReleaseRelsead
Release_completeRelease_complete
Clr_CommCh_Release
Clr_Complete
Interface A
Fig. 2.3. procédure MTC
2.3.2 Appel sortant (Mobile Originating Call MOC)
Il s�agit presque de la même procédure MTC sauf que cette fois-ci, c�est le mobile qui initie
l�appel, il fait la connexion radio SDCCH avec sa station de base puis il transmet une demande
Mahdi Kallel 14
Projet de �n d�études Etat de l�art
de service (SERVICE REQUEST). Ensuite, les étapes qui suivent sont identiques à celle décrites
en MTC. Voir la �gure 3.4[5].
MS BSS MSC VLR PSTN
Ch_Req
ImmAss
SABM + Serv_Req
UAConn_ Req
Process Access_Req
AuthenticateAuth_Req
Auth_Req
Auth_Resp Auth_Resp
Authenticate.Res
Set_Ciph_ModChiph_Mod_Cmd
Chiph_Mod_Cmd
Chiph_Mod_Cmd _completeChiph_Mod_Cmd _complete
Chiph_Mod_Cmd _complete
Réallocation TMSI Optionnelle
Process Access_Req_Accept
SETUPSETUP
Complete_CallCall_Proceeding
Call_Proceeding
AIM (numéro demandé)
ACM
Ass_ReqAss_Req
Ass_CompleteAss_Complete
AlertingAlerting Answer
ConnectConnect
Connect_AckConnect_Ack
CONVERSATION
RaccrochéDisconnect
Release
Relsead
Release_complete
Release
Release_complete
Clr_CommCh_Release
Clr_Complete
Interface A
Fig. 2.4. Procédure MOC
2.3.3 Mise à jour de localisation (Location UpdateLU) intra-VLR
En GSM la mise à jour de localisation se fait lorsque le mobile passe de l�état éteint à l�état
Idle, ou bien elle se fait d�une façon périodique.
Si la nouvelle localisation du mobile appartient au même VLR que la localisation précédente,
alors il s�agit d�un LU intra VLR. Les principales étapes sont : la connexion radio SDCCH, la
demande de LU, l�authenti�cation et en�n l�exécution de la mise à jour au niveau de VLR. Voir
la �gure 2.5[5].
Mahdi Kallel 15
Projet de �n d�études Etat de l�art
MS BSS MSC/VLRInterface A
Ch_Req
Imm_Ass
Loc_Upd_ReqLoc_Upd_Req
Auth_Req
Auth_Req
Auth_RespAuth_Resp
Loc_Upd_AccLoc_Upd_Acc
Clr_Comm
Clr_CompleteCh_Release
Fig. 2.5. LU intra -VLR
2.3.4 Mise à jour de localisation (Location UpdateLU) inter-VLR
La mise à jour de localisation inter-VLR se passe si la nouvelle localisation du mobile n�ap-
partient pas au même VLR de l�ancienne localisation.
Cette fois-ci, la mise à jour de localisation passe par le HLR qui con�rme la nouvelle connexion
et annule l�ancienne.
La mise à jour de localisation peut se faire ou bien avec TMSI seulement (voir �gure 2.4 [5]),
ou bien avec IMSI Attach avant la phase d�authenti�cation.
Mahdi Kallel 16
Projet de �n d�études Etat de l�art
MS BSS MSC VLR2 HLR VLR1
Ch_Req
Imm_Ass
Loc_Upd_ReqLoc_Upd_Req
Loc_Upd.Area
Provide IMSIIMSI_Req
Identity_Req
Identity_Resp
IMSI_AckSend Param (Req_Authent_set)
Send Param.Result (Rand, Sres, Kc)
IMSI_Resp
AuthenticateAuth_Req
Auth_Req
Auth_Resp Auth_Resp
Authenticate.ResUpdate_Loc
Insert Subscriber data
Insert Subscriber data.ACKCancel_Loc
Cancel_Loc_ACKUpdate_Loc_ACK
Set_Ciph_ModChiph_Mod_Cmd
Chiph_Mod_Cmd
Chiph_Mod_Cmd _completeChiph_Mod_Cmd _complete
Chiph_Mod_Cmd _complete
Forword_New_TMSITMSI Realloc_Cmd
TMSI Realloc_Cmd
TMSI Realloc_completeTMSI Realloc_complete
Forword_New_TMSI.Res
Loc_Upd.Area_ACKLoc_Upd_Accept
Loc_Upd_Accept
Clr_Comm
Clr_CompleteCh_Release
Interface A
Fig. 2.6. LU inter �VLR avec IMSI
2.3.5 Le handover
Un rapport de mesures radio est échangé entre le mobile et sa station de base, Le handover
se déclenche suite à un algorithme spéci�que qui met en vigueur les critères de déclenchement
suivants : le niveau de champs, la qualité du lien radio, le niveau d�interférence, l�éloignement du
mobile de sa station de base et le tra�c.
Les handovers peuvent être par ordre hiérarchique intra ou inter cellulaires, intra ou inter
BSC, intra ou inter MSC.
Vu sa position, l�interface A ne pouvait être utile que pour la détermination de la performance
du HO inter BSC. Pour le handover intra-BSC, seul le messager HANDOVER-PERFORMED
transite à traver l�interface A vers la �n de la procédure.
Mahdi Kallel 17
Projet de �n d�études Etat de l�art
La procédure du handover inter-BSC est donnée par la �gure2.7.
Fig. 2.7. Handover inter-BSC
2.3.6 Le transfert de SMS
Le transfert de SMS se fait sur la voie de signalisation SDCCH. Après les phases rituelles
de connexion radio Sur SDCCH et l�authenti�cation, le mobile envoie son SMS sur la voie de
signalisation. Si ce message parvient au centre d�SMS (SMSC), le mobile reçoit un acquittement
positif.
Cette procédure est illustrée par la �gure 2.8 [6]. (On a pris le cas d�un SMS sortant).
Fig. 2.8. Le transfert d�un SMS sortant
Pour intercepter ces di¤érents messages transités a travers l�interface A, TUNISIANA a im-
plémenté un analyseur de protocole «Astellia» : une société spécialisée dans la conception de
solutions matérielles et logicielles dédiées à l�optimisation des performances des réseaux de la
téléphonie mobile. Le paragraphe suivant explique la méthode Astellia de capture.
Mahdi Kallel 18
Projet de �n d�études Etat de l�art
2.4 La méthode ASTELLIA : explication des notions Etat, tran-sition, event
Le dispositif de capture intercepte les messages qui transitent à travers l�interface A. Pour
qu�il réussisse à décoder et comprendre chaque message, l�enchaînement de chaque procédure
GSM doit être pris en compte lors de sa con�guration initiale.
Cette con�guration dé�nit un ensemble d�états de telle façon que chaque message intercepté
fait changer un état donné de l�automate de l�analyseur.
Par dé�nition, Une transition est constituée de :
- Un état original ;
- Un état �nal
- Un message (event) avec parfois une cause associée. Ce message est le message propre-
ment dit, connu, dé�nit par la norme et capté au niveau de l�interface A.
Les event sont parfois accompagnés d�une extension permettant :
- d�indiquer le sens du message ;
- d�ajouter une information supplémentaire.
La �gure 2.9 montre un extrait la table du �chier «Automate.BDT » (Un �chier input de
Cigale voir �gure 1.2 ) qui rassemble les di¤érentes transitions implémentées sur l�automate et
qui est fournis lors de la livraison du produit et mis à jour si nécessaire [6].
Fig. 2.9. Table des transitions et les compteurs relatifs
Chaque connexion passe une succession ordonnée d�états de l�automate selon la procédure
GSM (MOC, MTC, LU, SMS, HO. . . ). Dans la procédure MOC, par exemple, le premier mes-
sage qui passe par l�interface A est le message SERVICE_REQUEQST noté dans le tableau CM-
SRQ. Ce message fait donc changer l�état de l�automate de l�état VIDE à l�état OC_CMSREQ.
Le deuxième message est AUTHENTICATION_REQUEST. Ce message fait passer l�état de
l�automate de OC_CMSREQ à OC_AUTHRQ.
Ainsi de suite on peut tirer l�ensemble des transitions par lesquels la procédure MOC doit
passer. Par conséquent, la classi�cation des transitions par procédure et leur organisation par
ordre d�enchaînement de chaque procédure est indispensable pour tirer les compteurs associés qui
seront par la suite la base de la phase de la conception des indicateurs clefs de performance.
Chaque transition fait incrémenter un ou plusieurs ces compteurs dits «e¢ caces» qui �gurent
dans le �chier .EFF généré par Cigale.
Mahdi Kallel 19
Projet de �n d�études Etat de l�art
L�étude des spéci�tés de l�interface A dans ce chapitre, ainsi que la description de la méthode
Astellia vont être des éléments clefs pour la compréhension de la conception des indicateurs de
performance. Dans le chapitre suivant nous mettrons en pratique cette étude en concevant des
indicateurs clefs de performances qui re�ètent la qualité du réseau.
Mahdi Kallel 20
Chapitre 3
Conception des indicateurs
Projet de �n d�études Conception des indicateurs
3Conception des indicateurs
3.1 Démarche
La conception des indicateurs nécessite une connaissance des procédures que dé�nit la norme
GSM. Puisqu�en e¤et, les messages de ces procédures qui transitent à travers l�interface A consti-
tuent la base des indicateurs conçus. L�analyse et la distinction entre les messages sur l�interface
A des di¤érentes procédures s�avèrent donc indispensables dans la mesure où il s�agit de l�étape
préliminaire de la conception des indicateurs.
Après l�identi�cation des messages déterminant sur l�interface A, il faut trouver un moyen
de comptage de leurs occurrences sur un objet donné (MSC, BSC, Cellule, LAC). Dans cette
optique et après la documentation et analyse des di¤érents �chiers générés par Cigale, il s�est
avéré que le �chier .EFF, généré chaque jour par capture, est le plus intéressant vu qu�il donne
un ensemble de compteurs qui s�incrémentent suite aux transitions de l�état de l�automate donc
suite aux messages qu�on désire calculer l�occurrence. Ces compteurs sont classi�és par cellules.
La �gure 3.1 montre la structure d�un �chier .EFF.
Mahdi Kallel 22
Projet de �n d�études Conception des indicateurs
Fig. 3.1. Exemple de �chier .EFF
Il n�existe pas encore une documentation qui donne la dé�nition des compteurs que le �chier
.EFF calcule. On ne peut savoir leurs signi�cations que si on passe par une analyse exhaustive du
�chier «Automate.BDT» qui donne l�ensemble de toutes les transitions con�gurées sur l�analyseur
de protocole avec les compteurs qui s�incrémentent suite à chaque transition. La �gure 3.2 montre
le �chier « Automate.BDT » .
Fig. 3.2. �chier «Automate.BDT »
Chaque ligne est une transition formée par un état initial, le message, l�état suivant et,
optionnellement, les extensions et les causes (les causes des rejets si c�est une transition de rejet).
A la �n de la ligne on trouve les compteurs qui s�incrémentent suite à chaque transitions. Un
compteur peut correspondre à une ou plusieurs transitions et une transition peut incrémenter un
Mahdi Kallel 23
Projet de �n d�études Conception des indicateurs
ou plusieurs compteurs selon le cas et selon les extensions où les causes.
Par conséquent, pour la conception d�un indicateur il faut paser par les étapes suivantes :
- S�inspirer des indicateurs de performances OMC des fournisseurs d�équipements ;
- Identi�cation des messages cruciaux qui transitent à travers l�interface A pour chaque
procédure GSM selon le critère de qualité de service et les critères techniques ;
- Réorganiser les transitions qui se trouvent dans le �chier « Automate.BDT » selon le
déroulement de chaque procédure ;
- Identi�er la transition qui correspond à ces messages ;
- Tirer les compteurs associés ;
- Dé�nition de la formule.
3.2 Les indicateurs MOC
Lors de ce pargraphe, nous allons essayer de parcourir toute la procédure en commençant par
l�établissement d�appel sortant puis la converstion.
3.2.1 Etablissement d�appel (Call SETUP)
L�établissement d�un appel sortant passe par 3 étapes :
Fig. 3.3. Les étapes de la procédure MOC
- Etape 1 : Elle Commence avec le message initial sur l�interface A (CM SERVICE RE-
QUEST) et se termine avec la demande du canal de tra�c TCH (ASSIGNEMENT REQUEST)
- Etape 2 : Elle commence avec la demande du canal TCH (ASSIGNEMENT REQUEUST)
et se termine par le message de succès d�allocation d�un canal TCH (ASSIGNEMENT COM-
PLETE).
- Etape 3 : Elle commence avec le message de succès d�allocation d�un canal TCH (ASSI-
GNEMENT COMPLETE) et se termine par la connexion directe (DIRECT CONNECT).
Nous allons établir les indicateurs relatifs à chaque étape en distinguant les scénarios d�échec
et de succès correspondants.
3.2.1.1 L�établissement de la connexion radio (Demande de canal SDCCH)
L�établissement de la connexion radio est l�étape préliminaire pour toute procédure GSM.
Elle n�est pas spéci�que à la procédure de l�appel sortant. Néanmoins, il n�y a aucun message qui
transite sur l�interface A pour cette étape (voir �gure 3.4 [6])
Mahdi Kallel 24
Projet de �n d�études Conception des indicateurs
Fig. 3.4. Demande d�un canal SDCCH
Il en résulte que l�analyseur de protocole ne va pas détecter cette étape ce qui n�est pas le cas
des étapes suivantes. . .
3.2.1.2 Déclenchement :
Le déclenchement de toute la procédure de l�appel sortant MOC au niveau de l�interface A
est donné par le message SERVICE_REQUEST envoyé par le BSS au MSC. Ce message est
encapsulé dans un message de la couche BSSMAP et accompagné d�une demande de connexion
SCCP entre le BSC et le MSC. (Voir �gure 3.5 [6])
Fig. 3.5. Demande de service
L�état de l�automate passe alors de l�état vide (VIDE) à l�état demande de service (OCCM-
Mahdi Kallel 25
Projet de �n d�études Conception des indicateurs
SREQ) selon la transition suivante : (CMSRQ étant le message SERVICE_REQUEST selon la
nomenclature d�Astellia)
VIDECMSRQ
BSC MSCOC_CMS_REQ
Nous pouvons ainsi dé�nir le nombre total de demande MOC (initiation d�appel) sur l�interface
A comme étant la somme de l�occurrence de ce message.
Mais les captures sur l�interface A ont un début et une �n. Il se peut que la capture se
ferme alors que la procédure n�a pas encore terminée. Il en résulte qu�on peut trouver quelques
incohérences dans les �chiers générés par ces captures : c�est ce qu�on appelle les « Purges » .
Pour être plus concis, et pour que ce phénomène n�a¤ecte pas nos calculs, il faut retrancher le
nombre de purges du nombre total de tentatives MOC.
La transition mentionnée ci-dessus fait incrémenter le compteurNb_OC qui �gure dans le �-chier .EFF . Le nombre de purges de l�appel sortant est donné par le compteurNbPURGE_E1_OCpour les purges de la phase1 de l�établissement d�appel, NbPURGE_E2_OC pour les purges
de la phase2 de l�établissement d�appel et NbPURGE_E3_OC pour les purges de la phase3
de l�établissement d�appel. Ainsi on obtient la formule générique suivante :
Nombre_Appels_MOC=NbOC-NbPURGE_E1_OC-NbPURGE_E2_OC-
NbPURGE_E3_OC
3.2.1.3 Authenti�cation et passage en mode chi¤ré
Si tout se passe bien, l�état de l�automate passe de l�état demande de service (OC_CMS_REQ)
à l�état de la première tentative de l�authenti�cation (OC_AUT_REQ_1) selon la transition sui-
vante :
MSC BSCOC_CMS_REQ OC_AUT_REQ_1
AUTRQ
Cette transition correspond au message AUTHENTICATION_REQUEST. (Voir �gure 3.6)
Mahdi Kallel 26
Projet de �n d�études Conception des indicateurs
Fig. 3.6. authenti�cation et passage en mode chi¤ré
Si le mobile répond, le BSC envoi le SRES calculé par le mobile au MSC dans un message
AUTHENTICATION RESPONSE (AUTRP). L�automate fait alors la transition suivante :
BSC MSC
AUTRPOC_AUT_REQ_1 OC_AUT_RP
Une fois le mobile est authenti�é, le MSC envoi une commande de chi¤rement de la couche
BSSMAP CMCMD (Cipher Mode CoMmanD). Ceci correspond à la transition suivante :
MSC BSCOC_AUT_RP OC_CIM_CMD
CMCMD
Le mobile répond alors positivement si tout est bien passé. Il envoi le message CMCMP
(Cipher Mode CoMPlete). Ce message fait changer l�état de l�automate comme suit :
BSC MSCOC_CIM_CMP
CMCMPOC_CIM_CMD
Mahdi Kallel 27
Projet de �n d�études Conception des indicateurs
3.2.1.4 Début d�appel
Après la phase de l�authenti�cation et du passage en mode chi¤ré, vient la phase de début
d�appel ( On ne parle pas encore du début de la conversation). Dans cette phase les données
nécessaires pour l�établissement d�appel sont envoyées par le mobile (voir �gure 3.7)
Fig. 3.7. Début d�appel
Le passage à cette étape correspond à la transition suivante :
BSC MSCOC_SETUP
SETUPOC_CIM_CMP
Selon le numéro demandé, le MSC route l�appel. Il informe dans ce cas le mobile que l�appel
est en cours. Ceci Correspond à un message CPROC (Call PROCeeding) qui change l�état de
l�automate selon cette transition :
MSC BSCMSC
OC_SETUPCPROC
OC_PROC
3.2.1.5 A¤ectation d�un canal de tra�c
Si le MSC a alloué un circuit, il ordonne le BSC d�attribuer au mobile un canal de tra�c TCH
dans un message ASREQ (ASsignment REQuest). La procédure est illustrée par la �gure 3.8 [6]
Ce message fait changer l�état de l�automate comme suit :
Mahdi Kallel 28
Projet de �n d�études Conception des indicateurs
Fig. 3.8. A¤ectation d�un canal de tra�c
MSC BSCMSC
OC_PROCASREQ
OC_ASS_REQ_1
Cette transition fait incrémenter le compteur NbASREQ_OC.Si toute la procédure de l�a¤ectation de canal TCH est terminée avec succès, le BSC envoi le
message ASCMP (ASsignment CoMPlete) au MSC. L�automate change alors d�état :
BSC MSCMSC
OC_ASS_REQ_1ASCMP
OC_ASS_CMP
Cette transition fait incrémenter le compteur NbASCMP_OC.Ainsi on peut dé�nir un indicateur qui caractérise le taux de succès de l�attribution d�un canal
TCH dans la procédure MOC. Cet indicateur est de type Succès/Demandes. Il est donné par la
formule suivante :
Taux_succ�es_attribution_TCH_MOC =NbASCMP_OCNbASREQ_OC
(3.1)
Mahdi Kallel 29
Projet de �n d�études Conception des indicateurs
3.2.1.6 Con�rmation d�appel
Si l�appelé est trouvé, le MSC envoie une sonnerie à l�appelant. Le message correspondant est
ALERT (ALERTing) Voir �gure 3.9.
Fig. 3.9. Sonnerie et connexion
La transition correspondante à ce message est la suivante :
MSC BSCMSC
ALERTOC_ASS_CMP OC_SONN
Si l�appelé décroche, MSC fait la connexion avec le mobile par la commande CON (CONnect).
La transition correspondante est la suivante :
MSC BSCMSC
CONOC_SONN OC_CON
S�il est connecté, le mobile envoi un acquittement positif dans un message CONACK
(CONnect ACKnowledge). La transition est la suivante :
BSC MSCMSC
CONACKOC_CON OC_COMM
Mahdi Kallel 30
Projet de �n d�études Conception des indicateurs
Cette transition résume le succès de l�établissement d�appel MOC. Elle fait incrémenter le
compteur NbCONACK_OC.Nous pouvons dé�nir l�indicateur de succès d�établissement MOC comme étant succès/demandes,
soit :
Succ�es_�etablissement_MOC_User =Nb_CONACK_OCNombre_Appel_MOC
(3.2)
Cet indicateur re�ète la performance de la procédure MOC comme l�aperçoit l�utilisateur.
En e¤et, un établissement d�appel qui a commencé par SERVICE REQUEST et qui n�est pas
terminé par CONNECT Ack sera considéré comme échoué même si les causes sont normales et
ne représentant pas de problèmes techniques. Nous donnons des exemples de ces causes :
- Appelé occupé ;
- Appelant ou appelé raccroche intentionnellement avant la connexion CONNECT Ack.
Cet indicateur est utile dans la mesure où il permet de mettre en relief les plaintes des
clients et d�analyser le taux d�appels aboutis dans une zone donnée pour voir si les abonnées
communiquent ou non. Mais son insu¢ sance est qu�il induit à l�erreur s�il s�agit d�un problème
purement technique.
Dans ce contexte, notre idée était d�ajouter l�extension USER à cet indicateur pour montrer
sa signi�cation réelle. En outre, il a été indispensable de concevoir un indicateur qui re�ète la
performance de la procédure MOC techniquement.
Pour se faire, nous avons constaté que les causes normales d�abondant d�appel se produisent en
général pendant la phase de con�rmation d�appel, c�est-à-dire pendant la phase de sonnerie. Il en
résulte que le message qui re�ète le succès de la procédure d�établissement d�appel techniquement
est ASSIGNEMENT_COMPLETE : le message qui, suite auquel, un canal TCH est alloué. Ce
message fait incrémenter le compteur NbASCMP_OC.
Ainsi, le taux de succès de l�établissement d�appel sortant MOC techniquement est dé�nit
par :
Succ�es_�etablissement_MOC_Tech =NbASCMP_OC
Nombre_Appel_MOC(3.3)
3.2.2 Echec d�appel sortant
Lors de notre étude des di¤érents scénarios d�échec de l�appel sortant, on a pu identi�er les
messages d�échecs qui transitent à travers l�interface A, et de voir les causes correspondantes. Le
tableau ci-après illustre bien ces messages.
Mahdi Kallel 31
Projet de �n d�études Conception des indicateurs
Message/ Sens Causes Description des causesSERVICE_REJECT (MSC-BSC) SONS Service Option Not Supported , serv ice demandé n�est pas valab le.
IUH IMSI Unknown in the HLR
IUV IMSI Unknown in the VLR
NF Network Failure : échec NSS
IMEINA IMEI Not Accepted (Equip em ent volé)
CLEAR REQUEST(BSC -MSC) RIF Radio Interface Failure : le m obile p erd la connexion rad io avec sa BTS
EF Equip em ent Failure : un équip em ent de la partie BSS ne fonctionne pas
R IMF Radio Interface M essage Failure : erreur de m essage sur l�interface rad io .
AUTH REJECT (MSC-BSC) Le mobile donne un SRES erroné
CONNECTIO REFUFED (MSC-BSC) CR Connection SCCP est refusée entre le BSC et le MSC
NC Normal C learing : le m obile qu itte l�app el volontairem ent
INF Invalid Number Format : le m obile compose un format de numéro invalide
UN Unassigned Number : le numéro demandé est invalide
NUR No User Resp onding : l�app elé ne rép ond pas
UB User Busy : app elé o ccup é
NCCA No C ircu it Channel Availab le : pas de circu its valab les au niveau MSC .
NOOO Network Out O f order : le réseau ne rép ond pas
ASSEIGNMENT FAIL (BSC -MSC) NRRA No Radio Resource Availab le : pas de ressources TCH valab les.
R IF EF Même sign i�cation que le m essage C lear request
Tab. 3.1. dé�nition des causes de rejet
L�automate Cigale regroupe les scénarios d�échec de l�appel sortant par le couple (partie,
étape). On distingue :
- Le couple (NSS, étape x) regroupe les scénarios d�échec coté NSS pendent l�étape 1
de l�appel sortant. Il correspond au compteur OCx_AfNSS (x dans {1, 2, 3}). Ce compteurs�incrémente à chaque foi que l�automate détecte un échec d�établissement d�appel sortant pendant
l�étape 1 du à un problème du c�ur du réseau par une transition bien spéci�que. Les causes
Associés à ce compteur sont : NF, NOO, NCCA (voir la dé�nition de ces causes dans le tableau
précédant)
- Le couple (BSS, étape x) regroupe les scénarios d�échec coté BSS de l�appel sortant. Il
correspond au compteur OCx_AfBSS (x dans {1, 2, 3}). Ce compteur s�incrémente à chaquefois que l�automate détecte un échec d�établissement d�appel sortant pendant l�étape 1 du à un
problème dans les équipements de la partie BSS. Les causes associées à ce compteur sont : EF,
NRRA (Voir la dé�nition de ces causes dans le tableaux précédant).
- Le couple (MS, étape x) regroupe les scénarios d�échec de l�appel sortant du côté de
utilisateur. Il correspond au compteur OCx_AfMS : Ce compteur comptabilise l�échec de laprocédure MOC dans sa phase 1 à cause du mobile. Les causes associées à ce compteur sont :
SONS, UIH, UIV, IMEINA, NC, INF, UN, NUR, UB.
- Le couple (BSSMS, étape x) regroupe les scénarios d�échec de l�appel sortant sur l�in-
terface radio. Il correspond au compteur OCx_AfBSSMS : ce compteur est incrémenté s�il ya un échec au niveau de l�interface radio dans la première étape du MOC, par exemple lors de
l�authenti�cation (Voir �gure 3.10). Les causes associées à ce compteur sont : RIF, RIMF.
Mahdi Kallel 32
Projet de �n d�études Conception des indicateurs
Fig. 3.10. Echec radio lors de l�authenti�cation
- Le couple (NSSMS, étape x) regroupe les scénarios d�échec de l�appel sortant du à
un problème dans les protocole des couches hautes (CM, RR) qui régissent le dialogue direct
entre la partie NSS et le mobile. Il correspond au compteur OCx_AfNSSMS. Ce compteur estincrémenté s�il y a un problème dans le dialogue du mobile avec les bases de donnés du réseau
au court de la procédure MOC. Les causes associés à ce compteur sont : IUH et IUV.
- Le couple (NSSBS, étape x) regroupe les scénarios d�échec de l�appel sortant du à un
problème de connexion entre le BSC et le MSC. Il correspond au compteur OCx_AfNSSBS.Ce compteur est incrémenté s�il y a un problème de connexion SCCP entre le BSC et le MSC.
La cause associée à ce compteur est CR.
Nous avons pu identi�er ces compteurs en identi�ant les transitions correspondantes aux
messages d�échecs. Ainsi, nous pouvons rassembler des indicateurs de l�échec de l�établissement
de la procédure MOC par cause.
3.2.2.1 Le taux d�échec d�établissement MOC relié à un problème NSS
C�est la somme des échecs cause NSS des trois étapes ensembles divisée par le nombre total
des tentatives MOC, soit :
Echec_MOC_NSS =
3Px=1(OCx_AfNSS +OCx_AfNSSMS +OCx_AfNSSBS)
Nombre_Appel_MOC(3.4)
3.2.2.2 Le taux d�échec d�établissemnt MOC relié à un problème BSS
C�est la somme des échecs cause BSS des trois étapes ensembles divisée par le nombre total
de tentatives MOC, soit :
Mahdi Kallel 33
Projet de �n d�études Conception des indicateurs
Echec_MOC_BSS =
3Px=1(OCx_AfBSS +OCx_AfBSSMS)
Nombre_Appel_MOC(3.5)
3.2.2.3 Le taux d�échec d�établissemnt MOC relié à un problème utilisateur
C�est la somme des échecs cause utilisateur des trois étapes ensembles divisée par le nombre
total de tentatives MOC, soit :
Echec_MOC_User =
3Px=1
OCx_AfMS
Nombre_Appel_MOC(3.6)
Nous pouvons ainsi en déduire le taux d�échec de la procédure MOC techniquement, c�est-
à-dire que nous éliminons l�échec de la procédure causé par l�utilisateur car il n�entre pas en
jeux pour la détermination de la performance du réseau. Il en résulte que le taux d�échec de
l�établissement MOC est la somme des indicateurs Echec_MOC_NSS et Echec_MOC_BSS,
soit :
Echec_CALL_SETUP_MOC = Echec_MOC_NSS + Echec_MOC_BSS (3.7)
A partir de là, nous pouvons dégager une autre approche di¤érente de celle citée précédemment
concernant la formule du « Succès_établissement_MOC _Tech » , ce n�est d�autre que :
Succ�es_�etablissement_MOC_Tech = 1� Echec_CALL_SETUP_MOC (3.8)
3.2.3 La Conversation
La phase de la conversation commence après le message de connexion CONNECT ACK. La
chose qui peut le plus gêner l�utilisateur c�est lorsque son appel est coupé involontairement au
cour d�une communication, c�est ce qu�on appelle le « call drop » ou coupure d�appel.
C�est un indicateur crucial pour la détermination de la qualité de service du réseau techni-
quement mais, aussi du côté de l�utilisateur, car ce phénomène engendre en général les plaintes
des clients. Pour la coupure d�appel l�automate Cigale change d�état selon la transition suivante :
OC_COMM OC_COMM_FIN<Message i>
Avec <message i> dans {CLCMD (CLear CoMmanD), CLREQ (CLear REQuest), DISC
(DISConnect), REL (RELease)}
Ces messages varient selon la cause de la coupure. Les causes qui engendrent un call drop
sont : RIF, RIMF, EF, NOOO, CR (Voir la dé�nition de ces causes dans le tableau 4.1). On peut
ainsi dé�nir des indicateurs de performances relatifs à la coupure d�appel par cause.
Mahdi Kallel 34
Projet de �n d�études Conception des indicateurs
3.2.3.1 La Coupure d�appel due à un problème BSS
Deux paramètres entrent en jeux, les coupures au niveau des équipements BSS et les coupures
sur l�interface radio. Nous allons donc prendre en compte les compteurs OCcom_AfBSS etOCcom_AfBSSMS, et nous allons les diviser sur le nombre total des conversations sortantesqui est le nombre d�occurrence du dernier message de l�établissement d�appel CONNECT ACK,
Soit :
Coupure_MOC_BSS =OCcom_AfBSS +OCcom_AfBSSMS
NbCONACK_OC(3.9)
3.2.3.2 La Coupure d�appel due à un problème NSS
Les compteurs à prendre en compte sont OCcom_AfNSS, OCcom_AfNSSBS et OC-com_AfNSSMS. Et nous allons les diviser sur le nombre total des conversations sortantes.Soit :
Coupure_MOC_NSS =OCcom_AfNSS +OCcom_AfNSSMS +OCcom_AfNSSBS
NbCONACK_OC(3.10)
3.2.3.3 La Coupure totale d�appel MOC
C�est la somme des deux indicateurs précédents :
Coupure_MOC = Coupure_MOC_BSS + Coupure_MOC_NSS (3.11)
3.3 Les indicateurs MTC
La procédure MTC est identique à la procédure MOC sauf pour la phase d�initiation d�appel.
En e¤et, contrairement à la procédure MOC, celle-ci est initiée par le réseau et non pas par le
mobile. Pour le reste de la procédure tous les indicateurs auront la même dé�nition que leurs
homologues de la procédure MOC. Le réseau lance un avis de recherche du mobile (BSSMAP
PAGING) sur l�ensemble des BSC du LAC du mobile. Si le mobile reçoit cet avis de recherche
de la part de sa BTS, il établit la connexion radio (voir �gure 3.11) :
Mahdi Kallel 35
Projet de �n d�études Conception des indicateurs
Fig. 3.11. Recherche du mobile
Le message PAGING ne pouvait pas être le message déclencheur de la procédure MTC pour la
simple raison qu�il est envoyé pour tout les BSC du LAC du mobile recherché, donc sur l�ensemble
des interfaces A relatifs à ces BSC. Si le mobile est trouvé, il envoi au réseau sa réponse à la
recherche (PAGING RESPONSE). (Voir �gure 3.12) :
Mahdi Kallel 36
Projet de �n d�études Conception des indicateurs
Fig. 3.12. Réponse au paging
Le déclenchement de toute la procédure de l�appel entrant MTC au niveau de l�interface A
est donné par le message PAGING RESPONSE envoyé par le BSS au MSC. Ce message est
encapsulé dans un message de la couche BSSMAP et accompagné d�une demande de connexion
SCCP entre le BSC et le MSC. L�état de l�automate passe alors de l�état vide (VIDE) à l�état
réponse à la recherche (TC_PAG_RP) selon la transition :
VIDEBSC MSC
PAGRPTC_PAG_RP
PAGRP étant le message PAGING selon la nomenclature Astellia. On peut ainsi dé�nir le
nombre total de demande MTC (initiation d�appel) par la somme de l�occurrence de ce message.
Cependant, les captures sur l�interface A ont un début et une �n. Il se peut que la capture se
ferme alors que la procédure n�est pas encore terminée. Il en résulte qu�on peut trouver quelques
incohérences dans les �chiers générés par ces captures : c�est ce qu�on appelle les « Purges» . Pour
être plus concis, et pour que ce phénomène n�a¤ecte pas nos calculs, il faut retrancher le nombre
de purges du nombre total de tentatives MTC.
Or, la transition mentionnée ci-dessus fait incrémenter le compteur Nb_TC qui �gure dans
le �chier .EFF . Et le nombre de purges de l�appel entrant est donné par le compteur Nb-PURGE_E1_TC pour les Purges de la phase1 de l�établissement d�appel,NbPURGE_E2_TCpour les Purges de la phase2 de l�établissement d�appel et NbPURGE_E3TC pour les Purges
de la phase3 de l�établissement d�appel. Ainsi on obtient la formule générique suivante :
Nombre_tentatives_MTC=Nb_TC-NbPURGE_E1_TC-NbPURGE_E2_TC
Mahdi Kallel 37
Projet de �n d�études Conception des indicateurs
-NbPURGE_E3_TC
Pour tout le reste des indicateurs MTC, il s�agit de la même démarche adoptée pour les
indicateurs MOC puisqu�il s�agit quasiment de la même procédure. En conséquence de quoi, on
peut donner la dé�nition des indicateurs suivants :
Taux_succ�es_attribution_TCH_MTC =NbASCMP_TCNbASREQ_TC
(3.12)
Succ�es_�etablissement_MTC_User =Nb_CONACK_TCNombre_Appel_MTC
(3.13)
Succ�es_�etablissement_MTC_Tech =NbASCMP_TC
Nombre_Appel_MTC(3.14)
Echec_MTC_NSS =
3Px=1(TCx_AfNSS + TCx_AfNSSMS + TCx_AfNSSBS)
Nombre_Appel_MTC(3.15)
Echec_MTC_BSS =
3Px=1(TCx_AfBSS + TCx_AfBSSMS)
Nombre_Appel_MTC(3.16)
Echec_MTC_User =
3Px=1
TCx_AfMS
Nombre_Appel_MTC(3.17)
Echec_CALL_SETUP_MTC = Echec_MTC_NSS + Echec_MTC_BSS (3.18)
Succ�es_�etablissement_MTC_Tech = 1� Echec_CALL_SETUP_MTC (3.19)
Coupure_MTC_BSS =TCcom_AfBSS + TCcom_AfBSSMS
NbCONACK_TC(3.20)
Coupure_MTC_NSS =TCcom_AfNSS + TCcom_AfNSSMS + TCcom_AfNSSBS
NbCONACK_TC(3.21)
Coupure_MTC = Coupure_MTC_BSS + Coupure_MTC_NSS (3.22)
3.4 Les indicateurs d�appel
Ces sont des indicateurs hybrides MTC/MOC. Ils sont déduit à partir des indicateurs MOC
et MTC de la façon suivante :
Si indicateurMOC = x1y1et indicateurMTC = x2
y2
Alors indicateurAppel = x1+x2y1+y2
Mahdi Kallel 38
Projet de �n d�études Conception des indicateurs
3.5 Mise à jour de localisation (Location Update)
Comme nous avons fait pour la procédure MOC, nous allons parcourir toute la procédure
de mise à jour de localisation, tirer les messages cruciaux et identi�er les transitions automate
correspondantes. Nous allons déduire ensuite les compteurs bruts qui correspondent à ces transi-
tions pour essayer d�établir les indicateurs clefs de performances de la procédure Location Update
(LU).
3.5.1 Etablissement de la connexion radio
C�est l�étape préliminaire de toutes les procédures GSM initiées par le mobile. Elle consiste
à attribuer un canal SDCCH au mobile par le BSC. Nous n�allons pas en tenir compte pour la
détermination de la performance du la procédure LU vu qu�elle est indétectable sur l�interface A.
3.5.2 Indication de service
Après la commutation sur canal SDCCH, le mobile envoie une demande de mise à jour de
localisation qui contient des informations sur le type de cette mise à jour et sur l�identité du
mobile (voir �gure 3.13).
Fig. 3.13. Demande de service
Cette demande est transmise au MSC par le biais du message UPDATING_REQUEST en-
capsulé dans un message de la couche BSSMAP et accompagné par une demande de connexion
SCCP entre MSC et BSC. Ce message traduit le déclenchement de toute la procédure LU. L�au-
tomate Astellia fait la transition correspondante suivante :
Mahdi Kallel 39
Projet de �n d�études Conception des indicateurs
VIDE LU_NLUREQ
BSC MSC
Dans cette transition, l�état de l�automate passe de l�état initial vide (VIDE) à LU_N (Lo-
cation Updating Normal). Selon le type de demande de mise à jour de localisation, cet état
est :
- LU_P pour une mise à jour de localisation périodique,
- LU_N pour une mise à jour de localisation normale,
- LU_IA pour une mise à jour de localisation IMSI Attach.
Cette transition fait incrémenter le compteur NbLUREQ_NU pour le LU normal, NbLU-REQ_P pour le LU periodique et le NbLUREQ_IA pour le LU IMSI Attach. On doit, bien
entendu, retrancher le nombre des purges sur cette procédure. Cependant, l�automate ne comp-
tabilise que les purges pendant la mise à jour de localisation périodique, il ne le fait pas pour les
deux autres types (LU_P et LU_IA). Nous pouvons en déduire le nombre de tentative LU pour
chaque type :
Nombre_tentativesLU_N = NbLUREQ_NU �NbPURGE_LU_NUNombre_tentativesLU_P = NbLUREQ_P
Nombre_tentativesLU_IA = NbLUREQ_IA
3.5.3 Allocation Numéro temporaire
Après l�authenti�cation et le passage en mode chi¤ré, le nouveau VLR du mobile fait une
allocation d�un nouveau TMSI pour le mobile (Voir �gure 3.14).
A noter que s�il s�agissait d�un LU ave IMSI Attach, une étape de demande du IMSI est
ajoutée avant l�authenti�cation.
Mahdi Kallel 40
Projet de �n d�études Conception des indicateurs
Fig. 3.14. Allocation TMSI
Le message LOCATION_UPDATING_ACCEPT envoyé du MSC au BSC traduit, de point
de vue interface A, le succès de la procédure LU. Ce message correspond à la transition suivante
de l�état de l�automate :
LU_COMMLUACC
LU_FINMSC BSC
Cette transition fait incrémenter le compteur NbLUACC_NU s�il s�agit d�un LU normale,
NbLUACC_PU s�il s�agit d�un LU périodique. Pour LU avec IMSI Attach l�automate n�implé-
mente pas de compteurs spéci�ques. La déduction du taux de succès de la procédure LU en faisant
le rapport du nombre des messages de succès (ACCEPT) sur le nombre total de demandes est
désormais possible. Nous aurons alors les formules génériques suivantes :
Taux_Succ�es_LU_N =NbLUACC_NU
Nombre_tentativesLU_N(3.23)
Taux_Succ�es_LU_P =NbLUACC_PU
Nombre_tentativesLU_P(3.24)
3.5.4 Echec LU
Comme le cas de la procédure MOC ou MTC, les causes d�échec sont regroupées par partie :
NSS, BSS et MS. En cas d�échec l�automate Astellia fait la transition suivante :
Mahdi Kallel 41
Projet de �n d�études Conception des indicateurs
LU_NLUREJ
LU_FIN
Le message correspondant est LU REJect (Location Updating REJect). Cette transition
fait incrémenter le compteur LU_N_Fail_User s�il s�agit d�un échec causé par l�abonné,LU_N_Fail_BSS s�il s�agit d�un échec d�origine BSS et LU_N_Fail_NSS s�il s�agit d�unéchec d�origine NSS. Ceci concerne le LU normale. Pour le LU périodique ou IA, c�est le même
principe sauf que la nomenclature change. (Au lieu la lettre N pour normale on trouve la lettre
P pour périodique et IA pour IMSI Attach). Le calcul du taux d�échec LU est alors possible en
faisant le rapport nombre de message d�échec sur nombre total de tentatives :
Taux_�echec_LU_USER = NU_N_FAIL_USER+NU_P_FAIL_USER+NU_IA_FAIL_USERNombre_tentativesLU_N+Nombre_tentativesLU_P
Taux_�echec_LU_BSS = NU_N_FAIL_BSS+NU_P_FAIL_BSS+NU_IA_FAIL_BSSNombre_tentativesLU_N+Nombre_tentativesLU_P
Taux_�echec_LU_NSS = NU_N_FAIL_NSS+NU_P_FAIL_NSS+NU_IA_FAIL_NSSNombre_tentativesLU_N+Nombre_tentativesLU_P
On peut véri�er que la somme des taux d�échec NSS, USER et BSS n�est d�autre que la
di¤érence (1-taux de succès) déjà calculé.
3.6 Les indicateurs Handover
Parmi les maillons faibles du suivi de la performance du réseau GSM à partir de l�interface A,
on distingue une limite pour la procédure handover. En e¤et, les messages relatifs aux handovers
intra-BSC ne transitent pas sur l�interface A. Il semble alors évident que seule la mesure de la
performance du handover inter-BSC sera prise en compte par le biais de l�interface A.
3.6.1 Handover interBSC
3.6.1.1 Handover sortant
Le mobile échange avec sa station de base des rapports de mesures sur la qualité du lien radio
et la puissance du signal, si la qualité ou la puissance est au dessous d�un minimum requis, et que
la cellule cible appartient à un autre BSC, alors le BSC origine demande un handover Inter-BSC
auprès du MSC par le biais d�un message de la couche BSSMAP HORQD (HandOver_ReQuireD)
(voir �gure 3.15).
Mahdi Kallel 42
Projet de �n d�études Conception des indicateurs
Fig. 3.15. Handover sortant
Ce message traduit le déclenchement de toute la procédure Handover sortant. Il est possible
de constater que l�état de l�automate ne change pas pendant l�établissement et l�exécution du
handover. IL reste celui de la procédure en cours. IL en résulte que les transitions dans la procédure
handover sortant correspondent à des messages sans changement d�état. A titre d�exemple, la
transition suivante traduit la demande de handover sortant pendant un appel entrant en phase
de communication :
TC_COMM TC_COMMHORQD
BSC MSC
Et la transition suivante traduit la demande de handover entrant pendant un appel sortant
en phase de sonnerie :
TC_SONN TC_SONNHORQD
BSC MSC
L�occurrence du message HORQD est donnée par le compteur EtHoTotal_THorqd. Lenombre de purges sur HO sortant est donné par le compteur NbPURGE_E1_HO. Il enrésulte que le nombre total de demandes de HO sortant est :
Nombre_tentatives_HO_sortant = EtHoTotal_THorqd�NbPURGE_E1_HO (3.25)
Mahdi Kallel 43
Projet de �n d�études Conception des indicateurs
Si le BSC cible a accepté la demande, Le MSC envoie alors au BSC origine un message
HO COMMAND qui le transmet à son tour au mobile pour l�ordonner à exécuter le handover.
Ce message fait incrémenter le compteur EtHoTotal_THocmd. Pendant cette phase de laprocédure, il est utile de concevoir un indicateur qui re�ète la performance de la procédure du
handover en disponibilité des ressources ou bien l�absence de cellules capables de supporter le
mobile dans le BSC cible. Cet indicateur calcule le taux de réponse du BSC cible par rapport au
nombre total des demandes handover. Nous obtenons donc :
Taux_HO_InterBSC_Sortant_Reponse =EtHoTotal_THocmd
Nombre_tentatives_HO_sortant(3.26)
Après sa reception de l�ordre de l�exécution du handover, le mobile va essayer de rejoindre le
nouveau canal sur le BTS cible (voir �gure 3.16).
Fig. 3.16. suite Handover sortant
Si le mobile réussit à atteindre le BTS cible. Alors le MSC envoie un message CLEAR COM-
MAND au MSC. Il résume le succès de la procédure du HO sortant coté interface A origine. Ce
message de la couche BSSMAP fait incrémenter le compteur EtHoTotal_THoClmd. Le tauxde succès du handover sortant est alors le rapport de l�occurrence de ce message sur le nombre
total de tentatives HO sortant. Soit :
Taux_HO_InterBSC_Sortant_Succ�es =EtHoTotal_THoClmd
Nombre_tentatives_HO_sortant(3.27)
3.6.1.2 Handover entrant
Un handover est considéré comme entrant pour la cellule cible. Dans cette partie, nous n�allons
tenir compte que les messages qui transitent à travers l�interface A dans le BSS cible. Le MSC
transmet le message HOREQ (HandOver_REQuest) au BSC cible (voir �gure 3.17).
Mahdi Kallel 44
Projet de �n d�études Conception des indicateurs
Fig. 3.17. Handover entrant
L�état de l�automate fait donc la transition suivante :
VIDE HO_TCH_REQHOREQ
MSC BSC
L�occurrence de cette transition sur l�interface A traduit le nombre de demandes de handover
entrant. Et puisqu�elle fait incrémenter le compteur NbHORQ_HO et que le nombre de purges
sur le HO entrant est donné par NbPURGE_E2_HO, nous pouvons conclure donc que :
Nombre_tentatives_HO_entrant = NbHORQ_HO �NbPURGE_E2_HO (3.28)
Ensuite, le BSC cible active un canal radio sur la BTS demandée. Si cette action s�est déroulée
avec succès, le BSC envoie un message d�acquittement accompagné d�une commande d�exécution
du handover. Dans ce cas, l�état de l�automate fait la transition suivante :
HO_TCH_RACHORAC
BSC MSCHO_TCH_REQ
Cette transition fait incrémenter le compteur NbHORQACK_HO. Si cette transitionn�abouti pas, alors on peut conclure qu�il y a un problème de disponibilité de ressources radios.
Mahdi Kallel 45
Projet de �n d�études Conception des indicateurs
L�idées été de concevoir un indicateur qui met en évidence ce problème. C�est donc le rapport de
l�occurrence du message HORAC sur le nombre total de tentatives des HO sortants, soit :
Taux_HO_InterBSC_entrant_Reponse =NbHORQACK_HO
Nombre_tentatives_HO_entrant(3.29)
Ensuite, le BTS cible attend le mobile. Si ce dernier réussit à accéder au canal déjà alloué
sur l�interface air, alors le BTS le détecte et envoie un message HO DETECTON au BSC qui le
transmet à son tour au MSC dans un message HODET (HO DETection) de la couche BSSMAP
(voir �gure 3.18).
Fig. 3.18. Suite handover entrant
L�automate Astellia change d�état selon la transition suivante :
HO_TCH_DETHODET
BSC MSCHO_TCH_RAC
Cette transition fait incrémenter le compteur NbHODET_HO. Dans le cas échéant, c�est-à-dire que le message n�aboutit pas, on peut déduire que le mobile n�a pas pu rejoindre la nouvelle
cellule à cause d�un problème radio. Concevoir un taux de détection de handover pouvait aider à
analyser les problèmes radio. Cet indicateur est le rapport du nombre des messages de détection
sur le nombre total de réponse du BSS cible, soit :
Mahdi Kallel 46
Projet de �n d�études Conception des indicateurs
Taux_HO_InterBSC_entrant_Detect =NbHODET_HO
Nombre_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 procédure du handover sortant a été
exécutée avec succès. Ce message engendre la transition suivante :
HO_TCH_FINHOCMP
BSC MSCHO_TCH_DET
Cette transition fait incrémenter le compteur NbHOCMP_HO. Nous pouvons alors conce-voir l�indicateur du taux de succès du handover entrant comme suit :
Taux_HO_InterBSC_Entrant_Succ�es =NbHOCMP_HO
Nombre_tentatives_HO_entrant(3.31)
3.6.2 Handover intraBSC
Le seul message qui transite à travers l�interface A pendant la procédure du handover intra
BSC est le message HANDOVER_PERFORMED qui est envoyé par le BSC cible au MSC à la
�n d�un handover intra-BSC é¤ectué avec succès.
Ce message contient des informations tels que la cause du handover. Il est possible de conce-
voir un indicateur de répartition des causes du handover. Mais malheureusement, il y avait un
problème avec le �chier .XLH qui contient ce type d�informations. Ce �chier fait apparaître des
valeurs erronées. L�équipe QDF a contacté le fournisseur Astellia qui en a pris charge.
3.7 Les indicateurs SMS
Il existe deux scénarios de l�envoi d�SMS : SMS entrant ou SMS sortant. Pour l�SMS sortant,
le mobile envoi son SMS dans un message de type RP-DATA (voir �gure 4.19).
Mahdi Kallel 47
Projet de �n d�études Conception des indicateurs
Fig. 3.19. SMS Sortant
Ce message constitue l�événement déclencheur de la procédure SMS, nous allons donc prendre
l�occurrence de ce message comme étant le nombre de total d�SMS envoyés par le mobile. Ce
message engendre la transition suivante :
MOSMS_SUBSMS_SUBMIT
HOCMPBSC MSC
MOSMS_EST
Cette transition fait incrémenter le compteur SmsSubmit. Le nombre total de SMS sortantsest alors :
Nb_SMS_OC = SmsSubmit (3.32)
Si le message arrive au SMSC (SMS Center) et ce dernier envoi un acquittement positif, le
MSC retransmet cet acquittement au BSC qui le retransmet à son tour au mobile. Il s�agit du
message RPack. (Voir second message encerclé dans la �gure). Ce message engendre la transitionsuivante :
MOSMS_SUB_FINRPack
MSC BSCMOSMS_SUB
Cette transition fait incrémenter le compteur SmsSubmit_RPack. Il en résulte que le tauxde succès de message sortant est donné par :
Mahdi Kallel 48
Projet de �n d�études Conception des indicateurs
Taux_Succ�es_SMS_OC =SmsSubmit_RPackNb_SMS_OC
(3.33)
Le même principe est pour le transfert du SMS entrant sauf que le sens des messages s�inverse
et le nom des compteurs change. La transition qui déclenche la procédure au niveau de l�interface
A est la suivante
MTOSMS_DELSMS_DELIVER
MSC BSCMTSMS_EST
Cette transition fait incrémenter le compteur SmsDeliver. Le nombre total de SMS sortantsest alors :
Nb_SMS_TC = SmsDeliver (3.34)
Si le message arrive au mobile et ce dernier envoi un acquittement positif, alors le BSC
retransmet cet acquittement au MSC qui le retransmet à son tour au SMSC (SMS Center). Il
s�agit du message RP_MO_ack. Ce message engendre la transition suivante :
MOSMS_SUB_FINRP_MO_ack
MSC BSCMOSMS_DEL
Cette transition fait incrémenter le compteur SmsDeliver_RPack. Il en résulte que le tauxde succès de message entrant est donné par :
Taux_Succ�es_SMS_TC =SmsDeliver_RPackNb_SMS_TC
(3.35)
Il existe des scénarios et des messages d�erreurs si la procédure de transmission d�un SMS
n�abouti pas. Il y a un ensemble de transitions d�échec qui font incrémenter des compteurs d�échec.
Comme on a vu pour les autres procédures, les causes d�échec peuvent être groupées par
partie ; BSS ou NSS. Cela nous permet de concevoir des indicateurs d�échec à partir des compteurs
d�échec associés.
Lorsque l�échec est du à un problème BSS le compteur SmsDeliver_Fail_BSS est incré-menté pour le SMS entrant et le compteur SmsSubmit_Fail_BSS est incrémenté pour le SMSsortant. Le taux d�échec de transmission SMS du à un problème BSS est donné par :
Taux_Echec_SMS_BSS =SmsDeliver_Fail_BSS + SmsSubmit_Fail_BSS
Nb_SMS_TC +Nb_SMS_OC(3.36)
Lorsque l�échec est du à un problème NSS le compteur SmsDeliver_Fail_NSS est incré-menté pour le SMS entrant et le compteur SmsSubmit_Fail_NSS est incrémenté pour le SMSsortant. Le taux d�échec de transmission SMS du à un problème NSS est donné par :
Mahdi Kallel 49
Projet de �n d�études Conception des indicateurs
Taux_Echec_SMS_NSS =SmsDeliver_Fail_NSS + SmsSubmit_Fail_NSS
Nb_SMS_TC +Nb_SMS_OC(3.37)
3.8 Des indicateurs Divers
3.8.1 Le double appel
Si quelqu�un appelle un abonné en cours de communication, l�appel sera mis en attente. Si
l�appelé décide de basculer entre les deux appels qui lui sont arrivés, il doit immédiatement mettre
l�un d�eux en garde car il ne peut pas faire deux communications à la fois. Cette procédure est
appelée le double appel. Elle peut être activée en communication sortante comme elle peut être
activée en communication entrante. La transition qui correspond à une mise en attente pour un
appel sortant est :
OC_CALLWAITINGMOSMS_SUB_FIN
ALERT
BSC MSCOC_COMM
Cette transition fait incrémenter le compteur NbHOLDACK_OC. Et la transition quicorrespond à une mise en attente pour un appel entrant est :
TC_CALLWAITINGMOSMS_SUB_FIN
ALERT
MSC BSCTC_COMM
Cette transition fait incrémenter le compteur NbHOLDACK_TC.Nous pouvons doncconcevoir l�indicateur :
Nombre_MiseAttente = NbHOLDACK_OC +NbHOLDACK_TC (3.38)
L�appelé a le choix : soit de basculer entre les deux communications soit de maintienir la
communication en cours et négliger celle qui est arrivée jusqu�à ce que ce dernier termine de
sonner. Dans ce cas l�état de l�automate rentre à son état d�origine de communication OC_COMM
et la transition est la suivante pour l�appel sortant :
RELCMP
MSC BSCOC_CALLWAITING OC_COMM
Cette transition fait incrémenter le compteur NbRETACK_OC. De même, le compteur
NbRETACK_TC est incrémenté en cas d�appel entrant. Le nombre de basculement entre appels
est alors donné par :
Nombre_double_appel = (NbHOLDACK_OC +NbHOLDACK_TC)�(NbRETACK_OC +NbRETACK_TC)
Mahdi Kallel 50
Projet de �n d�études Conception des indicateurs
3.8.2 Connexion SCCP
Avant chaque transfert de messages entre MSC et BSC, une connexion SCCP est requise. Le
SCCP est un protocole qui garantie le transfert �able de signalisation entre deux n�uds sur le
réseau se signalisation SS7.
Astellia n�implémente sur son analyseur de protocole que les connexions SCCP pour les pro-
cédures LU, MTC et MOC et ne capte que les messages de type CC (Connection Con�rm) ou
CREF (Connection REFused). A partir de là, Nous avons eu l�idée de concevoir un indicateur qui
calcule le taux d�échec de la connexion SCCP pour les procédures précitées. Il s�agit du rapport de
nombre de refus de connexions sur le nombre de demande total de connexions. Chaque message CC
fait incrémenter les compteurs NbCC_LUia, NbCC_LUnu, NbCC_LUpu, NbCC_OCet NbCC_TC respectivement pour les procédures LU IMSI Attach, LU normal, Lu périodique,
MOC et MTC. Chaque message CREF fait incrémenter les compteurs NbCREF_LU et Nb-CREF_OCTC respectivement pour les procédures LU, MTC et MOC ensembles. Il en résulte
que l�indicateur du taux de refus SCCP a comme formule :
Taux_�echec_Connexion_SCCP =NbCREF_OCTC +NbCREF_LU
Nombre_ConnexionSCCP(3.39)
3.8.3 Indicateur de tra�c
Il est important de savoir l�évolution du tra�c écoulé dans le temps par objet (Cellule, BSC,
MSC). Pour chaque circuit (IT MIC), il est possible de dé�nir le taux d�occupation relatif. En
introduisant �pour représenter ce taux, il est dé�ni de la manière suivante :
� =Na �Da24� 3600 (3.40)
Dans cette expression Na représente le nombre d�appels passés ou reçus par jour dans le
circuit concerné, Da représente la durée moyenne d�un appel en secondes. En�n le produit 24
�3600 représente la durée d�une journée en secondes. On dé�nit ainsi l�occupation du circuit.L�unité retenue pour est l�Erlang. Ainsi un tra�c de 1 Erlang (1 E) correspond à un circuit
occupé 24 heures sur 24.
Du coté de la capture sur l�interface A, la durée d�occupation d�un circuit est calculée sur
chaque ITs des MICs entre BSC et MSC après transcodage. Elle est calculée pendant la procédure
MOC ou MTC entre le message CONNECT et le message DISCONNECT.
Dans cette optique, le �chier .XLT qui contient la répartition du tra�c sur chaque IT de
chaque MIC semble le plus intéressant (Voir �gure 3.20) :
Mahdi Kallel 51
Projet de �n d�études Conception des indicateurs
Fig. 3.20. Répartition du tra�c
Dans ce tableau Dmoy conv correspond à Da et Nb conv correspond à Na.Il en résulte que le
taux d�occupation d�un circuit est donné par :
� =Nbconv �Dmoyconv
24� 3600 (3.41)
Les indicateurs conçu doivent être mis en pratiques pour pouvoir les visualiser. Leurs im-
plémentation logicielle dans un outil informatique s�avère donc nécessaaire est interressante. Le
chapitre suivant va décrire l�application informatique développée en commençant par la concep-
tion informatique ensuite en passant vers la réalisation.
Mahdi Kallel 52
Chapitre 4
Implémentation logicielle
Projet de �n d�études Implémentation logicielle
4Implémentation logicielle
Ce chapitre décrit la mise en oeuvre de l�outil informatique développé. Il commence par
expliquer les choix techniques des langages de programmation et des outils utilisés. Ensuite,
il s�intéresse à la conception informatique. En�n il cite une description des résultats aboutis
approuvés par quelques captures d�écrans.
4.1 Conception
4.1.1 Entrée/sortie et architecture de l�application
Cette application doit mettre aux indicateurs clefs de performances conçus à partir de capture
sur l�interface A une utilité pratique. Elle doit permettre de suivre l�évolution de ces indicateurs
par cellule, BSC, MSC et LAC. Cette évolution est non seulement par objet, mais aussi dans le
temps. Pour se faire, les données qui existent dans les �chiers générés par captures de l�analyseur
de protocole sont les sources de base des données. L�outil doit les traiter de façon harmonique
avec l�architecture de la base de données dans laquelle elles seront stockées. Après le traitement
et la centralisation des données, le programme doit savoir exécuter les requêtes convenables et
e¤ectuer les calculs nécessaires pour pouvoir a¢ cher les courbes et les statistiques souhaitées.
Avant d�avancer dans les détails de la conception, il faut tout d�abord choisir une architecture
convenable pour notre application. L�architecture choisie était l�architecture client-serveur (2-
tiers). Les applications complexes peuvent tirer pro�t d�une base de données et accéder aux
informations qu�elle contient en envoyant des requêtes SQL à un serveur pour lire et écrire les
Mahdi Kallel 54
Projet de �n d�études Implémentation logicielle
données. Dans ce cas, la base de données fonctionne dans un processus indépendant de celui
de l�application, et parfois sur une machine di¤érente. Les composants permettant l�accès aux
données sont séparés du reste de l�application.
Fig. 4.1. Architecture client-serveur
Plusieurs utilisateurs de l�application peuvent l�utiliser simultanément. Un des inconvénients
de l�architecture deux-tiers est que la logique chargée de la manipulation des données et de
l�application des règles métiers est incluse dans l�application elle-même. Cela pose un problème
lorsque plusieurs applications doivent partager l�accès à une base de données.
Face à la multitude d�architectures informatiques existantes et des moyens de développement
associés, nous devons adopter une solution répondant aux besoins et à la nature même de l�ap-
plication. Pour choisir la bonne solution, il faut se baser sur des critères de choix qui sont dans
notre cas :
- Centraliser les données pour une multi-utilisation ;
- Alléger l�application du coté du client ;
- Fournir une interface homme machine conviviale.
L�architecture client-serveur, elle, répond à ces besoins, pour cela nous l�avons donc choisi.
En se basant sur l�architecture précédente et sur les entrées-sorties du système, nous avons
pu dégager le schéma synoptique suivant :
4.1.2 Choix de l�environnement de développement
Le choix du logiciel de développement est en fonction des exigences de l�application et de
degré de ses performances. Dans le cadre de cette application, nous avons besoin d�une part de
la gestion des �chiers et d�autre art d�un stockage des données de ces �chiers dans une base
de données. En outre, on a besoin de l�exécution des requêtes SQL pour l�a¢ chage de certains
résultats. Plusieurs logiciels de développement peuvent être utilisés ; tels que Windev, Visual
Basic, Delphi et visual C++ qui o¤rent tous presque les mêmes privilèges. Par ailleurs en tenant
compte des fonctionnalités o¤ertes par Windev à savoir la souplesse de traitement des �chiers et
la manipulation des bases de données, nous avons choisi de retenir ce langage de programmation.
4.1.2.1 Windev (w-Language)
WinDev 10 est un atelier de génie logiciel qui inclut plusieurs outils et modules tels que le
WDMap (Visionneur Hyper File), le WDOutil (outils d�administration Hyper File), le WDTrans
Mahdi Kallel 55
Projet de �n d�études Implémentation logicielle
Fichiers TXT
Préparation etcentralisation des
données
Extraction Centralisation
DB SQL Server Output
Reporting enformat text
Graphes
FichiersExcel
ApplicationWindev
Input
Fig. 4.2. Architecture du système
(gestionnaire de transaction), etc.
Parmi les nombreux atouts de WinDev �gure le W-langage qui est le langage de dévelop-
pement utilisé. C�est un langage de la cinquième génération (L5G), donc il est à la fois assez
simple et puissant. De plus, et c�est le plus important pour notre projet, WinDev a la capacité
de s�interfacer avec des codes écrits avec d�autres langages tels que Java, C, C#, Visual Basic,
Cobol, Fortran, etc. En�n, et c�est un plus pour notre outil, WinDev permet de créer des fenêtres
conviviales dont la gestion, la manipulation et la programmation sont assez simpli�ées.
Les caractéristiques que nous venons de citer sont, de fait, à la base du choix de WinDev 10
comme environnement de développement.
4.1.2.2 Le SGBD SQL SERVER 2000
Une base de données ( eng data base) est un ensemble structuré de données logiquement
reliées entre elle et enregistrées sur des supports accessibles par l�ordinateur, représentant des
informations du monde réel et pouvant être interrogées et mises à jour simultanément et de façon
sélective.
SQL SERVER est un système de gestion de base de données. A l�aide de ce logiciel nous
pouvons gérer nos informations.
Dans le cadre de notre projet, nous avons choisi SQL SERVER pour stocker et gérer des
données contenues dans les �chiers car il permet l�accès à la base à distance. Dans cette base on
distingue toutes les tables nécessaires pour l�exécution de l�application.
Mahdi Kallel 56
Projet de �n d�études Implémentation logicielle
4.1.3 Conception opérationnelle de l�application
La conception opérationnelle est la partie dans laquelle sont dressé les solutions prévues pour
le fonctionnement des di¤érents modules spéci�és dans le cahier des charges du projet. (Voir
annexeB pour mieux comprendre la conception par le language UML)
4.1.3.1 Modèle de cas d�utilisation (Use Cases)
L�intérêt des Use Cases est de traiter l�interaction entre les acteurs et le système d�une manière
formelle. Selon les cas d�utilisation nous pouvons déduire plusieurs scénarios dont la détermination
dépend essentiellement de ce que l�utilisateur attend du système. Compte tenu du besoin de notre
application, il s�avère que les acteurs éventuels se réduisent à un seul Utilisateur-Administrateur.
La �gure ci-après illustre le scénario complet d�une utilisation complète du système. On trouve
donc la fonction primordiale d�insertion des données dans la base de données, du suivi de l�évo-
lution des indicateurs de performances dans le temps et par objet, et en�n de la génération du
rapport.
Générer le rapport
Suivre l’évolution desindicateurs par objet
Suivre l’évolution desindicateurs dans le temps
Choisirl’indicateur
Choisir la duréed’observation
Choisir l’objet
Choisir la dated’observation
<<include>>
<<include>>
Choisirtype de courbe
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Insertion desdonnée dans la
baseCréation de la base
de donnée
Charger la topologiedu réseau
<<include>>
<<include>>
Fig. 4.3. Diagramme de cas d�utilisation
4.1.3.2 Diagramme de séquences
Le diagramme de séquences illustre le fonctionnement du système dans le temps. Il permet
d�analyser l�avancement chronologique des interactions entre les objets du système et de mieux
comprendre son fonctionnement interne. Le diagramme est structuré de la manière suivante : Le
diagramme possède un axe des temps dirigé du haut vers le bas. Chaque objet étudié dispose
d�une ligne de vie (ligne verticale pointillée). Sur ces lignes de vie, des périodes d�activité sont
Mahdi Kallel 57
Projet de �n d�études Implémentation logicielle
indiquées par des rectangles �ns dont les extrémités représentent le début et la �n de l�activité.
Les messages échangés entre les di¤érentes entités sont représentés par des �èches horizontales
orientées de l�émetteur vers le destinataire. Lorsque le message possède un temps de propagation
non négligeable, les �èches sont alors obliques.
Diagramme de séquences d�insertion des données dans la base : L�utilisateur
sélectionne les �chiers à charger dans la base de donnée. L�outil d�application se charge alors de
faire des traitements nécessaires sur ces �chiers, et il envoi les requêtes appropriées au serveur de
base de donnée. Ce dernier exécute les requêtes. Les entités sont : l�utilisateur, l�outil d�application
et le serveur application.
Utilisateur L’outild’application Serveur de base de données
Lancer l’application
Interface lancée
Choisir le f ichier à charger dans la base
Fichier choisi
Lancer le traitement des fichiersTraiter les fichier
Construire les requêtes d’insertion Exécuter les requêtes
Requêtes éxcécutées
Données insérées
Fig. 4.4. Diagramme de séquences d�insertion des données dans la base
Diagramme de séquence de génération des courbes Ce diagramme décrit le dérou-
lement des étapes nécessaires à la génération des courbes. L�utilisateur commence par choisir le
type de la courbe, choisir l�indicateur et choisir la date de capture. Il pouvait personnaliser ces
paramètres.
L�outil d�application, lui, �ltre les données. Il construit les requêtes de sélections appropriées
selon les paramètres �xées par l�utilisateur. Il les envoie au serveur base de donnée qui les exé-
cute et renvoie les résultats à l�outil. Celui-ci fait la mise en forme des courbes et les a¢ che à
l�utilisateur.
4.2 Réalisation
Nous avons essayé, dans la réalisation de ce projet, d�automatiser le plus possible la phase de
post traitement. C�est un ensemble d�opérations qui permettent en�n d�insérer les données dans
la base de donnée.
Le menu dédié à la phase de traitement et de la centralisation est le menu « traitement » .
La �gure suivante montre ce menu et les sous menus rattachés.
Mahdi Kallel 58
Projet de �n d�études Implémentation logicielle
Utilisateur L’outild’application Serveur de base de données
Lancer l’appliction
Interface lancée
Choisir les paramètres de l’affichage
Paramètres choisis
Demander l’affichage des courbes Filtrage des données
Construire les requêtes de sélection Exécution des requêtes
Résultat des requêtes de selectionMise en forme des courbes
Courbes affichées
Fig. 4.5. Diagramme de séquence de génération des courbes
L�action de création des tables de la base de données doit être faite une seule fois. C�est-à-dire
qu�il ne faut créer les tables que si elles n�étaient pas crées.
En cliquant sur le sous menu « insertion des donnée dans la base » , une fenêtre qui contient
deux anglets s�ouvre, l�un pour charger la topologie du réseau et l�autre pour faire le traitement
des �chiers.
Mahdi Kallel 59
Projet de �n d�études Implémentation logicielle
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 Implémentation logicielle
Après chargement des données dans la base de données, nous pouvons faire les analyses
souhaitées. Pour ce faire, il existe deux menus, l�un pour faire une analyse par objet : cellule,
BSC, MSC et LAC pour une journée donnée. Et l�autre pour faire une analyse dans le temps
pour chaque objet. La fenêtre pour faire une analyse par cellule est la suivante.
Mahdi Kallel 61
Projet de �n d�études Implémentation logicielle
Ici nous devons choisir le BSC pour lequel on souhaite a¢ cher les cellules, nous devons choisir
l�indicateur à calculer et choisir la date de capture, et c�est optionnel de choisir le type de graphe.
En appuyant sur le bouton a¢ cher, la courbe correspondante aux paramètres �xés s�a¢ che.
Mahdi Kallel 62
Projet de �n d�études Implémentation logicielle
La même procédure se fait si on désire a¢ cher les statistiques par BSC, MSC et LAC. La
�gure suivante montre une analyse par BSC pour l�indicateur de coupure d�appel :
Nous pouvons modi�er les paramètres de la courbe en faisant un click droit sur la courbe. On
peut inverser les axes, faire une légende, modi�er la police, changer le type de graphe, imprimer
et enregistrer le graphique.
Le menu analyse dans le temps permet de montrer une évolution dans le temps d�un indicateur
donné sur un objet donné : cellule, BSC, MSC et LAC. Par exemple, la �gure suivante montre
l�évolution du taux de succès SMS sur une période donnée sur un MSC donné
Mahdi Kallel 63
Projet de �n d�études Implémentation logicielle
En�n, après que l�analyse est faite, nous pouvons générer un rapport de QoS en sélectionnant
le menu « �chier » ensuite l�option «générer le rapport » .
Mahdi Kallel 64
Projet de �n d�études Implémentation logicielle
L�implémentation logicielle des indicateurs conçus a permi de suivre leurs évolutions par
cellule, BSC, MSC ou LAC. La sélection des données et leurs rassemblements et l�a¢ chage des
statitistiques auraient pu être plus longs à manipuler s�ils étaient manuels. L�implémentation
logicielle fait gagner beaucoup de temps.
Le chapitre suivant va détailler la validation de quelques indicateurs ainsi que quelques études
de cas.
Mahdi Kallel 65
Chapitre 5
Validation et étude de cas
Projet de �n d�études Validation et étude de cas
5Validation et étude de cas
L�objectif de ce chapitre est de valider quelques indicateurs conçus, en les comparant avec
leurs homologues du coté de l�OMC. La validation est d�une importance extrême dans la mesure
où elle met en évidence l�objectivité de nouveaux indicateurs.
Le traitement de quelques exemples et de cas réels en analysant leurs causes et leurs e¤ets
éventuels permet, entre autre, de donner à ces indicateurs une importance technique dans la
pratique.
5.1 Validation
5.1.1 Choix des indicateurs à valider
Vu le nombre relativement élevé des indicateurs conçus, le choix était de valider seulement les
indicateurs qui re�ètent la performance globale de chaque procédure. Autrement dit, pour chaque
procédure GSM, l�indicateur qui résume le succès et / ou l�échec de la procédure est identi�é pour
être validé. Bien entendu, ceci ne voulait pas dire que le reste des indicateurs n�est pas apte pour
être validé.
En conséquence de quoi, les indicateurs à valider sont :
- Succès_établissement_MOC _Tech
- Succès_établissement_MTC _Tech
- Coupure_Appel
- Taux_Succès_LU_Tot
- Taux_HO_InterBSC_Sortant_Succès
Mahdi Kallel 67
Projet de �n d�études Validation et étude de cas
- Taux_HO_InterBSC_Entrant_Succès
- Taux_Succès_SMS_OC
5.1.2 Aperçu sur les outils utilisés pour la validation
OTT dispose d�un ensemble d�outils fournis par les deux constructeurs Alcatel et Siemens
permettant d�explorer les di¤érentes données de qualité de service du réseau, que se soit des
données OMC ou des données équipements. Les principaux outils sont RNO et SPOTS.
5.1.2.1 RNO d�Alcatel
L�outil RNO (Radio Network Optimisation) est un logiciel de gestion des équipements AL-
CATEL qui permet le management en temps réel de tout le réseau. Outre les fonctionnalités
classiques à savoir la gestion des alarmes, le suivi et la con�guration des composants physiques
et logiques du réseau, ce logiciel permet :
- Une analyse totalement informatisée des mesures de performance.
- La visualisation et l�export des données sur la con�guration software et hardware du
réseau.
- La détection des problèmes liés à la qualité de service du réseau et la localisation des
questions les plus urgentes.
- Le choix des actions correctives à entreprendre pour améliorer la QoS.
- L�optimisation de la recherche des ressources radio.
- Fournir les rapports de la QoS.
Cependant RNO présente un ensemble de limitation qui se résume dans les points suivants :
- Il est Opérationnel que pour un seul constructeur à savoir Alcatel.
- Il présente un retard au niveau de l�import des données, ce qui oblige parfois les ingé-
nieurs à utiliser d�autres outils. Le schéma synoptique d�un tel système est donné par la �gure
5.1.
Mahdi Kallel 68
Projet de �n d�études Validation et étude de cas
Fig. 5.1. RNO system (Alcatel)
5.1.2.2 SPOTS
L�outil SPOTS de SIEMENS permet de :
- Traiter les données par famille de compteurs NSS, BSS, BTS ;
- Fournir des rapports de QoS ;
- Détecter les problèmes du réseau par la con�guration d�alerteur de QoS à temps réel.
Les principaux problèmes à SPOT se résument dans les points suivants :
- Un outil opérationnel pour un seul constructeur à savoir SIEMENS ;
- Il n�existe pas de traitement par Heure de Pointe ;
- Il n�existe pas d�édition de zones.
5.1.3 Validation de Succès_établissement_MOC _Tech
Connu sous le nom de CSSR_MOC (Call Setup Sucess Rate), cet indicateur détermine le
taux de succès de l�établissement d�appel sortant. Etant donné qu�il faut comparer des choses
comparables, Il a été un peu di¢ cile de voir l�équivalent exact de cet indicateur sur RNO ou
SPOTS. Du coté de RNO, il ne donne pas de taux de succès d�établissement d�appel sortant.
En revanche il accumule les taux d�échecs BSS (radio ou équipements BSS). En général, Utiliser
RNO revient à traiter des problèmes radio.
Coté SPOTS, le problème était qu�il adopte une approche qui dé�ni l�établissement d�appel
comme étant tous les messages échangés avant l�a¤ectation du canal de tra�c TCH.
Contrairement à la notre qui dé�ni l�établissement comme étant tous les messages échangés
avant le début de la conversation proprement dite.
Mahdi Kallel 69
Projet de �n d�études Validation et étude de cas
Puisqu�il s�est avéré impossible de comparer l�indicateur en question avec l�indicateur SPOTS
prédé�nit, il a été nécessaire de se référencier à la documentation SIEMENS pour voir la signi�-
cation des compteurs brutes pour pouvoir les adapter à la formule qu�on désire valider.
Les compteurs trouvés étaient des compteurs MSC, c�est-à-dire qu�ils sont implémentés du coté
du MSC. Par conséquent, on va suivre l�évolution des indicateurs par MSC lors de la comparaison.
La formule de Succès_établissement_MOC _Tech conçue sur l�interface A est :
Succ�es_�etablissement_MOC_Tech =NbASCMP_OC
Nombre_Appel_MOC(5.1)
Où NbASCMP_OC désigne le nombre de messages de la �n d�a¤ectation d�un canal de
tra�c et Nombre_Appels_MOC désigne le nombre total de tentatives d�établissement d�un appel
sortant donné par le nombre d�occurrence du message CM_SERVICE REQUEST envoyé par le
BSC au MSC.
Il a fallu chercher le compteur SIEMENS qui est incrémenté suite à la réception de ce message
par le MSC concerné. Le compteur est celui encerclé dans la �gure 5.2 [8].
Fig. 5.2. le compteur SIEMENS de CM_SERVICE_REQUEST
SPOTS donne aux indicateurs SIEMENS une nomenclature dédiée. L�équivalent de ce message
en SPOTS est CA_MORIG Nr.En suivant la même démarche pour le compteur NbASCMP_OC, on trouve que l�équivalent
de ce compteur en SPOTS est CSTCHMOR Nr.
Mahdi Kallel 70
Projet de �n d�études Validation et étude de cas
L�étape suivante était de comparer les valeurs du rapport CSTCHMOR Nr/CA_MORIG Nr
avec celles de l�indicateur à valider rassemblés par MSC. L�écart était considérable !
Par la suite, il s�est avéré que cet écart est dû au fait que le compteur CA_MORIG Nrs�incrémente aussi à chaque fois où le MSC fait la redirection de l�appel vers une autre destination
lorsqu�il y a un renvoie d�appel. Il en résulte, en terme de nombre, qu�il y avait une di¤érence
considérable entre CA_MORIG Nr de SIEMENS et Nombre_Appels_MOC de l�interface A.Pour corriger cet écart, il a fallu trouver le compteur MSC SIEMENS qui compte le nombre de
renvoie d�appel et de le faire retrancher du compteur CA_MORIG Nr : C�était le compteurCS_EFOMOR Nr. Le résultat de la comparaison était le suivant sur l�objet MSCx classé par
jour :
CSSR_MOC_InterfaceA Vs CSSR_MOC_SPOTS
0,50,55
0,60,65
0,70,75
0,80,85
0,90,95
1
04/04/2
007
05/04/20
07
06/04/2
007
07/04
/2007
08/04/2
007
09/04
/2007
Jour
CS
SR
_MO
C
CSSR_MOC_SPOTSCSSR_MOC_InterfaceA
Fig. 5.3. Résultat de la comparaison CSSR_MOC
Il est clair qu�il existe une petite di¤érence . Cette petite di¤érence négligeable est due à un
petit retard ou avance de part ou d�autre des captures sur l�interface A ou des captures sur le
MSC.
5.1.4 Validation de Succès_établissement_MTC _Tech
La même démarche était suivie pour valider cet indicateur. La formule de cet indicateur
conçue sur l�interface A est :
Succ�es_�etablissement_MTC_Tech =NbASCMP_TC
Nombre_Appel_MTC(5.2)
Le Nombre_Tentatives_MTC est donnée par le nombre d�occurrence du message PAGIN-
GRESPONSE envoyé par le BSC au MSC. Après la consultation de la documentation SIEMENS,
Le compteur SPOTS relatif était REC_PRMTE Nr [10].De même pour NbASCMP_TC, le compteur SPOTS équivalent étaitCSTCHMTERNr[10].
En calculant le rapport CSTCHMTER Nr/RECPRMTE Nr sur l�objet MSCx et en le comparant
avec les valeurs de l�indicateur interface A en question, les résultats suivants ont été obtenus :
Mahdi Kallel 71
Projet de �n d�études Validation et étude de cas
CSSR_MTC_InterfaceA Vs CSSR_MTC_SPOTS
0,50,55
0,60,65
0,70,75
0,80,85
0,90,95
1
04/04/2
007
05/04/2
007
06/04
/2007
07/04/2
007
08/04/2
007
09/04
/2007
Jour
CS
SR
_MTC
CSSR_MTC_SPOTSCSSR_MTC_InterfaceA
Fig. 5.4. Résultat de la comparaison CSSR_MTC
5.1.5 Validation de coupure_Appel
Il a été impossible de valider l�indicateur coupure_Appel par le biais de SPOTS dans la
mesure où ce dernier considère que la communication commence juste après l�a¤ectation d�un
canal TCH, c�est-à-dire après le message ASSIGNMENT_ COMPLETE. Cette approche était
di¤érente de celle adoptée pour la conception de l�indicateur coupure_Appel sur l�interface A, et
qui considère que la communication commence après que l�appelé ait décroché dans le vrai sens
physique de l�action, donc après le message CONNECT_ACK.
D�autre part, dégager les compteurs bruts SIEMENS comme on l�a fait pour la validation du
Call Setup a été inutile vu que SIEMENS n�implémente pas un compteur pour ce message.
Ensuite, il s�est avéré que RNO adopte la deuxième approche. Cependant il ne comptabilise
que le taux de coupure d�appel suite à une cause BSS (radio ou équipements). C�est la raison
pour laquelle, seul l�indicateur Coupure_Appel_BSS pouvait être validé.
Le résultat de comparaison entre les valeurs de cet indicateur prises sur BSCx et �ltrées par
jour, et les valeurs de l�indicateur RNO Call_drop_rate (QSCDR) est illustré par la �gure 5.5.
Mahdi Kallel 72
Projet de �n d�études Validation et étude de cas
Call drop RNO Vs Call drop interface A BSS radio
0,00%0,10%0,20%0,30%0,40%0,50%0,60%0,70%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
call
drop
Call drop RNO
Call drop BSS InterfaceA
Fig. 5.5. Résultat de la comparaison Call drop
5.1.6 Validation de l�indicateur Taux_Succès_LU_Tot
Il est plus rigoureux de valider les indicateurs de mise à jour de localisation par le biais des
indicateurs MSC puisque l�exécution de la procédure se fait au c�ur du réseau entre le MSC, le
VLR et/ou le HLR. La formule de l�indicateur conçu était la suivante :
Taux_Succ�es_LU_Tot =NbACC_PU +NbACC_NU
Nombre_tentativesLU_P +Nombre_tentativesLU_N(5.3)
Il est à noté que la mise à jour de localisation avec IMSI Attach n�est pas prise en compte
dans cette formule car l�automate Cigale n�implémente pas de compteurs relatifs.
En se basant sur la documentation SIEMENS, il s�est avéré que le compteur SPOTS RQ_LCNr calcule le nombre de demande de mise à jour de localisation (LUREQ) non seulement normaleet périodique mais aussi par IMSI Attach. Par conséquent il a fallu chercher le compteur SIEMENS
qui calcule le nombre de demandes pour la mise à jour de localisation avec IMSI Attach et le
faire retrancher du compteur RQ_LC Nr pour adapter de part et d�autre les formules des deux
indicateurs à comparer, le compteur était RQ_LCIMAT Nr [10].D�autre part le compteur SPOTS qui indique le nombre des mises à jour de localisations
normales et périodiques acceptées est SUCC_RQLC Nr.En�n, Le résultat de comparaison entre les valeurs de l�indicateur Taux_Succès_LU_Tot
prises sur MSCx et �ltrées par jour, et les valeurs du rapport SUCC_RQLC Nr / (RQ_LC Nr -
RQ_LCIMAT Nr) est illustré par la �gure 5.6.
Mahdi Kallel 73
Projet de �n d�études Validation et étude de cas
Lu_SUCC SPOTS Vs LU SUCC Interface A
94,00%95,00%96,00%97,00%98,00%99,00%
100,00%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
Jour
LU_S
UCC
MSC
08
LU_SUCC SPOTSLU_SUCC Interface A
Fig. 5.6. Résultat de la comparaison LU_SUCC
Les valeurs comparées sont proches, sauf pour le deuxième jour où il y avait une di¤érence
relative. La cause et que les durées d�observations de part et d�autres n�étaient pas exactement
confondues.
5.1.7 Validation du TauxHOInterBSCSortantSuccès et TauxHOInterBSCEntrant-Succès
La validation du succès du handover sortant et entrant était possible par le biais de RNO.
RNO donne les valeurs de ces indicateurs aussi bien au niveau d�une cellule qu�au niveau d�un
BSC. Par contre, SPOTS calcule le taux de succès des handover inter MSC et intra MSC sans
distinguer s�ils soient inter ou intra BSC.
La comparaison de l�indicateur TauxHOInterBSCSortantSuccès avec l�indicateur RNO équi-
valent HoOutMSCsuccess_rate est donnée par la �gure 5.7 pour le BSCx :
Mahdi Kallel 74
Projet de �n d�études Validation et étude de cas
SUCC_Ho_Out RNO Vs SUCC_Ho_Out InterfaceA
76,00%78,00%80,00%82,00%84,00%86,00%88,00%90,00%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
SUC
C_H
o_O
ut
SUCC_Ho_Out RNO
SUCC_Ho_Out InterfaceA
Fig. 5.7. Résultat de lacomparaison SUCC_HO_Out
La même comparaison pour une cellule a donné les résultatsillustrés par la �gure 5.8.
SUCC_Ho_Out RNO Vs SUCC_Ho_Out InterfaceA
91,00%92,00%93,00%94,00%95,00%96,00%97,00%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
SUCC
_Ho_
Out
SUCC_Ho_Out RNO
SUCC_Ho_Out InterfaceA
Fig. 5.8. Résultat de la comparaison SUCC_HO_Out pour une cellule
La comparaison des l�indicateur TauxHOInterBSCEntrantSuccès avec l�indicateur RNO équi-
valent HOIncMSCsuccessrate est donnée par la �gure 5.9 pour le BSCx�:
Mahdi Kallel 75
Projet de �n d�études Validation et étude de cas
SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A
84,00%85,00%86,00%87,00%88,00%89,00%90,00%91,00%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
SUC
C_Ho
_In
SUCC_Ho_In RNOSUCC_Ho_In Interface A
Fig. 5.9. Résultat de comparaison SUCC_HO_In
La même comparaison pour une cellule a donné les résultats (voir �gure 5.10)
SUCC_Ho_In RNO Vs SUCC_Ho_In Interface A
0,00%20,00%40,00%60,00%80,00%
100,00%120,00%
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
SUCC
_Ho_
In
SUCC_Ho_In RNOSUCC_Ho_In Interface A
Fig. 5.10. Résultat de la comparaison SUCC_HO_In pour une cellule
C�est quasiment les mêmes valeurs sauf pour le deuxième jour (Durée d�observation di¤érente).
5.1.8 Validation du Taux_Succès_SMS_OC
SPOTS dé�nit le taux de succès de SMS sortant comme étant :
MOSMS% =SUCC_SMS_SEND_RP_ACKMS_SER_REQ_ATTEMPTS
(5.4)
C�est exactement la même formule qui a était dé�nie coté interface A :
Taux_Succ�es_SMS_OC =SmsSubmit_RPackNb_SMS_OC
(5.5)
La comparaison des l�indicateur Taux_Succès_SMS_OC avec l�indicateur SPOTS équivalent
MOSMS % est donnée par la �gure 5.11 pour le MSCx :
Mahdi Kallel 76
Projet de �n d�études Validation et étude de cas
MOSMS SUCC SPOTS Vs MOSMS SUCC InterfaceA
657075808590
04/04
/2007
05/04
/2007
06/04
/2007
07/04
/2007
08/04
/2007
09/04
/2007
jour
MO
SMS
SUCC
MSC
08
MOSMS SUCC SPOTS
MOSMS SUCC InterfaceA
Fig. 5.11. Comparaison du MOSMS SUCC
5.2 Etude de cas
La mise en évidence de l�importance du suivi de la performance du réseau GSM par le biais
de captures sur l�interface A, ne peut se faire qu�en traitant des cas réels.Ce paragraphe donne
un aperçu sur quelques analyses faites sur des zones bien précises, suite à des observations sur
l�évolution des indicateurs de performances déjà conçus ainsi que sur les di¤érents �chiers générés
sur leur formes semi-brutes.
5.2.1 Etude d�une congestion sur l�interface A
Une congestion sur l�interface A est un manque de circuit sur cette interface suite à une
demande. La congestion se produit si le dimensionnement de l�interface A sous-estime le nombre de
connexions simultanées sur cette interface suite à une demande massive de ressources simultanées.
Pour commencer l�analyse, le suivi de l�évolution des indicateurs EchecMOCNSS, Echec-
MOCBSS et EchecMOCUser par BSC est illustrée par la �gure 5.12.
Fig. 5.12. Les échec MOC
Mahdi Kallel 77
Projet de �n d�études Validation et étude de cas
En examinant cette évolution, on peut tirer des observations. En e¤et, le graphe représente
une commodité : Les origines d�échec sont réparties de la façon suivante : Causes User > Causes
BSS > Causes NSS. Ceci semble tout à fait logique dans la mesure où la majorité des cas
d�échec d�établissement d�un appel sortant sont dus à l�utilisateur lui-même ; Par exemple : solde
insu¢ sante, composition d�un numéro non valide, raccrochage précoce etc. . .
Les causes d�échec BSS, de leurs cotés, sont supérieures aux causes d�échec NSS car la partie
BSS du réseau est la plus vulnérable aux erreurs vu la non stationnarité de l�interface radio. La
partie NSS, relativement stable, contribue peu dans les causes d�échec. Toutefois, le taux d�échec
NSS ne devait pas dépasser un seuil tolérable �xé par l�opérateur.
L�indicateur Echec_MOC_NSS dépasse les 5% pour les 6 premiers BSC ce qui est un taux
élevé par rapport à un seuil �xé (Courbe jaune).
Dans le but de poursuivre l�investigation, nous avons analysé les �chiers générés sur l�interface
A exhaustivement pour essayer de trouvé la cause exacte qui est à l�origine de cette hausse.
Pour ce faire, nous avons essayé de rassembler la répartition des causes citées dans le tableau
3.1. Le résultat est donné par la �gure 5.13.
Fig. 5.13. Répartition des causes d�échec
En exploitant le camembert, on constate que le message DISCONNECT, avec une extension
F pour dire qu�il est envoyé par le MSC, et avec la cause NCCA, occupe une bonne partie du
camembert (la partie en noir). La cause NCCA (No Circuit Channel Available) veut dire qu�il
n�y avait plus de circuit pour satisfaire à la demande. Il s�agissait dès lors d�une congestion.
Il est à noter que le camembert précédent n�est pas restreint aux causes NSS, il illustre toutes
les causes possibles sans tenir compte de leurs types (NSS, BSS, USER), par exemple les causes
NSS sont RUu (ResourcesUnavailable) et NCCA.
L�étape suivante était d�essayer de connaître pendant quelle étape de la procédure MOC la
congestion se produit. Pour se faire, il a été indispensable d�exploiter le �chier .XL3 qui donne
l�ensemble des transitions de l�automate que fait chaque connexion sur le réseau. Il nous a permit
de voir la répartition des états de l�automate à partir desquels le message DISC_F-NCCA a été
envoyé. (Voir �gure 5.14)
Mahdi Kallel 78
Projet de �n d�études Validation et étude de cas
Fig. 5.14. Répartition des états
Le camembert montre bien que la majorité absolue des messages DISC_F-NCCA a été en-
voyée lorsque l�état de l�automate était OC_PROC. C�est-à-dire pendant la phase proceeding de
la procédure MOC. L�allocation de circuit au niveau MSC se fait pendant cette étape. Ce qui
montre bien qu�il s�agissait bien d�une congestion !
D�autre part, en ce qui concerne la procédure MTC, la même démarche a été faite. Le suivi
de l�évolution des indicateurs Echec_MTC_NSS, Echec_MTC_BSS et Echec_MTC_User par
BSC est illustrée par la �gure 5.15.
Fig. 5.15. Les échecs MTC
La première constatation est que les taux d�échec MTC sont supérieurs à leurs homologues
MOC. La raison est que la procédure MOC est plus vulnérable à l�échec étant donné qu�elle est
initiée par le mobile.
Si on observe la partie jaune du graphe, on constate que le taux d�échec MOC NSS est
relativement élevé pour 3 BSC (3 pics).
Mahdi Kallel 79
Projet de �n d�études Validation et étude de cas
L�analyse des �chiers générés après capture sur l�interface A nous a permit de rassembler la
répartition des causes citées dans le tableau 2.1. Le résultat est donné par la �gure 5.16.
Fig. 5.16. Répartition des causes
La partie en bleu du camembert montre que le message DISC_F-NCCA est responsable de
la dégradation de l�établissement d�un appel entrant sur ces BSC.
En examinant le �chier .XL3, il s�est avéré que ce message a été envoyé lorsque l�état de
l�automate était TC_CONF, c�est à dire pendant la phase de con�rmation d�appel (Voir �gure
5.17).
Fig. 5.17. Répartition des états
La phase de con�rmation d�appel est équivalente à Proceeding dans la procédure MOC. On
peut donc a¢ rmer qu�il s�agit bel et bien d�une congestion. Dans le but de con�rmer l�analyse
précédente, nous avons observé le �chier .XLT qui donne le tra�c écoulé pour chaque circuit. Nous
avons ensuite organisé ce tra�c de telle façon qu�il est rassemblé par BSC, la partie en bleu du
graphe de la �gure 5.18 compte le tra�c écoulé par BSC. Les points verts représentent le nombre
Mahdi Kallel 80
Projet de �n d�études Validation et étude de cas
maximal de connexions simultanées et les points en noirs représentent le nombre maximal de
circuits disponibles par BSC (c�est-à-dire par interface A).
Fig. 5.18. Tra�c par BSC
En comparaison avec les trois BSC dans lesquels nous avons constaté une congestion selon
la méthode du calcul de l�évolution de l�indicateur Echec_MTC_NSS, seules la congestion des
deux premiers est montrée par la �gure 5.18.
En e¤et, pour les deux premiers BSC, les points verts et noirs sont quasi-confondus. Le fait de
trouver que le nombre de connexions simultanées est très proche de celui des circuits disponibles,
et en plus, pendant une courte durée d�observation, ne fait qu�a¢ rmer qu�il y avait certainement
une congestion au niveau des deux premiers BSC.
Cependant, pour le troisième BSC, les deux points verts et noirs sont relativement éloignés.
Cela représente une contradiction avec l�analyse précédente (calcul de l�évolution de l�indicateur
Echec_MTC_NSS) qui a montré une congestion au niveau de ce BSC.
L�analyse des �chiers générés par capture sur l�interface A a permit de comprendre la cause
de cette incohérence. La méthode était de véri�er les causes du Taux d�échec MTC élevé pour le
BSC en question. (Voir �gure 5.19)
Mahdi Kallel 81
Projet de �n d�études Validation et étude de cas
Fig. 5.19. Distribution des causes pour le BSC
Le camembert montre que les Purges sont à l�origine de cette incohérence. Le problème
était que l�interface A, celle rattaché au BSC concerné, n�était pas supervisée par l�analyseur de
protocole ce qui a donné lieu à des incohérences et des purges sur les �chiers de capture.
5.2.2 Etude d�échec SMS Sortant
A partir d�observations sur l�évolution de l�indicateur Taux_Succès_SMS_OC sur les MSC
du réseau, nous avons pu signaler qu�il y avait une forte dégradation pour le MSCx et le MSCx�.
Fig. 5.20. Résultat de l�analyse de l�indicateur Taux_Succès_SMS_OC
En e¤et, le taux de succès était inférieur à 3%. Dès lors, une investigation a été lancée.
Tout d�abord, nous avons véri�é ce taux avec SPOTS en générant un rapport graphique qui
donne l�évolution de l�indicateur SPOTS « MOSMS %» sur le MSCx et le MSCx�. La �gure 5.21
illustre le résultat.
Nous remarquons bien que le taux de succès de l�envoi d�un SMS sortant a été dégradé pendant
la nuit, de 00h à 08h, pour les trois derniers jours.
Mahdi Kallel 82
Projet de �n d�études Validation et étude de cas
Fig. 5.21. MOSMS% sur SPOTS
D�autre part, on n�a pas signalé des plaintes des clients autour de cette période. Il en résulte
qu�il a été indispensable de faire une trace sur l�envoie de ces SMS pour voir la cause exacte du
problème.
En parallèle avec cette trace, nous avons suivis l�évolution des indicateurs Taux_Echec_SMS_NSS
et Taux_Echec_SMS_BSS. Il n�y avait rien à signaler puisque les valeurs de ces indicateurs pen-
dant la période en question étaient régulières.
A priori, il semble clair que la cause des échecs d�envois est liée principalement aux utilisateurs
eux même.
Le résultat de la trace a montré que seul 4 numéros sont concernés par cet échec. Ces numéros
sont d�MSISDN consécutifs et la contribution de chacun dans l�échec était la suivante :
Fig. 5.22. Echec SMS par numéro
Ces numéros envoient tous des messages vers un même numéro qui était erroné ! Il s�est avéré
ensuite que ces numéros appartiennent à une société privée qui gère un réseau de véhicules par
Mahdi Kallel 83
Projet de �n d�études Validation et étude de cas
GPS, elle envoie périodiquement, chaque minute, les coordonnées GPS de ses véhicules par le
biais d�une plate forme qui envoi les SMS automatiquement. En�n, la société a été contactée
pour corriger la con�guration de sa plateforme SMS.
5.2.3 Etude de détection d�un problème de croisement
Plusieurs critères d�analyse ont été faites, parmi elles celle relative à notre approche sur
l�interface A. En e¤et, nous avons suivi l�évolution de l�indicateur SuccèsEtablissementAppelTech
sur les cellules de la zone concernée et nous avons trouvé que l�indicateur est dégradé, il était au
dessous des 40%.
Fig. 5.23. Résultat d�analyse de l�indicateur Succès_Etablissement_Appel_Tech
Notre analyse sur l�analyse sur l�interface A a montré que deux secteurs appartenant au même
site étaient les plus dégradés. En consultant la liste des opérations programmées, Il s�est avéré
qu�il y avait une opération dans le site en question.
Suite à cette opération, nous avons constaté une diminution considérable du tra�c sur le
secteur 4 du site grâce à l�outil OTT-Perf (Voir �gure 5.24)
Fig. 5.24. Tra�c sur le secteur 4
Mahdi Kallel 84
Projet de �n d�études Validation et étude de cas
Il est clair que le pic vers le bas des TCH valables (ligne bleu) indique le temps exact de l�opé-
ration. Ce défaut de tra�c est compensé par le secteur 3 augmentant ainsi le taux de congestion
SDCCH et TCH sur la cellule (atteint 90%). Voir �gure 5.25.
Mahdi Kallel 85
Projet de �n d�études Validation et étude de cas
Fig. 5.25. Tra�c sur le secteur 3
L�idée était de véri�er s�il y avait un croisement de câblage. Pour véri�er cela, il a était
indispensable de comparer les performance des HO avant et après l�opération. Les positions GIS
des secteurs 4 avec une cellule voisine x et 3 avec une cellule voisine x�sont présentées par la
�gure 6.26.
Fig. 5.26. Positions GIS des secteurs.
RNO montre que les performances HO pour les deux couples précédents ont été inversées
avant et après l�opération (Voir les �gures 5.27 et 5.28).
Mahdi Kallel 86
Projet de �n d�études Validation et étude de cas
Fig. 5.27. Performances HO pour le couple 4-x
Fig. 5.28. Performances HO pour le couple 3-x�
La conclusion est qu�il y avait un croisement de câblage.
Mahdi Kallel 87
Projet de �n d�études Validation et étude de cas
Conclusion générale
Il ne fait désormais plus aucun doute que le suivi de la qualité de service du réseau GSM est
une tâche assez délicate, qui nécessite la coopération de méthodes et d�alternatives di¤érentes
pour parvenir à maintenir un niveau de QoS acceptable.
L�approche développée dans notre étude était de faire en sorte que l�opérateur pouvait en
pro�ter de l�analyseur de protocole installé sur les interface A de son réseau et qui intercepte le
�ux des messages sur cette interface.
Dans cette optique, l�apport de notre étude était la mise en disposition de nouveaux in-
dicateurs clefs de performance conçus à partir des captures sur l�interface A. Ces indicateurs
permettent d�analyser la performance du réseau ou bien de con�rmer quelques résultats.
Ces indicateurs peuvent aussi jouer un rôle de validation pour des opérations techniques
données. Ils permettent parfois de détecter les problèmes parvenus sur le réseau.
L�analyse par les indicateurs clefs de performance n�est qu�une étape durant tout un processus
du maintien d�une qualité de fonctionnent adéquate. Il est commode de se faire en pro�ter de tous
les outils mis à disposition. Il c�est avéré dès lors qu�une implémentation logicielle des indicateurs
conçus est indispensable dans la mesure où elle va servir de tableau de bord pour la visualisation
du réseau.
Cette implémentation logicielle nous a permis de nous familiariser avec des langages de dé-
veloppent et de modélisation intéressants. La validation des indicateurs conçus nous a permis de
toucher de prés les outils de performance mis à disposition et de s�intégrer au sein du service
QDF. L�étude de cas réels nous a permis d�aborder de vrais problèmes d�ingénierie technique.
En�n, et c�est le plus important, ce travail nous a permis de comprendre le vrais sens du
travail en équipe et de sentir son charme.
Mahdi Kallel 88
AnnexeA
Présentation du système GSM
Projet de �n d�études Présentation du système GSM
APrésentation du système GSM
A.1 Principe du réseau GSM
Le GSM est un système cellulaire qui a été développé dans le but de permettre aux utilisateurs,
où qu�ils soient, stationnaires ou mobiles, de communiquer entre eux et avec les abonnés du réseau
�xe (RTC, Réseau Téléphonique Commuté), par l�intermédiaire d�un terminal portatif émettant
à faible puissance (de 0.25 à 8W).
Pour cela, le territoire est découpé en "cellules" couvertes par des émetteurs récepteurs de
base (BTS, Base Transceiver Station). Pour éviter les interférences, deux cellules contiguës ne
peuvent utiliser les mêmes fréquences ; par contre les mêmes fréquences peuvent être réutilisées
pour des cellules su¢ samment éloignées.
Les réseaux GSM utilisent le format numérique pour la transmission des informations, qu�elles
soient de type voix, données ou signalisation. Les équipements spéci�ques constituant le squelette
matériel d�un réseau GSM (BTS, BSC, MSC, VLR et HLR) dialoguent entre eux en mettant en
oeuvre les mêmes principes que ceux utilisés dans le RNIS (Réseau Numérique à Intégration de
Service) :
�Architecture en couche (couches 1 à 3 du modèle OSI),
�Utilisation des liaisons sémaphores (signalisation),
�Caractéristiques des liaisons : codage MIC (Modulation par Impulsion et Codage).
La norme GSM fonctionne sur des largeurs de bandes comprises entre 890 et 915 MHz pour
l�émission du mobile 935 et 960 MHz pour la réception, soit une disponibilité en fréquences de
25 MHz. La bande de fréquences utilisée par un portable GSM (900 MHz) ainsi que la puissance
Mahdi Kallel 90
Projet de �n d�études Présentation du système GSM
développée par celui-ci (2 watts) permet à un relais de couvrir une surface plus importante qu�avec
un portable DCS 1800 (Digital Cellular System 1800 : transposition de
la norme GSM dans la bande de fréquence des 1800Mhz) (1800 MHz - 1 watt), la distance
maximale à laquelle un portable peut accrocher un relais est donc moins importante ce qui le
désavantage en milieu rural par rapport au GSM. De ce fait pour couvrir une même surface,on
estime qu�il est nécessaire d�avoir une fois et demi plus de relais DCS 1800 que de relais GSM.
Les principales caractéristiques de la norme GSM sont données dans le tableau A.1.
GSM DCSFréquence d�émission du terminal vers la station de base 890-915 MHz 1710-1785
Fréquence d�émission de la BTS vers le terminal 935-960 MHz 1805-1880Bande de fréquence disponible 25+25 MHz 75+75 MHz
Mode d�accès TDMA TDMAEspacement des canaux radio 200kHz 200kHzEspacement du duplex 45 MHz 95 MHz
Nombre de canaux radio par sens 124 374Nombre de canaux de parole plein débit 8 8
Débit d�un codec à plein débit 13 kbit/s 13 kbit/sDébit maximal de transmission de données 9.6 kbit/s 9.6 kbit/s
Tab. A.1. Caractéristiques de la norme GSM
A.2 Architecture GSM
Un réseau GSM est constitué de deux sous parties essentielles qui sont le BSS (Base station
Sub-System) qui gère les ressources radio, et le NSS (Network Sub-System) qui assure l�établis-
sement des appels et la mobilité. Les principaux composants d�un réseau GSM sont illustrés dans
la �gure A.1.
Fig. A.1. Architecture du réseau GSM
Mahdi Kallel 91
Projet de �n d�études Présentation du système GSM
A.2.1 La station Mobile
La station mobile est composée d�une part du terminal mobile, et d�autre part du module
d�identité d�abonné (SIM �Subscriber Indentity Module). Le terminal mobile est l�appareil utilisé
par l�abonné. Di¤érents types de terminal sont prescrits par la norme en fonction de leur appli-
cation et de leur puissance (de 0.8W à 20W). Chaque terminal mobile est identifé par un code
unique IMEI (InternationalMobile Equipment Identity). La carte SIM est une carte à puces qui
contient dans sa mémoire le code IMSI (International Mobile Subscriber Indentity) qui identife
l�abonné de même que les renseignements relatifs à l�abonnement (services auxquels l�abonné a
droit).
A.2.2 Le sous-système radio
Le sous-système radio, représenté par la �gure A.2, comprend deux parties. La première,
appelée station de base (BTS : Base Transceiver Station). Une BTS est le point d�accès au PLMN.
Elle est composée d�un ensemble d�émetteur récepteur appelés TRX, Transceiver. Elle a la charge
de la transmission radio, la modulation, la démodulation et le codage correcteur d�erreur. La BTS
gère la couche physique en assurant le multiplexage TDMA, le saut de fréquence et le chi¤rement.
Elle réalise aussi les mesures radio nécessaires. La seconde partie est le contrôleur de station de
base (BSC : Base Station Controller), c�est l�organe intelligent du BSS dont le rôle est de gérer les
ressources radio (confguration des canaux, transfert intercellulaire) d�une ou plusieurs stations de
base (BTS), de contrôler les puissances émises par la BTS et la MS et de décider l�exécution du
handover, en plus d�établir le lien physique (via l�interface A) entre les BTS et le commutateur
de service mobile (MSC).
Fig. A.2. Le sous système Radio
A.2.3 Le sous Système Réseau
Le rôle principal de ce sous-système est de gérer les communications entre les abonnés et les
autres usagers qui peuvent être d�autres abonnés ou des usagers du réseau téléphonique �xxe.
Comme l�illustre la �gure A.3, ce sous-système est composé de :
Mahdi Kallel 92
Projet de �n d�études Présentation du système GSM
Fig. A.3. Le sous système réseau
�Commutateur de service mobile (MSC - Mobile Switching Center) : est un commutateur
numérique en mode circuit. Cet élément s�occupe de la gestion des appels, gère la transmission des
messages courts (Short Message Service SMS) et l�exécution du handover inter BSC. Il dialogue
avec le VLR pour gérer la mobilité des usagers et tout ce qui est lié à l�identité des abonnés, à
leur enregistrement et à leur localisation.
�Commutateur d�entrée de service mobile (GMSC �Gateway MSC) : Ce commutateur est
l�interface entre le réseau cellulaire et le réseau téléphonique publique. Le GMSC est chargé
d�acheminer les appels entre le réseau �xe et le réseau GSM.
�Registre des abonnés locaux (HLR �Home Location Register) : Le HLR est une base de
données dans laquelle sont stockées les informations de tous les abonnés à un PLMN. Ces données
regroupent l�IMSI, le numéro de l�abonné et le pro�l de l�abonnement. Le HLR mémorise pour
chaque abonné le VLR où il est enregistré.
�Registre des abonnés visiteurs (VLR �Visitor Location Register) : C�est une base de don-
nées contenant les informations relatives aux abonnés présents dans une zone géographique. Ces
données regroupent principalement l�identité temporelle et la zone de
localisation. En général il y a un seul VLR pour chaque MSC.
Centre d�authenticité (AuC �Authentication Center) : Le AuC est une base de données pro-
tégée qui contient une copie de la clé secrète inscrite sur la carte SIM de chaque abonné. Cette
clé est utilisée pour vérifer l�authenticité de l�abonné et pour l�encryptage des données envoyées.
�Registre d�identi�cation d�équipement (EIR �Equipement Identity Register) : Le registre
EIR contient la liste de tous les terminaux valides, chaque terminal étant identi�é par un code
IMEI.
A.3 Les interfaces du réseau GSM
Les di¤érents éléments du réseau GSM assurent des fonctions complémentaires et chacun
obéit à des normes spéci�ques. En e¤et, chaque lien entre deux équipements adjacents forme
une interface. Les interfaces sont des composantes importantes du réseau GSM car elles assurent
le dialogue entre les équipements et permettent leur inter-fonctionnement. Ces interfaces sont
présentées dans le tableau A.2.
Mahdi Kallel 93
Projet de �n d�études Présentation du système GSM
Nom Localisation UtilisationUm MS� BTS Interface radioAbis BTS� BSC DiversA BSC� MSC DiversC GMSC� HLR Interrogation HLR pour appel entrantD VLR� HLR Gestion des inforamtions d�abonnées et de localisationE MSC� MSC Exécution des handoversG VLR� VLR Gestion des informations abonnéesF MSC� EIR Vérifcation de l�identité du terminalB MSC� VLR DiversH HLR� AUC Echange des données d�authenti�cation
Tab. A.2. Liste des interfaces dans le réseau GSM
A.4 Fonctionnement du réseau GSM
A.4.1 Traitement des appels
A.4.1.1 L�établissement d�une communication
Lorsqu�un mobile désire faire un appel :
�Il transmet son identité et le numéro à appeler sur un canal d�accès.
�Le BSC reçoit le message et prévient le MSC. Le MSC cherche un canal libre et le transmet
au mobile.
�Le mobile se met sur le nouveau canal et attend la réponse.
Lorsqu�un mobile est appelé :
�Le mobile est toujours à l�écoute du canal de paging, attendant qu�un message lui soit
envoyé.
�Lorsqu�un MSC doit diriger un appel vers sa destination, il demande au MSC d�attache
du téléphone appelé qui l�informe de la position de celui-ci.
�Il achemine l�appel au MSC responsable de la zone de l�appelé, qui peut transmettre sur
le canal de paging la requête d�appel.
�Le téléphone qui se reconnaît répond et reçoit alors le canal à utiliser pour la communication.
Il se met alors à sonner.
A.4.1.2 Authenti�cation et sécurité
L�emploi d�un canal radio rend les communications vulnérables aux écoutes et aux utilisations
frauduleuses, le système GSM a donc recours aux procédés suivants :
�Authenti�cation de chaque abonné avant de lui autoriser l�accès à un service,
�Utilisation d�une identité temporaire,
�Chi¤rement (ou cryptage) des communications.
Mahdi Kallel 94
Projet de �n d�études Présentation du système GSM
A.4.2 Gestion de la mobilité
A.4.2.1 La mise à jour de localisation
La fonction de mise à jour de localisation permet de localiser en permanence les abonnés du
réseau et de mettre à jour les informations de localisation. Pour faciliter cette localisation, les
cellules sont regroupées en "zones de localisation" et à chaque changement de zone, le mobile
doit s�authenti�er au réseau pour indiquer sa nouvelle position. Dans le cas habituel, un message
de mise à jour de la localisation est envoyé au nouveau MSC/VLR s�il y a changement de zone
de localisation de l�abonné. Le VLR procède par la suite à la récupération du pro�l de l�abonné
auprès de l�ancien VLR qui enregistre les informations et les envoie au HLR de l�abonné. Le HLR
demande alors à l�ancien VLR d�e¤acer les données relatives à l�abonné.
A.4.2.2 Le Handover
Dans un réseau cellulaire, la liaison radio entre un mobile et une station de base n�est pas
allouée dé�nitivement pour toute la conversation. Le "Handover" représente la commutation d�un
appel en cours vers un autre canal ou une autre cellule.
Les problèmes liés à la mobilité d�un terminal en communication, sont réglés conjointement
par la structure �xe et le mobile. La décision d�e¤ectue un basculement de fréquence nécessaire au
traitement d�un transfert intercellulaire (Handover) reste toutefois à la charge des équipements
�xes (MSC + BSC). Cette décision découle des traitements liés aux mesures sur le niveau de
réception du mobile e¤ectué par ce dernier (sur les fréquences balises environnantes) et transmises
à la BTS nominale relayant la communication en cours.
Le principe repose sur :
�Les mesures faites par le terminal mobile et transmises au BSC courant ;
�La décision prise par le BSC d�eectuer un Handover après identi�cation d�une ou plusieurs
cellules utilisables ; si plusieurs cellules sont éligibles, le MSC détermine, en fonction des charges
de tra�c, la cellule la plus judicieuse à e¤ectuer la communication ;
�La réservation d�un deuxième canal de tra�c entre la nouvelle BTS et le mobile ;
�Un basculement eectué par le mobile sur réception d�une commande émise par le BSC.
Dans le GSM, le Handover s�eectue avec coupure de la communication imperceptible pour
l�utilisateur.On peut di¢ érencier deux classes standard de Handovers :
� Better cell Handovers qui sont déclenchés a�n d�améliorer la performance du réseau en
minimisant l�interférence et la charge de signalisation.
�Emergency Handovers qui sont déclenchés lors de la détection d�un problème dans la cellule
de service (une mauvaise qualité du signal, un niveau faible du signal, des interférences,. . . ).
A.4.2.3 La sélection/re-sélection des cellules
Contrairement au Handover qui se déroule lorsque le mobile est en mode dédié, le processus
de sélection ou de re-sélection de cellules s�e¤ectue lorsque le mobile est en mode de veille. La
fonction de sélection de cellule est réalisée uniquement à la mise sous tension du mobile, elle
permet à ce dernier de choisir à quelle cellule se connecter a�n de communiquer avec le réseau et
d�être prêt à tout instant à émettre ou recevoir des appels.
Mahdi Kallel 95
Projet de �n d�études Présentation du système GSM
La fonction de re-sélection n�est e¤ectuée qu�après une première sélection et est réalisée lors
du déplacement du mobile. Cette fonction est activée si la cellule précédemment sélectionnée ne
permet plus au mobile de communiquer correctement avec le réseau pour une raison ou une autre.
Mahdi Kallel 96
AnnexeB
Le langage de modélisation UML
Projet de �n d�études Le langage de modélisation UML
BLe langage de modélisation UML
UML (Uni�ed Modeling Language) se dé�nit comme un langage de modélisation graphique
et textuelle destiné à comprendre et d´ecrire des besoins, spéci�er et documenter des systémes,
esquisser des architectures logicielles, concevoir et communiquer à travers divers points de vue.
Nous essayerons dans ce qui suit de donner une brève présentation sur ce langage conceptuel.
B.1 La syntaxe du langage UML
La modélisation du systéme commence par l�identi�cation des acteurs et des use cases et se
poursuit par la description des use cases. Pour une bonne
compréhension du modèle, il paraît nécessaire de dé�nir certains termes propres au langage
UML.
� Les acteurs : Ils n�appartiennent pas au système, mais ils interagissent aveccelui ci. Ils
fournissent de l�information en entrée et/ou reçoivent de l�information en sortie. Le nom de
l�acteur correspond au rôle joué par la personne.
�Les scénarios ou use cases : Un use case modélise un dialogue entre un acteur et le système.
C�est la représentation d�une fonctionnalité o¤erte par le
système. L�ensemble des uses forme toutes les façons possibles d�utilisation du système.
�Les relations dans les uses cases : UML propose di¤érents types de liens [UML en Action]
entre les acteurs et les use cases : la relation de communication, la relation d�utilisation et la
relation d�extension. La relation de communication indique la participation d�un acteur et est
représentée par une ligne solide entre l�acteur et le use case. C�est la seule relation possible entre
un acteur et les use cases.
Mahdi Kallel 98
Projet de �n d�études Le langage de modélisation UML
�La relation d�utilisation ou �includes�entre use cases signi�e qu�une instance du use case
source inclut aussi le comportement d´ecrit dans le use
case destination. Cette relation lie l�exécution d�un use case à un autre.
� La relation d�extension ou �extends �entre deux use cases signife que le use case source
étend le comportement du use case destination. L�exécution
d�une fonction peut s�e¤ectuer indépendamment d�une autre.
B.2 Les diagrammes UML
La notation uni�ée dé�nit 9 diagrammes pour représenter les diérents points de vue de modé-
lisation. Ces diagrammes permettent de visualiser et de manipuler les éléments de modélisation.
Les diagrammes dé�nis par UML sont les suivants :
�Les diagrammes des use cases : représentation des fonctions du système du point de vue de
l�utilisateur.
�Les diagrammes de séquence : représentation temporelle des objets et de leurs interactions.
� Les diagrammes d�activités : représentation du comportement d�une opérationen terme
d�actions.
�Les diagrammes de composants : représentation du code en termes de modules,de compo-
sants et surtout des concepts du langage ou de l�environnement d�implémentation.
�Les diagrammes de classes : représentation de la structure statique en terme de classes et
de relations.
�Les diagrammes de collaboration : représentation spatiale des objets, des liens et des inter-
actions.
�Les diagrammes de déploiement : représentation du d´eploiement des composants sur les
dispositifs matériels.
�Les diagrammes d�́ etats transitions : représentation du comportement d�une classe en terme
d�état.
�Les diagrammes d�objets :représentation des objets et de leurs relations, correspond à un
diagramme de collaboration simpli. . . é, sans représentation des
envois de messages.
D�une façon plus générale, UML permet de modéliser les utilisations de cas et les scénarios
(spéci�cations, architecture fonctionnelle), les classes et les objets (analyse technique détaillée), les
composants (architecture logicielle) et la distribution et le déploiement (architecture technique).
Mahdi Kallel 99
Projet de �n d�études Le langage de modélisation UML
Bibliographie
[1] Recommantion UIT E-800
[2] MISSAOUI Mohammed Taher, cours SUP�COM, 2006/2007.
[3] Lionel Lumbroso, www.01net.com, 2002.
[4] GUNNAR Heine, GSM Networks : protocols, terminology and implementation, Artech
House, 1999.
[5] LAGRANGE Xavier, GODLEWSKI Philippe, TABBANE Sami, Réseaux GSM-DCS 4ème
édition revue et augmentée, Hermes science 1999.
[6] Astellia, Protocoles automates module 3, 2003.
[7] ZNARTY Simon, Le réseau Sémaphore n�7, E¤ort 2005.
[8] SIEMENS, GSM Call and Procedures, 2003
[9] SIEMENS, Tra¢ c annd performance Data counter description SR13, Siemens AG 2006
[10] SIEMENS, Data Model, SPOTS V10 Drop 3, Mai 2003
[11] ASTELLIA, Cigale USER MANUAL, ASTELLIA (2002).
Mahdi Kallel 100