Cissouma

Dramane CISSOUMA Orange Côte d’Ivoire

IGTT (Option Informatique) Année Académique 2005-2006

2

ECOLE SUPERIEURE MULTINATIONALE ORANG E COTE D’IVOIRE (OCI) DES TELECOMMUNICATIONS

Présenté par : MAITRE de stage : M.Dramane CISSOUMA M. Bamoro TRAORE Elève ingénieur des travaux de télécommunication Ingénieur suivi qualité Option informatique



3

Promotion: 2004-2006



4

Sommaire Remerciements………………………………………………………………………………7 Introduction…...………………………………………………………………………………8 1.Présentation d'Orange CÔTE D'IVOIRE….………………………………………………..9 1.1L'entreprise Orange CÔTE D'IVOIRE au sein du groupe France Télécom……........9 1.1.1Les dates clés du groupe France Télécom……………………………………........9 1.1.2Orange France en Chiffre……………………………………………………………..9 1.2Orange CÔTE D'IVOIRE…………………………………………………………..………9 1.2.1Historique……………………………………………………………………………….9 1.2.2Orange CÔTE D'IVOIRE en chiffre…………………………………………………10 1.2.3Organisation et politique générale………………………………………………….10 1.2.3.1Organigramme…………………………………………………………………10 1.2.3.2Direction Générale…………………………………………………………….11 1.2.3.3Direction des Ressources Humaines et de l'Administration………………11 1.2.3.4Direction Commerciale………………………………………………………..11 1.2.3.5Direction Marketing et Communication……………………………………...12 1.2.3.6Direction Financière…………………………………………………………...12 1.2.3.7Direction du système d’information……………………………………….....12 1.2.3.7Direction Technique…………………………………………………………...12

PARTIE 1 1.Principes du GSM………………………………………………………………………..16 1.2Architecture du réseau GSM…………………………………………………………17 1.3Le sous système d'acheminement (NSS)…………………………………………..18 1.4Le sous système radio (BSS)………………………………………………………..19 1.5Le sous système d'exploitation et de maintenance (OSS)………………………..19 2.Les protocoles GSM……………………………………………………………………..20 3.Les canaux logiques:Les Interfaces……………………………………………………21 3.1Les canaux dédiés…………………………………………………………………….21 3.2Les canaux de contrôles……………………………………………………………...22 3.3Processus d'établissement d'un appel………………………………………………22 3.4.Les interfaces………………………………………………………………………....23 3.4.1L'interface radio (Um)…………………………………………………………….23 3.4.2L'interface Abis …………………………………………………………………...23 3.4.3L'interface A……………………………………………………………………….23

PARTIE 2 1.Les indicateurs de qualité de service…………………………………………………….25

1.1Notions de compteurs et indicateurs………….…………………………………….25 1.1.1Notion de compteurs………………………...……………………………………..25

1.1.2Définition d’indicateur:……………………………………………………………25 1.2Accessibilité au réseau :……………………………………………………………...27 1.3La Continuité:…………………………………………………………………………..33 2.Présentation des outils d’analyse qualité………………………………………………36 2.1 NPA(Network Performance Analyser)………………………………………………36 2.1.1Définition.…………………………………………………………………………..36 2.2RNO(Radio Network Optimisation)……………………………………………….....38 2.2.1Définition……………………………………………………………………………38

2.3AGIIR(Analyse et Gestion des Incidents et des Interventions sur le Réseau)…...41



5

2.3.1Définition……………………………………………………………………………..41 2.4CIGALE(Contrôle d’Interface Généralisée A partir de Lecture d'Enregistrement)………………………………………………………………………………41 2.4.1Définition……………………………………………………………………………....41 3.Présentation du document warning et la procédure d’édition ..................................... 51 3.1 Presentation du document warning ....................................................................... 51 3.2 Description de la procédure actuelle du warning ................................................... 54 3.2.1 Mise à jour du warning de la veille: jour ″J-1″ .................................................. 49 3.2.2 Détection de nouveaux incidents sur le réseau ............................................... 49 3.2.3 Création de ticket d’incident avec AGIIR ......................................................... 50 3.2.4 Traitement du ticket d’incident ......................................................................... 52

PARTIE 3

1 Analyse et critique de l’existant .................................................................................. 54 1.1Analyse et critique des outils .................................................................................. 54 1.1.1RNO ................................................................................................................. 54 1.1.2NPA .................................................................................................................. 54 1.1.3AGIIR................................................................................................................ 55 1.1.4CIGALE ............................................................................................................ 55 1.2Analyse et critique du document warning ............................................................... 56 1.3Analyse et critique de la procédure de traitement du warning ................................ 56 1.4Analyse et critique de la création de ticket ............................................................. 56 1.5Analyse et critique du suivi des actions .................................................................. 56 2.Propositions d’optimisation du warning et suivi des actions ....................................... 57 2.1Propositions d’optimisation du warning: ................................................................. 57 2.1.1Les outils: ......................................................................................................... 57 2.1.2Propositions de document warning:.................................................................. 57 2.1.3Proposition de procédure d’édition du warning................................................. 66 2.1.3.1Détection des nouveaux incidents avec NPA .......................................... 66 2.1.3.2Mise à jour du warning de la veille (jour j-1) ............................................ 67 2.1.3.3Création de tickets d’incident avec AGIIR................................................ 67 2.1.3.4Traitement des tickets précédemment créés ........................................... 67 2.2 Proposition de suivi des actions ............................................................................ 68 CONCLUSION............................................................................................................... 71 ANNEXES ..................................................................................................................... 72 ANNEXE 1..................................................................................................................... 72 ANNEXE 2..................................................................................................................... 73 ANNEXE 3..................................................................................................................... 81 Bibliographie...……………………………………………………………………………….…82 Glossaire ....................................................................................................................... 83

Table des figures Figure 1: organigramme d'Orange CÔTE D'IVOIRE…………………………………….7 Figure 2: organigramme de la Direction Technique……………………………………..7 Figure 3: organigramme du QPG, mon poste…………………………………………..10 Figure 4:Architecture du réseau GSM……………………………………………………14 Figure 5:Protocoles des réseaux GSM…………………………………………………..18 Figure 6: Phase établissement de la liaison radio………………………………………29 Figure 7 : phase d’utilisation du canal SDCCH………………………………………….30



6

Figure 8 : Phase d’assignation du canal TCH…………………………………………..32 Figure 9 : phase de la sonnerie………………………………………………………….......34 Figure 10: Page de recherche d’incidents sur NPA………………………………………..37 Figure 11 :Page de recherche d’incidents sur RNO………………………………………..39 Figure12 : connexion des outils RNO, NPA et CIGALE au BSS…………………………41 Figure 13: Page d’accueil AGIIR ................................................................................... 40 Figure 14: Page d’accueil CIGALE................................................................................ 42 Figure 15 : Page de détections des CICs défaillants (données) .................................... 44 Figure 16:Page de détections des CICs défaillants (graphe) ........................................ 50 Figure 17: Exemple de document warning .................................................................... 52 Figure 17: Page de création de ticket d’incident AGIIR ................................................. 51 Figure 18: Nouveau format warning (zones 1800\ rubrique accessibilité) ..................... 65 Figure 19: Nouveau format warning (zones 1800\ rubrique continuité) ......................... 67 Figure 20: Nouveau format warning (zones 1800\ rubrique trafic)................................. 69 Figure 21: Nouveau format warning (zones 1800\ rubrique TRX défectueux)............... 69 Figure 22: Nouveau format warning (zones 1800\ rubrique CICs défaillants) ............... 63 Figure 23: Nouveau format warning (zones 1800\ rubrique nombre d’incidents)........... 64 Figure 1: Nouveau format warning (zones 900\ rubrique accessibilité) ......................... 71 Figure 2 : Nouveau format warning (zones 900\ rubrique continuité) ............................ 72 Figure 3 : Nouveau format warning (zones 900\ rubrique trafic).................................... 74 Figure 4: Nouveau format warning (zones 900\ rubrique TRX défectueux)................... 75 Figure 5: Nouveau format warning (zones 900\ rubrique CICs défaillants) ................... 76 Figure 6: Nouveau format warning (zones 900\ rubrique nombre d’incident) ................ 78 Figure 7: Une BTS (Base Transceiver Station; Station de Base émetteur-récepteur) ... 79



7

Remerciements Avant d’entamer le projet d’étude qui m’a été confié, je souhaiterai adresser ma gratitude et mes sincères reconnaissances à toutes les personnes qui m’ont aidé et avec qui j’ai eu plaisir à travailler pendant mon stage. C’est ainsi que nous pensons spécialement au niveau de : Orange Côte D’IVOIRE à : M.François BRUNET : Directeur Général M.PITAH Joseph : Directeur Technique M.Pascal PEROUSSE : Directeur Technique Adjoint M. Mathias ADIABASS : chef de service Analyse Qualité et ses collaborateurs Bamoro TRAORE, AMUAN Ollier Aimé, Serge ASSANDE, Kevin TANOH et Roselyne HASSOUANKON. Ainsi que : M. Francis BA : Chef de service Optimisation radio Pour l’opportunité qu’ils m’ont offert pour mener à bien notre travail, l’aide apportée pour la conduite de cette étude. L’ESMT à : M. FALL Brahim Adama : Directeur de l’école, l’administrateur des programmes M. Oumar NDIAYE, M. Oumar SAMBA, Bruno ROGER et tout le corps professoral. Sans doute mes sincères remerciements destinés à tous les étudiants de l’ESMT, particulièrement ceux de la classe IGTT (option informatique). Je ne saurai terminer ces remerciements sans remercier les familles LECORFEC, DIOP, SARR, GUEYE, particulièrement Marie-Liesse LECORFEC ma marraine, Christine LECORFEC et Yannick LECORFEC, ma famille ainsi que tout mes amis de Dakar (SENEGAL), Ouagadougou (BURKINA FASO), Bamako (MALI) et Abidjan (CÔTE D’IVOIRE). Pour terminer je remercie le Seigneur de m’avoir donner la chance d’atteindre ce niveau d’études.



8

Introduction L’enseignement de deuxième année du cycle ingénieur de l’ESMT (Ecole Supérieure Multinationale des Télécommunications) comprend deux mois de stage de fin d’études en entreprise. J’ai effectué le mien au sein de la direction technique d’Orange Côte d’Ivoire, dans le département Qualité et Pilotage Globale (QPG). Suite à la détection des incidents sur le réseau, chaque matin un rapport comportant les incidents sur le réseau est envoyé aux services compétents afin d’y trouver des solutions. Le terme donné à la détection d’incident sur le réseau est le WARNING. Le Warning se fait à l’aide des outils tel que RNO, NPA et CIGALE comportant des indicateurs permettant d’analyser le comportement du réseau. C'est-à-dire déceler les incidents sur le réseau et y apporter des solutions. Les actions que le warning crée sont suivies via l’outil AGIIR. Mon rôle pendant le stage était d’assister le chargé du Suivi Qualité dans sa procédure d’édition du warning de la branche Réseau d’Accès (BSS). Ma mission n’a pas pour objectif la production d’un résultat technique concret. Il s’agissait de mener à bien le suivi qualité du réseau de façon optimale avec les autres entités concernées par la qualité du réseau (Optimisation Radio, OMC - R) et dans le respect des objectifs fixés. La compréhension de l’environnement BSS en particulier le coté radio, ses acteurs, son organisation et ses étapes a été primordiale pour bien appréhender notre étude et d’apporter une amélioration. La connaissance de tous ces aspects a probablement été pour moi la tâche la plus difficile et la plus longue. Cela traduit tout le travail d’adaptation et d’immersion que j’ai dû fournir à mon arrivée dans l’entreprise et pendant la moitié de la période qui m’a été accordé pour ce stage. L’Analyse de Qualité de service est déjà effectuée au QPG d’Orange Côte d’Ivoire. La mission qui m’a été confié est de mettre en place une procédure d’optimisation du warning (traitement, suivi action). La durée de mon stage a été repartie en deux périodes :

• Avec les outils déjà existant au sein de la Direction Technique, la première période a été consacrée à l’étude de ces outils existant (fonctionnement, insuffisances, etc…)

• Les deuxièmes périodes a été consacrés à la recherche de solution afin d’optimiser du warning. A l’issu de cette deuxième période, une solution d’optimisation devait être présentée au QPG et les entités concernés par la qualité.

Nous allons donc dans ce rapport faire une première partie sur la généralité GSM, puis étudier l’existant dans la deuxième partie. Par la suite dans la troisième partie nous ferons des critiques suivies des propositions d’optimisation. Pour finir, nous allons motiver la nécessité d’un outil unique pouvant fournir à la fois les données de RNO, NPA et CIGALE. Afin d’éviter l’usage simultané de RNO, NPA et CIGALE qui rend fastidieux le traitement du warning.



9

1. Présentation d’Orange Côte d’Ivoire : 1.1 L’entreprise Orange Côte d’Ivoire au sein du groupe France Télécom : 1.1.1Les dates clés du groupe France Télécom :

• 1992 : Début des activités de téléphonie mobile FT • 1994 : Didier Quillot en devient le Directeur Général • Mai 2000 : Rachat d’Orange UK par France Télécom • Février 2001 : Introduction en bourse • 21 juin 2001 : France Télécom regroupe sous la marque Orange l'ensemble de

ses activités mobiles implantées en France et dans le monde. Séparation de la marque de FT mobile.

• 1er juin 2006 : Tous les services du groupe FT passent sous la marque Orange.

1.1.2 Orange France en chiffre:

• 1er opérateur français avec 48,8% de part de marché • Chiffre d’Affaire en 2005 supérieurs à 8 milliards d’euros • 7600 salariés en France, répartis sur 20 villes • Plus de 20,3 millions de clients (dont 2 millions de clients entreprises) • 11.8 Millions de forfaits et 8,5 millions de prépayés • 15000 BTS et 5000 NodeB (BTS 3G) • 90% de la population et des entreprises couvertes par EDGE • 52% de la population couverte en 3G

1.2 Orange Côte d’Ivoire: 1.2.1 Historique: La Société Ivoirienne de Mobile (SIM), détenue à 85% par France Télécom et à 15% par le groupe Sifcom, a été créée le 19 mars 1996. Elle a débuté ses activités commerciales le 28 octobre 1996 avec l’ouverture de son réseau dénommé Ivoiris. La Société Ivoirienne de Mobile va connaître un important changement suite au rachat pour un montant global de 26.9 billions de francs français de la société anglaise Orange, par France -Télécom en mai 2000.

Fondée en 1994, le lancement de Orange UK par HUTCHISON MICROTEL a lieu en avril de la même année. Orange UK est une société dont l’expertise commerciale et marketing ainsi que l’approche client sont reconnus les plus performants du monde de la téléphonie. Cela s’est traduit deux (2) ans après son lancement, en avril 1996, par sa cotation à la bourse de Londres et du NASDAQ.

Suite à la création de la holding de droit français, Orange SA, France Télécom décide de dénommer « Orange » toutes ses filiales mobiles, dans lesquelles elle est majoritaire, afin de leur faire bénéficier de l’expertise commerciale et de la notoriété dont



10

jouit la marque. C’est ainsi que le 18 mars 2002, la Société Ivoirienne de Mobile change de dénomination sociale et commerciale et devient Orange Côte d’Ivoire SA (OCI SA). Conformément à la politique du groupe, le statut de franchise d’Orange Côte d’Ivoire SA se traduit le 29 mai 2002 par l’adoption de la marque, de ses valeurs et de sa vision du futur. Orange CI SA est à cette date, la première représentation de la marque Orange en Afrique. Au-delà du changement de dénomination et de logo, le passage à Orange est un projet fondé sur une véritable culture d’entreprise partagée au quotidien par plus de 600 personnes.

1.2.2 Orange Côte d’Ivoire en chiffre : • 1er opérateur Ivoirien avec 55% de part du marché • Plus de 165 villes couvertes • Plus d'un million cinq cents abonnés • 1618 Cellules • 676 BTS (émetteur-récepteur)

1.2.3 Organisation et politique générale : 1.2.3.1 Organigramme : L’organigramme d’Orange Côte d’Ivoire se présente comme suit :

Figure 1: Organigramme d'Orange Côte d’Ivoire

� Communication d’entreprise :

Afin de fluidifier la circulation des informations à l’intérieur de l’entreprise et développer l’esprit d’entreprise, plusieurs supports de communication sont mis à la disposition du personnel. Ce sont : une messagerie interne, Intranet, Internet, les notes de service, les notes d’information, affiches. Présentation des directions :

L’organisation au sein d’Orange Côte D’Ivoire s’articule autour de trois activités principales :

Direct eur Technique

Gestions des Moyens & Patrimoine Technique

Département Exploitation Maintenance

Directeur Technique

Département Production Ingénierie

Département Nouvelles Technologies

Département Supervision des réseaux

Département Accès Radio

Département Qualité Pilotage Globale

EQUIPE DT



11

L’Administration : Direction Générale, Direction des Ressources Humaines et la Direction Financière ; Le Commercial : Direction Commerciale, Direction Marketing et Communication La Technique : Direction Technique, Direction du système d’information. 1.2.3.2 Direction Générale :

Le Directeur Général est nommé par le conseil d’administration. Il définit avec l’équipe de direction la stratégie de l’entreprise, les orientations, les objectifs et les plans d’actions qui sont ensuite approuvés par les administrateurs. Le Directeur Général supervise et coordonne l’activité de toutes directions auxquelles il délègue un certain pouvoir de décision. Il rend compte du fonctionnement et des résultats de l’entreprise au Conseil d’Administration.

1.2.3.3 Direction des Ressources Humaines et de l'a dministration :

Elle a pour mission de : o Réaliser une gestion administrative du personnel (embauche, paie, législation,

contrat de travail…) ; o Gérer les emplois et les compétences (emploi, évaluation du personnel,

formation, suivi des carrières) ; o Suivre les relations sociales (délégués du personnel, Comité d’Entreprise…) ; o Mettre en application la politique sociale (gestion du centre médico-social,

assurance maladie, assurance individuelle accident…) ; o Garantir les intérêts de Orange Côte d’Ivoire par des actions juridiques (conseil

aux directions, gestion des litiges, formalisation et suivi des relations entre Orange Côte d’Ivoire et ses partenaires) ;

o Coordonner les activités de construction, d’entretien et de maintenance des bâtiments de l’entreprise (gestion du parc véhicules, amélioration des rapports clients fournisseurs).

1.2.3.4 Direction Commerciale : Elle a pour mission de :

o Développer le chiffre d’affaires de la société en assurant la commercialisation de ses produits (prépayés, abonnements, terminaux) auprès de ses différents clients en entreprise et dans le grand public ;

o Fidéliser le parc clients existant et le faire croître ; o Assurer l’interface au profit des clients potentiels et des clients existants en

répondant à leurs différentes questions et réclamations.

1.2.3.5 Direction Marketing et Communication : Elle a pour mission de :

o Détecter et déterminer les besoins pour conquérir de nouveaux clients et fidéliser le parc acquis ;

Concevoir des produits et services adaptés en vue de répondre à leurs attentes ; o Créer, planifier et mettre en œuvre les actions visant à promouvoir les produits et

services ainsi qu’à nourrir l’image de marque de l’entreprise.



12

1.2.3.6 Direction Financière : Les prérogatives de la Direction Financière sont les suivantes :

o optimiser les ressources, les performances et la rentabilité ; o Garantir la fiabilité du système de contrôle interne ; o Evaluer la maîtrise des risques opérationnels et financiers ; o Préconiser des actions correctives o Enregistrer, contrôler et vérifier toutes les opérations comptables et

financières effectuées par l’entreprise. 1.2.3.7 Direction du système d’information :

La Direction du Système d’Information s’attelle à construire et exploiter un système d’information efficace et cohérent pour soutenir l’activité d’Orange Côte d’Ivoire et d’assurer des prestations de soutien et de qualité sur le système d’information.

1.2.3.8 Direction Technique:

• Organigramme : Figure 2 : Organigramme de la Direction Technique QPG : Département Qualité Pilotage Global DAR : Département accès Radio DEM : Département Exploitation et Maintenance DSR : Département supervision Réseau DNT : Département Nouvelle Technologie DPI : Département Planification et ingénierie

DPI

DAR

DEM

DSR

DNT

QPG

Directeur Générale

Directeur Technique Adjoint



13

• Les principales missions de la Direction Technique sont:

• Garantir la qualité du réseau en inscrivant les actions et les interventions

dans une démarche ; • Mettre en œuvre le déploiement des équipements du réseau ; • Exploiter et maintenir le réseau ; • Anticiper et prévoir les évolutions du réseau ; • Elaborer le schéma directeur technique.

• Département Qualité et Pilotage Globale (QPG) :

� Organigramme, mon poste :

Figure 3 : Organigramme du QPG, mon poste

La qualité du service offert à ses clients étant la première préoccupation du fournisseur. Orange Côte d’Ivoire afin d’être rassurer de la bonne qualité de ses services offert à ses abonnés a mis en place un département Qualité et Pilotage Global (QPG) subdivisé en deux sections qui sont :

� La section Optimisation :

CHEF DE DEPARTEMENT QPG

UNITE QUALITE DE SERVICE

UNITE GESTION TRAFIC

CHEF DE SERVICE GESTION DES RESSOURCES

CHEF DE SERVICE ANALYSE QUALITE

UNITE GESTION DES RESSOURCES

Mon Poste

UNITE OPTIMISATION RADIO



14

Elle a pour mission comme son nom l’indique l’optimisation des ressources radio pour l’amélioration de la qualité réseau et de sa capacité .Elle définit le paramétrage radio, planifie et met en œuvre le plan de fréquence global, etc.

� La section qualité Services (QoS) : Elle veille à la qualité de fonctionnement des équipements réseaux et à leurs dimensionnements. Elle gère les outils de qualité et définit les indicateurs de qualité. Puis elle édite les tableaux de bords et les rapports de synthèse qui permettent de suivre le fonctionnement du réseau. Le département QPG gère les projets et suit la qualité et le fonctionnement des équipements réseaux. Les objectifs globaux assignés au service QPG sont ainsi résumés :

• Améliorer l’analyse des indicateurs suite aux détections en proposant des solutions ;

• Fournir les rapports techniques mensuels au plus tard le dix (10) du mois suivant ;

Exemple: les rapports du mois de septembre sont à fournir le dix (10) du mois d'octobre. • Améliorer la qualité du réseau par un processus qualité

rigoureux et performant ; • Participer aux différents projets mis en œuvre par OCI.

Ces tâches sont reparties entre : La section Qualité Service et la section Optimisation.

� Service Analyse Qualité : Le Service Analyse Qualité se subdivise en deux unités : L’unité Service Qualité et l’unité Gestion Trafic.

⇒ Unité Service Qualité :

C’est au sein de l’Unité Service Qualité que se situe mon poste. Elle a pour missions :

• Détection des problèmes réseaux • Analyse et Solutions • Reporting • Faire le suivi des actions correctives • Calcul des CPN (Cellule à Point Noir) • Participer à l’élaboration de l’architecture évolutive du réseau

Mon poste à pour priorité • Détection des problèmes réseaux • Analyse et Solutions • Faire le suivi des actions correctives ⇒ Unité Gestion Trafic :

• Garantir l'écoulement fluide des trafics (national, international, IP) • Gérer les plans d’acheminements. • Participer à l’élaboration de l’architecture évolutive du réseau



15



16

1. Principes du GSM :

Le réseau GSM est le principal réseau normalisé de la téléphonie mobile numérique en Europe. Le projet est né en 1984 au sein de la CEPT (Conférence européenne des postes et télécommunications), qui a créé à cet effet le Groupe Spécial Mobiles (GSM), France Télécom étant le moteur de ce projet. Les premiers tests en grandeur nature ont été possibles à partir de 1991, tandis que le premier service GSM commercial, Itinéris, de France Télécom, a été ouvert en 1992. Cette année-là, le système reçoit un nouveau nom : Global System for Mobile Communications. Il s'agit d'un réseau radio fonctionnant autour de la fréquence 900 MHz avec accès multiple à répartition dans le temps (TDMA). Huit canaux sont disponibles par fréquence porteuse, et ces dernières sont séparées de 200 kHz. L'architecture du système comprend :

� la station mobile, composée d'un terminal (téléphone portable) et d'une carte d’abonner;

� la station radio de base (BTS), qui couvre une cellule de territoire dont la taille peut aller de 250 m en zone urbaine à 30 km en zone rurale;

� le gestionnaire de stations (BSC), qui assure l'interface entre les stations de base et le centre de commutation;

� le centre de commutation (MSC), qui interconnecte le système cellulaire et les autres réseaux de télécommunication en utilisant le réseau de signalisation CCITT n°7;

� des bases de données des abonnés VLR permettant la localisation de chaque terminal mobile visiteur dans une zone et HLR permettant d'enregistrer tous les abonnés du réseau.

Un sous-système dit d'itinérance (handover) permet de maintenir une communication en cours lorsque l'on change de cellule. Au début des années 90, pour augmenter les fréquences disponibles, dont la capacité des réseaux GSM européens, une norme de réseau concurrente, DCS 1800 (Digital cellular system, 1800 MHz), fondée sur le système cellulaire britannique, a été adaptée à l'architecture GSM. Aux Etats-Unis, d'autres normes de réseau de téléphonie cellulaire sont en vigueur, fondées sur les multiplexages TDMA et CDMA. Au Japon, les normes utilisées sont proches de leurs homologues américaines. Le réseau GSM est néanmoins conçu pour la téléphonie vocale. C'est pourquoi il est fondé sur la commutation de circuits (de canaux hertziens), ce qui ne le destine pas à la transmission de données, qui n'est possible qu'au faible débit de 9600 bit/s . Il est actuellement aménagé pour tirer parti de la commutation de paquets, grâce aux normes GPRS et EDGE, qui permettent des débits plus élevés. Mais c'est la troisième génération de réseaux sans fil (la première ayant été celle des réseaux analogiques et la deuxième celles des réseaux numériques voir de type GSM), baptisée UMTS , qui devrait réellement imposer la convergence de tous les types de communications.



17

1.2 Architecture du réseau GSM:

Le réseau GSM a pour premier rôle de permettre des communications entre abonnés mobiles (GSM) et abonnés du réseau téléphonique commuté (RTC, réseau fixe). Le réseau GSM s'interface avec le réseau RTC et comprend des commutateurs. Le réseau GSM se distingue par un accès spécifique : la liaison radio. Le réseau GSM est composé de trois sous réseaux :

• le sous système radio, BSS (Base Station Sub-system) assure et gère les transmissions radio;

• le sous système d'acheminement, NSS (Network Sub System). Le NSS comprend l'ensemble des fonctions nécessaires pour les appels et la gestion de la mobilité. ;

• le sous-système d'exploitation et de maintenance, OSS (Operation Support System) qui permet à l'opérateur d'exploiter son réseau.

La mise en place d'un réseau GSM (en mode circuit) va permettre à un opérateur de proposer des services de type " Voix " à ses clients en donnant l'accès à la mobilité tout en conservant un interfaçage avec le réseau fixe RTC existant. La mise en place d’un réseau GSM représente un investissement considérable. A l’heure actuelle les réseaux GSM ne cessent d’évoluer afin d’assurer une qualité de couverture toujours plus importante. La couverture du réseau est assurée par la multiplication des ensembles BTS – BSC. Rappelons ici rapidement qu’une BTS couvre environ 500m de zone en ville et 10 km de zone en campagne. Ci dessous un rappel de l’architecture GSM, en encadré les éléments de couverture.

Figure 4 : Architecture du réseau GSM



18

Le tableau ci-dessous illustre les interfaces entre équipements d'un réseau GSM : Nom interface

Um

Abis

A

B

C

D

E

F

G

MSC-VLR

VLR-VLR Gestion des informations d’abonnés

Vérification de l’identité du terminal

Utilisation

Interface radio

Divers (transfert des communications …)

Divers (Transfert de données)

Divers (Transfert de données)

Interrogation HLR pour appel entrant

Gestion des informations d’abonnés et de localisationServices Supplémentaires

Exécution des handovers

Localisation

Terminal –BTS

BTS – BSC

BSC – MSC

MSC –VLR

GMSC-HLR

VLR-VLR

MSC-MSC

Tableau 1: Liste des interfaces dans un système GSM Un réseau de radiotéléphonie est constitué par trois sous réseaux, le sous-système radio (BSS), le sous-système d’acheminement (NSS) et le sous-système d’exploitation et de maintenance (OSS). L’équipement terminal de l’utilisateur ou Station Mobile (MS) peut être inclus ou exclu du sous-système radio suivant s’il est connecté ou non.

1.3 Le sous-système d’acheminement (NSS) :

NSS est l’abréviation de Network Switching Sub-System. Ce sous système comprend :

• HLR (Home Location Register), • VLR (Visitor Location Register), • MSC (Mobiles-services Switching Center).

Le VLR, Visitor Location Register, est une base de données reliée a un MSC qui contient le profil des abonnés présents dans la zone du MSC et leur cellule de rattachement. Le HLR, Home Location Register, est une base de données qui contient les profils des abonnés et leur zone de rattachement. A partir du numéro d'un abonné, il est possible de retrouver les caractéristiques de l'abonné. Le MSC, Mobile-services Switching Center, est un commutateur téléphonique adapté pour supporter les fonctions mobiles:

o gestion des appels effectués par les mobiles présents dans la zone ; o dialogue avec les bases de données pour accueillir les mobiles se

présentant dans la zone ;



19

o fonction passerelle pour traiter les appels vers les mobiles (qui peuvent se trouver en un point quelconque) venant des abonnés téléphoniques voisins.

1.4 Le sous-système radio (BSS) :

BSS est l’abréviation de Base Station Sub-System. On distingue deux types de matériels au sein du BSS :

• La BTS (Base Transceiver Station) qui est un ensemble d’émetteurs – récepteurs • Le BSC (Base Station Controller) qui est l’organe intelligent du BSS.

La BTS, Base Transceiver Station, est un ensemble d'émetteurs-récepteurs. La BTS prend en charge la modulation/démodulation, le chiffrement, la mise en trame et en paquets élémentaires radios. C'est un organe avec peu d'intelligence. La capacité maximale d’un BTS est de 100 communications simultanées. En zone rurale, une BTS est composé d’un TRX et se limite alors à sept communications simultanées. Le BSC, Base Station Controller, commande un ensemble de stations radios BTS. Il gère la ressource radio, exploite les mesures effectuées par les BTS et les mobiles pour décider l’exécution du handover. Pendant une communication, le terminal est en liaison radio avec une station de base déterminée. Il faut assurer la continuité du service quand l’utilisateur se déplace. En effet, ce dernier peut changer de cellules lors d’une communication. Il faut alors changer la station de base avec laquelle le terminal est relié tout en maintenant la communication : c’est le transfert inter cellulaire ou handover.

1.5 Le sous-système d’exploitation et de maintenanc e (OSS):

OSS est l’abréviation de Opération Sub-System. L’architecture détaillée précédemment a besoin d’être supervisée, maintenue en état de fonctionnement en assurant la qualité. Etant donné le nombre et la répartition géographique de ces équipements, il faut les administrer à distance. C’est le rôle des composants de l’OSS : -l'OMC (Operation and Maintenance Centre),centre d’opération et de maintenance, -le NMC (Network Management Centre), centre de supervision du réseau -l’EIR (Equipment Identity Register), registre des identités des équipements -l’AUC (authentification Centre), centre d’authentification. On observe deux entités de supervision: OMC et NMC Les OMC (OMC-R et OMC-S) dont la principale fonction est de superviser localement les équipements : soit un ensemble de BTS et BSC, soit des MSC et VLR. Les OMC s’occupent des incidents mineurs. � L'OMC-R (Centre d'Opération et de Maintenance pour le réseau d'accès Radio)

contient toutes les fonctions d'opérations et de maintenance (O&M) capables de gérer les équipements :



20

o Gestion de la configuration (Configuration Management). o Gestion des performances (Performance Management) o Gestion des alarmes et des événements (Fault Management) � L’OMC-S (Operation and Maintenance Center Switching) est le Centre

d'exploitation et de maintenance du sous-système réseau. Il gère les fonctions d'exploitation technique du MSC (configuration, paramétrage, alarmes, indicateurs…). � Le NMC s’occupe des incidents majeurs. Il supervise le réseau de façon globale.

Il récolte les informations importantes provenant des OMC, les autres étant filtrées par ces derniers.

� L’EIR stocke les identités des terminaux (IMEI pour International Mobile Equipment Identity) dans ses bases de données. Ainsi il peut vérifier si :

o Le terminal est autorisé à fonctionner sur le réseau (liste blanche) o Le terminal est volé (liste noire) o Le terminal est défectueux ou non homologué (liste grise).

� L’AUC est le centre d’authentification qui garde en mémoire pour chaque abonné une clé secrète qui sert à prouver son identité lors d’une demande de service ou pour chiffrer les communications. Un AUC est associé à un HLR, il peut même être intégré mais du point de vue logique il ne fait pas partie du même sous-système.

2. Les Protocoles GSM :

La figure ci dessous représente l'architecture des protocoles GSM des différents éléments du réseau. Au niveau applicatif, on distingue les protocoles suivants qui, au travers de différents éléments du réseau, relient un mobile à un centre de commutation (MSC) :

• Le protocole Call Control (CC) prend en charge le traitement des appels tels que l'établissement, la terminaison et la supervision

• Le protocole Short Message Service (SMS) permet l'envoi de courts messages au départ d'un mobile.

• Le protocole Supplementary Services (SS) prend en charge les compléments de services.

• Le protocole Mobility Management (MM) gère l'identification, l'authentification sur le réseau et la localisation d'un terminal. Cette application se trouve dans le sous-réseau de commutation (NSS) et dans le mobile car ils doivent tous deux connaître la position du mobile dans le réseau.

• Le protocole Radio Ressource management (RR) s'occupe de la liaison radio. Il interconnecte une BTS et un BSC car ce dernier gère l'attribution des fréquences radio dans une zone.

Les trois premiers protocoles applicatifs cités (CC, SMS et SS) ne sont implémentés que dans les terminaux mobiles et les commutateurs ; leurs messages voyagent de façon transparente à travers le BSC et la BTS.



21

Figure 5 : Protocoles des réseaux GSM

3. Les canaux logiques: Interfaces Un canal physique peut fonctionner comme un canal de trafic (pour la transmission de la voix ou des données) et comme un canal de contrôle (pour la transmission de la signalisation et les informations de contrôle). Le terme générique pour désigner les canaux de trafic et de contrôle est : canal logique. 3.1 Les canaux dédiés : On distingue deux types de canaux dédiés : TCH et SDCCH

• Les canaux de trafic TCH (Traffic Channel) sont dédiés au mobile pour le transport de la parole ou des données.

• Les canaux de signalisation SDCCH (Stand alone Dedicated Channel) ces canaux transportent les échanges d’informations entre le mobile et le réseau avant l’attribution du canal de trafic. A ces canaux dédiés, on associe certains canaux pour leur contrôle:

• SACCH (Slow Associated Control Channel): C’est sur ce canal que se font les mesures de puissance du mobile et de qualité du lien radio.

• FACCH (Fast Associated Control Channel): ce canal permet de transporter les informations de signalisations pendant le handover. Il utilise une partie du TCH ce qui fait qu’on parle souvent de vol de la capacité du TCH. Le canal FACCH est alloué à un canal dédié (TCH ou SDCCH) et permet d’écouler différents types de contrôle.

Pour gérer plus efficacement l’interface radio, plusieurs paramètres sont mis en œuvre. Il s’agit de paramètres d’identification du réseau et de la cellule, de paramètre d’accès à la cellule et de paramètre concernant les handovers.



22

3.2 Les canaux de contrôle :

Ils permettent aux mobiles et aux stations de base de demander et de fournir des canaux dédiés. On distingue les canaux suivants :

• RACH (random Access Channel): lorsque le mobile veut effectuer une opération sur le réseau. il doit le signaler. Cette requête est envoyée sur le canal d’accès aléatoire RACH.

• AGCH (Access Grant Channel) : c’est sur ce canal que le mobile reçoit la réponse à sa requête.

• PCH (Paging Channel): lorsque le réseau recherche un mobile, il diffuse l’identité du mobile sur tout le réseau. Ces informations sont transmises sur le canal PCH.

• CBCH (Cell Broadcast Channel): c’est sur ce canal qu’on diffuse et envoie des messages dans la cellule.

• SCH (Synchronisation Channel): c'est le canal de synchronisation dont les bursts, diffusé par la BTS, ont une longue séquence d'apprentissage; il permet au mobile de se synchroniser sur la BTS.

3.3 Processus d'établissement d'un appel :

La première étape dans l'établissement d'une communication départ est l'établissement d'une connexion radio (RR), mettant en œuvre les canaux spécifiques RACH et AGCH. La station mobile doit bien entendu être déjà en mode veille, c'est-à-dire présynchronisée sur une cellule, dont elle a décodé les canaux FCCH, SCH BCCH, ce qui permet de connaître l'organisation des canaux de contrôle. Le mobile se signale donc au réseau sur le canal RACH. Cette étape permettra au réseau de savoir si un TCH est nécessaire ou non pour cet appel. La demande d'accès du mobile, reçue par la BTS, sera répercutée au BSC. Le BSC peut accepter ou non la demande, selon son taux d'occupation par exemple. Alors un canal de signalisation dédié SDCCH est alloué au mobile. Lorsque la réservation est acceptée par la BTS, le BSC répond à la requête du mobile sur le canal AGCH via un message qui contient l'identité du canal alloué. Après l'établissement d'une connexion radio sur SDCCH vient les procédures d'authentification et de chiffrement. On se préoccupe alors d'allouer un canal de trafic au mobile. Après consultation de la BTS le BSC choisit un TCH, donne à la BTS l'ordre de le rendre actif, puis envoie une message fournissant au mobile les coordonnées du canal alloué. Après l'établissement de cette liaison, le réseau est informé de l'allocation d'un TCH au mobile. A partir de cet instant C'est le canal FACCH qui sera utilisé pour échanger le reste de la signalisation nécessaire pour mettre en relation le demandeur et le demandé. Cette phase est suivie de la sonnerie du demandé. Enfin, au décrochage du demandé la conversation des deux usagers est entamée.



23

3.4 Les Interfaces: 3.4.1 L’interface Um (Radio) : L’interface radio représente le maillon faible, sensible de la chaîne de transmission qui permet de lier un utilisateur mobile au réseau. C’est sur cette interface que le système doit faire face aux différents problèmes (atténuation, interférences, etc…). Afin de rendre plus résistant ce maillon, nous devons prévoir un nombre de fonctions de contrôle de nature variée pour assurer l’accessibilité au réseau et la continuité lorsque l’utilisateur est en communication. L’interface Um se située entre le mobile et la BTS, assure le transport de la parole ou données à 13 Kbits/s utile pour la communication. La transmission de signaux de gestion du trafic et des mobiles .Elle s’appuie sur le protocole LAPDm (Link Access Protocol on the Dm Channel) et utilise comme support l’onde électromagnétique. Le premier service qu’offre un réseau GSM est un service de parole de type téléphone. C’est le plus important en volume aujourd’hui. La transmission de la parole neccéssite simplement des « tuyaux » synchrone durant une communication. Ces tuyaux synchrones sont les canaux de trafic (TCH, Traffic Channel). Le fonctionnement du canal TCH nécessite des canaux logiques. L’interface radio permet d’offrir un certain nombre de canaux TCH qui transporte des données utilisateur, les autres sont des canaux de contrôle (SACCH, FACCH,…). 3.4.2 L’interface Abis : Cette interface assure le transport de la parole ou données à 16 Kbits/s par communication entre la BTS et le BSC pour la gestion du trafic radio et l’exploitation et la maintenance des stations de base. Elles s’appuie sur le protocole LAPD (Link Acces Protocol on the D Channel) et utilise comme support les liaisons louées 2,048 Mbits/s. 3.4.3 L'interface A: Elle se située entre le BSC et le MSC, cette interface assure le transport de la parole ou des données à 64 Kbits/s. Elle s’appuie sur le protocole sémaphore N°7 du CCITT et utilise comme support les liaisons MIC à 2,048 Mbits/s.



24



25

1. Les indicateurs de qualité de service :

1.1 Notions de compteurs et indicateurs :

1.1.1 Notion de compteurs : Afin de faciliter la gestion et rendre fiable le réseau les constructeurs incorporent des compteurs au sein de leurs équipements (BSC). Le principe est de compter pour une durée donnée les évènements qui se produisent sur les interfaces. Les compteurs permettent de comptabiliser les indicateurs. Il comptabilise chaque événement qui se produit sur le réseau. Nous pouvons définir qu'un compteur un outil qui permet d'enregistrer chaque évènement qui se déroule sur le réseau.

1.1.2 Définition d’indicateur : Un indicateur est un outil simple qui permet d’observer périodiquement les évolutions d’un phénomène, en le positionnant par rapport à des objectifs fixés. Nous pouvons donc dire que c’est un instrument de mesure. Un indicateur s’obtient à partir des compteurs.

• Pourquoi l’indicateur qualité ? Une question que nous tenterons de répondre de la manière suivante : Supposons un conducteur qui se met en route pour une destination sans aucune information sur la voiture qu’il conduit: c’est à dire pas d’indicateur de vitesse, pas de niveau d’essence, pas de voyant de pression d’huile, etc … Il risque de rouler à un excès de vitesse qui peut causer un accident. Alors que la présence de l’indicateur de vitesse pouvait le situer sur l’évolution de la vitesse à laquelle il roule. Ou soit en pleine autoroute, la voiture s’arrête. Et il constate que le réservoir à essence est vide. Il aurait pu éviter ces problèmes avec la présence de niveau d’essence. Le conducteur pouvait éviter tout problème pouvant mettre en cause sa voiture ainsi que sa santé. Cet exemple illustre la nécessité d’avoir un retour d’information sur la qualité obtenue pour mieux mener les actions. Un indicateur permet donc de faire un suivi qualité du réseau.

• Quelques critères d’un indicateur qualité : Un indicateur qualité doit répondre à plusieurs critères pour être efficace, c’est à dire :

⇒ Être pertinent : c’est à dire il doit répondre à un besoin. ⇒ Être simple : dans sa conception, sa mise en œuvre et sa représentation, et

surtout compréhensible. ⇒ Être reproductible : il est très souvent judicieux de suivre l’évolution d’un

indicateur dans le temps pour apprécier l’efficacité des différentes actions engagées.

⇒ Être fiable pour être crédible



26

⇒ Être rentable : c’est à dire il ne doit pas occasionner de coût trop important dans sa construction et son utilisation.



27

La communication sur un réseau nécessite l’accès à ses ressources de signalisation et de la parole. Les deux phases nécessaires pour communiquer sur un réseau sont : L’accessibilité et le continuité.

1.2 Accessibilité au réseau : L’accessibilité désigne le caractère possible de la liberté de déplacement dans l’espace, d’utilisation d’outils, et de compréhension. En GSM l’accessibilité est la possibilité d’accès au réseau. C’est la phase pendant laquelle le mobile tente à accéder au canal SDCCH. L’accessibilité est composée des phases suivantes:

⇒ La phase d’établissement de la liaison radio ⇒ La phase d’utilisation du canal SDCCH ⇒ La phase d’assignation TCH

La première étape d’établissement d’un appel est d’avoir accès à la liaison radio. C’est une liaison très complexe (interférence, environnement,…)

• La phase d’établissement de liaison radio :

Dans un système de communication radio-mobile l’interface la plus délicate à gérer, à cause notamment de ses caractéristiques très fluctuante, est l’interface radio. La phase d’établissement de liaison radio est la phase d’accès au canal SDCCH. C’est pendant cette phase que pourrait se produire un incident sur le canal SDCCH. Cette liaison radio se situe entre le mobile et la BTS. Les indicateurs qui pourraient déceler des incidents pendant cette phase d’établissement de la liaison radio sont: SDCCH congestion, SDCCH Radio Frequency Access Failure et SDCCH Access Failure BSS. Chacun de ces indicateurs présente des causes succeptible de provoquer l’incident.

⇒ SDCCH congestion : Cet indicateur représente l’état congestion (manque de ressource) sur le canal SDCCH. Le seuil est de 0,5% . Tout taux supérieur à 0,5% est considéré comme une indication d’incident sur la cellule. Les principales causes de cette congestion sont :

• Manque de ressource radio: C'est-à-dire que lorsqu’il y a peu de canaux SDCCH par rapport au nombre de tentative d’appel.

• Tentative d’appel élevé • Nombre important de mise à jour de localisation

⇒ SDCCH RF (Radio Frequency) Access Failure :

C’est l’indicateur qui représente l’état d’échec radio (problème radio) sur le canal SDCCH. Les principales causes de cet échec radio sont :

• Mauvaise couverture • Interférence de fréquence (par exemple en downlink) En cas d’échec radio, le mobile continu à envoyer des requêtes sur le canal SDCCH. Ce qui engendre la congestion sur le canal SDCCH.

C’est l’indicateur qui permet de déterminer les coupures de signalisation dans une cellule. Le seuil est de 1% . Tout taux supérieur à 1% est considéré comme une indication d’incident sur la cellule.



28

. ⇒ SDCCH Access Failure BSS :

C’est l’indicateur qui représente des problèmes matériel ou logiciel. Dans ce cas les incidents se situent entre la BTS et le BSC. Le plus souvent lorsque le taux observé est supérieur à 25% pour les SDCCH Fail et supérieure à 1% pour le SDCCH Drop. Nous avons dons des incidents Sur le canal de signalisation. Quelque fois il suffit de faire "reset" au niveau logiciel pour que le TRX fonctionne correctement. Sinon il est remplacé par un autre TRX La figure ci-dessous illustre l’accès à la liaison radio.



29

Figure 6: Phase établissement de la liaison radio

Problème BSS

Causes GPRS

REQUËTE

Causes invalide GPRS/GSM

Causes valide GSM

Tentative Echec de préparation

Congestion

Echec de l’exécution

Succès

Echec d’accès radio

Problème BSS

Evènements possible



30

• La phase d’utilisation du canal SDCCH :

Après avoir accédé au canal SDCCH. On arrive à sa phase utilisation. C’est la phase qui précède celle de l’assignation du canal TCH. L’indicateur SDCCH Drop représente l’état de coupure sur le canal SDCCH. Les principales causes d’échec d’utilisation de ce canal SDCCH sont:

• Les problèmes radio (échec de la liaison radio,..) • Les problèmes BSS (matériel ou logiciel,…) • Echec d’handover (problème matériel ou logiciel, échec de la liaison radio)

Figure 7 : phase d’utilisation du canal SDCCH

• La phase d’assignation du canal TCH : C’est la phase d’accès au canal TCH. Elle suit la phase d’utilisation du canal SDCCH. Le principal rôle du GSM étant de transmettre la voix via le canal TCH. L’indicateur nous permettant de suivre le bon fonctionnement de ce canal est donc une priorité dans le warning. Il permet de déterminer les échecs d’allocation du canal TCH. Le seuil est de 10%. Tout taux supérieur à 10% est synonyme d’incident. TCH Fail radio : Ces indicateurs permettent de voir les échecs d’allocation du canal TCH. Les causes principales sont des incidents radio ou incidents BSS (matériel ou CICs défaillants). Généralement la cause est due au disfonctionnement d’un ou des TRX.

Coupure normale

SDCCH connexion

Phase d’assignation TCH SDCCH Drop

Drop radio

Drop HO

Drop BSS




31

Quand au TCH Fail Congestion, il nous permet de voir si la cellule est congestionnée ou pas. Les causes principales sont : -TRX en défaut : C'est-à-dire qu’il y a des TRX parmi les quatre qui ne trafiquent pas correctement ou qui ne trafiquent pas du tout. Dans ce cas les TRX trafiquant n’arrive pas à supporter le trafic. Alors on parle de congestion. -Nombre de TRX insuffisant : Dans ce cas le trafic écoulé ne peut pas être géré par les TRX en Fonction, on parlera aussi de congestion. Alors dans ce cas il faudra ajouter des TRX ou soit mettre en service s’il y a un TRX qui avait été arrêté lors d’une intervention. Les principales causes d’échecs de cette phase sont:

⇒ congestion : c’est l’affluence d’appel qui gène la cellule. Lorsque la cellule est très sollicitée et qu’elle ne dispose pas de ressources nécessaire pour répondre à ces sollicitations. On parle de congestion et elle est provoqué suit au cause suivante : • Le fil d’attente n’est pas permis et est sollicité • Le fil est long • Manque de ressource du canal TCH sur l’interface Abis • Indisponibilité de canal RTCH (Random Access Channel, canal de control

partagé par un ensemble de mobile et leur permettant de se signaler au réseau pour demander un service particulier)

⇒ Radio: Ces problèmes sont liés à la radio. Les principales causes sont : • Mauvaise couverture • Interférence • Bilan de puissance

⇒ BSS: Au niveau BSS les problèmes sont liés soit au matériel ou logiciel. Généralement ce sont des problèmes de TRE ou TRX.



32

Figure 8 : Phase d’assignation du canal TCH

Afin de garantir une accessibilité au abonné nous utilisons les indicateurs suivants: SDCCH Fail, SDCCH Drop, TCH Fail

REQUËTE


Echec d’accès radio

Problème BSS

Succès

Echec de l’exécution

Congestion

Problème BSS

Echec de la REQUÊT

Tentative



33

1.3 La Continuité : La notion de continuité sert à décrire des phénomènes qui ne saute pas brutalement, mais évoluent progressivement. • Les phases sonnerie et connexion :

Après l’assignation complète du canal TCH. On passe à la phase sonnerie, suivi de la phase connexion. C’est la dernière phase avant la communication Durant cette phase de sonnerie il peut y avoir des incidents de coupure dus au:

⇒ Drop radio ayant pour cause les problèmes radio ⇒ Drop TC (TransCodeur) ayant pour cause les problèmes au niveau du

Transcodeur ⇒ Drop BSS ayant pour cause des problèmes interne au BSS à l’exclusion du

TC. Ces problèmes se situent entre la BTS et le BSC. ⇒ Drop HO ayant pour cause l’échec des Handover ⇒ Drop preemption (priorité de coupure) ayant pour cause coupure du TCH d’un

abonné au profit d’un autre prioritaire.



34

Figure 9 : phase de la sonnerie

Connexion TCH

Evènements possible Call Drop HO

Call Drop BSS

Call Drop prioritaire

Call Drop radio

Problème interne au BSS

TC

Coupure anormale NSS

Coupure normale

Succès HO

Call Drop



35

En GSM lorsqu’un mobile communique sur le canal TCH. Des phénomènes ne doivent pas interrompre la communication brutalement. Lorsque des précautions sont prises pour éviter l’interruption de la communication. Alors on parle de continuité. L’échec de cette continuité est représente par l’indicateur Call Drop . C’est l’indicateur qui permet de déceler les coupures d’appel dans une cellule. Le seuil est de 2%. Les Call Drop peuvent être dus aux problèmes BSS ou radio. En fonction des mesures apportées par la section design radio et les conclusions des analyses de la section qualité service , la section optimisation est chargée d’optimiser les ressources radio afin d’améliorer la qualité et la capacité du réseau. Ces actions sont menées de façon quotidienne. Généralement les incidents sur le réseau sont provoqués par un/des TRX en panne ou MIC défaillants. Concernant l’indicateur Traffic & Call Duration, il n y a pas de seuil définit comme les autres indicateurs. C’est l’analyse du trafic sur chaque TRX qui nous permet de savoir si un TRX trafique ou pas. Il suffit de comparer le trafique sur tout TRX et déduire celui qui ne trafique pas ou soit qui trafique pas correctement. Avant de communiquer sur un réseau, il faudra y accéder. D’où le terme accessibilité au réseau. Lorsqu’on a accès, commences la phase de signalisation. Elle est suivie par la phase communication. Les principales causes de cet échec sont:

• des incidents sur l’interface Abis • des problèmes matériels ou logiciels au niveau du BSC • des problèmes matérielles ou logiciels au niveau de la BTS • Drop preemption (priorité de coupure) ayant pour cause coupure du TCH

d’un abonné en communication au profit d’un autre. Lorsque le problème d’accessibilité est résolu, la continuité devient un facteur très important. C’est le cas d’un abonné en communication lorsqu’il change de cellule (handover). Le fait de changer de cellule ne doit pas impacter sur la communication. Pour assurer cette continuité. Nous utilisons les indicateurs Drop TCH et Call Drop afin de déceler les incidents. Les Drop TCH permettent de voir le taux de coupure pendant la communication. Le seuil est de 0,1%



36

2. Présentation des outils d’analyse qualité : 2.1 NPA (Network Performance Analyser) :

2.1.1 Définition : C’est une application qui permet de mieux suivre la qualité de service à partir des indicateurs qualités. Il est connecté à l'OMC-R et permet de déceler les incidents sur les interfaces Um (radio) et Abis. C’est un produit ALCATEL. Il fournit les données obtenues sous forme de graphe ou de données, le résultat dépendra de l’utilisateur. Elle est attachée à la base de donnée via NPR.



37Figure 10: Page de recherche d’incidents sur NPA



38

2.2 RNO (Radio Network Optimisation): 2.2.1 Définition: RNO est un outil ALCATEL qui permet le diagnostique des problèmes plus fins sur le réseau à temps différé. Il est connecté à l'OMC-R. Il collecte les données de l’OMC-R. Il traite ces informations pour permettre la configuration des ressources radio, pour mettre au point des paramètres radio.



39



40

Figure 11 : Page de recherche d’incidents sur RNO



41

Le schéma ci-dessous illustre les relations entre les outils et les interfaces radio, Abis et A du réseau BSS.

Figure12 : connexion des outils RNO, NPA et CIGALE au BSS L’OMC-R est connecté au BSC afin de prendre les différentes données se trouvant au niveau du BSC. Rappelons que les compteurs au niveau du BSC comptabilisent les différents évènements. C’est à partir de ces compteurs que s'obtient les différents indicateurs. NPA est connecté à L’OMC-R. Au sein du QPG NPA permet de faire remonter les données sur le réseau via l’OMC-R. A956-RNO importe les données de NPA à son niveau sous forme de graphe ou donnée. A partir de A956-RNO il est possible de faire des configurations, puis de les envoyer à l’OMC-R qui les l’achemine au NPA. Enfin les données sont analysées sur RNO et NPA. 2.3 AGIIR: (Analyse et Gestion des Incidents et des Interven tions sur le Réseau) 2.3.1 Définition : C’est l’outil utilisé pour assurer le suivi des incidents sur le réseau. Lorsqu’un incident survient sur un élément du réseau, le technicien de suivi qualité le détecte puis crée un ticket sur AGIIR et le transmet à la bonne entité de maintenance (OMC-R).

BTS

MSC BSC

NPA RNO

OMC-R

A Abis

Um

OCEAN

CIGALE



42



43

Figure 13 : Page d’accueil AGIIR



44

2.4 CIGALE (Contrôle d’Interface Généralisée A part ir de Lecture d'Enregistrement) : 2.4.1Définition: C’est également un outil de suivi, gestion, supervision du réseau GSM connecté sur l’interface A et GPRS (General Packet Radio Service). C'est un produit ASTELLIA Dans le cadre de mon stage je n’ai pas acquis l’expertise de CIGALE proprement parler. C’est en étudiant et en pratiquant sur le warning que j’ai été amené à comprendre les principales fonctionnalités de CIGALE.



45



46

Figure 14: Page d’accueil CIGALE



47

Puisque RNO et NPA ne permettent pas de voir les CICS défaillants. Nous utilisons CIGALE pour ce traitement. En observant le schéma ci-dessous les CICs défaillants sont déterminés de la manière suivante : Observons les colonnes nommés : MSC, BSC, CIC number, Number of allocations et Nb Clreq EF. Nous avons: La colonne MSC:elle contient le nombre de MSC La colonne BSC: elle contient Le numero du BSC La colonne CIC number : elle contient le numero de CIC La colonne Number of allocation : elle contient le nombre d’appel émis La colonne Nb Clreq EF: elle contient le nombre d’é chec d’appel Pour la détermination des CICs défaillants, on procède par le rapport Nb Clreq EF/Number of allocation . Le résultat est exprimé en pourcentage (%). Lorsque le pourcentage est élevé on considère le CIC correspondant défaillant. Une autre façon plus simple de déterminer les CICs est de comparer le nombre d’appel émis à celui d’échec d’appel. En observant les données de CIGALE. Nous pouvons affirmer que les quatre premiers CICs sont défaillants. Pour le premier CIC, le rapport Nb Clreq EF/Number of allocation nous donne 685/877=78%. Nous constatons que le taux d’échec d’appel est très hausse sur ce MIC. Alors nous mentionnons que ce CIC est défaillant. On précise n suite le MIC et Time Slot (TS) de la manière suivante : Pour le premier CIC on a BSC_N 6 0042/31. La notation est de la forme BSC_Numero Point Sémaphore Numéro MIC/Numéro IT. Numéro MIC est égal à n+1. Chaque numero Point Sémaphore (PS) correspond à un numero de BSC. Ainsi pour la détermination du premier CIC défaillant on a : BSC 5 MIC 43 IT 31 (n=42 →Numero MIC=43, PS 6=BSC 5). Voir la correspondance entre BSC et PS à l’annexe 1. De façon analogue Le deuxième CIC défaillant est BSC yakro MIC 38 IT 13, Le troisième CIC défaillante est BSC San-Pédro MIC 37 IT 26, En fin le quatrième CIC défaillant est BSC 2 MIC 15 IT 4.



48

Figure 15 : Page de détections des CICs défaillants (données)



49

Il est possible d’obtenir les CICs défaillants par le graphe ci-dessous. Il est plus simple avec les données que le graphe de déterminer le CIC défaillant. Mais le graphe permet une bonne compréhension du résultat sous forme de données



50

.

Figure 16: Page de détections des CICs défaillants (graphe)



51

CIGALE permet aussi de traiter le warning. Tous ces outils comportent des indicateurs qui nous permettent d’analyser le comportement des cellules. Les plus pratiques sont NPA et RNO.

3. Présentation du document warning et la procédure d’édition : De façon quotidienne les incidents du réseau du jour ‘’j-1‘’ sont décelés au jour ‘’j’’ via des outils de gestion du réseau. Warning (mot anglais signifiant avertissement) est le nom d’un onglet se trouvant sur l’outil NPA. Le warning est le nom donné par OCI à sa procédure de détections d’incidents sur réseau.

3.1 Présentation du document warning : Le warning est édité sur l’application Excel. Il comprend trois rubriques nommées respectivement Problèmes résolus, Amélioration et Anomalies .

⇒ La rubrique Problème Résolu: C’est la rubrique qui contient les cellules fonctionnant sans incidents. Elle contient également des cellules déclarées bonne mais pourtant des incidents persiste dans ces cellules. Par exemple le cas d’un TRX (incident fréquent) qui ne trafique pas.

⇒ La rubrique Amélioration : Celle-ci contient les cellules dont les actions menées ont réduit le problème. On trouve souvent des cellules qui trafiquent malgré la présence d’un l’incident.

⇒ la rubrique Anomalie : Cette dernière rubrique contient les cellules dont l’incident a provoqué l’arrêt des trafiques.

Dans chaque rubrique deux parties sont consacrées à la déclaration des TRX et des faisceaux (CICs défaillants) défectueux.



52

Figure 17: Exemple de document warning



53



54

Les cellules sont notées comme suit : Pour les cellules 1800 : NOM .CELLULE_BANDE-SECTEUR Exemple : KORHOGO_1800-1 Pour les cellules 900 : NOM .CELLULE-SECTEUR Exemple : KORHOGO-1 3.2 Description de la procédure actuelle du warning : La procédure d’édition du warning actuel se présente comme suit : � Mise à jour du warning de la veille (jour J-1) � Détection de nouveaux incidents avec NPA � Création de ticket d’incident avec AGIIR � Traitement du ticket d’incident

. 3.2.1 Mise à jour du warning de la veille: jour ″J-1″ : La qualité d’un réseau étant incontournable pour tout opérateur. Le suivi qualité quotidien d’un réseau demande une grande attention sur son comportement. Pour répondre au suivi de cette qualité. On procède par une mise à jour du warning de la veille. La mise à jour consiste à traiter cellule par cellule la rubrique Anomalie en mettant à jour les valeurs des indicateurs et les TRX défectueux sur la cellule avec RNO et NPA. Ensuite les CICs défaillants sont déterminés avec CIGALE. Les indicateurs utilisés sont:

• SDCCH Fail/ SDCCH Radio • TCH Fail Radio/Drop/Congestion • Call Drop BSS/Radio • Traffic & call duration

Au cours de l’observation des indicateurs, lorsqu’une cellule ne présente pas d’anomalie, elle est signalée dans la rubrique Problèmes résolus. Lorsque l’incident persiste, la cellule demeure dans la rubrique anomalie en mettant à jour le taux de l’indicateur. Les CICs (Circuit Identification Code) et TRX défaillants sont déterminés respectivement à partir de CIGALE et NPA. 3.2.2 Détection de nouveaux incidents sur le rése au : . Les nouveaux incidents sont visibles sur NPA à partir de l’onglet warning de l’application Alcatel-Metrica/NPR-DICO. Toutes les cellules montrées par NPA représentent les cellules impactées. Ce sont les cellules où les taux d’indicateurs sont supérieurs aux seuils fixés. Seule les cellules aux taux plus élevés ne figurant pas dans la rubrique Anomalie sont checker1, et ajoutées à cette rubrique.



55

3.2.3 Création de ticket d’incident avec AGIIR: Un ticket d’incident est un fichier créé dans AGIIR lors de la détection d’un incident sur une cellule. Il contient les informations relatives à l’élément du réseau impacté et à l’incident survenu. Une fois renseigné, il est transmis via AGIIR à l’entité responsable de la réparation. Trois évènements peuvent être à l’origine de la création d’un ticket :

• Signalisations clients • Alarmes qualifiées (détection d’incidents en temps réel) • Alertes qualité de service (détection en temps différé, Optimisation du réseau)

Le troisième évènement est à l’origine des tickets crées au sein De l’Unité Service Qualité. La création des tickets se fait par tri des cellules (cellules présentant des incidents persistants).

.

Checker : Recherche d’incident sur une cellule ou dans une zone



56

Figure 17: Page de création de ticket d’incident AGIIR

Bandeau comprenant les informations principales

Corps du ticket à renseigner



57

3.2.4 Traitement du ticket d’incident: Une fois le ticket créé, il existe deux moyens de le traiter :

• En effectuant des télé-actions à distance : ces actions sont menées à l’OMC. Exemple : Arrêt ou mise en service d’un TRX. Configuration de canal SDCCH ou TCH selon l’incident observé. Dans ce cas il faut créer une action sur le ticket et renseigner les champs de la page d’action (type d’action, urgence, commentaire, etc.), afin de décrire l’action et les conditions dans lesquelles elle doit être réalisée.

• En transférant la responsabilité du ticket à une autre entité qui devra mener

soit des télé-actions ou une intervention sur site (remplacement d’un TRE)

Dans ce cas il faut créer une intervention sur le ticket et renseigner les champs de la page d’intervention. La responsabilité du ticket est ensuite transférée à une autre entité, qui sera en charge de réparer l’incident en fonction des données entrées par le créateur du ticket.

Lorsque l’incident demande l’intervention du fournisseur. Une demande d’intervention est envoyée au fournisseur ALCATEL. Le ticket passe alors à l’état en cours de traitement. Une fois toutes les actions et interventions terminées, le technicien en charge du ticket a une responsabilité de reporting sur la résolution du problème. Il doit préciser par exemple les dates d’intervention sur site et de rétablissement de l’incident, ou encore préciser la cause de l’incident et introduire au besoin un commentaire. Il passe alors le ticket à l’état « traité ». Dans le cas d’un transfert de responsabilité, le ticket est rendu au créateur. Celui-ci est responsable de la vérification de la résolution de l’incident et des différentes dates entrées dans le ticket. Ceci fait, il passe le ticket à l’état validé. Le ticket est finalement clôturé. Il sera alors historisé pour consultations ultérieures et calculs d’indicateurs de performances.



58



59

Dans cette troisième partie nous aborderons le volet analyses et critiques de l’existant. Puis nous terminerons par le volet propositions de solutions. 1 Analyse et critique de l’existant : 1.1 Analyse et critique des outils:

Les outils existant ne présentent pas d’obstacles dans leurs formats actuels pour un bon suivi qualité. 1.1.1 RNO : RNO est intéressant pour l’historisation. Il permet de faire une analyse plus approfondie des problèmes. On trouve les indicateurs nécessaires pour détecter les incidents. L’outil RNO vient de subir une migration. Les options ajoutées à la dernière version 4.0 n’ont pas été expliquées aux utilisateurs. De décembre 2005 à juillet 2006 RNO a connu deux migrations.

• La première migration : Cette migration a apporté deux options à la précédente version. Ces options sont:

⇒ Busy Hours GSM : c’est l’option qui permet de voir les données d’une cellule par jour pour une période précise sur le réseau GSM.

⇒ Busy Hours GPRS : c’est l’option qui permet de voir les données d’une cellule par jour pour une période déterminée sur le réseau GPRS.

Ces options sont utilisées dans la recherche d’incident. Par contre les nouvelles options intégrées par la seconde migration (juillet-août 2006) ne sont pas encore utilisées par faute d’information.

• La seconde migration: Cette migration a également apporté des options qui pourront faciliter le suivi qualité

⇒ Trend on Hours of day : Elle permet d’observer l’état d’une cellule pour une heure du jour « j-1 » (entre 0 heure et 23 heure).

⇒ Trend on Hours of week : Elle permet d’observer l’état d’une cellule pour une heure pendant une journée précise de la dernière semaine.

⇒ Trend on day of week : Elle permet d’observer l’état d’une cellule pour une journée précise de la dernière semaine.

⇒ Trend on day of month : Elle permet d’observer l’état d’une cellule pour une journée précise du dernier mois.

Ces options ne sont pas utilisées dans la gestion du réseau. RNO nous donne souvent des valeurs négatives. Ceci est dû aux données erronées enregistrées sur le serveur. 1.1.2 NPA: Outil performant utilisé pour la détection systématique des incidents. Le point faible de NPA est qu’il ne permet pas de voir les CICs en fautes. Par contre il est très approprié à la détection des TRX défectueux. L’indicateur utilisé pour



60

détecter les TRX défectueux n’est pas approprié. Car avec cet indicateur on obtient les données en terme de durée de communication. 1.1.3 AGIIR: Le principal rôle d’AGIIR est de suivre l’évolution des différents incidents. L’application est simple en soi, facile à exploiter. Malheureusement l’application n’est pas exploitée comme il le faut pour assurer un bon suivi qualité du réseau. Certes certains incidents sont résolus sans création de ticket. Peu de tickets sont crées lorsque nous faisons une comparaison aux nombres d’incidents quotidien qu’on observe via les outils de gestion. La création des tickets permet un suivi des actions crées par le warning. L’évolution du traitement des incidents est plutôt fait généralement par des échanges de mails entre le QPG et les entités compétentes pour la résolution des problèmes. Malgré sa fonction de suivi des actions AGIIR ne permet pas de ressortir un tableau de suivi des actions. Un tel tableau est nécessaire lors des évaluations de performance du réseau. 1.1.4 CIGALE: CIGALE permet de déceler les CICs (Circuit Identification Code) défaillants et peut servir au traitement du warning, mais RNO et NPA sont mieux adaptés. Il permet de voir le taux de rejet et de réussite d’appel. Il permet une analyse plus fine des problèmes rencontrés à travers une analyse protocolaire de l’interface A. Une de ces limites est qu’il ne permet pas de voir les TRX défectueux. 1.2 Analyse et critique du document warning: Au point de vue format du fichier warning: Le format actuel du fichier doit être changé. Car il ne permet pas un suivi correctif des actions. Ce format est inexploitable par d’autre entité, car la compréhension est malaisé. Les cellules 1800 sont mélangées aux cellules 900 lors du traitement du warning. Le fichier n’est pas renseigné comme il se doit. Alors il est impossible de retrouver une solution à un problème antérieure afin de résoudre ce problème dans le futur. Les différentes rubriques du fichier warning sont :

• La rubrique Problèmes résolus : C’est la rubrique qui contient les problèmes résolus. Elle n’est pas mise à jour de façon régulière. Pourtant des cellules où les incidents ont disparu y sont ajoutées. Certaines cellules ne présentant pas d’incidents à la veille peuvent présenter des incidents le lendemain. Alors celles-ci doivent être supprimées de la rubrique Problème résolus afin de les mentionner dans la rubrique Anomalie. Malheureusement cette rubrique est rarement traitée. Nous retrouvons dans cette rubrique des cellules présentant des incidents qui sont fréquemment dû aux perturbations du trafic sur les TRX ou aux MICs défaillants.

• La rubrique Amélioration :



61

Elle contient les cellules où des améliorations sont constatées sur le problème. Malheureusement cette rubrique est inexploitée. Ceci engendre des problèmes de mise à jour. Elle permet de ranger les cellules dont les actions menées n’ont pas résolu totalement le problème. Mais néanmoins elles trafiquent. Ce sont des cellules à suivre de près car elles peuvent arrêter de trafiquer d’un moment à un autre.

• La rubrique Anomalie : C’est la rubrique qui contient les cellules impactées. La rubrique Problèmes Résolus n’est pas mise à jour. Par conséquent la mise à jour de la rubrique Anomalie n’est pas véritable. Nous rencontrons généralement les mêmes incidents sur les cellules. C'est-à-dire -Fautes matérielles (TRX, CICs défaillants,…) -congestion radio -Problème de couverture (fréquent à l’intérieur) 1.3 Analyse et critique de la procédure de traiteme nt du warning: La procédure actuelle d’édition du warning est fastidieuse. Elle ne permet pas d’optimiser le warning. Par exemples:

• Vérifier la rubrique Anomalie sans déceler les nouveaux problèmes complique le traitement.

• Lors de la détection des nouveaux problèmes, le choix de cellule par taux élevés laisse d’autres cellules avec leurs anomalies.

• Le tri de cellule lors de la création de ticket ne permet pas un suivi des actions créé par le warning.

L’édition du warning doit être prompt, puisqu’elle doit être envoyé au plus tard à 10 heure du jour ″J″. Le bon suivi qualité passe par une bonne procédure de traitement du warning. 1.4 Analyse et critique de la création de ticket : AGIIR est une application conçue pour la gestion des incidents sur le réseau. Par conséquent la création des tickets doit être proportionnelle aux incidents observés. La négligence de créations de tickets aux profits des échanges de mails doit être arrêté. Car le suivi des problèmes sur le réseau ne peut pas être assuré par échange de mails. L’application appropriée pour le suivi des actions est AGIIR. Les différents champs à renseigner sur la page de création de ticket garantissent le suivi et la gestion des actions créés par le warning. 1.5 Analyse et critique du suivi des actions: Le suivi des actions est important après le traitement du warning. Car il s’agira de suivre l’évolution des incidents déceler sur le réseau. C'est-à-dire voir si les incidents repérés ont été résolus ou demeurent. Les actions créées par le warning sont gérées par échange de mails entre les différentes entités. Certains problèmes sont résolus par mails. Ce suivi des actions par échange de mails ne permet de résoudre de manière efficace les problèmes car elle ne permet de suivre par étape leurs résolutions. La description des problèmes n’est pas exhaustive dans les mails.



62

2. Propositions d’optimisation du warning et suivi des actions: 2.1 Propositions d’optimisation du warning: 2.1.1Les outils: Il serait intéressant de maîtriser les outils afin d’éditer de façon correcte et rapide le warning. Nos propositions qui vont suivre sont à courts termes. Ces solutions peuvent être mis en œuvre dans l’immédiat afin d’optimiser le warning.

• NPA: Nous proposons d’utiliser NPA pour le traitement du warning. L’avantage que nous offre NPA est de donner toutes les cellules impactées et d'importer ces cellules impactée sur excel.

• AGIIR:

Il n’est pas utilisé à sa juste valeur ce qui engendre un mauvais suivi des incidents. Nous proposons de créer un nombre de ticket proportionnel aux nouveaux problèmes. Puis intégré une application qui permettra de ressortir un tableau de suivi qualité des actions. Ce tableau est nécessaire pour faire un point sur la performance du réseau.

• CIGALE: Bon outil pour une analyse plus fine des problèmes. Nous proposons d’utiliser davantage CIGALE en plus des CICs défaillant qu’il nous montre. En plus de RNO nous proposons l’utilisation de CIGALE dans l’analyse plus fine des problèmes. En plus de ces propositions à court terme, nous proposons une solution à long terme qui serait l’idéal. C'est-à-dire l’acquisition ou le développement d’une application unique qui rassemblera les données de RNO, NPA, et CIGALE. Il serait plus intéressant de traiter le warning puis faire le traitement du warning par zone. Vu la taille du réseau les techniciens procèdent par taux élevé sur les cellules lors du traitement du warning. C’est à dire voir uniquement les cellules qui présentent de grands incidents. Vu l’importance de la qualité du réseau et compte tenue de la première place qu’occupe Orange-CI sur le marché de la téléphonie mobile. Cette application serait nécessaire et indispensable au département QPG. Cette proposition nécessitera une charge financière. Mais sa réalisation rendra facile le warning. 2.1.2 Propositions de document warning: Les solutions que nous proposerons dans cette partie sont des solutions à court terme. Ces solutions devront être mise en œuvre afin d’optimiser le warning et de le rendre exploitable à toute entité concernée par le suivi qualité.



63

• la répartition des zones en zones 1800 et 900: Nous proposons de regrouper les zones par bande. C'est-à-dire regrouper par zones les cellules 1800 et 900. On pourra nommer ces zones : zone 1800 et zone 900 Ainsi nous trouverons dans la zone 1800 que des cellules 1800 et dans la zone 900 nous trouverons que des cellules 900. Nous proposons également la séparation des zones d’Abidjan à celles de l’intérieure du pays comme suit : Abidjan_1800 Abidjan_900 Interieur_1800 Intérieur_900 Nos motivations pour ce choix sont :

⇒ Faciliter la recherche des cellules : Lorsqu’on a besoin des informations sur l’état d’une cellule. On prend comme référence le plus récent warning. L’organisation des cellules indiquées ci-dessus facilitera les recherches de cellules.

⇒ Faciliter les rapports hebdomadaires qui doivent contenir des données de certaines cellules.

Afin de rendre cohérent la proposition de subdivision par zone au document warning. Nous proposons un nouveau format du document warning. Notre format comprend six rubriques au lieu de trois du format actuel. Nous avons défini les rubriques en fonction des principaux aspects du réseau. Lorsque nous remplissons le fichier, nous déclarerons que des problèmes observés en renseignant parfaitement les différents champs concernés. L’entité chargée de mener les actions doit renseigner le fichier de ses actions menées. Ces rubriques sont:

• La rubrique Accessibilité : Dans cette rubrique nous déclarerons que des problèmes d’inaccessibilité au réseau à l’aide des indicateurs d’accessibilité.



65

Figure 18: Nouveau format warning (zones 1800\ rubrique accessibilité)



66

• La rubrique Continuité



67

Dans cette rubrique nous déclarerons que des problèmes de continuité au réseau à l’aide des indicateurs d’accessibilité.

Figure 1 9: Nouveau format warning (zones 1800\ rubrique continuité)



68

• La rubrique trafic : Dans cette rubrique nous déclarerons que des cellules qui ne trafiquent pas.



69

Figure 20: Nouveau format warning (zones 1800\ rubrique trafic) • La rubrique TRX défectueux : Elle contient les TRX défectueux de chaque cellule :

Figure 21 : Nouveau format warning (zones 1800\ rubrique TRX défectueux)



70

• La rubrique CICs défaillants: C’est dans cette rubrique que les MICs défaillants sont déclarés avec leurs BSC correspondant.

Figure 22: Nouveau format warning (zones 1800\ rubrique CICs défaillants)



71

• La rubrique nombre d’incident : Cette rubrique en tant que telle ne concerne pas le warning. Nous avons les nombres d’incidents résolus en zone 900 et 1800. Cette rubrique est utilisée pour renseigner le rapport hebdomadaire. Elle facilite le dénombrement des incidents résolus et non résolus en fin de semaine. Nous avons intégré cette rubrique sur le fichier warning car il est plus facile de compter les incidents résolus et non résolus juste après le traitement du warning.



72

Figure 23 : Nouveau format warning (zones 1800\ rubrique nombre d’incidents)



73

Le nouveau format nécessitera un partage de tâche lors du traitement du warning. Nous proposons au moins deux personnes, sinon trois pour le traitement du warning. Certes cette proposition nécessitera du personnel d’où une charge pour OCI. Ce sont les conséquences, mais nous avons une citation qui dit : ″La qualité n’a pas de prix″. C'est-à-dire avec une meilleur qualité du réseau le nombre d’abonnés ne fera qu’augmenté. Car le souci du client est d’être satisfait par le service auquel il a accès. En téléphonie mobile le souci des clients est de pouvoir appeler et d’être appelés. Et c’est à l’opérateur concerné de les satisfaire

Les tâches seront reparties comme suit: Une personne chargée du traitement du warning de la zone 1800 (Abidjan _1800 et Intérieur_1800) Une autre personne pour le traitement de la zone 900 (Abidjan _900 et Intérieur_900). Enfin la personne chargée d’envoyer le fichier aux entités concernées ne fera que copier et coller la partie traitée par son collègue au sein de son fichier. C'est-à-dire : supposons que celle qui doit envoyer le warning a traité les zones 1800. Alors elle ne fera que copier le warning des zones 900 et les coller dans son fichier en respectant la casse de l’expéditeur. Nos motivations pour cette proposition sont :

⇒ Accommoder le fichier warning. ⇒ Rendre le fichier exploitable par une autre entité intéressé par les

données du warning. ⇒ rapidité d’édition du warning, ⇒ Augmenter la probabilité de traitement de toutes les cellules, ⇒ Rendre facile la recherche des cellules pour remplir les rapports

hebdomadaires. ⇒ Permettre au warning de suivre les actions qu’il crée.

2.1.3 Proposition de procédure d’édition du warning : Pour atteindre une meilleure qualité du réseau Orange-CI, l’USQ (Unité Service Qualité) a besoin d’une procédure optimisée pour l’édition du warning. Nous trouvons que la procédure actuelle de traitement du warning est fastidieuse. Dans cette optique d’optimisation nous proposons la procédure de traitement suivante:

• Détection des nouveaux incidents avec NPA • Mise à jour du warning de la veille (jour j-1) • Création de tickets d’incidents avec AGIIR • Traitement des tickets précédemment créés

. 2.1.3.1 Détection des nouveaux incidents avec NPA: Nous jugeons nécessaire d’entamer le traitement du warning par la détection des nouveaux problèmes. Les cellules impactées seront comparées avec ceux de la veille. Ainsi les nouveaux incidents seront ceux qui ne se trouvent pas dans le warning du jour.



74

Nous proposons les indicateurs suivant pour déceler les TRX défectueux • TRX TCH Traffic • TRX TCH Attempts • TRX SDCCH Traffic Avec ces indicateurs nous obtiendrons les données en terme de performance sur un TRX précis.

2.1.3.2 Mise à jour du warning de la veille (jour j -1): La mise à jour se fera par comparaison des anomalies de la veille aux nouvelles anomalies. Puis mentionner, dans la bonne rubrique et sous le bon indicateur. Les cellules nouvellement impactées qui ne sont pas dans le warning. On passe ensuite à la vérification des problèmes persistant des rubriques. C'est-à-dire voir si l’origine de l’incident est l’une des causes suivante:

⇒ Accessibilité; ⇒ Continuité; ⇒ Trafic; ⇒ TRX défectueux; ⇒ CICs défaillants. De façon ordonnée chaque rubrique doit être renseignée selon la nature du problème détecté.

2.1.3.3 Création de tickets d’incident avec AGIIR: La création de tickets concerne les nouveaux incidents. La création de tickets devient facile puisque les nouveaux incidents sont connus. Concernant les nouveaux problèmes du jour.

Nous proposons la création de tickets de façon proportionnelle au nombre d’incidents. Car elle permet un bon suivi des actions créées par le warning.

2.1.3.4 Traitement des tickets précédemment créés: Nous ne pouvons parler de traitement de ticket que lorsqu’il est crée. Le traitement des tickets précédemment crées est une priorité du suivi des actions. Il permet de connaître les incidents résolus et ceux qui persistent. Lorsque les tickets créés par la QoS sont acheminés à l’OMC-R. Nous proposons un traitement des tickets précédemment crées de façon quotidienne. Afin de faire un suivi des actions créées par le warning.

• Cas du week-end: Le trafic est moins élevé pendant le week-end que les jours ouvrables. Puisque celui du dimanche est traité le lundi. Le traitement du warning du week-end concerne le vendredi et le samedi. Nous avons deux alternatives : La première consiste à traiter le warning pendant le week-end et la seconde est de créer des tickets à l’OMC-R lors de la supervision du réseau pendant le week-end.



75

La première alternative est une charge pour Orange-CI. Car les périodes de traitement du warning par la QoS sera considéré comme des heures supplémentaires. Par contre une équipe chargée à l’OMC-R pour la supervision du réseau pendant le week-end peut s’en occuper. Donc nous proposons la deuxième alternative. C'est-à-dire l’équipe en service pendant le week-end doit créer des tickets sur AGIIR pour tout incident qu’il n’arrive pas résoudre. Ces tickets seront transmis à la QoS. Ainsi les tickets crées seront pris en compte lors du traitement du warning le lundi et le cas du warning sera résolus.

2.2 Proposition de suivi des actions: Comme nous le proposons au niveau des outils. AGIIR est l’application appropriée pour le suivi des actions. Au niveau de la QoS le ticket est constitué de différents champs à renseigner qui sont:

• Description • Short description • Historic Ces champs concernent l’incident en question.

Le champ "Description" permet de faire une description totale du problème. C'est-à-dire mentionner la cellule impactée, l'incident en question, date du début de l'incident. C'est dans ce champ que est noté toutes explications en relation avec l'incident. Cette description du problème permet à l'entité chargée de mener l'action de mieux connaître le problème et d'optimiser son temps de résolution de l'incident.

Le champ "Short description" permet de faire une courte description de l'incident Enfin le champ Historic permet d'ajouter un historique du problème au ticket. C'est à dire si le même problème a été constaté dans le passé. Ces trois champs bien renseignés donne une vue du problème et facilite la résolution de l'incident. Les principales entités qui permettent de faire le suivi des actions créées par le warning sont: la QoS et l'OMC-R Les autres entités concernées par le suivi des actions sont: les services optimisation radio, BSS et transmission. La QoS créée généralement les tickets pour chacun des nouveaux problèmes décelés et l'OMC-R qui reçoit dans un premier tant les tickets venant de la QoS. Le premier diagnostique que fait l'OMC-R est de voir si l'origine de l'incident est de type logiciel, matériel où paramétrage. Lorsque la résolution d'un incident implique selon l'origine du problème de façon logique une autre entité. L'OMC-R achemine le ticket à cette entité. Lorsque l'OMC-R détermine l'origine de l'incident. Elle intervient où achemine le ticket au service compétent.



76

Lorsque le problème est de type logiciel l'OMC-R intervient. Si c'est de type matériel le ticket est envoyé au service BSS et lorsque c'est de type paramétrage il est acheminé au service optimisation radio. Dans les cas où le problème est de type paramétrage, le service Optimisation envoie une équipe de techniciens sur la cellule impactée pour faire des mesures de puissance des TRX et de tilt (orientation des antennes). Lorsque c'est toute une zone qui est impactée, l'équipe fait des parcours en véhicule pour déceler les points défaillants de la zone à partir du logiciel Nemo. Un ticket peut être adressé au service BSS lorsque l'incident est matériel par exemple le changement de TRE, BTS, coupure sur le transcodeur, etc… Dans ce cas lorsque le service BSS n'arrive pas à résoudre le problème matériel. Il envoie une demande au près du constructeur. Il est envoyé au service transmission lorsque il y a des incidents sur le faisceau telque les CICs défaillants, le non trafique des TRX. Le ticket peut être envoyé à l'Optimisation radio lorsque l'incident est

⇒ un échec d'assignation du canal TCH; ⇒ un échec d'assignation du canal SDCCH; ⇒ une coupure du canal SDCCH; ⇒ une coupure sur le canal SDCCH; ⇒ une sur l'interface radio.

Lorsque le ticket est envoyé à l'entité concernée. Elle renseigne le ticket en mentionnant les actions menées puis le renvoie au responsable du ticket. Si l'entité qui reçoit le ticket n'arrive pas à résoudre le problème. Elle l'achemine à une autre entité compétente. Le ticket suit de cette manière son parcours jusqu'à ce que le problème soit résolu. Lorsque le problème est résolu le ticket est renvoyé à la QoS qui se charge de le valider. Ainsi la cellule qui était impactée est déclarée dans la rubrique Problèmes résolus.



77

CONCLUSION

Mon stage de fin d’études m’a permis de m’intégrer dans le monde complexe de la branche technique d’Orange Côte d’Ivoire, de découvrir ses processus de suivi qualité, et de travailler quotidiennement d’égal à égal avec des ingénieurs et techniciens de divers horizons. De plus, cette période a consolidé mes connaissances techniques dans le domaine de la téléphonie cellulaire : les rencontres fréquente avec les équipes de l’OMC-R (maintenance, gestion de la configuration, gestion des performances, Gestion des alarmes et des événements) m’ont permis de comprendre concrètement le rôle de chaque entité dans le réseau et les enjeux du suivi qualité. Après avoir intégré l’Unité Service Qualité du Département Qualité et Pilotage Global, j’ai participé activement au suivi qualité du réseau en traitant le warning et en remplissant le tableau de bord (tableau permettant de faire un suivi des actions créées par le warning). C’est donc une immersion totale dans le monde de la qualité de service du réseau qui m’a été offerte à travers ce stage. J’ai pu voir des actions concrètes sur des cellules de grande envergure et aux enjeux forts. Mais avant tout je pense avoir appris les bases du métier d’ingénieur suivi qualité, et bien identifié ses tenants et ses aboutissants. J’ai également acquis une connaissance plus grande du monde de l’entreprise et notamment l’attitude à adopter en entreprise et l’esprit de groupe de travail. Vu la croissante taille du réseau, ce document se propose comme un cahier de charge pour le développement d’une application unique. Cette application sera connectée aux outils RNO et NPA. Afin de traiter le warning sur plusieurs cellules en une requête. Connaissant les faiblesses des outils actuels de suivi qualité, je souhaiterai participer au développement de cette application.



78

ANNEXES ANNEXE 1

Correspondance entre BSC et points sémaphores .

POINT SEMAPHORE NUMERO BSC

3 2

7 6

14 San_Pedro

5 4

6 5

11 8

18 14

4 3

2 10

10 7

12 9

20 16

16 11

15 12

13 YAKRO

8 BKE

17 13

9 DALOA



79

ANNEXE 2 Cette partie de la rubrique accessibilité concerne la zone 900. C’est dans cette partie que seront mentionnées les cellules affectées d’incidents sous l’observation d’indicateur précis. Dans ce cas c’est l’indicateur SDCCH Fail. De façon analogue le traitement de warning de la rubrique accessibilité se fera par zone et par indicateur d’accessibilité (SDCCH Fail, SDCCH Drop, TCH Assignment Failure). C'est-à-dire pour chaque indicateur les cellules impactées d’incident seront déterminées. Ainsi nous aurons un warning ordonné et optimisé.

Figure 1: Nouveau format warning (zones 900\ rubrique accessibilité)



80

La rubrique suivante est celle de la continuité. Le suivi qualité de la continuité sur le réseau est assuré par l’observation de l’indicateur Call Drop. Tout comme pour la rubrique accessibilité le traitement se fera par zone et avec l’indicateur Call Drop.



81

Figure 2 : Nouveau format warning (zones 900\ rubrique continuité) La figure suivante est celle de la rubrique TRAFIC, seul les cellules ne trafiquant pas y sont mentionnées. Observons la figure suivante : Le troisième graphe représente le trafic sur les TRX. Nous constatons que les trois TRX ne trafiquent plus depuis le 27/07/2006 à 13 heures. Ce qui engendre un arrêt du trafic sur la cellule MACA-1. Alors la cellule MACA-1 sera mentionnée dans la rubrique TRAFIC.



82



83

Figure 3 : Nouveau format warning (zones 900\ rubrique trafic)



84

La suivante figure représente la rubrique TRX DEFECTUEUX. Nous déclarons les TRX défectueux précédant le nom de la cellule concernée.



85

Figure 4: Nouveau format warning (zones 900\ rubrique TRX défectueux) Cette avant dernière figure est la rubrique CICs DEFAILLANT. Par le biais de CIGALE nous déterminons les BSC présentant des MICs (Modulation par Impulsion et Codage).



86

Figure 5 : Nouveau format warning (zones 900\ rubrique CICs défaillants)



87

Enfin la dernière figure représente la rubrique NOMBRE D’INCIDENT. Cette rubrique ne fait pas en tant tel parti du warning. Nous l’avions intégré car il serait plus facile aux personnes traitant le warning d’y mentionner les nombres de problèmes résolus et non résolus. Cette rubrique à pour but de faciliter le renseignement du rapport hebdomadaire. La méthode actuelle consiste à attendre en fin de semaine pour comptabiliser les problèmes résolus et non résolus, ce processus est fastidieux. Afin d’optimiser le renseignement du rapport hebdomadaire concernant les problèmes résolus et non résolus. Nous avions proposé l’intégration de cette rubrique dans le fichier warning.



88 Figure 6 : Nouveau format warning (zones 900\ rubrique nombre d’incident)



89

ANNEXE 3: Image d’une BTS du constructeur ALCATEL utilisé par Orange Côte d’Ivoire sur ces sites. Figure 7 : Une BTS (Base Transceiver Station; Station de Base émetteur-récepteur)

Quatre TRE



90

Bibliographie :

• Xavier Lagrange, Philippe Godlewski, Sami Tabbane,”Réseaux GSM”, 5e

édition revue et augmentée”. • Alcatel University, ”Introduction to QUALITY OF SERVICE and TRAFFIC

LOAD MONITORING BSS release B8”. • Alcatel University, “2 GLOBAL INDICATORS” • A956 RNO User Guide,”O&M Documentation” • Alcatel TELECOM RESEAUX DE COMMUNICATION RADIOMOBILE

GSM/DCS



91

Glossaire AGCH:Access Grant Channel; Canal d’octroi d’accès AGIIR : Analyse et Gestion des Incidents et des Interventions sur le Réseau AUC : Authentication centre; centre d’authentification des abonnés d’un réseau GSM BCCH : Broadcast Control Channel ; Canal de commande de diffusion BSC : Base Station Controller ; Contrôleur de Station de Base BSS : Base Station Sub-system; Sous système de Station de Base BTS : Base Transceiver Station; Station de Base émetteur-récepteur CBCH : Cell Broadcast Channel; Canal sur lequel sont envoyé les messages broadcast CIGALE : Contrôle d’Interface Généralisée A partir de Lecture d’Enregistrement EIR : Equipment Identity Register, registre des identités des équipements FACCH : Fast Associated Channel; Canal de commande Associé rapide FCCH : Frequency correction Channel; Canal de correction de fréquence GS : Gestion de Sites GSM : Global System Mobile for communication; système Global de communication Mobile HO : Hand-Over LAPD : Link Access Protocol on the D Channel; Procédure d’Accès à Liaison sur le canal D.Protocol de liaison de données utilisé dans le RNIS LAPDm :Link Access Protocol on the Dm Channel; Procédure d’Accès à Liaison sur le canal D.Protocol De liaison de données utilisé sur les canaux radio de signalisation et les canaux de contrôle associés MAP : Mobile Application Part ; Protocole utilisateur, basé sur le SS7, qui gère les dialogues entre les équipements NSS MS : Mobile station; téléphone portable MSC : Mobile service Switching Centre ; Centre de commutation des Mobiles NMC (Network Management Centre), centre de supervision du réseau NPA : Network Optimisation Analyser ; Optimisation du réseau radio (outil de gestion de réseau) NSS : Network Station Sub-system; Sous Système radio OMC:Operation and Maintenance ; Centre d’administration OMC-R: Operation and Maintenance Centre-Radio; Centre d’administration Radio OMC-S: Operation and Maintenance Centre-Switch; Centre d’administration-Réseau OSS:Operating Support Sub-system; sous système d’administration PCH : Paging Channel ; canal logique GSM supportant l’ensemble des appels en diffusion PCM (MIC) : Pulse Code Modulation (Modulation Par Impulsion et Codage) QoS : Quality of Service; Qualité de Service QPG:Qualité et Pilotage Globale RACH : Random Access Channel ; canal d’accès aléatoire RNO : Radio Network Optimisation; Optimisation du réseau radio (outil de gestion du réseau) RTCP/PSTN : Réseau Téléphonique Public Commuté/Public Switcher Téléphone Network SACCH: Slow Associated Control Channel ; Canal de commande associé lent SDCCH: Stand-alone Dedicated Control Channel SRES : Signed Reponse ; résultat de l’authentification



92

SS7 :signalisation sémaphore n°7,système de signalisa tion normalisé par l’UIT où une voie particulière est utilisée pour transporter la signalisation se rapportant à un ensemble de circuits ou indépendante de tout circuit TCH : Traffic Channel ; Canal de Trafic TCOUP/ (Taux de Coupures en Communication) TCU : Transcodeur Unit; Transcodeur TDMA : Time Division Multiple Access ; Accès Multiple par répartition dans le Temps TIR : Taux d’inaccessibilité radio TRE: Transceiver Equipement TRX : Transceiver ; Emetteur-Recepteur UIT : Union Internationale des Télécommunications

Cissouma

Documents

Transcript of Cissouma